CVE-2025-45769: 
PHP vulnerability analysis and mitigation

CVE-2025-45769 is a weak encryption vulnerability (CWE-326) in Google's firebase/php-jwt library, affecting versions up to and including v6.11.0. The issue was reported on July 30, 2025, and published to the NVD on July 31, 2025. It concerns HMAC and RSA key lengths used in JSON Web Signature (JWS) implementations that do not meet recommended security standards per RFC 7518, NIST SP800-117, and RFC 2437. The CVE carries a CVSS v3.1 base score of 6.5 (Medium) per NVD, though the GitHub Advisory Database rates it Low (2.7 CVSS v4). Importantly, this CVE has been disputed by MITRE/NVD (as of August 17, 2025) on the basis that key length enforcement is the responsibility of the consuming application, not the library itself (GitHub Advisory, Feedly, Gist).

The vulnerability is classified as CWE-326 (Inadequate Encryption Strength). The reporter found that firebase/php-jwt v6.x does not enforce minimum key length requirements for HMAC (e.g., HS256) or RSA signing operations, allowing applications to use cryptographically weak keys without any library-level warning or rejection. According to the original disclosure gist, the library's JWS implementation accepts keys shorter than those recommended by RFC 7518 and NIST SP800-117, which could enable brute-force or protocol analysis attacks (CAPEC-112, CAPEC-192, CAPEC-20) against JWTs signed with such keys. The dispute centers on the argument that key length validation is an application-level concern — PHP's own hash_hmac() and openssl_sign() functions impose no such restrictions either (Gist, GitHub Issue, GitHub Advisory).

If an application using firebase/php-jwt v6.x is configured with a short or weak HMAC/RSA key, an attacker could potentially forge or brute-force JWT signatures, leading to unauthorized access, privilege escalation, or session hijacking depending on how JWTs are used in the application. The confidentiality and integrity impacts are rated Low, with no availability impact, and the vulnerability does not affect systems where applications already enforce adequate key lengths. The practical risk is highly dependent on the consuming application's key management practices (GitHub Advisory, Feedly).

There is no known public exploit code or evidence of in-the-wild exploitation for CVE-2025-45769. The EPSS score is approximately 0.014% (very low probability of exploitation in the next 30 days), and the CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The CVE has been disputed by NVD, which has assigned no CVSS score from NIST, further reducing its practical threat profile. Exploitation would require an attacker to already know or brute-force a weak key used by a specific application, making opportunistic mass exploitation unlikely (GitHub Advisory, Feedly).

The GitHub Advisory Database identifies firebase/php-jwt v7.0.0 as the patched version, which introduces key length validation at the library level. Upgrading to v7.0.0 or later is the recommended remediation. For projects that cannot upgrade (e.g., those pinned to laravel/passport ^11 which requires firebase/php-jwt ^6.4), the immediate workaround is to ensure all application-level HMAC keys meet minimum length requirements per RFC 7518 (e.g., HS256 requires at least 256-bit keys). Projects blocked by Composer's security audit can add audit.ignore for this CVE in composer.json while acknowledging the disputed nature of the vulnerability (GitHub Advisory, GitHub Issue, php-jwt repo).

The CVE has generated notable community pushback. A GitHub issue (#620) filed in February 2026 highlights that the GitHub Advisory Database's failure to reflect NVD's "Disputed" status is causing Composer's --audit feature to block all firebase/php-jwt v6 installations, impacting projects like laravel/passport ^11 that cannot easily upgrade to v7. Community members argue the CVE is not a library bug but a misuse pattern, and that NVD's own decision to dispute the CVE and assign no score supports this view. A blog post on Mastering Laravel (March 2026) also addressed the issue, advising developers not to simply silence Composer security warnings without understanding the context (GitHub Issue, Mastering Laravel).