13 Advisories, One Coordinated Fix
On May 6, 2026, the Next.js and React teams disclosed 12 security vulnerabilities — one in React Server Components and eleven in Next.js — followed by a thirteenth advisory on May 7. The vulnerabilities span middleware bypass, denial of service, Server-Side Request Forgery (SSRF), cache poisoning, and cross-site scripting. Next.js versions 15.5.18 and 16.2.6 patch all of them.
The most severe is CVE-2026-44578, an SSRF vulnerability in the Next.js WebSocket upgrade handler with a CVSS score of 8.6. CVE-2026-44580 is a cross-site scripting vulnerability affecting the beforeInteractive Script component, present in every Next.js version from 13.0.0 onward. These are not theoretical — they affect production deployments processing real traffic.
The Honest Assessment
WebPulse's editorial stance is data-driven, not partisan. Next.js scores 88 on AI-Readiness and ranks among the top frameworks for modern web development. Thirteen security advisories in a single release is a significant number. It would be dishonest to cover WordPress's 18,005 CVEs without acknowledging that modern frameworks have vulnerabilities too.
The difference is not in the existence of vulnerabilities. It is in the response model. Vercel coordinates with the React team, discloses all issues simultaneously, ships patches for every supported version, and publishes detailed advisories within hours. The patch is available before most organizations know the vulnerability exists. WordPress plugin vulnerabilities are discovered by external researchers, disclosed through Wordfence or other third parties, and patched by individual plugin developers on their own timelines.
The React Server Components Factor
One of the 13 advisories affects React Server Components (RSC) directly — the architecture that enables Next.js, Remix, and other React frameworks to render components on the server. An RSC vulnerability is not Next.js-specific; it affects every framework that implements React Server Components. The attack surface is in the shared infrastructure, not the individual framework.
This is the trade-off of shared infrastructure. When React's core team fixes an RSC vulnerability, every framework that uses RSC gets the fix. When a WordPress plugin developer fixes a vulnerability, only that plugin's users get the fix — and only if they update. The shared infrastructure model distributes both risk and remediation. The plugin model fragments both.
What This Means for Migration Decisions
Organizations evaluating a WordPress-to-Next.js migration should not expect zero vulnerabilities. They should expect a different vulnerability profile: fewer total CVEs, higher average severity, faster patch availability, and coordinated disclosure. The operational burden shifts from 'monitor 27 independent plugin developers' to 'track one framework's security releases.'
For organizations that want zero runtime vulnerabilities, the answer remains static-output frameworks. Hugo, Eleventy, and Astro in static mode have no server-side attack surface — no middleware to bypass, no WebSocket handlers to SSRF, no server components to exploit. The trade-off is functionality: no server-side rendering, no API routes, no dynamic content. For content-focused sites, that trade-off is often the right one.
