This is an account-takeover vulnerability at the identity boundary: a successful attacker can sign in as a federated user and inherit that user’s roles and access. It warrants immediate review and a defined patch or containment decision, even though Red Hat currently has no erratum for its affected supported builds.
Start with the real exposure, not every Keycloak server. Identify realms, which are Keycloak’s isolated authentication and configuration spaces, where Keycloak brokers authentication from a SAML identity provider through the HTTP-Redirect binding, a method of carrying SAML messages in a browser redirect. Those are the login paths implicated by this vulnerability. Red Hat currently marks both its standalone component and RHEL 9 container image as affected, with no erratum, or vendor-issued fix advisory, yet listed for this CVE. (github.com)
At a glance: CVE-2026-117691 has a Common Vulnerability Scoring System (CVSS) 3.1 score of 9.1. It is network-reachable, requires no privileges or user interaction, and has high confidentiality and integrity impact. Red Hat rates the product impact as Important, despite the critical CVSS score. Don’t let that classification difference obscure the operational reality: this is an authentication bypass at an identity boundary. (access.redhat.com)
Risk in plain English: a trusted login can be turned into an untrusted one
In this setup, the identity provider (IdP) authenticates the person and Keycloak brokers that identity to local accounts and applications. The SAML message signature is the assurance that an identity claim came from the configured IdP and wasn’t altered along the way.
According to Red Hat, Keycloak’s SAML HTTP-Redirect implementation handles percent-encoded parameter names differently from the signature-verification logic. Keycloak can interpret a parameter name after decoding it while the verification path looks only for its literal form. That mismatch can lead Keycloak to process an unsigned SAML message after validating a different, signed message. (access.redhat.com)
That is an account-takeover issue, not merely a SAML parsing defect. Red Hat says successful exploitation allows login as any federated user, with that user’s roles and data. The public Bugzilla record adds an important condition: an attacker needs access to their own account at the external IdP to obtain a valid signed redirect-binding message. They don’t need administrator credentials, and that condition doesn’t make the flaw low risk. It does mean exposure depends on the affected federation flow being in use and on who can reach it. (bugzilla.redhat.com)
What is confirmed — and what is not
Confirmed: Red Hat published CVE-2026-117691 on 5 November 2026. Red Hat build of Keycloak and the rhbk/keycloak-rhel9 image are marked affected. Red Hat Single Sign-On 7 is marked not affected because the vulnerable code is not present. The vendor says there is currently no mitigation that meets its criteria for practical deployment and stability. (access.redhat.com)
Confirmed for upstream Keycloak: Keycloak’s issue tracker assigns the fix to releases 26.4.18, 26.6.9 and 26.8.2. Of those, 26.8.2 is demonstrably released and lists CVE-2026-117691 among its security fixes. The 26.4.18 and 26.6.9 labels are release targets in the upstream tracker, not proof that those releases were available at the time of writing. (github.com)
Not confirmed: Neither Red Hat’s advisory nor the upstream advisory publishes a complete affected-version range or a Red Hat fixed build. Don’t assume a Red Hat build is safe because its version number is close to an upstream fixed version; Red Hat packages and supports its own release streams. Equally, a Red Hat-supported team shouldn’t simply replace its product with a community build without a proper support and change decision.
Known exploitation: The official advisories reviewed for this article do not report exploitation in the wild, and the CVE is not currently listed in CISA’s Known Exploited Vulnerabilities catalogue. Useful context, but not a reason to defer action. The flaw was publicly disclosed alongside upstream patch information, and identity-bypass defects become more attractive once fixes reveal the shape of the problem. (access.redhat.com)
Priority actions for the next working day
- Inventory the actual exposure. Identify Keycloak realms configured with SAML identity providers and establish whether they accept SAML HTTP-Redirect messages. Include externally reachable broker endpoints, not just the main administration console.
- Separate community and Red Hat-supported estates. Community Keycloak users should plan an urgent upgrade to 26.8.2, with normal pre-production validation. Red Hat build of Keycloak users should open the CVE record, subscribe to errata notifications, and prepare a maintenance change now rather than beginning that work when an update appears.
- Check versions against the source, not a scanner label alone. Red Hat commonly backports fixes, so a package-version-only scanner can be misleading once an erratum is issued. Until then, the official Red Hat record says its listed builds are affected.
- Review federated login activity from 5 November 2026 onwards. Compare Keycloak login events, reverse-proxy access records and IdP authentication logs. Look for successful brokered logins without a matching IdP authentication event, unfamiliar source networks, unusual IdP aliases, abrupt role-sensitive application access, or privilege changes following a federated session.
- Preserve evidence before it ages out. Ensure the relevant Keycloak event stream, proxy logs and IdP audit records are retained. Raw SAML-bearing URLs can contain sensitive material, so tightly control access to those records and handle retention deliberately.
- Have a containment decision ready. If a suspected malicious federated login is found, investigate the account’s application activity, revoke Keycloak sessions and tokens as appropriate, and consider disabling the affected federation connection pending incident response. Resetting a password alone doesn’t undo access already granted through an active single-sign-on session.
Do not confuse exposure reduction with a vendor mitigation
There are sensible temporary risk-reduction measures, but they aren’t a substitute for a corrected Keycloak build. Restricting network access to a broker endpoint can reduce the pool of potential attackers. Temporarily disabling a SAML federation connection can remove the vulnerable flow, but may also remove workforce or customer login. Those are business-continuity decisions, not clean technical fixes.
Be especially wary of improvised proxy rewriting or web application firewall rules intended to normalise encoded query parameters. This vulnerability sits at the integrity boundary around signed protocol data. Altering requests in transit can create interoperability problems, interfere with signature validation, or create false confidence. Red Hat’s explicit position is that no available mitigation currently meets its normal deployment and stability criteria. (access.redhat.com)
For organisations in Jersey, Guernsey and the wider UK using Keycloak as a shared entry point for staff, partners or public-facing services, that distinction matters. A small identity platform can have a large blast radius if it fronts finance, case-management, customer or operational systems. The immediate task isn’t a broad security-control review. Establish whether a vulnerable SAML broker path exists, then get the accountable service owner, identity team and application owners aligned on a patch or containment window.
Identity-centred recovery planning applies here too: authentication systems need the same restoration discipline as the applications they protect. A federated account takeover can look quiet and legitimate long before it resembles a conventional endpoint incident.
Residual risk: patching closes the flaw, not necessarily the incident
An upgrade to a fixed release stops this particular signature-validation bypass. It doesn’t establish that nobody used it before the maintenance window, and it doesn’t revoke sessions, tokens or changes made by a compromised federated account. Where there is evidence of suspicious activity, treat identity logs, high-value application audit trails and role assignments as incident-response evidence.
The decision is straightforward. There is no confirmed public exploitation at present, and the exploit path depends on a specific SAML federation design. Where that design exists, however, the consequence is severe: an attacker may be able to become a legitimate-looking user without that user authenticating. For community Keycloak, 26.8.2 is the available fixed destination. For Red Hat build of Keycloak, the urgent work is exposure mapping, detection review and readiness to install the vendor’s forthcoming erratum as soon as it is published.
Spot an error?
If something factual looks wrong, outdated or misleading, flag it here. Corrections are reviewed separately from normal article comments and reader questions.