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

CVE-2025-66033 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2025-66033?

Yes, a patch is available for CVE-2025-66033. Update the affected software to the latest version immediately.

Okta Java SDK CVE-2025-66033

MEDIUM

Memory Leak (CWE-401)

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

Java Information Disclosure Java Management Sdk

5.3

CVSS 3.1 · Vendor: github

Severity by source

Vendor (github) PRIMARY

5.3 MEDIUM

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

vuln.today AI

5.3 MEDIUM

Availability-only leak (C:N/I:N/A:H) that manifests only under sustained multithreaded load over time, hence AC:H; PR:L retained per vendor as authenticated API usage drives the condition.

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

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

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Sep 26, 2026 - 00:02 vuln.today

DescriptionCVE.org

Okta Java Management SDK facilitates interactions with the Okta management API. In versions 21.0.0 through 24.0.0, specific multithreaded implementations may encounter memory issues as threads are not properly cleaned up after requests are completed. Over time, this can degrade performance and availability in long-running applications and may result in a denial-of-service condition under sustained load. In addition to using the affected versions, users may be at risk if they are implementing a long-running application using the ApiClient in a multi-threaded manner. This issue is fixed in version 24.0.1.

AnalysisAI

Memory and thread resource exhaustion in the Okta Java Management SDK 21.0.0 through 24.0.0 allows long-running, multithreaded applications to progressively degrade and eventually suffer a denial-of-service condition against themselves, because threads are not properly cleaned up after requests complete. Only applications that integrate the SDK's ApiClient in a multithreaded manner and run for extended periods under sustained load are at risk; short-lived processes, single-threaded integrations, and applications on 24.0.1 or later are unaffected. This is not an attacker-triggerable flaw but an availability defect that surfaces through the application's own normal operation, rated CVSS 5.3 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) with a very low EPSS of 0.27% (17th percentile); no public exploit code or confirmed active exploitation has been identified at time of analysis, and this is a low-real-priority availability issue despite the network attack vector.

Technical ContextAI

The flaw is classified as CWE-401 (Missing Release of Memory after Effective Lifetime), i.e. a memory/resource leak, and the Okta advisory attributes it to threads not being properly cleaned up after requests complete inside specific multithreaded implementations of the SDK's ApiClient. The affected technology is the Okta Java Management SDK (CPE cpe:2.3:a:okta:java_management_sdk, Maven artifact com.okta.sdk:okta-sdk-root), the Java client library used to drive the Okta management API over HTTP, whose pagination and HTTP-response handling logic traditionally relied on shared mutable state. The upstream fix commit (1daa9229a70fc38fb252aeaa637f82d0b0729b3f) illustrates the underlying design problem: it deprecates the stateful PaginationUtil for removal (since 24.1.0) and introduces an immutable, thread-safe ApiResponse<T> object that packages status code, headers and body together, plus a PagedIterable abstraction for automatic pagination, explicitly replacing the old approach that stored response headers in a shared HashMap. That refactor removes the shared per-request state and provides lifecycle-safe iteration, which is consistent with eliminating the resource accumulation. Note that the CVSS vector carries PR:L rather than PR:N, reflecting that exploitation requires an already-running, privileged SDK consumer (an authenticated API client context) rather than an unauthenticated external attacker; the practical exposure is to the availability of the integrating service itself.

RemediationAI

Vendor-released patch: upgrade Okta Java Management SDK to 24.0.1 or greater (maven/com.okta.sdk:okta-sdk-root fixed in 24.0.1), per the GitHub advisory at https://github.com/okta/okta-sdk-java/security/advisories/GHSA-qhr6-6cgv-6638 and the fix commit at https://github.com/okta/okta-sdk-java/commit/1daa9229a70fc38fb252aeaa637f82d0b0729b3f; because this is a library-level defect, the patched dependency must be rebuilt and redeployed into every integrating application, and dependency scanners should confirm no transitive pin still resolves to a 21.0.0-24.0.0 artifact. If upgrading cannot be done immediately, the most effective compensating control is to stop using long-lived, multithreaded ApiClient instances: serialize SDK calls onto a single request thread or use a short-lived, per-operation ApiClient with bounded HTTP connection pools, which caps thread and memory growth at the cost of reduced concurrency and throughput for parallel Okta API workloads. Additional mitigations include scheduling rolling restarts of the integrating service before memory/thread counts cross the degradation threshold (introduces brief availability windows and only delays, not removes, the leak), tightening heap and thread-count alerting so growth is detected early, and restricting the blast radius by isolating the Okta-integration service from other critical workloads. Although the fix commit deprecates PaginationUtil in favour of the immutable PagedIterable/ApiResponse path, that change is a code-modernisation side effect rather than a standalone remediation, and it should not be relied on as a substitute for upgrading to 24.0.1 or later. Vendor patch status per advisory: patch available; no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.