Vulnerable JS Library (nextjs)

[dsotirho-ucsc]

From ZAP scan 2026-05-05
Severity: Medium

The identified library appears to be vulnerable.

Recommended Solution

Upgrade to the latest version of the affected library.

Other Info

The identified library nextjs, version 15.5.15 is vulnerable.

CVE-2025-59472
CVE-2026-27980

Evidence

https://anvilproject.org/_next/static/chunks/main-5fe8474ae46b6e58.js
https://explore.anvilproject.org/_next/static/chunks/main-48f8a7016b502370.js
https://data.humancellatlas.org/_next/static/chunks/main-5fe8474ae46b6e58.js
https://explore.data.humancellatlas.org/_next/static/chunks/main-48f8a7016b502370.js

="15.5.15",X=(0,P.default)(),W=e=>[].slice.call(e),G=!1;class q extends E.default.
Component{componentDidCatch(e,t){this.props.fn(e,t)}componentDidMount

[dsotirho-ucsc]

Assignee to label issue consistent with similar ones from the past.

[frano-m]

Both CVEs flagged by ZAP are not present in our currently-installed Next.js 15.5.15 — neither GHSA lists 15.5.15 in its vulnerable version ranges, and npm audit against our lockfile reports neither CVE.

CVE-2026-27980 — Unbounded next/image disk cache growth
GHSA: GHSA-3x4c-7xq6-9pq8
Vulnerable: >=10.0.0, <15.5.14 and >=16.0.0-beta.0, <16.1.7
Patched: 15.5.14, 16.1.7
We are on 15.5.15 — one patch ahead.

CVE-2025-59472 — Unbounded memory consumption via PPR resume endpoint
GHSA: GHSA-5f7q-jpqc-wp7h
Vulnerable: >=16.0.0-beta.0, <16.1.5, >=15.6.0-canary.0, <15.6.0-canary.61, plus canary slices in 15.0.0–15.5.1
Patched: 16.1.5, 15.6.0-canary.61
Our 15.5.15 is not in any listed vulnerable range.

npm audit against our lockfile confirms neither CVE is reported on our installed next@15.5.15.

Suggested next step: could compliance re-run the ZAP scan? I expect this to clear once the scanner refreshes, since 15.5.15 is outside the vulnerable ranges of both advisories.

[frano-m]

Given the above, would it be appropriate to close this ticket as not-applicable, or would you prefer to keep it open until compliance has re-run ZAP and confirmed the finding has cleared? Happy either way — just flagging that there's no code change pending from our side.

[hannes-ucsc]

We can close this issue as completed once the scanner doesn't produce the finding anymore. I have no reason to believe our scanner is wrong about this, so something needs to be done. If I understand the above correctly, then building and deploying the application again is expected to fix the issue since dependencies are automatically updated at build time. Could you please confirm, @frano-m?

At the moment we appear to have no Software Bill of Materials (SBOM) for the Data Browser. Is there a npm command you recommend for producing one? We could add it to our CD process so that we always know which specific versions of dependencies were deployed.