GHSA-6VVH-PXR4-25R7

GHSA-6VVH-PXR4-25R7 is a medium-severity security vulnerability in web-token/jwt-experimental (composer), affecting versions <= 4.1.6. 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 Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption

Affected configurations

Applications that register Jose\Experimental\KeyEncryption\Chacha20Poly1305 (package web-token/jwt-experimental) as a JWE alg.

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.

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 versions

web-token/jwt-experimental (<= 4.1.6) web-token/jwt-library (< 3.4.10) 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

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 tag header is now emitted and required).

Frequently Asked Questions

  1. What is GHSA-6VVH-PXR4-25R7? GHSA-6VVH-PXR4-25R7 is a medium-severity security vulnerability in web-token/jwt-experimental (composer), affecting versions <= 4.1.6. It is fixed in 3.4.10, 4.0.7, 4.1.7.
  2. Which packages are affected by GHSA-6VVH-PXR4-25R7?
    • web-token/jwt-experimental (composer) (versions <= 4.1.6)
    • web-token/jwt-library (composer) (versions < 3.4.10)
  3. Is there a fix for GHSA-6VVH-PXR4-25R7? Yes. GHSA-6VVH-PXR4-25R7 is fixed in 3.4.10, 4.0.7, 4.1.7. Upgrade to this version or later.
  4. Is GHSA-6VVH-PXR4-25R7 exploitable, and should I be worried? Whether GHSA-6VVH-PXR4-25R7 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-6VVH-PXR4-25R7 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-6VVH-PXR4-25R7?
    • 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-experimental

Stop the waste.
Protect your environment with Kodem.