The Keycloak Upgrade Ledger

Every upgrade we have rehearsed, with the environment stated and the clock running.

You're on the list

Nothing else arrives until Keycloak publishes a security advisory batch. That could be tomorrow or six weeks out. Keycloak sets the cadence, and it works out to one or two emails a month.

What arrives, and when

When Keycloak publishes a security advisory batch, you get one email within 72 hours. It carries four things:

For each new Keycloak major, a breaking-change writeup from upgrades we actually ran.

Why 72 hours, and why a table

Keycloak's own policy ties the fix target to severity:

"Depending on the severity of a vulnerability, the issue may be fixed in the current major.minor release of Keycloak, or for lower severity vulnerabilities or hardening in the following major.minor release."

keycloak.org/security, retrieved 2026-09-06

Which lines that works out to is decided per batch and announced nowhere in advance. Three consecutive rounds, taken from the advisory records themselves:

PublishedAdvisoriesMinor lines patched
2026-05-191126.6.3 — plus 26.4.12, for exactly one of the eleven
2026-05-28826.6.4 — one line
2026-08-181, critical26.4.15, 26.6.6, 26.7.2 — three lines

Batch size does not predict coverage. Eleven advisories in May moved essentially one line. A single critical advisory in August moved three. Severity drives it, which is what the policy says and what nobody can act on in advance.

Coverage is not uniform inside a round either. Of the eleven advisories on 2026-05-19, ten shipped a 26.6 patch, one of those also shipped 26.4, and one shipped no patched version at all. On 2026-05-28, two of the eight shipped none.

So "does my line have a patch, or is my remediation the major upgrade I have been deferring" is a question you cannot answer until the batch lands, and once it lands you are on a clock. Answering it takes reading every advisory and building the table. That is the work this list does, inside 72 hours, so you can start the upgrade instead of the research.

What sits behind the breakage claims

Every "this breaks" line traces to an upgrade we ran in our own lab, and the run is published: ledger.mlabs.city — each rehearsal with its version pair, the dataset size, the database engine, the condition it ran under, and what broke. They are our own environments, so nothing is redacted to protect a customer.

The rules we hold ourselves to, and that you should hold us to:

  1. Every CVE reference is verified against the advisory page. We never paraphrase one from memory. Where the advisory API's version field contradicts the page it belongs to, the page wins, and we say which we used.
  2. Every breaking-change claim comes from a rehearsal we ran, with the versions stated.
  3. Anything we have not verified ourselves goes out labelled as such, with a link and a date.
  4. Corrections appear in the next issue, prominently. We treat the correction record as part of what you subscribed to.
  5. We never write that a named organisation is vulnerable. Classes of exposure, never your posture.

Where we have not rehearsed a hop you would have to make, the issue says so in a sentence rather than guessing. An admitted gap is what makes the rest worth reading.

The mechanics

Double opt-in, which is the click that got you here. The issues carry no tracking pixels and no click tracking. Links do carry a campaign parameter that identifies the issue, not you, and it is how we tell whether an issue was worth writing. Every issue goes into a public archive. Unsubscribe is one click and nothing follows it.

An issue carries advisories, patched versions and what broke in rehearsal. This line is the whole of the exception: MLabs runs Keycloak and identity infrastructure upgrades for a living, which is why the lab exists at all. Replies reach a person.

The first issue arrives when Keycloak publishes.