Red Hat build of Keycloak · Public exploit code

PoC exploits JWT algorithm confusion in Red Hat Keycloak

Nov 10, 2026 · 1 min read

The flaw allows attackers with valid client credentials to bypass signature verification in the JWT Authorization Grant flow. A PoC has been discovered, but the item does not identify a fixed version.

By HIFY Radar newsroom Updated 11/10/2026 03:52 PM Get this every day →← Back to the feed 1 source

HighVulnerabilityPublic exploit codeFix unconfirmed

In 30 seconds

Alleged

A public post reports that a proof of concept has surfaced for CVE-2026-11800, a claimed Keycloak JWT algorithm-confusion flaw. The described attack requires valid client credentials and could produce unauthorized access tokens, but this evidence batch does not establish successful attacks or identify a fixed version.

What happened

Alleged

According to ptdbugs, the issue affects the JWT Authorization Grant flow. An attacker who already has valid client credentials could allegedly forge an assertion, bypass signature verification and obtain tokens impersonating a federated user connected to the affected identity provider.

Why it matters

Alleged

If the report is accurate, the weakness crosses an important trust boundary: credentials for one client could become a path to tokens for other identities. That could expose applications relying on Keycloak authentication and, depending on the impersonated user's permissions, lead to privilege escalation.

What to do

Inferred

Teams using Red Hat builds of Keycloak should inventory deployments, identify use of the JWT Authorization Grant flow, tightly protect client credentials and watch for unexpected token issuance or federated-user impersonation. Because the batch contains no authoritative remediation details, operators should obtain Red Hat's guidance and verify a fixed release before treating an upgrade target as definitive.

Confirmed and still uncertain

Observed

The supplied material names valid client credentials as a prerequisite and lists Red Hat build of Keycloak 26.6 and 26.6.4 among the products. It does not show the exploit code, independent reproduction, required configuration, real-world exploitation, severity score or a fixed version.

What people are saying

Observed

The ptdbugs account says a PoC or exploit was discovered and attributes the vulnerability to Red Hat Keycloak products. It further says forged assertions could enable federated-user impersonation, unauthorized access and possible privilege escalation. These are the poster's claims, not independent confirmation within this batch.

Evolution

Observed

The dbugs record, one GitHub repository record and the ptdbugs post carry the same publication timestamp in the batch. That provides a single snapshot rather than a reliable chronology, so the evidence does not show when the flaw was found, when Red Hat was notified or whether remediation followed.

Reach

Observed

2 independent groups, 1 updates, and 0 engagements.

Technical detail

Alleged

The claimed bug is an algorithm-confusion weakness, meaning the verifier may be induced to handle a signed JWT assertion under an unintended verification method. In the reported chain, that confusion allegedly defeats signature checking inside the JWT Authorization Grant flow and lets a forged assertion be exchanged for an unauthorized access token.

Sources and evidence

Observed

Only the ptdbugs post supplies a technical description in this batch. The associated dbugs RSS item provides a URL and timestamp but no title or body, so it adds no independently reviewable technical detail here.

Observed

Two GitHub RSS records point to repositories named for CVE-2026-11800, but both lack titles and bodies in the supplied evidence. Their presence supports that repository links were collected, not that the code works or that the vulnerability has been independently reproduced.