GitHub Advisory GHSA for CVE-2025-45769 ignores NVD "Disputed" status, blocks all php-jwt v6 users

[s00d]

Problem

CVE-2025-45769 was marked as Disputed by MITRE/NVD on August 17, 2025:

"this issue has been disputed on the basis that key lengths are expected to be
set by an application, not by this library"
NVD has assigned no CVSS score (N/A). However, the GitHub Advisory Database
still lists this as High severity (using the CISA-ADP score of 7.3) and has
not reflected the disputed status.
As a result, Composer's block-insecure feature treats this as a confirmed
high-severity vulnerability and refuses to install any php-jwt v6 release.

Impact

Packages pinned to php-jwt ^6 cannot be installed or updated:

• laravel/passport ^11 requires firebase/php-jwt ^6.4
• Passport 12+ requires Laravel 11, so projects on Laravel 10 have no upgrade path
• Every affected project must manually add audit.ignore in composer.json

The CVE itself

The "vulnerability" is that php-jwt accepts short HMAC keys without validation.
This is not a library bug — key management is the caller's responsibility.
PHP's own hash_hmac() and openssl_sign() behave identically and have no CVEs
for this.
NVD agrees — hence the Disputed tag and no score from NIST.

Request

1. Update the GitHub Advisory to reflect the NVD disputed status, or withdraw it
2. If that's not possible, backport the key length check to a v6.x patch (e.g. 6.11.2)
   so ^6 consumers are unblocked without a major version jump

Reproduction

On any project with laravel/passport ^11

composer update

firebase/php-jwt[v6.4.0, ..., v6.11.1] were not loaded, because they are
affected by security advisories ("PKSA-y2cr-5h3j-g3ys")

[ohader]

It seems, that a recent change to the GitHub advisory database in github/advisory-database#6934 might be the origin. And GitHub not validating the CVE disputed tag (https://github.com/CVEProject/cvelistV5/blame/main/cves/2025/45xxx/CVE-2025-45769.json#L59-L61)

[ohader]

Request

1. Update the GitHub Advisory to reflect the NVD disputed status, or withdraw it
2. If that's not possible, backport the key length check to a v6.x patch (e.g. 6.11.2)
   so ^6 consumers are unblocked without a major version jump

Some more context on the disputed tag:
https://www.cve.org/Media/News/item/blog/2024/01/30/CVE-Records-DISPUTED-Tag-Clarification

That information is also reflected in the CVE description:

This dispute is subject to review under CNA rules 4.1.4, 4.1.14, and other rules; the dispute tagging is not meant to recommend an outcome for this CVE Record.

https://www.cve.org/resourcessupport/allresources/cnarules#section_4-1_Vulnerability_Determination states

• 4.1.4 Insecure default configuration settings SHOULD be determined to be Vulnerabilities.
• 4.1.14 Sociotechnical and other changes over time MAY be determined to be new Vulnerabilities or types of Vulnerabilities.
  (Examples given include cryptographic algorithms that became insecure as computing power advanced, or plain-text protocols that are now considered unsafe.)

Thus, with considering these rules above - if it turns out that there is no vulnerability, the CVE has to be set to REJECTED.

[derhansen]

I created a PR (github/advisory-database#6954) for the GH Advisory DB. Hopefully, they will review the PR and decide to remove advisory.

[ohader]

I evaluated and applied the CNA rules to the underlying topic:

CNA Rules Applied

CNA Rule	Verdict	Reasoning
4.1.2	Against CVE	No exploitable security impact within the library itself
4.1.3	Against CVE	Weak keys are a caller-supplied configuration decision, not a library default
4.1.4	Against CVE	There is no default configuration setting in the library that governs key size
4.1.14	Neutral/weak for CVE	The library does not chose a key size; this rule targets algorithms chosen by the library that become weak over time

In each case, the secret key is supplied by a user/developer.
The firebase/php-jwt library does not create weak keys on its own.

ℹ️ From this point of view, applying the REJECTED state to CVE-2025-45769 seems to be feasible.

---

What about other projects/tools?

PHP v8.5.3

$ php -r 'var_dump(hash_hmac("sha256", "message", "key"));'
string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"

→ short key, no error

OpenSSL v3.6.1

echo -n "message" | openssl dgst -sha256 -hmac "key"
SHA2-256(stdin)= 6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a

→ short key, no error

[shelbyc]

Hi @ohader and @derhansen, I'm responding to this thread to explain why my teammates and I reviewed CVE-2025-45769 and why we think the advisory is appropriate to keep in the ADB.

When github/advisory-database#6934 landed in my review queue, I dug deeper and found #611, #613, and #618. Since the maintainer decided the issue described in CVE-2025-45769 required a patch, we inferred that the issue was valid and the weight of the evidence tipped in favor of reviewing the advisory.

Because the maintainer behaved based on the validity of CVE-2025-45769 and a fix exists, it's appropriate to treat the advisory as valid and alert users to the existence of a fix.

One thing that I would change about the advisory, though, is the CVSS. Upon a closer re-read, I think CISA-ADP's score of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L should be tweaked. Something like https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N or https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, both of which land on a medium severity, would be more appropriate because I don't see an availability impact from the issue described in CVE-2025-45769.

[dallison-cisa]

@shelbyc ,

Based on the above discussion, CVSS V3.1 vectorString has been updated to the following:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

[ohader]

Hi @shelbyc, thank you for the detailed analysis and for taking the time to walk through this issue. I appreciate the clarity of your response.

I realize that my earlier comments were largely driven by a consumer‑centric view of the technical details, and I inadvertently left out the maintainers' perspective and their statements. That focus probably made my assessment a bit one‑sided and biased.

I also appreciate that the CISA‑ADP CVSS scoring has been adjusted to a more realistic value.
Thanks again for your thoughtful input and for helping ensure the advisory reflects a balanced view.

[ohader]

Users who still rely on version 6.x of the package can explicitly ignore the CVE in their projects:

composer config -jm audit.ignore '{"CVE-2025-45769":"disputed"}'

This adds the following section to composer.json:

"audit": {
    "ignore": {
        "CVE-2025-45769": "disputed"
    }
}

[stepo2]

@shelbyc

why we think the advisory is appropriate to keep in the ADB.

You reasons for taking it into the ADB are fully valid, from your maintainers POV. But this issue here is about removing it and it explains why your decission was most likely wrong from a developers/users POV.

Since the maintainer decided the issue described in GHSA-2x45-7fc3-mxwq required a patch

Because at this point in time it was unclear whether firebase/php-jwt is actually responsible to validate key length. The goal at this point in time was to just get away "the big red warnings" (due to the CVE). Now it turned out: no it is not the responsibility of firebase/php-jwt. So the CVE is invalid because there are more insights.

The given patch is still super nice and useful, but it doesn't render the pre-patched version any more insecure..