# Okta Java SDK race condition crosses responses between requests

Source: https://startwithidentity.com/cves/cve-2025-67505/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

The [Okta](https://startwithidentity.com/vendors/iam/okta/) Java SDK had a race (CWE-362) that could return client B's API response to client A. Under load, that response can include tokens, factors, or user profile data. CVSS 8.4. Patched in v20.0.1 (December 2025).

## Why it matters

This is not an Okta-service auth bypass. It is worse in a different way: the official SDK, in your JVM, mixing identity responses. Same class as [Duende's token-management race](https://startwithidentity.com/cves/cve-2025-26620/). Customers will file it as "intermittent wrong user" until someone reads the advisory.

## What to do

- Upgrade the Okta Java SDK to 20.0.1 or later in every service that talks to Okta.
- Load-test after the upgrade: two users, concurrent calls, assert `sub` never crosses.
- Review logs from December 2025 for support cases that look like session mix-up.

## After you patch

Patching closes the entry point. It does not remove access an attacker established through it.

- **Revoke sessions and API tokens** on the affected system rather than only resetting passwords.
- **Audit accounts, tokens, and administrative changes** made during the exposure window.
- **Rotate credentials the system stored or could reach**, including directory service accounts and integration keys. See [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/).
- **Treat the system as a pivot**: whatever it could authenticate to is in scope until you have checked it.

## Sources

- [NVD: CVE-2025-67505](https://nvd.nist.gov/vuln/detail/CVE-2025-67505)
- Okta Java SDK 20.0.1 release notes