Bug 2501270 (CVE-2026-15943)
| Summary: | CVE-2026-15943 keycloak-services: keycloak-services: OIDC IdP update reuses masked client secret after token URL change | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | anujha, aschwart, asoldano, aszczucz, bbaranow, bmaxwell, boliveir, bstansbe, dlofthou, drichtar, istudens, ivassile, iweiss, mosmerov, mposolda, msvehla, nwallace, pberan, pesilva, pjindal, pmackay, rmartinc, rstancel, ssilvert, sthorger, thjenkin, vdosoudi, vmuzikar |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in the Keycloak keycloak-services component, which handles the management of identity providers. The issue occurs when a delegated administrator updates an OIDC identity provider using a masked client secret sentinel value. Due to improper validation, Keycloak reuses the existing real secret even if security-sensitive fields like the token URL have been changed, allowing an attacker to redirect and capture the secret.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
A vulnerability was identified in Keycloak's admin API where the secret masking boundary is bypassed for OIDC identity-provider client secrets. The flaw exists in the IdentityProviderResource.updateIdpFromRep() function. When a PUT request is made to update an IdP configuration and the clientSecret is set to the masked sentinel value (ComponentRepresentation.SECRET_VALUE), Keycloak unconditionally copies the actual stored secret into the update. The root cause is a lack of validation to check if security-sensitive destination fields—specifically tokenUrl, clientId, or clientAuthMethod}}—have been modified in the same request. A delegated IdP manager with {{manage-identity-providers permissions can exploit this by changing the tokenUrl to an attacker-controlled endpoint while providing the masked secret sentinel. Keycloak will then bind the real secret to the new, malicious endpoint, allowing the attacker to capture the secret through normal broker traffic.