Keycloak CVE-2026-117691: SAML Signature Bypass Enables Federated Account Takeover

Keycloak CVE-2026-117691 allows an attacker to bypass SAML HTTP-Redirect signature verification and impersonate federated users. The community fix is Keycloak 26.8.2 or later, released on November 5, 2026. Organizations using Keycloak as an identity broker should identify affected deployments and obtain evidence that their identity-service suppliers have addressed the flaw. [1][2][3]

Red Hat and the CVE record displayed on its portal assign a CVSS v3.1 score of 9.1. GitHub's advisory labels the issue Critical, while Red Hat's product-security impact label is Important. These classifications should not be conflated. The practical exposure is serious: successful exploitation permits full takeover of federated users, including unauthorized access to their roles and data. [2][3]

This is a prepare-now advisory, not a report of confirmed attacks. CERT Santé's November 6 notice marks active exploitation as not observed and reports that an open-source proof of concept exists. CVE-2026-117691 is not in CISA's Known Exploited Vulnerabilities catalog (catalogVersion 2026.11.04, checked 6 November 2026). Neither a public proof of concept nor a CVSS score of 9.1 establishes exploitation in the wild. [4][6]

Technical Information

The vulnerability is an inconsistency between two interpretations of the same SAML HTTP-Redirect request. Keycloak decodes percent-encoded parameter names during message processing, but its signature-verification logic recognizes only literal parameter names when reading the raw query. A parameter name such as %53AMLResponse can therefore be treated differently by these two stages. Red Hat classifies the weakness as CWE-347: Improper Verification of Cryptographic Signature. [2][5]

The result is a verification-to-processing mismatch: a legitimate signed message can satisfy the signature check while a different, crafted unsigned message is processed. The signed data and the data trusted for authentication are no longer necessarily the same. Red Hat describes the consequence as full account takeover of federated users; its release issue describes broker login as any user. This is not merely a failed signature check or an authentication-service availability issue. [1][2][5]

An important prerequisite limits how the attack should be described. Red Hat's Bugzilla report and CERT Santé state that the attacker needs their own account at the external identity provider to obtain a legitimately signed redirect-binding message, such as a logout response. The published CVSS vector nevertheless records no privileges required on the vulnerable target. Reporting the external-IdP prerequisite alongside that vector avoids implying that no account or signed-message access is needed anywhere. [4][5]

The published vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N: network-reachable attack, low complexity, no target privileges or user interaction, unchanged scope, and confidentiality and integrity impacts of C:H/I:H, with no availability impact (A:N) in the score. This advisory does not infer remote code execution or universal exposure of every Keycloak configuration from that score. Exposure assessment should focus on affected SAML identity-brokering deployments and HTTP-Redirect use. [2][3]

Affected Product Versions

The community release notice is dated November 5 and explicitly includes issue #54714 for CVE-2026-117691. The older-branch migration guidance comes from CERT Santé, not from an invented vendor backport schedule. A community fixed-version number is not evidence that a supported RHBK package has been remediated. Product owners should retain the precise product, package, image and fix reference in their exposure record. [1][2][4]

Workaround and Mitigation

Community deployments: plan and validate an upgrade to Keycloak 26.8.2 or later. The release page directs administrators to the migration guide before upgrading. Include identity-broker login, logout and dependent application access in normal change validation; avoid treating a version change alone as proof that the running deployment has been replaced. For 26.7, 26.6 and 26.4, the reviewed guidance is migration to the fixed branch, not waiting for an unannounced backport. [1][4]

RHBK deployments: Red Hat still lists the relevant packages as Affected in the checked data, and CERT Santé reports no published erratum. Obtain supported remediation guidance from Red Hat and track the product-specific advisory when issued. Do not substitute a community image or declare RHBK fixed solely because upstream 26.8.2 exists. [2][4]

Workarounds: Red Hat states that mitigation is either unavailable or does not meet its criteria for ease of deployment, broad applicability or stability. CERT Santé likewise lists no workaround. This advisory therefore does not present a proxy rule, parameter filter, binding change or generic access control as a validated fix. Any interim restriction on IdP or broker endpoints should be assessed by the service owner for operational impact and residual exposure; it is not equivalent to a vendor-confirmed remediation. [2][4]

As an operational recommendation, inventory the identity brokers behind business-critical applications, identify their product and running version, and assign a remediation owner. Record whether the SAML HTTP-Redirect path is actually used. Validate changes through approved administrative checks and normal authentication testing, not by reproducing a public exploit against production services.

Indicators of Compromise

No validated campaign-specific indicators of compromise were provided in the reviewed primary sources. They do not identify malicious IP addresses, domains, file hashes, confirmed victims or a named threat actor for this vulnerability. The availability of a public proof of concept does not supply those missing facts. [2][4][5]

For defensive review, preserve relevant broker authentication events, IdP events and available HTTP request logs. Investigate unusual federated-user activity or inconsistencies between the expected identity flow and resulting sessions. Percent-encoded SAML parameter names can be a triage lead when raw requests are available, but their presence alone is not proof of compromise. Logging may normalize request parameters; a clean search is therefore not proof that exploitation was impossible. These are analyst recommendations, not vendor-validated detection signatures.

Third-Party Risk: What to Ask Identity-Service Vendors Today

A supplier can place this flaw in a customer's authentication chain even when the customer does not operate Keycloak directly. Prioritize vendors and SaaS providers that broker identity through Keycloak SAML, including community and Red Hat builds. Assess the actual federation configuration rather than assuming all SSO services or all Keycloak users are exposed.

Request four concrete answers:

• Product and version: Is the service running community Keycloak or RHBK, and which exact version, package or image is deployed?
• Binding exposure: Is SAML HTTP-Redirect enabled or used in the broker flow serving your organization?
• Fix evidence: For community deployments, provide evidence that the running service was upgraded to 26.8.2 or later. For RHBK, provide the applicable Red Hat fix or erratum and deployment evidence when available; an upstream version claim is not sufficient.
• Compensating controls: What restrictions protect IdP and broker endpoints while remediation is pending, who approved them, and what residual risk remains?

Treat an upgrade plan as pending work until deployment evidence is available. If a provider says it is unaffected, request its product and configuration basis. Keep unsupported assertions, interim restrictions and completed remediation separate in the vendor record.

Sources

1. Keycloak: 26.8.2 released, November 5, 2026
2. Red Hat: CVE-2026-117691
3. GitHub Advisory Database: GHSA-c85j-3hq2-q6wj — Critical; unreviewed advisory record.
4. CERT Santé: Red Hat — CVE-2026-117691, November 6, 2026
5. Red Hat Bugzilla: 2561977
6. CISA vulnerability catalog JSON feed — checked 6 November 2026; catalogVersion 2026.11.04.

Need help working through identity-service suppliers exposed to CVE-2026-117691? Our team can help you prioritize them and track their answers. Talk to an expert