CVE-2023-52428

What it actually does

Connect2id Nimbus JOSE+JWT versions before 9.37.2 allow untrusted JWE input to specify an excessively large PBKDF2 iteration count through the JWE protected header parameter p2c when PasswordBasedDecrypter is used. Because the library performs password-based key derivation according to that attacker-controlled value, a single crafted token can force very high CPU consumption and thread occupation during decryption. The issue is remotely reachable wherever applications accept encrypted JWT/JWE values from users, API clients, identity flows, cookies, headers, or message queues and decrypt them with Nimbus PasswordBasedDecrypter. The impact is availability loss only; it does not directly provide data disclosure or code execution.

Why it matters to the business

Applications that rely on vulnerable Nimbus JOSE+JWT code to process encrypted tokens can be slowed down or made unavailable by a small number of malicious requests, potentially disrupting authentication, API access, session handling, or identity-dependent business workflows. The CVSS availability impact is high, but this is not currently in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so urgency should be driven primarily by whether externally reachable services decrypt password-based JWE tokens. Because this is a common Java security library, exposure may exist indirectly through downstream services and frameworks rather than only in applications that explicitly reference the library.

How an attack unfolds

An attacker identifies an endpoint or processing path that accepts encrypted JWT/JWE input and passes it to Nimbus JOSE+JWT PasswordBasedDecrypter. The attacker creates a syntactically valid JWE with a protected header containing a p2c value far larger than normal. When the vulnerable application receives the token, the library honors the attacker-supplied iteration count and starts PBKDF2 processing. Repeated submissions or parallel requests can consume CPU cores, saturate application worker threads, increase latency, trigger request timeouts, and cause service-level denial of service. No credentials, prior authentication, or user interaction are required if the vulnerable token-processing endpoint is publicly reachable.

How to fix it

Upgrade Connect2id Nimbus JOSE+JWT to version 9.37.2 or later. For source builds from rg/connect2id/nimbus-jose-jwt, include the fix at commit 3b3b77e or a later commit/release containing it. Update direct and transitive dependencies in Maven, Gradle, SBT, Bazel, container images, shaded JARs, fat JARs, and vendor-bundled application packages. Where immediate upgrade is not possible, apply compensating controls: reject JWE inputs with p2c above a conservative application-defined maximum before decryption, restrict password-based JWE decryption to trusted sources, rate-limit token-processing endpoints, enforce request timeouts, cap authentication/API concurrency, and monitor CPU saturation. Avoid relying on perimeter request size limits alone, because the malicious p2c value can be small while causing large compute cost.

How to confirm the fix worked

Confirm dependency resolution shows Nimbus JOSE+JWT 9.37.2 or later, or a build that includes commit 3b3b77e. Inspect SBOMs, dependency lockfiles, packaged artifacts, and running containers for older nimbus-jose-jwt JARs, including shaded or relocated copies. In Java builds, verify with commands such as dependency:tree, gradle dependencies, jar tf, and manifest inspection where applicable. Functionally test affected token-processing paths with normal JWE traffic to confirm no regression, and with a controlled oversized p2c test token in a non-production environment to verify the application rejects or safely handles it without sustained CPU spike or request-thread exhaustion. Validate that monitoring detects abnormal p2c values, high token-decryption latency, and CPU-bound request bursts.

Typical attack path

1. Find an application endpoint, API, authentication flow, cookie parser, or message consumer that accepts JWE/JWT input.
2. Determine or assume that the target uses password-based JWE decryption with Nimbus JOSE+JWT PasswordBasedDecrypter.
3. Generate a compact or JSON-serialized JWE whose protected header includes an abnormally large p2c PBKDF2 iteration count.
4. Submit the crafted JWE to the target service in a request parameter, Authorization header, cookie, form field, JSON body, or queued message field accepted by the application.
5. Repeat the request or send it concurrently to force excessive PBKDF2 computation.
6. Cause high CPU usage, worker-thread exhaustion, long request latency, errors, health-check failures, or service unavailability.

How to detect it

To determine whether exploitation has already occurred, review application, API gateway, WAF, load balancer, identity service, and authentication logs for bursts of requests carrying JWT/JWE-like values immediately followed by high CPU, request latency, 5xx responses, 401/400 spikes, upstream timeouts, or application restarts. Focus on endpoints that process Authorization headers, cookies, token exchange requests, login/session flows, webhook receivers, and APIs accepting token fields in JSON bodies. If request bodies or headers are logged, look for compact JWE patterns with five dot-separated Base64URL segments where the decoded protected header contains a p2c value that is unusually large for the environment. On Java hosts, correlate suspicious request windows with thread dumps showing PBKDF2, password-based decryption, or Nimbus PasswordBasedDecrypter activity consuming CPU. Review APM traces for expensive token-decryption spans and long-running requests in authentication middleware. There are no widely reported public campaign-specific indicators or named threat actors for this vulnerability; detection should therefore focus on behavioral evidence of abnormal JWE decryption cost and oversized p2c headers.

• "p2c"
• "PasswordBasedDecrypter"
• "PBKDF2"
• "PBKDF2WithHmacSHA256"
• "PBKDF2WithHmacSHA384"
• "PBKDF2WithHmacSHA512"
• "com.nimbusds.jose.crypto.PasswordBasedDecrypter"
• "com.nimbusds.jose.JWEObject"
• "com.nimbusds.jwt.EncryptedJWT"
• "alg":"PBES2-HS256+A128KW"
• "alg":"PBES2-HS384+A192KW"
• "alg":"PBES2-HS512+A256KW"
• "p2c":1000000
• "p2c":10000000
• "p2c":100000000
• "p2c":2147483647

What your security team should do

• Prioritize externally exposed services that accept encrypted JWT/JWE values and use Nimbus JOSE+JWT PasswordBasedDecrypter.
• Upgrade all direct and transitive nimbus-jose-jwt dependencies to 9.37.2 or later, or to builds containing commit 3b3b77e.
• Search source code and configuration for PasswordBasedDecrypter, JWEDecrypter, JWEObject.parse, EncryptedJWT.parse, and password-based JWE algorithms to identify reachable usage.
• Add application-side validation to reject excessive JWE p2c values before decryption, even after patching, as defense in depth.
• Apply rate limiting and concurrency controls to authentication, token exchange, session, and API endpoints that process untrusted tokens.
• Review packaged artifacts, shaded JARs, vendor libraries, and container images because vulnerable Nimbus code may be embedded indirectly.
• Create detections for bursts of token-processing failures, unusually high CPU per request, request timeouts, and malformed or high-iteration JWE headers.
• Because EPSS is low and there is no KEV listing, prioritize based on actual exposure rather than broad emergency response, but remediate promptly for internet-facing token processors.