CVE-2026-16443 in Build of Keycloak
Summary
by MITRE • 08/05/2026
A flaw was found in the SAML metadata import functionality of the keycloak-services component, which is the core engine for identity brokering in Red Hat Build of Keycloak. When importing identity provider metadata that lacks specific usage attributes for keys, the system incorrectly disables signature validation for SAML responses even if a signing certificate is provided. This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability exists within the keycloak-services component of Red Hat Build of Keycloak, specifically affecting the SAML metadata import functionality that serves as the core identity brokering engine. The flaw manifests when processing identity provider metadata that omits certain usage attributes for cryptographic keys, creating a dangerous security gap in the authentication pipeline. The system's flawed logic automatically disables signature validation for SAML responses under these conditions, regardless of whether a valid signing certificate has been provided by the external identity provider.
The technical implementation issue stems from improper attribute validation and trust assumptions within the metadata processing workflow. When key usage attributes are missing from the imported SAML metadata, the system incorrectly assumes that signature validation should be disabled to maintain compatibility with certain legacy implementations. However, this assumption creates a critical security vulnerability because it bypasses essential cryptographic verification mechanisms that should always be active when signing certificates are present. The flaw operates at the intersection of weak input validation and overzealous compatibility handling, where the system's attempt to accommodate missing metadata attributes inadvertently introduces a backdoor for malicious actors.
The operational impact of this vulnerability is severe as it enables unauthenticated attackers to forge SAML responses without requiring valid credentials or access tokens. An attacker only needs to know a target user's external identifier within the identity provider system to successfully impersonate that user and gain unauthorized access to their account. This represents a fundamental breakdown in the authentication chain, transforming what should be a highly secure single sign-on process into a potential vector for account takeover attacks. The vulnerability undermines the entire purpose of SAML-based authentication by allowing forged responses to bypass signature validation entirely.
This security flaw aligns with CWE-347, which addresses improper verification of cryptographic signatures, and relates to ATT&CK technique T1566.002 for credential access through spearphishing with links. The vulnerability demonstrates poor input validation practices and inadequate trust model implementation in identity management systems. Organizations using Red Hat Build of Keycloak that have configured SAML identity providers are at risk, particularly those with external identity providers that may not fully specify key usage attributes in their metadata. The attack vector is particularly concerning because it requires minimal information about the target user beyond their external identifier, making it relatively easy to exploit in targeted attacks.
The recommended mitigation strategy involves updating to patched versions of Red Hat Build of Keycloak where the metadata import logic has been corrected to properly validate key usage attributes before disabling signature validation. Administrators should also implement additional monitoring for suspicious authentication patterns and review SAML metadata configurations to ensure all required attributes are properly specified. Organizations should consider implementing network-level controls such as firewalls or access control lists to limit exposure and establish more robust logging mechanisms to detect potential exploitation attempts. The fix should enforce that signature validation remains active when signing certificates are present, regardless of the completeness of metadata attributes.