SURIQ
An identity broker has one job you are trusting it to do without watching over its shoulder: prove that a login truly came from the provider it claims. CVE-2026-16443, published by Red Hat on August 5, is a case where Keycloak can quietly stop proving it. Add a SAML identity provider by importing its metadata, and under some conditions Keycloak leaves the response-signature check turned off, even when that metadata shipped a signing certificate. Someone who never logs in, but who knows how your provider names a given user, can then present a self-made login assertion and be waved through as that person.
Keycloak is one of the most widely run open-source single sign-on servers, and the defect lives in keycloak-services, the module that drives identity federation in Keycloak, as shipped in Red Hat Build of Keycloak. Red Hat scores it 7.4 (High) and credits Paul Bottinelli of Trail of Bits. Nothing points to exploitation in the wild so far, and at the time of writing Red Hat lists no fixed errata and no workaround for its build.
What the flaw actually does
Federated single sign-on rests on one switch in Keycloak: Validate Signatures. Turned on, the broker insists that everything a provider sends be signed by the key it already trusts. Turned off, it believes whatever it is handed. The bug is that the import path can save this switch in the off position. It is meant to flip on the instant imported metadata carries a signing certificate. Upstream tracked the miss as issue #42213: the flag was being set only when the metadata also asked for signed outbound requests, an unrelated option. Red Hat pins the trigger instead on keys that arrive without their usage attributes. The effect is one and the same. You import a provider's genuine metadata, you see its certificate, you assume you are covered, and you are not.
What follows is the oldest problem in this protocol. The broker acts on whatever a provider asserts about your identity. Skip the signature and nothing stops an outsider from writing an assertion that names the victim and sending it in. The severity breakdown makes the shape plain: reachable over the network, no credentials and no click required, full impact to confidentiality and integrity, none to availability. The high-complexity rating reflects the two things an attacker has to line up, a provider sitting in the vulnerable state and the target's identifier at that provider. This is a precision account-takeover tool rather than a spray-and-pray bug, and in front of an admin console or a cloud tenant that distinction offers thin comfort.
Why upgrading is not the whole fix
Here is the detail the advisory leaves implicit, and the reason to spend an afternoon on it. The fault is in how the switch gets written during import, not in how a response is judged later. Keycloak maintainers repaired the import path in version 26.4.0, after the behavior surfaced as a regression in 26.3.3.
Repairing the code changes what the next import does. It does nothing for a provider you already brought in while running a vulnerable build. That choice is persisted in your configuration, and it sits there untouched by the update. An operator who patches and calls it done can still be running a provider that trusts unsigned logins. Take the upgrade as step one, then go read the actual switch on every provider you have.
How exposed are you
You are in range if you run Keycloak, community or Red Hat build, as a SAML broker, meaning you accept logins from an outside SAML provider rather than only minting your own. The stakes climb with what sits behind that broker: an administrative console, a tenant in the cloud, an internal app that honors the SSO session. One provider left unchecked is a standing door for anyone who can learn a single target's identifier.
What to do this week
- Audit every SAML provider today. Open each one in the admin console, confirm Validate Signatures is enabled, and confirm a validating certificate is attached. Do this before, and apart from, any upgrade, because the upgrade will not do it for you.
- Move the broker to a fixed build. Take community Keycloak to 26.4.0 or newer so fresh imports set the flag correctly. For Red Hat Build of Keycloak, watch Red Hat's advisory and apply the fixed errata as soon as it lands.
- Hunt for abuse. A forged sign-in still writes a brokered-login event to Keycloak's audit trail. Comb authentication events on the affected providers for privileged accounts signing in from odd places, and alert on new brokered sessions for those accounts from here on.
This is the third Keycloak brokering weakness we have written up in recent weeks, next to a domain-restriction bypass and a vault secret exposure. One thread ties them together: the broker is what everything downstream trusts, so a quiet default inside it becomes everyone's problem. The same held when researchers reported that a SAML plugin could let a stranger sign in as WordPress admin. Check the trust boundary you cannot see, because attackers are reading the same advisory you are.