What is the CVSS score of CVE-2025-67505?

CVE-2025-67505 has a CVSS 3.1 base score of 8.4 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L. EPSS exploitation probability: 0.2%.

Which versions of Okta Java SDK are affected by CVE-2025-67505?

Okta Java SDK versions 11.0.0 through 20.0.0 introduce a high-severity concurrency flaw that can cause affected Java applications to make incorrect authorization decisions when handling simultaneous…. A patch is available.

How to fix or mitigate CVE-2025-67505?

Within 24 hours, inventory all Java applications and services for Okta Java SDK versions 11.0.0 through 20.0.0 and flag any that invoke ApiClient concurrently or base authorization decisions on response status codes or headers; if such a service is externally exposed or handles regulated data, consider temporary defensive changes such as serializing affected ApiClient calls or avoiding reliance on response headers/status for access control until upgrade. Within 7 days, upgrade affected components to vendor-released patch 20.0.1 (or 21.0.0+ where the GHSA guidance applies), run regression tests on multithreaded authorization paths, and verify that no transitive dependencies still pull affected Okta Java SDK versions. Within 30 days, complete remediation across all remaining environments, add dependency scanning or SBOM controls to prevent reintroduction of versions 11.0.0 through 20.0.0, and confirm with application owners that concurrent ApiClient calls no longer influence access-control decisions without independent validation.

Okta Java SDK CVE-2025-67505

HIGH

Race Condition (CWE-362)

2025-12-10 security-advisories@github.com

Java Information Disclosure Race Condition Okta Java Management Sdk

8.4

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.4 HIGH

AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L

vuln.today AI

6.0 MEDIUM

AC:H because winning the concurrency race is unreliable and not directly attacker-forced; C/I/A lowered to L because impact only materializes conditionally in specific consuming-app authz patterns; S:C as the SDK defect affects the hosting application's decisions.

3.1 AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Metadata Corrected

Sep 26, 2026 - 00:40 vuln.today

tag: Okta added

Analysis Generated

Sep 25, 2026 - 23:48 vuln.today

CVE Published

Dec 10, 2025 - 23:15 cve.org

HIGH 8.4

DescriptionCVE.org

Okta Java Management SDK facilitates interactions with the Okta management API. In versions 11.0.0 through 20.0.0, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request’s response to influence another request’s response. This issue is fixed in version 20.0.1.

AnalysisAI

Okta Java SDK versions 11.0.0 through 20.0.0 allow concurrent ApiClient requests to cross-contaminate response status codes and headers, which can undermine access-control decisions in multithreaded applications. This is a timing-dependent race condition (CWE-362) that is not remotely exploitable against default deployments; exploitation requires an application that invokes ApiClient concurrently and bases authorization on its response status or headers. No public exploit or active exploitation has been identified, and EPSS is low at 0.21%, but a vendor patch is available in version 20.0.1 (GHSA text says 21.0.0+).

Technical ContextAI

The Okta Java Management SDK (okta-sdk-java) is a Java library for interacting with Okta's management API. Its ApiClient class handles HTTP requests, and in versions 11.0.0 through 20.0.0 (CPE cpe:2.3:a:okta:java_management_sdk:*:*:*:*:*:*:*:*) the invokeAPI method lacked proper synchronization. This introduced a race condition classified as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization), where concurrent threads could interleave such that one request's response status code or header is read from shared mutable state by another request. The root cause is unsynchronized access to shared response state within ApiClient. The vendor fixed this by adding the synchronized keyword to invokeAPI in commit abf4f128, serializing access. The flaw is timing-dependent and only manifests when an application uses a single ApiClient instance across multiple threads and makes security decisions based on the returned status or headers.

RemediationAI

Upgrade the Okta Java Management SDK to version 20.0.1 or later (the GHSA also references 21.0.0+ as a fix; confirm the appropriate version for your dependency manager). The patch, available from the vendor, adds synchronization to the ApiClient.invokeAPI method to prevent cross-request contamination. If an immediate upgrade is not feasible, avoid sharing a single ApiClient instance across multiple threads in security-sensitive paths, or wrap all ApiClient calls with external synchronization (e.g., using a lock) to serialize access-though this can degrade performance and is error-prone. Additionally, review applications to ensure they do not base access-control decisions solely on HTTP response status codes or headers from ApiClient unless those values are isolated per request. Consult the advisory at https://github.com/okta/okta-sdk-java/security/advisories/GHSA-j5gq-897m-2rff and the fix commit at https://github.com/okta/okta-sdk-java/commit/abf4f128a0441f90cb7efcdcf4bde1aef8703243 for details.