A webpage you visit in your browser can read source files from your Next.js dev server. CVE-2025-48068, disclosed by researchers sapphi-red and Radman Siddiki and published by Vercel on May 28, 2025, lets any cross-origin page inject a <script> tag pointing at predictable paths on localhost:3000 and exfiltrate the response. Vercel classifies the severity as low. But the same bug class just resurfaced in webpack-dev-server nine days ago, which means the assumption that localhost is a trusted enclave is still baked into frontend tooling.
What the vulnerability actually does
The bug is really two bugs, both stemming from missing origin validation on the Next.js development server.
The first is Cross-Site WebSocket Hijacking (CSWSH). The dev server’s WebSocket connection does not verify the Origin header of incoming requests. A malicious page opens a WebSocket to ws://localhost:3000 and receives hot-module-replacement messages, which can include source code content.
The second is Cross-Origin Script Inclusion. The dev server serves JavaScript source files at predictable paths. An attacker page injects a <script> tag referencing, say, /app/page.js on localhost:3000. The browser fetches it. Because the script is included (not fetched via fetch()), the same-origin policy does not block it, and the attacker page can read the loaded module’s exports or use error-based leak techniques to reconstruct the source.
Both sub-issues affect Next.js 13.0.0 through 14.2.29 and 15.0.0 through 15.2.1.
Why “low severity, dev-only” understates the risk
Vercel’s framing is technically correct. This is not a production vulnerability. No deployed Next.js app is affected. The severity rating reflects that. But the severity rating assumes the dev server holds no sensitive data.
In practice, a developer running next dev typically has .env files loaded with production API keys, database credentials, and third-party service tokens. The dev server injects these as environment variables at build time. A cross-origin script inclusion attack that pulls /app/api/route.js or any server-component source can expose those secrets directly.
The social engineering angle is also straightforward. A targeted developer receives a link to a “design review,” “storybook preview,” or any plausible React-ecosystem URL. They click it. If next dev is running, the page has seconds to enumerate predictable source paths and exfiltrate whatever it finds.
The same bug class keeps recurring
CVE-2025-48068 is not an isolated finding. It is one instance of a class of vulnerabilities in JavaScript development servers that serve source code over plain HTTP with no origin checks.
On May 18, 2026, CVE-2026-6402 was published for webpack-dev-server. It is the same pattern: over plain HTTP, Sec-Fetch headers are absent, allowing cross-origin <script> inclusion and full module source exfiltration. The GitLab advisory for CVE-2026-6402 classifies it identically.
The lineage goes back further. CVE-2025-30359 (webpack-dev-server, earlier in 2025) was the same cross-origin exposure in a different context. The 2018-era CVE-2018-14732 in webpack-dev-server was a prior instance of the same trust boundary failure. Every few years, a frontend dev-server gets caught assuming that localhost traffic only comes from the developer’s own tabs.
This is not a Next.js problem or a webpack problem. It is a frontend-tooling problem. Development servers serve raw source over HTTP with no authentication and historically no origin validation, because the assumption was that nothing on the developer’s machine would make hostile cross-origin requests. That assumption stopped being safe years ago.
What to do right now
Upgrade. Next.js 14.2.30 and 15.2.2 fix the vulnerability. Current Next.js versions block cross-origin requests to dev-only assets and endpoints by default. The allowedDevOrigins option exists to grant access to additional origins beyond the server’s default hostname. Developers still running the initial 14.2.30 or 15.2.2 patched releases, where origin checks were opt-in, should upgrade to a current version for default-on protection.
Isolate your dev browser profile. If you run next dev with production credentials loaded, do not use the same browser session to browse the web. A separate Chrome profile or Firefox container costs nothing and eliminates the entire attack vector.
Audit what your .env files contain during dev. If your development environment loads production database credentials, API keys with write access, or third-party tokens, this CVE gives a malicious page a path to exfiltrate them. Use separate, scoped credentials for local development.
Localhost is not a security boundary
The recurring lesson across CVE-2025-48068, CVE-2026-6402, and their predecessors is that frontend tooling still treats the loopback interface as private. It is not. Any page the developer visits can address localhost:3000, localhost:8080, or any other port the dev server listens on. The browser’s same-origin policy protects against fetch() cross-origin reads, but <script> inclusion and WebSocket connections operate under different rules.
Vercel’s posture on this is worth noting in context. In April 2026, the company disclosed a separate security breach traced to a compromised third-party AI tool (Context.ai), unrelated to this CVE. Two distinct security incidents in twelve months, one in the product and one in the supply chain, do not establish a pattern on their own. The fix did ship as opt-in when 14.2.30 and 15.2.2 were released, only becoming default-on in later versions. Any team that upgraded to those initial patched releases and assumed they were covered should verify their configuration.
The practical takeaway is narrow and unglamorous: upgrade to a current Next.js version, stop loading production secrets into dev environments, and treat your development server as an internet-facing surface. Every frontend team running next dev should do this today. The bug class will keep appearing in new tooling until origin validation is the default everywhere.
Frequently Asked Questions
Has CVE-2025-48068 been exploited in the wild?
No confirmed exploitation has been reported. The EPSS model rates the 30-day exploitation probability at 0.01%, and the CVSS v4.0 base score is 2.3 (LOW), classified under CWE-1385 for missing origin validation in WebSocket handling. The narrow attack window, requiring a developer to visit a hostile page while their dev server runs, contributes to the low exploitation likelihood.
Why does plain HTTP make this cross-origin attack possible?
Over plain HTTP, browsers omit Sec-Fetch-Site and Sec-Fetch-Mode request headers. Without those, a server cannot distinguish a legitimate same-origin navigation request from a hostile cross-origin <script> tag inclusion. The webpack-dev-server advisory for CVE-2026-6402 identifies this header gap explicitly as the root cause, and the same mechanism applies to the Next.js dev server.
Are there other CVEs in this class beyond webpack-dev-server?
SentinelOne’s vulnerability database flags CVE-2026-44576 and CVE-2026-44574 as related entries in this cross-origin dev-server exposure class. Neither has been independently confirmed by other sources as of May 2026, so teams should monitor NVD for validation rather than assume their tooling is affected or covered by existing patches.
What was the disclosure timeline for CVE-2025-48068?
Vercel published their changelog advisory on May 28, 2025. The CVE entry appeared on the National Vulnerability Database two days later, on May 30, 2025. That split timeline is worth noting: the vendor advisory and the authoritative NVD record did not ship simultaneously, which means teams relying solely on NVD alerts would have had a two-day blind spot before the CVE was trackable in their vulnerability scanners.