GHSA-5739-39V2-5754

GHSA-5739-39V2-5754 is a medium-severity security vulnerability in web-token/jwt-library (composer), affecting versions < 3.4.10. It is fixed in 3.4.10, 4.0.7, 4.1.7.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

PHP JWT Library: RSA15 (RSAES-PKCS1-v15) decryption lacks implicit rejection, exposing a Bleichenbacher/Marvin padding oracle

Affected configurations

Applications that register RSA1_5 in their decryption AlgorithmManager and hold an RSA private key.

Workarounds

Prefer RSA-OAEP/RSA-OAEP-256; do not enable RSA1_5 for untrusted tokens.

References

  • RFC 3447 §7.2.2 / RFC 8017 §7.1.2
  • Bleichenbacher (1998); Marvin attack
  • CWE-208: Observable Timing Discrepancy

Résolution

Un correctif a été préparé sur une branche dédiée basée sur 3.4.x, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).

RSA1_5, déchiffrement PKCS#1 v1.5 avec implicit rejection en temps constant (RFC 3447 §7.2.2) : un padding invalide n'est plus distinguable d'un padding valide, neutralisant l'oracle Bleichenbacher.

Validation : php -l OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs 3.4.x), aucun commentaire ajouté dans le code source. Après merge, cascade prévue 3.4.x → 4.0.x → 4.1.x.

Impact

RSACrypt::decryptWithRSA15() (used by the RSA1_5 key-encryption algorithm) implements RSAES-PKCS1-v1_5 decryption by inspecting the padding after RSADP and throwing InvalidArgumentException as soon as the padding is malformed. It does not implement the implicit-rejection countermeasure required by RFC 3447 §7.2.2 / RFC 8017 §7.1.2 (return a deterministic pseudo-random value of the expected length on padding failure and let the downstream step fail uniformly).

From a JWE caller this yields a Bleichenbacher/Marvin padding oracle: an attacker submitting adaptively crafted encrypted_key values can distinguish (a) padding rejected, (b) padding valid but wrong CEK length, and (c) padding valid and full AEAD executed, even though JWEDecrypter returns the same false in all cases, because each path performs a measurably different amount of work, amplifiable by enlarging the ciphertext (CWE-208 timing side channel). Enough adaptive queries can recover the wrapped CEK.

Affected versions

web-token/jwt-library (< 3.4.10) web-token/jwt-framework (<= 4.1.6) web-token/jwt-library (>= 4.0.0, < 4.0.7) web-token/jwt-library (>= 4.1.0, < 4.1.7)

Security releases

web-token/jwt-library → 3.4.10 (composer) web-token/jwt-library → 4.0.7 (composer) web-token/jwt-library → 4.1.7 (composer)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

PKCS#1 v1.5 decryption now performs implicit rejection: on invalid padding (or unexpected recovered length) it returns a random CEK of the expected size selected in constant time, so the full content-decryption (AEAD) step always runs and fails uniformly, removing the observable difference between padding-valid and padding-invalid ciphertexts. Users are still strongly encouraged to migrate to RSA-OAEP.

Frequently Asked Questions

  1. What is GHSA-5739-39V2-5754? GHSA-5739-39V2-5754 is a medium-severity security vulnerability in web-token/jwt-library (composer), affecting versions < 3.4.10. It is fixed in 3.4.10, 4.0.7, 4.1.7.
  2. Which packages are affected by GHSA-5739-39V2-5754?
    • web-token/jwt-library (composer) (versions < 3.4.10)
    • web-token/jwt-framework (composer) (versions <= 4.1.6)
  3. Is there a fix for GHSA-5739-39V2-5754? Yes. GHSA-5739-39V2-5754 is fixed in 3.4.10, 4.0.7, 4.1.7. Upgrade to this version or later.
  4. Is GHSA-5739-39V2-5754 exploitable, and should I be worried? Whether GHSA-5739-39V2-5754 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether GHSA-5739-39V2-5754 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix GHSA-5739-39V2-5754?
    • Upgrade web-token/jwt-library to 3.4.10 or later
    • Upgrade web-token/jwt-library to 4.0.7 or later
    • Upgrade web-token/jwt-library to 4.1.7 or later

Other vulnerabilities in web-token/jwt-library

Stop the waste.
Protect your environment with Kodem.