Missing next.js GHSA-9qr9-h5gf-34mp

[jmion2s]

trivy-db published 2025-12-04T12:25:36.62596429Z does not include
GHSA-9qr9-h5gf-34mp published 2025-12-03T15:43:12Z
but does include the related
GHSA-fv66-9v8q-g76r published 2025-12-03T15:48:19Z

Speculation:
GHSA-9qr9-h5gf-34mp references CVE-2025-66478 which is rejected by NVD (correction: by github, see below) as a duplicate of CVE-2025-55182 aka GHSA-fv66-9v8q-g76r
However that status is debatable, as the advisories name different software as affected, the former "next", the later "react-server-dom-*"
trivy-db probably drops it because of the cve rejection.
This may "work as intended" and require an upstream solutions. In the meantime this is still a false negative in trivy-db and should be double checked.

Reproduction:

echo '{"dependencies":{"next": "16.0.6"}}' > package.json
npm install --package-lock-only
trivy fs --scanners vuln .

npm warns about a critical vulnerability, trivy does not

Related:
I've asked next.js to dispute the rejection: vercel/next.js#86834 but as @mswilson points out that may not happen.
He opened github/advisory-database#6509 to remove the alias from GHSA-9qr9-h5gf-34mp which probably also fixes this.

[trevermckee]

This is also my analysis currently @jmion2s.

It seems like this vulnerability should be reported given that next.js bundles/vendors these libraries and given the different sources are reporting different information here. The NVD rejection is taking prioritization over the GHSA advisory in pkg/vulnsrc/vulnerability/vulnerability.go:217.

It's a difficult situation given that GHSA is still reporting this advisory, but NVD has rejected it. The code for react-server-dom-* is compiled into the next.js repository here. This would prevent any transitive or traditional lock file scanning from triggering for these libraries.

This is affecting our ability to use this tool currently to investigate this next.js CVE.

[MedUnes]

Trivy Fails to Detect Critical Next.js RCE Vulnerability (CVE-2025-66478 / CVE-2025-55182)

Summary

Trivy is not detecting a CRITICAL severity RCE vulnerability (CVSS 10.0) in Next.js 15.4.7 and React 19.1.0, despite the vulnerability being present in the GitHub Security Advisory database and the packages being clearly vulnerable according to the advisory's version ranges.

This is extremely dangerous as automated security pipelines relying on Trivy will not alert on this critical vulnerability, potentially leaving production systems exposed to remote code execution.

Environment

• Trivy Version: Latest (as of 2025-12-04)
• Database Version: mirror.gcr.io/aquasec/trivy-db:2 (downloaded 2025-12-04)
• Scan Target: yarn.lock with Next.js 15.4.7 and React 19.1.0
• Scanner: trivy fs --scanners vuln ./

Vulnerability Details

• CVE-2025-66478 (Next.js-specific CVE)
• CVE-2025-55182 (Upstream React CVE)
• GHSA-9qr9-h5gf-34mp (GitHub Security Advisory)
• Severity: CRITICAL (CVSS 10.0)
• Type: Remote Code Execution in React Server Components
• Published: 2025-12-03

Affected Versions

According to the GHSA, the following versions are vulnerable:

• Next.js: 14.3.0-canary.77 through 16.0.6 (multiple version ranges)
• React: 19.0.0, 19.1.0, 19.1.1, 19.2.0

My package.json contains:

"next": "15.4.7"    // VULNERABLE - needs 15.4.8+
"react": "19.1.0"   // VULNERABLE - needs 19.1.2+

Steps to Reproduce

1. Verified GHSA exists in trivy-db source cache

$ cat cache/ghsa/advisories/github-reviewed/2025/12/GHSA-9qr9-h5gf-34mp/GHSA-9qr9-h5gf-34mp.json | jq
{
  "schema_version": "1.4.0",
  "id": "GHSA-9qr9-h5gf-34mp",
  "modified": "2025-12-03T19:07:11Z",
  "published": "2025-12-03T19:07:11Z",
  "aliases": [
    "CVE-2025-66478"
  ],
  "summary": "Next.js is vulnerable to RCE in React flight protocol",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "15.4.0-canary.0"
            },
            {
              "fixed": "15.4.8"
            }
          ]
        }
      ]
    }
    // ... additional version ranges
  ]
}

