Oxia has an OIDC token audience validation bypass via SkipClientIDCheck

This vulnerability poses a significant risk to deployments utilizing OIDC authentication. An attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (a different client_id/aud) can successfully authenticate to Oxia. This effectively bypasses the intended audience isolation mechanisms of OAuth2/OIDC, allowing an attacker to impersonate legitimate users or gain administrative access depending on the user's privileges within Oxia. The potential impact includes data breaches, unauthorized modifications to system configurations, and complete compromise of the Oxia instance.

Organizations heavily reliant on OIDC for authentication, particularly those with multiple services sharing the same identity provider, are at heightened risk. Environments with legacy configurations or those lacking robust OIDC monitoring practices are also more vulnerable.

• linux / server:

journalctl -u oxia | grep "SkipClientIDCheck: true"

• generic web:

curl -I <oxia_endpoint> | grep -i "Authorization: Bearer"

1. 2026-04-21Disclosure

   disclosure

1. Reservado2026-04-15
2. Publicada2026-04-21
3. Modificada2026-04-22
4. EPSS actualizado2026-04-29

The primary mitigation is to upgrade to Oxia version 0.16.2 or later, which addresses the vulnerability by properly validating the audience claim. If upgrading immediately is not feasible, consider implementing temporary workarounds such as restricting access to Oxia based on known trusted client IDs or implementing stricter validation rules at the application level. Monitor OIDC authentication logs for suspicious activity, particularly tokens with unexpected audience claims. Review and audit OIDC configuration to ensure proper audience restriction is enforced.