astropod Contact Us sign in

Keycloak Account Takeover Flaw

28 Aug 2026 · Chris vulnerability-intelligencesoftware-supply-chain-securitykeycloakidentity-and-access-managementoci-containersmaven

Published on gastropod.io on 08-28-2026

Critical Keycloak Account Takeover Flaw Shipped With an Advisory That Lists No Affected Versions

Tags: vulnerability-intelligence, software-supply-chain-security, keycloak, identity-and-access-management, oci-containers, maven

Red Hat published four errata on August 18 and the Keycloak project released 26.7.2 on August 19 to fix CVE-2026-18963, an unauthenticated account takeover in the reset-credentials flow.

Red Hat rates it 9.1 and classifies it as CWE-640, a weak password recovery mechanism. An attacker needs a username or an email address and network access to the login endpoints. That's it. Nothing else.

The attacker sends a crafted request to the reset-credentials endpoint. The authentication session advances directly to the password update phase, skipping the action token that Keycloak normally emails to the account owner. The attacker then sets a new password on the target account.

Red Hat's advisory names improper state validation within the reset-credentials flow as the root cause, and confirms that....

"administrative accounts are reachable the same way as any other."!!!

Exploitation requires the realm to have the "Forgot password" feature enabled, which is where a self-service reset flow normally lives.

Keycloak fronts the login for everything behind it. An administrator account on the identity provider is a path into every application that trusts it, which is the same escalation pattern as the Metabase endpoint that granted full admin, which I have already covered here.

The advisory carries no bad package information to coordinate against

The GitHub Advisory Database record, GHSA-4gv3-mc9p-5wqc, reads as follows:

  • Package: no package listed
  • Affected versions: unknown
  • Patched versions: unknown
  • Status: unreviewed

GitHub states on the record that Dependabot alerts are not supported for it, because the advisory has no package from a supported ecosystem with an affected and fixed version. Any tool that matches advisories against declared dependency versions returns nothing for CVE-2026-18963. The severity is critical, the CVSS vector is fully unauthenticated and remote, and the automated correlation path produces zero findings. This is the same reporting gap as the OpenSSL HollowByte flaw that scanners miss, which I have already covered here.

The fixed builds are also split across four numbering schemes:

  • Upstream Keycloak: 26.7.2
  • Red Hat build of Keycloak 26.4: operator bundle 26.4.15-1, and the rhbk/keycloak-rhel9 and rhbk/keycloak-rhel9-operator images at tag 26.4-23
  • Red Hat build of Keycloak 26.6: operator bundle 26.6.6-1, and the keycloak-rhel9 and operator containers at tag 26.6-12
  • Red Hat errata: RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523, RHSA-2026:56524

A team running the container tag 26.6 has no version number to compare against anything. Container tags are mutable pointers, so 26.6 resolved to one digest before August 18 and a different digest after. The question that determines exposure is which digest each cluster actually pulled, and on what date.

Your application teams can use Keycloak in at least five forms: an OCI container image, an operator bundle from a registry, a Helm chart, the Maven artifacts under org.keycloak for client and adapter code, and RPM packages on the Red Hat side. Different teams inside the same organization might even pick different forms, and the advisory names none of them.

Finding it without a version range

Red Hat's temporary mitigation is to turn off "Forgot password" under Realm settings, then Login, in every realm. That removes self-service password recovery for legitimate users until an upgrade is ready and implemented to fix this.

How does gastropod.io handle things like this?

Well I'm glad you asked! Gastropod identifies every artifact by PURL and sha256 digest at the moment it proxies the pull, so a keycloak-rhel9:26.6 pull is recorded as the exact digest the registry served, not as the tag the client asked for. The per-pull access spine records who pulled it, from which client and source IP, and when, which is how you list the clusters and build jobs that took a pre-August-18 digest during the exposure window. The blast-radius graph covers the Maven side of the same problem: services that pull org.keycloak artifacts transitively, through an internal auth library nobody re-reviews, appear as dependents of that artifact version rather than as a manual survey of who might be using Keycloak.

OSV correlation does not help with this specific CVE, because the OSV and GHSA records carry no package and no version range to correlate against. The digest inventory and the pull history answer it instead. Once the fixed digests are known, a block rule at intake stops the superseded ones from entering new builds while the upgrade proceeds, and a CycloneDX SBOM per consumer gives auditors the artifact list without a separate collection effort... it's just there ready to download.

If you cannot list every cluster, build job, and service that pulled a Keycloak artifact in the last thirty days, and the exact digest each one received, the next advisory with an empty version range causes the same scramble. The product page covers how the identity and audit layer works, or you can point a client at it and check your own artifacts at app.gastropod.io/start.

Sources

← news