2. Built fresh trivy-db from source

$ cd trivy-db
$ make build

3. Checked compiled database - Next.js CVE is MISSING

# The Next.js CVE is NOT in the database
$ ~/go/bin/bbolt get ./out/trivy.db vulnerability CVE-2025-66478
Error key not found for key: "CVE-2025-66478"

# The GHSA ID is NOT in the database
$ ~/go/bin/bbolt get ./out/trivy.db vulnerability GHSA-9qr9-h5gf-34mp
Error key not found for key: "GHSA-9qr9-h5gf-34mp"

# Only the upstream React CVE exists
$ ~/go/bin/bbolt get ./out/trivy.db vulnerability CVE-2025-55182 | jq
{
  "Title": "React Server Components are Vulnerable to RCE",
  "Description": "A pre-authentication remote code execution vulnerability exists in React Server Components...",
  "Severity": "CRITICAL",
  "VendorSeverity": {
    "ghsa": 4
  },
  "CVSS": {
    "ghsa": {
      "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "V3Score": 10
    }
  }
  // ... references
}

4. Scanned vulnerable project - NO DETECTION

$ trivy fs --scanners vuln ./
# removed content here for privacy reasons, but the results do not list any of the expected Next and/or React Vulnerabilities.

Result: No detection of CVE-2025-66478 or CVE-2025-55182 despite vulnerable Next.js 15.4.7 and React 19.1.0 being present.

5. Verified yarn.lock does not contain react-server-dom packages

$ grep -i "react-server-dom" yarn.lock
# No results

Root Cause Analysis

Based on my investigation, I believe the issue is:

1. GHSA deduplication removes Next.js CVE: The trivy-db build process sees that GHSA-9qr9-h5gf-34mp has an alias CVE-2025-66478 that references the upstream React vulnerability CVE-2025-55182. It likely deduplicates by only storing the React CVE and discarding the Next.js-specific advisory.

2. Database only contains React packages, not Next.js: The stored CVE-2025-55182 entry likely only lists the specific React packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack) as affected, not the next package itself.

3. yarn.lock doesn't explicitly list react-server-dom packages: These packages are transitive dependencies of Next.js and may not appear explicitly in the lockfile, so Trivy has nothing to match against.

4. No version matching for Next.js: Even though the GHSA clearly states Next.js 15.4.7 is vulnerable, Trivy never checks the next package version against this vulnerability because the database entry doesn't include Next.js.

Expected Behavior

Trivy should detect and report:

next      CVE-2025-66478   CRITICAL   fixed   15.4.7   15.4.8   Next.js is vulnerable to RCE in React flight protocol
react     CVE-2025-55182   CRITICAL   fixed   19.1.0   19.1.2   React Server Components are Vulnerable to RCE

Actual Behavior

Trivy reports ZERO CRITICAL vulnerabilities and does not mention CVE-2025-66478 or CVE-2025-55182 at all.

Impact & Danger

This is extremely dangerous because:

1. CVSS 10.0 RCE vulnerability goes undetected - Remote code execution with no authentication required
2. Automated CI/CD pipelines will not block vulnerable deployments - Security gates will pass
3. No alerts or notifications - Teams relying on Trivy won't know they're vulnerable
4. False sense of security - "Scan passed" when production is actually critically vulnerable
5. Widespread impact - Next.js is extremely popular; many projects affected

This is not a theoretical concern - this exact scenario happened to me today. I only discovered the vulnerability through external sources, not through Trivy.

Proposed Solution

The trivy-db build process should:

