Correction, 2026-10-14, issued after one day of circulation: two claims below are wrong. "The GitHub release page's entire body of text is one line" — the quoted sentence is the tag's commit message; it appears nowhere in the release body. And "the tag carries fixes for three CVEs" — the release body's Security fixes list carries twenty CVE identifiers, fifteen of them Keycloak-native fixes that this post never mentioned, plus fifteen disclosed "Weaknesses" that carry no CVE numbers. The tag-level verification this post describes (the three fix locations, the 119-line upgrading guide, the six behavior changes) holds. The full map, and the method note on how the mistake happened, are in the correction.

At 08:58 UTC this morning the Keycloak project shipped 26.8.1, a patch release on the 26.8 line, twelve days after 26.8.0. The GitHub release page's entire body of text is one line: "Set version to 26.8.1." Then SHA-256 checksums for the tarballs. At publish time — roughly an hour and a half later — the project blog's newest entry was still October 1's 26.8.0; if a 26.8.1 post has appeared by the time you read this, read it. The tag does not move, however, and every claim below was verified against the tag.

Last week this site's post on the 26.7.5/26.8.0 batch ended by telling operators to diff tags, because the two release notes each described only their own half of the story. 26.8.1 is the first release in this site's covering of the project where the release notes are not incomplete — they are absent. The complete operator-facing description of the release is docs/documentation/upgrading/topics/changes/changes-26_8_1.adoc, a new 119-line file that exists only inside the tag: discoverable by diffing, or by nothing.

The three CVEs the release page does not mention

CVE-2026-107121 — SMTP "encryption" could be negotiated away. Published by NVD on October 7, six days before the fix shipped: moderate, 6.5, CWE-319, Red Hat Bugzilla 2547296. When a realm's SMTP configuration had Enable StartTLS on, Keycloak set only JavaMail's opportunistic property. Opportunistic means what it says: an attacker on the network path could strip the STARTTLS advertisement — or the server could simply never support it — and Keycloak would proceed anyway, sending the SMTP password and every message body, including password-reset mail and account invitations, in cleartext. The fix, in services/src/main/java/org/keycloak/email/DefaultEmailSenderProvider.java, is one added property after the existing one:

props.setProperty("mail.smtp.starttls.enable", "true"); // Prevent STARTTLS downgrade: fail if the server does not advertise STARTTLS props.setProperty("mail.smtp.starttls.required", "true");

One line. But it changes behavior in a way that will page an operator: delivery now fails hard if the connection cannot actually upgrade. Community deployments live on password-reset mail; this is the change most likely to be the first thing you notice after upgrading.

CVE-2026-15943 — a delegated identity-provider manager could redirect the IdP's client secret. Published by NVD on July 17 — twelve weeks before this release shipped a fix: moderate, 5.5, CWE-1288, Red Hat Bugzilla 2501270. The Admin API masks IdP client secrets as asterisks; reading an IdP and writing it back was a normal round trip. But the masked sentinel was always interpreted as "keep the stored secret," with no check on whether the request had also changed where that secret gets sent. An account holding only manage-identity-providers could point the IdP's token endpoint at a server it controlled and Keycloak would deliver the real client secret there — the credential that exchanges user tokens with, say, your Nextcloud. This is the same delegation boundary this site documented twice before — the IdP mapper escalation (CVE-2026-12388) and the password-reset path — in yet another position. Delegated administration is where Keycloak keeps finding holes, and in community infrastructure it is the part you use most, because it is what makes volunteer division of labor possible. The fix rejects the update with HTTP 400 when the secret's destination fields change (clientId, clientAuthMethod, tokenUrl, tokenIntrospectionUrl, baseUrl, tenantId for Microsoft, sandbox for PayPal) unless the real secret is resubmitted; the providerId is now immutable; vault-expression secrets are unaffected. The guard code (IdentityProviderModel#canReuseMaskedClientSecret, getClientSecretDestinationConfigKeys) is new in this tag — verified present as an addition in the 26.8.0...26.8.1 diff.

CVE-2026-18569 — forged backchannel-logout tokens. Published by NVD on August 4: low, 3.7, CWE-347, Red Hat Bugzilla 2509755. The affected configuration is an OIDC identity provider with Validate Signatures switched off. In exactly that configuration, Keycloak accepted logout tokens with no signature at all — alg=none — and acted on them; per the advisory, an attacker who knows certain technical details about a user's session could force that user's session to end. The score is low because it needs a misconfiguration. The context matters: the OIDC Back-Channel Logout 1.0 specification has always required signed logout tokens and prohibited alg=none; "Validate Signatures: OFF" on a brokered IdP is a common staging shortcut that survives into production more often than anyone admits. The fix removes the option. Backchannel logout tokens are now signature-validated unconditionally, regardless of the IdP's setting — new code in OIDCIdentityProvider.validateLogoutToken this tag, which warns the operator by log line that a JWKS URL or static validating key must be configured.

Put the dates together: July 17, August 4, October 7. After the first of these identifiers was public, Keycloak shipped six releases — 26.7.1 (Aug 5), 26.7.2 (Aug 19), 26.7.3 (Aug 31), 26.7.4 (Sep 16), 26.7.5 (Sep 30), 26.8.0 (Oct 1). Their release notes list 7, 8, 20, 6, 14, and 6 CVEs respectively — 61 identifiers — and none of the three above appears in any of them. None of those tags contains any of the three fixes: at 26.8.0 they are verifiably absent at code level (the SMTP property, the logout-token validator, and the secret-destination guard all appear as additions in the tag diff), and the last 26.7 line release, 26.7.5, is the four-week-old batch this site covered October 8, with no point release since. Every advisory in the batch reads the same as every advisory in the last three batches: affected versions: Unknown, patched versions: Unknown. A scanner driven by the advisory feeds sees nothing here.

