Listen to this Post
The OIDC token introspection endpoint is designed to allow a resource server to validate a token and obtain its metadata. However, a flaw in how this endpoint enforces audience (aud) restrictions enables a legitimate yet malicious confidential client to bypass access controls. A confidential client is an application capable of securely authenticating with a client secret or a private key; in a typical OIDC flow, such a client can only introspect tokens that were issued for its own use. But due to missing or incomplete validation, an attacker who controls any confidential client in the realm can present a valid token (even one intended for a completely different resource server) to the introspection endpoint and receive the full set of claims from that token.
This occurs because the endpoint fails to check that the `aud` claim in the token actually matches the client that is requesting introspection. The attack requires only that the attacker has access to a valid token (which could be obtained through legitimate means or by intercepting a token) and that the attacker controls a client with valid credentials. When the attacker sends a POST request to `/realms/{realm}/protocol/openid-connect/token/introspect` with the token and the client’s credentials, the endpoint returns the token’s active status and claims, regardless of the audience. This effectively turns any compromised or malicious client into a universal token‑decoder for the entire realm, leaking the token’s contents (including user identity, roles, and other sensitive claims) that were meant only for other resource servers. The CVSSv3.1 score is 6.5 (Medium) with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, reflecting the ease of exploitation over a network with low‑privileged access and the high impact on confidentiality.
DailyCVE Form:
Platform: Keycloak / RHBK
Version: < 24.0.7, 25.0.0-25.0.4
Vulnerability: audience validation bypass
Severity: CVSS 6.5 (Medium)
date: 2026‑05‑19
Prediction: 2026‑07‑07 (patch estimate)
What Undercode Say:
To check if a Keycloak deployment is vulnerable, the introspection endpoint’s response to a cross‑audience token can be tested manually. The following bash snippet uses `curl` to simulate the attack:
Obtain a token for victim client 'resource-server'
VICTIM_TOKEN=$(curl -s -X POST \
"https://keycloak.local/realms/demo/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=resource-server&client_secret=secret1&grant_type=client_credentials" \
| jq -r '.access_token')
Introspect that token using a different confidential client 'evil-client'
curl -s -X POST \
"https://keycloak.local/realms/demo/protocol/openid-connect/token/introspect" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=evil-client&client_secret=secret2&token=${VICTIM_TOKEN}"
If the introspection returns the token’s claims (including aud, sub, and custom attributes) when the client `evil-client` is not listed in the `aud` claim, the system is vulnerable. The expected secure behavior is to return `”active”: false` or to omit the claims altogether.
Exploit:
A remote attacker who has compromised or registered a confidential client within the target realm can:
1. Obtain a valid access token for any other client in the same realm (e.g., by capturing a token in transit, replaying a stolen token, or using a leaked token).
2. Send that token to the `/token/introspect` endpoint along with the attacker’s own client credentials.
3. Retrieve the full token metadata, including all claims, thereby leaking data that should only be visible to the intended audience.
Because the vulnerability lies in the introspection endpoint’s logic, no special privileges are required beyond having a valid client ID and secret. The attack is entirely network‑based and can be automated.
Protection:
- Upgrade Keycloak to a patched version (24.0.7+, 25.0.5+, or any later release) as soon as an official fix is published.
- If upgrading is not immediately possible, disable the token introspection endpoint for all but the most trusted clients, or implement a custom authentication flow that enforces audience checks.
- Monitor access logs for the introspection endpoint; look for requests where the client ID does not match the audience of the token being introspected.
- Use short‑lived tokens to reduce the window of opportunity, and rotate client secrets frequently.
- Enforce network restrictions so that only known resource servers can reach the introspection endpoint.
Impact:
- Confidentiality compromise – sensitive token claims (user IDs, roles, permissions, email addresses) intended for one resource server are exposed to any malicious client in the realm.
- Privilege escalation – an attacker can use the leaked claims to gain a deeper understanding of user privileges, potentially leading to further attacks (e.g., token replay, session hijacking).
- Broken trust boundaries – the vulnerability undermines the assumption that token introspection is a secure operation, making it impossible to trust that a client sees only its own data.
- Widespread risk – because any confidential client can be used as an attack vector, the threat surface expands to every client with valid credentials in the realm, increasing the likelihood of exploitation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