1. Preserve framework-specific CVEs: When a GHSA references both a framework (Next.js) and upstream library (React), store entries for BOTH packages
2. Match against parent packages: If react-server-dom-* packages are vulnerable and these are dependencies of next, create vulnerability entries for next with the appropriate version ranges
3. Don't over-deduplicate: Keep both the aliased CVE (CVE-2025-66478) and the upstream CVE (CVE-2025-55182) when they apply to different packages
4. Test with real-world lockfiles: Ensure detection works when transitive dependencies aren't explicitly listed

Additional Context

• Advisory: GHSA-9qr9-h5gf-34mp
• Upstream React Advisory: GHSA-fv66-9v8q-g76r
• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-66478

Question

Is there a reason why react-server-dom-* packages don't appear in yarn.lock even though Next.js depends on them? If these are internal/bundled dependencies, how should Trivy detect vulnerabilities in them?

---

This issue needs urgent attention as it represents a significant gap in Trivy's ability to detect critical vulnerabilities in one of the most popular JavaScript frameworks.

[mswilson]

NVD did not reject CVE-2025-66478. The GitHub CNA did (per https://github.com/CVEProject/cvelistV5/blame/71b6e72b338b2f880ea8434eeb10bb62ee995157/cves/2025/66xxx/CVE-2025-66478.json#L17), as they are required to do under the CNA operational rules:

https://www.cve.org/resourcessupport/allresources/cnarules

4.1.12 The act of updating Product dependencies MUST NOT be determined to be a Vulnerability, regardless of whether the dependencies have Vulnerabilities. For example, updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library, and a Vulnerability advisory for the Product SHOULD reference the CVE ID for the Vulnerability in the library

[jmion2s]

@MedUnes your assumption that "react":"19.1.0" is affected by GHSA-fv66-9v8q-g76r is wrong: the "react" module contains only the functionality necessary to define React components, it is not listed in that advisory and should not be flagged. To answer your question how next uses the affected code see vercel/next.js#86793 (comment) which also answers why the react-server-dom-* modules do not appear in your yarn.lock. For your second question, trivy should detect affected next versions by checking against GHSA-9qr9-h5gf-34mp

@mswilson thanks for the correction who, and explanation why the CVE was rejected. Let's see if your pr also fixes this.

Leaves me wonder if this is a rare case, or if if trivy-db often drops valid GHSAs for having a bad alias.

[knqyf263]

Thanks for the reports. As you correctly understand, it's due to rejection. Trivy relies on information from the NVD. If a rejected CVE-ID exists in an alias, that CVE-ID is treated as the primary ID, and if the CVE-ID has been excluded from the NVD, it is removed from the database. In other words, it should work if the CVE-ID is removed from the alias.
In the meantime, we will attempt to detect it by overwriting the database on our side.

[knqyf263]

We added a custom advisory as a workaround until GHSA merges github/advisory-database#6509, and Trivy now detects GHSA-9qr9-h5gf-34mp 🎉

Note

Trivy downloads the vulnerability database from mirror.gcr.io by default, but it may download older assets because of the cache. In that case, you can directly download it from GHCR or Docker Hub.

$ trivy fs ./pnpm-lock.yaml --scanners vuln --db-repository ghcr.io/aquasecurity/trivy-db --table-mode detailed -q

pnpm-lock.yaml (pnpm)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)

┌────────────────────┬─────────────────────┬──────────┬────────┬───────────────────┬────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────┐
│      Library       │    Vulnerability    │ Severity │ Status │ Installed Version │                     Fixed Version                      │                           Title                            │
├────────────────────┼─────────────────────┼──────────┼────────┼───────────────────┼────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────┤
│ next               │ GHSA-9qr9-h5gf-34mp │ CRITICAL │        │ 16.0.0            │ 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 │ Next.js is vulnerable to RCE in React flight protocol      │
│                    │                     │          │        │                   │                                                        │ https://github.com/advisories/GHSA-9qr9-h5gf-34mp          │
└────────────────────┴─────────────────────┴──────────┴────────┴───────────────────┴────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────┘