GHSA-5739-39v2-5754 Impact `RSACrypt::decryptWithRSA15()` (used by the `RSA1_5` key-encryption algorithm) implements RSAES-PKCS1-v1_5 decryption by inspecti
A timing side-channel in RSA1_5 decryption allows attackers to recover the content encryption key via a padding oracle attack.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Over the internet
- Victim action needed
- Not needed
- Fix
- Available
What is GHSA-5739-39v2-5754?
GHSA-5739-39v2-5754 is a vulnerability in web-token/jwt-library, published on 18 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Official description
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 configurations
Applications that register RSA1_5 in their decryption AlgorithmManager and hold an RSA private key.
Patches
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.
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.
Which versions are affected by GHSA-5739-39v2-5754?
6 open source packages ship an affected version, including web-token/jwt-library.
| Package | Affected | Fixed in |
|---|---|---|
web-token/jwt-library Packagist | All versions | 3.4.10 |
web-token/jwt-library Packagist | All versions | 3.4.10 |
web-token/jwt-library Packagist | From 4.0.0 | 4.0.7 |
web-token/jwt-library Packagist | From 4.0.0 | 4.0.7 |
web-token/jwt-library Packagist | From 4.1.0 | 4.1.7 |
web-token/jwt-library Packagist | From 4.1.0 | 4.1.7 |
How do I fix GHSA-5739-39v2-5754?
Upgrade web-token/jwt-library to a fixed version for your release line: 3.4.10, 4.0.7 or 4.1.7.
Is GHSA-5739-39v2-5754 being exploited?
There is no known exploitation of GHSA-5739-39v2-5754 in the wild and no public exploit code.