GHSA-6vvh-pxr4-25r7
PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption
GHSA-6vvh-pxr4-25r7 is a medium vulnerability (CVSS 6.0) in web-token/jwt-experimental, published June 18, 2026. No source lists public exploit code. Fixed in web-token/jwt-library 3.4.10.
- Severity
- 6.0 MediumCVSS 4.0, GitHub Advisories
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
3.4.10web-token/jwt-library +7 more
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.
Attack profile
How easy it is to exploit
- Attack vector
- Adjacent network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Affected packages
| Package | Affected | Fixed |
|---|---|---|
web-token/jwt-experimentalPackagist | through 4.1.6 | None known |
web-token/jwt-libraryPackagist | before 3.4.10 | 3.4.10 |
web-token/jwt-libraryPackagist | 4.0.0 up to 4.0.7 | 4.0.7 |
web-token/jwt-libraryPackagist | 4.1.0 up to 4.1.7 | 4.1.7 |
web-token/jwt-experimentalPackagist | through 4.1.6, plus listed versions 3.3.03.3.13.3.23.3.33.3.4 Show 26 moreShow less3.3.53.4.03.4.13.4.103.4.23.4.33.4.43.4.53.4.63.4.73.4.83.4.94.0.04.0.14.0.24.0.34.0.44.0.54.0.64.0.74.1.04.1.14.1.24.1.34.1.44.1.5 | None known |
web-token/jwt-libraryPackagist | before 3.4.10, plus listed versions 3.3.03.3.13.3.23.3.33.3.4 Show 11 moreShow less3.3.53.4.03.4.13.4.23.4.33.4.43.4.53.4.63.4.73.4.83.4.9 | 3.4.10 |
web-token/jwt-libraryPackagist | 4.0.0 up to 4.0.7, plus listed versions 4.0.14.0.24.0.34.0.44.0.54.0.6 | 4.0.7 |
web-token/jwt-libraryPackagist | 4.1.0 up to 4.1.7, plus listed versions 4.1.14.1.24.1.34.1.44.1.54.1.6 | 4.1.7 |
What each source reports
GitHub Advisories Score used
PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption
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.
- Record
GHSA-6vvh-pxr4-25r7- CVSS 4.0
- 6.0 Medium
CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-347, CWE-353
- Updated
- 2026-11-02
OSV
PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption
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.
- Record
GHSA-6vvh-pxr4-25r7- CVSS 4.0
- 6.0 Medium
CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-347, CWE-353
- Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.