Race condition in the Okta Java SDK

Vulnerability

The Okta Java Management SDK versions 11.0.0 through 20.0.0 contain a race condition in the ApiClient.invokeApi() method. When multiple threads call this method concurrently, unsynchronized access to shared request/response state can cause the status code or response headers from one thread's HTTP response to leak into the context of another thread's ongoing request. [1][2]

Exploitation

An attacker does not directly trigger the race; instead, exploitation requires the vulnerable SDK to be deployed in a multithreaded application where different threads handle API calls that the application relies on for access control decisions. Under the right timing conditions, a thread that performs a privileged operation may unintentionally see the HTTP response (e.g., a 403 status) intended for a different, less privileged request, or vice versa. The application must actively inspect the response status or headers to enforce authentication or authorization logic. [1][3]

Impact

If the application uses the HTTP status code or a header from the ApiClient response to make authorization decisions, the race condition could cause a thread to act on stale or mismatched result data. This might lead to inappropriate granting or denial of access. The maximum severity depends on the sensitivity of the operations protected by such checks, but the SDK itself does not define the policy—it only provides the transport. [3]

Mitigation

The issue is fixed in version 20.0.1 (and later, e.g., 21.0.0+). The fix adds the synchronized keyword to invokeApi(), ensuring that only one thread executes the method at a time, thus eliminating the data race. Users are advised to upgrade as soon as possible, especially if their applications use the SDK in a multithreaded context for access-control-related flows. [2][3]