PT-2026-53178 · Packagist · Web-Token/Jwt-Framework+1

Publicado

2026-06-18

·

Atualizado

2026-06-18

CVSS v4.0

8.7

Alta

VetorAV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Impact

When a JWE uses a password-based key-encryption algorithm (PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW), PBES2AESKW::unwrapKey() reads the p2c (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header and passes it to hash pbkdf2() with no upper bound. The only validation performed (checkHeaderAdditionalParameters()) was is int($p2c) && $p2c > 0.
An unauthenticated attacker can craft a single JWE whose protected header sets a very large p2c (e.g. 100 000 000 ≈ 87 s of CPU, or PHP INT MAX), forcing a worker to spend an arbitrary amount of CPU inside PBKDF2 before the key unwrap can even fail. The decrypter swallows the eventual exception, so the attacker pays almost nothing while the server burns CPU. JSON General serialization (multiple recipients) and multi-key JWKSets multiply the cost. This is a classic uncontrolled-resource-consumption (CWE-400) denial of service.

Affected configurations

Applications that register any PBES2-HS*+A*KW algorithm in their decryption AlgorithmManager.

Patches

PBES2AESKW now enforces a configurable maximum iteration count (DEFAULT MAX COUNT = 1 000 000, well above realistic legitimate values which are a few thousand) in checkHeaderAdditionalParameters(), before any PBKDF2 computation. The bound is exposed as a constructor argument so operators can tune it.

Workarounds

Before upgrading: validate/limit the p2c header with a custom header checker, or do not enable PBES2 algorithms for untrusted tokens.

References

  • RFC 7518 §4.8 (PBES2)
  • CWE-400: Uncontrolled Resource Consumption

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).
PBES2 — PBES2AESKW::unwrapKey() borne désormais le paramètre p2c (constante DEFAULT MAX COUNT = 1 000 000, configurable via le constructeur) avant tout appel à hash pbkdf2(), empêchant l'amplification CPU (DoS).
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.

Correção

Allocation of Resources Without Limits

Resource Exhaustion

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-770CWE-400

Identificadores relacionados

GHSA-3PRJ-6HQW-CM82

Produtos afetados

Web-Token/Jwt-Framework
Web-Token/Jwt-Library