GHSA-jgvc-jfgh-rjvv

What it actually does

Jose4j versions before 0.9.3 are vulnerable to a chosen-ciphertext attack in JOSE/JWE decryption scenarios. When an application accepts attacker-controlled encrypted JOSE objects, especially JWE tokens using vulnerable key-management behavior such as RSA-based key wrapping, differences in decryption failure handling can act as an oracle. An attacker may repeatedly submit modified ciphertexts and use observable responses, timing, or error differences to infer information about encrypted content or key material. The impact depends heavily on how the application uses Jose4j: systems that only sign/verify JWTs, or that do not decrypt attacker-supplied JWEs, are less exposed than systems that decrypt externally supplied encrypted tokens.

Why it matters to the business

Applications using affected Jose4j versions to decrypt untrusted encrypted tokens may expose confidential token contents or weaken authentication and authorization protections that rely on encrypted JOSE data. Successful exploitation could lead to disclosure of sensitive claims, session-related data, or application secrets carried inside encrypted tokens. The issue is not listed in CISA KEV, has no known ransomware association in the supplied data, and has no reported exploit maturity, but it has been public for a long time, so affected dependencies should be treated as stale security debt and upgraded during normal vulnerability remediation cycles.

How an attack unfolds

An attacker first identifies an application endpoint that accepts encrypted JOSE/JWE input processed by Jose4j, such as an authentication, authorization, API, SSO, or token exchange endpoint. The attacker obtains or creates a valid encrypted token format and then sends many carefully modified ciphertexts to the application. If the application or library behavior reveals distinguishable outcomes for different decryption failures—through HTTP status codes, response bodies, exception messages, latency, retries, or authentication behavior—the attacker can use those observations as a decryption oracle. Over many requests, the attacker may recover information about protected plaintext or cryptographic material associated with the encrypted JOSE object. Practical exploitation requires oracle access to a decrypting service and enough repeated attempts to observe reliable differences, so exposure is highest on internet-facing services that decrypt externally supplied JWE tokens.

How to fix it

Upgrade org.bitbucket.b_c:jose4j to version 0.9.3 or later. The fixed Maven coordinate is org.bitbucket.b_c:jose4j:0.9.3. Remove dependency overrides, shaded copies, or transitive dependency pins that keep older Jose4j versions in the runtime classpath. If immediate upgrade is not possible, reduce exposure by disabling decryption of attacker-supplied JWE inputs where feasible, avoiding legacy RSA1_5 key-management algorithms, enforcing modern JOSE algorithms, normalizing decryption error responses, rate-limiting token decryption failures, and preventing detailed cryptographic exception messages from being returned to clients. Mitigations should be considered temporary; the durable fix is to run a patched Jose4j release.

How to confirm the fix worked

Confirm all build manifests and runtime artifacts resolve org.bitbucket.b_c:jose4j at 0.9.3 or later using dependency tooling such as Maven dependency:tree, Gradle dependencies, software composition analysis, or SBOM comparison. Check packaged application archives for embedded jose4j JARs and verify no older versions remain in application servers, containers, fat JARs, shaded libraries, or vendor-supplied bundles. Exercise token decryption paths in a staging environment with malformed or tampered JWE inputs and confirm the application returns uniform generic failures without detailed cryptographic errors. Review configuration to ensure deprecated or unnecessary JOSE algorithms are disabled. After deployment, monitor logs for continued loading or startup references to older Jose4j versions.

Typical attack path

1. Find an application endpoint that accepts encrypted JOSE/JWE tokens or payloads from users, clients, partners, or APIs.
2. Confirm that the application uses an affected Jose4j version before 0.9.3 and performs JWE decryption on attacker-controlled input.
3. Capture or construct a syntactically valid encrypted JOSE object, commonly in compact JWE form.
4. Modify ciphertext, encrypted key, initialization vector, authentication tag, or protected header values across many requests.
5. Submit the modified tokens to the decrypting endpoint and observe differences in HTTP status, response text, application behavior, exception logging, or timing.
6. Use those differences as a chosen-ciphertext oracle to infer information about the encrypted content or key handling.
7. Abuse any recovered sensitive token data or claims to escalate access, impersonate users, or bypass security controls if the application trusts the decrypted contents.

How to detect it

Review application, API gateway, identity provider, authentication service, and reverse proxy logs for repeated failed JWE/JWT processing from the same source, unusual bursts of token validation failures, or sequences of requests containing slightly different encrypted token values. Focus on endpoints that accept Authorization headers, bearer tokens, cookies, SSO assertions, OAuth/OIDC artifacts, or encrypted token parameters. Look for Jose4j exceptions involving JWE decryption, invalid JOSE compact serialization, RSA1_5 processing, authentication tag failures, padding failures, or malformed encrypted key/ciphertext values. Compare HTTP response behavior for token failures; historical evidence of many 400/401/403/500 responses with varying malformed encrypted tokens may indicate oracle probing. If detailed application logs are available, correlate source IPs, user agents, session identifiers, and request counts against token-processing failures. Because chosen-ciphertext attacks may not leave a final malware or file artifact, detection is primarily behavioral and log-based rather than host-IOC based.

• org.bitbucket.b_c:jose4j
• jose4j-0.9.2.jar
• jose4j-0.9.1.jar
• jose4j-0.9.0.jar
• jose4j-0.8.
• org.jose4j.lang.JoseException
• org.jose4j.jwe.JsonWebEncryption
• RSA1_5
• "alg":"RSA1_5"
• Invalid JOSE Compact Serialization
• Unable to decrypt
• JWE decryption failed
• authentication tag check failed
• Tag mismatch
• BadPaddingException
• AEADBadTagException
• InvalidJweException

What your security team should do

• Inventory all applications and services that include org.bitbucket.b_c:jose4j, including transitive, shaded, and bundled copies.
• Prioritize remediation for internet-facing authentication, authorization, API gateway, SSO, federation, and token exchange services that decrypt externally supplied JWE content.
• Upgrade Jose4j to 0.9.3 or later and redeploy affected services.
• Disable or restrict legacy JOSE encryption algorithms where business requirements allow, especially where encrypted tokens are accepted from untrusted sources.
• Ensure decryption failures produce generic, consistent client responses and do not expose stack traces or cryptographic exception details.
• Add rate limits and anomaly detection for repeated malformed JWE/JWT submissions to token-processing endpoints.
• Search historical logs for evidence of repeated decryption failures, RSA1_5/JWE parsing errors, and high-volume token tampering attempts.
• Document accepted JOSE algorithms and token issuers so unexpected encrypted token formats can be rejected early.