An advisory is not evidence of an incident
The Next.js team published an upstream security update on 14 October 2026 covering two critical remote-code-execution issues and a high-severity denial-of-service issue. The announcement identified patched releases 16.4.1 and 15.5.28. These are the historical October patch baselines, not a recommendation to stop updating there.
The announcement describes affected Cache Components returning multiple typed arrays, an upstream image-processing vulnerability on glibc-based Linux, and Server Actions CPU exhaustion. The image issue has an upstream sharp workaround; the cache issue has no known workaround in the announcement. Applicability differs by feature and runtime. These are vendor-disclosed vulnerabilities; this article does not allege that Web3Sec or any particular organization was exploited.
The November release changes the baseline
The maintainers published further advisories on 3 November 2026. For example, GHSA-f3mh-rxg3-f5g2 describes an internal response header exposing cookies set through NextResponse on affected Edge runtime routes. Same-origin JavaScript could read the duplicate value even when the cookie was HttpOnly. Its patched versions are 16.4.5 and 15.5.29.
As of this analysis on 8 November 2026, review those newer fixes alongside the October update. Recheck the official advisories and current release for your supported version line before selecting an upgrade. A patched version cited in a historical advisory is a minimum for that issue, not a permanent statement that a release is free of vulnerabilities.
Verify the release that receives traffic
Our analysis: inventory the resolved framework version, runtime, router and enabled features in the deployed artifact. Check the lockfile and dependency tree for the native image library as well as the top-level package. A manifest edit alone does not demonstrate that production uses the fix.
Build with the updated lockfile, run the affected application flows, and confirm deployment completion. Validate representative cache isolation, image requests and cookie-setting responses where those features are used. Check that obsolete deployment instances are no longer receiving traffic. Keep the previous artifact for diagnosis, while ensuring rollback procedures cannot silently restore a known-vulnerable release.
Controls to take away
- Check newer advisories before choosing a historical patched version.
- Assess the deployed features, runtime and resolved upstream libraries.
- Verify the rebuilt release is the one actually receiving production traffic.
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.