SURIQ
The rule you set on Google sign-in, "only accounts from our company's Workspace domain," holds on the front door and gets waved through on a side door. That gap is CVE-2026-18214, a missing-authorization flaw in Red Hat Build of Keycloak disclosed on July 31 and credited to Paul Bottinelli at Trail of Bits. It carries a medium rating (CVSS 6.8), there is no report of it being exploited, and no fixed package has shipped. It still deserves an afternoon, because the control it defeats is one teams deliberately switch on to keep strangers out.
Keycloak is a widely deployed open-source identity and access management server. A Keycloak setup can use Google as an identity provider and can be pinned to a single Google Workspace domain, so that only, say, @yourcompany.com accounts are let through. Google carries that membership in a token field called hd (hosted domain). Sign in the normal way and Keycloak reads hd and enforces it. Arrive by a different route and it does not.
What actually broke
Keycloak also offers token exchange, which trades an external token, here a Google access token, for a Keycloak-issued one so an application can act for the user. Keycloak inspects hd when a person logs in interactively, but the code that accepts an incoming Google access token never runs that same comparison, per Red Hat's bug report. On that route Keycloak fetches the account's profile from Google and then admits it without ever measuring the account's domain against the one you pinned the connection to. The single check that gives the restriction any teeth is simply absent.
| Keycloak sign-in path | Checks the Google domain (`hd`)? | Domain restriction |
|---|---|---|
| Interactive Google login | Yes | Enforced |
| External access-token exchange (Token Exchange V1) | No | Bypassed |
Put it together: someone holding any working Google token, from any domain at all, who can reach a confidential client cleared to run token exchange, can swap that Google token for a Keycloak one and walk into a login that was meant to exclude them. The severity math sits at medium mainly because of that setup cost, not because the payoff is small. Once it works, confidentiality and integrity both take a full hit while availability is untouched. Red Hat adds that the same path can be used to spin up or attach a federated account the domain rule was meant to keep out, which is the part that outlasts a single session.
Who is actually exposed
This is not every Keycloak install. You are in scope only when all of these hold at once:
- Google is set up as an identity provider.
- That connection carries a hosted-domain restriction (the "our domain only" control).
- Token Exchange V1 is enabled.
- A confidential client is allowed to run token exchange, and an attacker can drive it with a Google access token.
Red Hat names the affected software as Red Hat Build of Keycloak, in the keycloak-services component shipped through rhbk-keycloak-rhel9 and rhbk-openshift-rhel9. It marks Red Hat Single Sign-On 7, Red Hat Data Grid 8, and the JBoss Enterprise Application Platform Expansion Pack as not affected. Teams running upstream Keycloak with the same Google broker and token-exchange setup should assume they may be in scope and follow the project's advisories, since the faulty logic lives in keycloak-services itself.
Why token-exchange flows keep doing this
Worth a defender's attention past this one CVE: Keycloak's alternate token paths have tripped on this same shape before. Earlier this year CVE-2026-1486 covered the JWT authorization-grant flow neglecting to confirm whether an identity provider was even enabled during token exchange. Different field, same category of miss: a guard the interactive login runs is missing on an exchange or alternate-grant route. Anyone operating an identity broker should stop assuming a restriction proven on the login screen also holds on every other way a token can arrive. Each grant type is its own entrance, and each one needs the guard posted.
We looked at another Keycloak issue last week, a view-only admin able to read live client secrets, and it rhymed: a check that held in one spot did not hold in another. It also echoes single sign-on bypasses elsewhere, like the miniOrange SSO plugin flaw that researchers reported could let a stranger log in as WordPress admin. Federation keeps moving the trust decision to a place you may not be watching.
How to contain this before a patch lands
No fixed version exists yet, so today's work is trimming exposure and turning on the lights.
- Confirm you are exposed at all. Check each Keycloak configuration for a Google identity provider carrying a hosted-domain restriction. No such pairing, no exposure through this path.
- Cut who can run token exchange. The attack needs a confidential client cleared for token exchange, so use Keycloak's fine-grained permissions to grant that only where an application truly needs it, and strip it everywhere else.
- Switch off Token Exchange V1 if nothing uses it. With no application depending on external token exchange, disabling the feature shuts this route.
- Stop leaning on the domain rule as the only gate. Layer a group or role mapping that independently confirms a federated user belongs, rather than trusting
hdto police everything. - Follow Red Hat's advisory. Watch the CVE page for the errata and apply the corrected
keycloak-servicespackage the moment it lands.
How to tell if it was already used
Because the bypass mints a genuine, admitted account, the giveaway is a Google-federated user whose email domain is not the one you allowed. Comb Keycloak's login and identity-broker events for Google accounts sitting outside your permitted domain, and give extra weight to identities born from a token-exchange call rather than an interactive sign-in. If your domain rule is working on the front door, an outside Google account already inside is a contradiction worth chasing down. The clean way to close the gap until the fix ships is to verify the email domain of every federated Google account yourself, instead of trusting that the restriction did it.
Medium score aside, a control that quietly stops applying is worse than one you know is off, because you have already looked away. That is the real bill here, and it is why this is worth handling before the errata arrives.