The other changes a release note would have highlighted

The 119-line guide is divided into six Breaking changes — the three CVE fixes above plus three X.509 hardening items — and four Notable changes. All are behavior changes, not maintenance:

  • X.509 authenticators validate key usage and extended key usage regardless of the certificate's critical flag. Previously validation only ran when the extension was marked critical. A legacy opt-out flag exists.
  • X.509 CRL files must resolve inside the server's conf directory. CRL Path and file-based distribution points no longer chase arbitrary filesystem paths.
  • CRL and OCSP responses fetched over HTTP are size-capped (10 MB default, provider option) — a quiet denial-of-service door closed.
  • Kerberos username/password authentication performs a local service-ticket round trip — a TGS-REQ/TGS-REP validated against the local keytab — so authenticating against a wrong or rogue KDC no longer succeeds on its own.
  • A SAML client's registration access token no longer works against the OpenID Connect registration endpoint (and vice versa) — cross-protocol client-registration use now returns invalid_client, as reads already did.
  • Semicolons are no longer query parameter delimiters. Previously /path?a=1;b=2 parsed as two parameters — and, the guide notes, different server layers applied the rule inconsistently, so the parameters a request was processed with could differ from the ones its signature was verified with. That divergence is request-smuggling adjacent; now the semicolon is a literal everywhere.
  • Header-based OTP skip and force rules require a trusted proxy. SKIP_OTP_FOR_HTTP_HEADER now verifies both that --proxy-headers is configured and that the request arrived through a genuinely trusted proxy; otherwise the skip rule is ignored. The safe direction — users get more OTP prompts, never fewer — but a community help desk will hear about it.

What to actually do

  1. On 26.8.0: upgrade to 26.8.1. Last week's version map said 26.8.0 was the endpoint; it held until 08:58 UTC this morning. Everything the October 8 post and the 26.8 configuration post asked you to check stands, unchanged, and gets this batch on top.
  2. On 26.7.x at any level: the endpoint is no longer reachable from where you stand. No released 26.7 tag carries any of these three fixes, and as of publish time no 26.7.6 exists. Jump to 26.8.1; it is verified to subsume everything the 26.7 line shipped.
  3. Test SMTP delivery in staging before you roll. Confirm your mail server actually upgrades the connection when asked. If you intentionally run plaintext SMTP, disable Enable StartTLS explicitly — do not leave the setting on and let the upgrade fail you mid-morning.
  4. If you broker OIDC IdPs that use backchannel logout and had signature validation off: fix the trust configuration first. Set Use JWKS URL with the provider's JWKS endpoint, or paste the provider's public key into the validating-key field. Do that before the upgrade, or logout propagation stops working on upgrade instead of after patching.
  5. Audit IdP automation. Scripts or infrastructure-as-code that read an IdP, change one of the destination fields, and write it back — the guide names the kcadm.sh pattern (update identity-provider/instances/<alias> -s config.tokenUrl=...) — now answer 400 until the real secret is resubmitted.
  6. CRL file paths: move them inside conf/ and set the CRL Path relative to that directory.
  7. Clients that rely on semicolons in URLs: switch to ampersands or expect the parameter to stop splitting.
  8. Red Hat Build of Keycloak: track errata. The NVD rows for this batch name no fixed-in-product versions — they name no versions at all.

Closing

Two of these three CVE identifiers were public before this site's Keycloak coverage started in early August. The project's security policy allows moderate findings to wait for the following minor, and the release notes of the six releases that shipped in the meantime correctly list only their own tags. But nowhere in the system is there a row that says "these three identifiers are open, and this is the release that will close them" — the advisory feeds say Unknown, the release notes are silent, and the release page that finally carries the fixes says "Set version to 26.8.1."

Credit where it is due, because the record is mixed rather than bad: the 119-line upgrading guide is precise, carries migration commands, documents an opt-out for every breaking change, and the same tag adds .cveignore.yaml — a file where upstream now writes structured "not affected" statements (two bootstrap CVEs; the JavaScript component is not distributed). The disclosure machinery is being maintained. Just not on the one surface every operator's feed, scanner, and Monday-morning triage actually reads.

Six Keycloak releases in a row now, this site has had to read the tag because the release page did not fully describe the release. This morning's is the first that does not describe it at all. The diff takes minutes and produces every fact above. Run the diff; skip the RSS feed.

Sources: Keycloak 26.8.1 release tag (body: "Set version to 26.8.1", 2026-10-13 08:58 UTC); upstream tag diff 26.8.0...26.8.1 — file-level comparisons in DefaultEmailSenderProvider.java (STARTTLS required one-liner), OIDCIdentityProvider.java/IdentityBrokerService (logout-token validator + signed-JWE unwrap), IdentityProviderModel.java/OAuth2IdentityProviderConfig.java (secret-destination guard), Kerberos providers (service-ticket round trip and disableKerberosAuthenticationRoundTrip), .cveignore.yaml; docs/documentation/upgrading/topics/changes/changes-26_8_1.adoc (119 lines, new file in the tag); CVE-2026-107121 advisory / Bugzilla 2547296; CVE-2026-15943 advisory / Bugzilla 2501270; CVE-2026-18569 advisory / Bugzilla 2509755; Keycloak 26.8.0 release notes (six-CVE list checked against these identifiers); Keycloak security policy.