CVE-2026-19625: Quarkus OIDC token introspection cache authorization bypass

CVE-2026-19625 · Severity: medium · CVSS 5.3 · Published 2026-09-08

Quarkus is a Java application framework that many organizations use to build microservices. When a Quarkus application protects multiple endpoints with different OpenID Connect (OIDC) providers and enables token caching, an attacker with a valid token from one provider can incorrectly gain access to endpoints secured by a different provider. This breaks the intended isolation between authentication domains and could allow unauthorized access to protected resources.

Technologies: IBM Enterprise Build of Quarkus. Vendors: IBM.

Quick answers

Is CVE-2026-19625 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-19625 being exploited in the wild.
How severe is CVE-2026-19625?
Medium severity, with a CVSS score of 5.3, published 8 September 2026.
Which products and versions are affected?
IBM Enterprise Build of Quarkus 3.27.1 through 3.27.5, 3.33.1 through 3.33.3.
Is there a fix for CVE-2026-19625?
No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is CVE-2026-19625 attacked?
It is attacked over the network.
Am I affected by CVE-2026-19625?
Check whether you run IBM Enterprise Build of Quarkus at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an improper access control issue (CWE-284) in Quarkus's OIDC integration when token introspection caching is enabled. The root cause is that the token introspection cache fails to properly account for the OIDC provider tenant identity, allowing tokens from one provider to be accepted as valid for endpoints secured by another provider. An attacker with a valid token from OIDC Provider 1 can send it to an endpoint protected by OIDC Provider 2; the cached introspection result is incorrectly reused across provider boundaries. The attack requires network access to the application and no authentication or special privileges beyond holding a valid token from any configured provider. The fix is available in IBM Enterprise Build of Quarkus 3.27.5.SP1 and 3.33.3.SP1.

Affected products

  • IBM Enterprise Build of Quarkus 3.27.1 through 3.27.5, 3.33.1 through 3.33.3

Timeline

  • 2026-09-08: disclosed

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.