A flaw in Keycloak’s IdentityProviderResource component allows for the inadvertent reuse of masked client secrets during OIDC configuration updates, creating a path for credential interception. Disclosed on October 13, 2026, CVE-2026-15943 represents a failure in the secret-masking boundary within the Keycloak IdentityProviderResource. The vulnerability centers on how the system handles masked sentinel values-typically represented as a string of asterisks-when an administrator modifies an existing OpenID Connect (OIDC) Identity Provider (IdP) configuration. Under normal operation, the masking mechanism is intended to prevent the exposure of sensitive credentials in the UI. However, the logic fails to invalidate or re-verify the underlying secret when the associated token endpoint is altered.
The technical mechanism of the failure is straightforward: when an administrator updates an OIDC IdP configuration, the system checks the provided secret field. If the field contains the masked sentinel value, the application logic assumes the existing, stored secret remains valid and persists it. The vulnerability triggers when an attacker with ‘manage-identity-providers’ permissions modifies the tokenUrl field while leaving the secret field populated with the masked sentinel. Because the system does not perform a re-validation of the secret against the new endpoint, it binds the existing, valid client secret to the attacker-controlled token endpoint. This effectively bypasses the intended security boundary between the configuration state and the credential store.
The impact of this flaw on IdP federation trust is significant. By redirecting token requests to an endpoint under their control, an attacker can capture the real client secret during the subsequent exchange. Once the secret is intercepted, the attacker can impersonate the Keycloak instance to the external IdP. This allows for the potential manipulation of authentication flows or the unauthorized acquisition of tokens, undermining the integrity of the federated identity relationship. The risk is confined to environments where delegated administrators possess sufficient permissions to modify IdP configurations.
Red Hat has assessed the severity of this vulnerability as Moderate. The affected product suite includes the Red Hat Build of Keycloak, Red Hat SSO 7, Red Hat Data Grid 8, and the JBoss EAP Expansion Pack. To remediate this issue, operators must upgrade to Keycloak 26.8.1. This version introduces the necessary logic to ensure that changes to critical configuration parameters, such as the tokenUrl, trigger a mandatory re-submission or validation of the client secret, thereby breaking the cycle of automatic reuse.
Connections, not re-covers: this is the week’s identity failures landing at the maintenance and configuration plane rather than the login screen. Microsoft is hardening AD FS token-signing keys behind an opt-out its own documentation says leaves the container vulnerable (Post 131823), and the Golden SAML explainer walks what a stolen signing key buys (Post 131832). BotSharp’s starter template ships a hard-coded signing key every agent built on it inherits (Post 131847). IBM Verify Access deserializes untrusted data at its management interface (Post 131927). The self-hosted IdP side of the same week is in the ZITADEL authentication-bypass cluster (Post 131285) and the four-provider, fifteen-CVE identity-stack window (Post 131292). None of these is authentication missing. Each is a system trusting its own configuration or processing state without re-validating it-here, the masked sentinel standing in for the secret while the endpoint beneath it moves.
Mitigation requires strict adherence to the principle of least privilege regarding administrative roles. Organizations should audit their current ‘manage-identity-providers’ assignments to ensure that only trusted personnel can modify IdP configurations. Beyond the immediate patch, this incident highlights the maintenance surface risk inherent in complex identity management systems. The reliance on masked sentinel values for UI convenience creates a persistent state where the boundary between ‘no change’ and ‘re-use’ can become blurred. Operators should prioritize regular updates to the Keycloak, Red Hat Build of Keycloak, and Red Hat SSO ecosystems to minimize exposure to similar configuration-logic flaws.