We read every Keycloak advisory batch and publish the version table within 72 hours

Keycloak

9 Sept

When Keycloak publishes a batch of security advisories, the question that decides your week is narrow: did my minor line get a patch, or is my remediation the major upgrade I have been deferring?

That question cannot be answered in advance. 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 ahead of time.

Batch size does not predict coverage

Three consecutive rounds, read from the advisory records themselves:

Published	Advisories	Minor lines patched
2026-05-19	11	26.6.3 — plus 26.4.12, for exactly one of the eleven
2026-05-28	8	26.6.4 — one line
2026-08-18	1, critical	26.4.15, 26.6.6, 26.7.2 — three lines

Eleven advisories in May moved essentially one line. A single critical advisory in August moved three. Severity drives it, which is exactly what the policy says.

Coverage is not uniform inside a round, either. Of the eleven 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 the answer exists only once the batch lands — and once it lands, you are reading twenty advisory pages to build a table before you can start the work.

What the list does

When Keycloak publishes an advisory batch, one email goes out within 72 hours. It carries:

every advisory in the batch, with a link to each advisory page
the patched versions that shipped, per maintained minor line, as a table
the highest patched version on each line — and where an advisory lists no patch for a line, the fact that it does not
what we have seen break on the upgrade path there, and the rehearsal it came from

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

That is typically one or two emails a month. Keycloak sets the cadence, not us — the list does not send because we have something to say.

What sits behind the breakage claims

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

If you want a worked example before subscribing, start with the one where DDL rights were not the problem — a migration that failed with must be owner of index while the connecting role demonstrably had CREATE.