GHSA-6vvh-pxr4-25r7
PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption
Blast Radius
web-token/jwt-experimental🐘web-token/jwt-library🐘web-token/jwt-library🐘web-token/jwt-libraryReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The experimental Chacha20Poly1305 key-encryption algorithm generates the 16-byte Poly1305 authentication tag during encryptKey() but discards it: the tag is never written to the header and therefore never reaches the wire. On the receiving side, decryptKey() calls openssl_decrypt('chacha20-poly1305', ...) without the tag argument, which makes OpenSSL skip authentication entirely.
As a result the AEAD construction is silently degraded to unauthenticated ChaCha20: a tampered encrypted CEK is accepted, and because ChaCha20 is a stream cipher, a single-byte change in the ciphertext propagates as a single-byte change in the recovered CEK with no integrity check (CWE-353 / CWE-347). An attacker on the token path can manipulate the wrapped key without detection.
Affected configurations
Applications that register Jose\Experimental\KeyEncryption\Chacha20Poly1305 (package web-token/jwt-experimental) as a JWE alg.
Patches
encryptKey() now publishes the Poly1305 tag as the base64url tag header parameter (and asserts it is 16 bytes). decryptKey() requires the tag header, validates its length, and passes it to openssl_decrypt() so the tag is actually verified, in line with RFC 7539 / RFC 8439. Tampering now results in a decryption failure.
Note: this changes the wire format of tokens produced with this experimental algorithm (a
tagheader is now emitted and required).
Workarounds
Do not use the experimental Chacha20Poly1305 key-encryption algorithm for untrusted input until upgraded.
References
- RFC 7539 / RFC 8439 (ChaCha20-Poly1305 AEAD)
- CWE-353: Missing Support for Integrity Check
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).
ChaCha20-Poly1305 — le tag d'authentification Poly1305 est désormais publié dans le header au chiffrement et vérifié au déchiffrement (RFC 7539), rétablissant l'intégrité AEAD.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | web-token/jwt-experimental | all versions | No fix |
| 🐘Packagist | web-token/jwt-library | all versions | 3.4.10 |
| 🐘Packagist | web-token/jwt-library | ≥ 4.0.0&&< 4.0.7 | 4.0.7 |
| 🐘Packagist | web-token/jwt-library | ≥ 4.1.0&&< 4.1.7 | 4.1.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for web-token/jwt-experimental. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
No patched version of web-token/jwt-experimental has shipped for GHSA-6vvh-pxr4-25r7 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6vvh-pxr4-25r7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6vvh-pxr4-25r7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6vvh-pxr4-25r7 in your dependencies?
O3 detects GHSA-6vvh-pxr4-25r7 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.