- Cloudflare's Vinext 1.2 fixes several places where it differed from Next.js, including middleware skipping public files and cache keys that could match two different requests.
- The lesson: a framework's security often rests on unstated behaviour, and moving platforms can silently remove it.
- Teams running Vinext should upgrade @vitejs/plugin-rsc to 0.5.37 and add the new middleware settings to existing projects by hand.
A framework makes promises it never writes down. Developers assume middleware runs before a page loads. They assume one customer's cached answer is not handed to another. These habits are not features on a price list. They are the quiet rules that security rests on.
Vinext 1.2 shows how many of these rules there are. Vinext is Cloudflare's project for running Next.js apps on other platforms, including Workers. According to the Vinext release post, most of this release is fixes. The team says many came from three kinds of checking: comparing against Next.js 16, running a nightly Next.js deploy test suite, and running the next-intl localization library's own tests against Vinext.
The lesson here is that a compatible framework is only as safe as its least-noticed behaviour. Copying the features is the easy part.
When the platform changes the rules
The clearest example is middleware, the code that checks a request before it is served. Next.js applies middleware to any path that matches its configured pattern. That includes files in the public folder. Workers works differently. Its Static Assets feature returns those files first, before any Worker code starts. Middleware therefore never got to see them.
Any team that used middleware to guard a public file would have had a gap, because the check was skipped. Vinext now generates a runWorkerFirst setting when you run vinext init. It sends everything except the hashed build output through the Worker.
Existing projects are not changed. The release post says teams that want middleware to cover public files must add the settings themselves and keep both exclusions.
The image optimizer had the same problem. A public image that middleware blocked could previously be read through the /_next/image route. It now goes through middleware too.
When two requests share one cache entry
A cache stores an answer so it can be reused. It finds the answer using a key built from the request. If two different requests produce the same key, one caller's result can be served to another.
The release post says several fixes address edge cases of exactly this kind. The release notes list many key changes. One treats the x-api-key header as a credential for shared response caches. Another keys unstable_cache by the source of its callback, even when keyParts is supplied. A third swaps very long cache identities for a SHA-256 hash, a short fingerprint of fixed length.
The notes do not report that any of these were exploited. They do show how many small details decide who sees whose data.
Server Actions and shared state
Server Actions are functions a browser can call on the server. The release post describes a flaw in older versions of @vitejs/plugin-rsc. A client could take the encrypted data that one action had captured and submit it to a different action on the same route. Version 0.5.37 ties that data to its own action. Vinext now stops with an error on older versions. Inline "use cache" functions get a matching defence against forged captures.
A separate fix targets leaked state. Vinext now loads Server Action modules apart from whichever request happened to trigger the first load. Code at the top level of such a module can call cookies() or headers(). That code can no longer hold on to the first visitor's values and reuse them for later requests handled by the same running instance, known as an isolate.
Why the Next.js reference matters
Vinext measures itself against Next.js, so Next.js behaviour sets the bar. WebPulse's September 2026 scan of the Tranco top 10,000 domains found Next.js on 791 of the 2,491 sites where a platform was detected. That is a sample of detected sites, not the whole web. Next.js is the platform detected most often in that sample, so its behaviour is the reference many teams already expect.
What to ask your team
If you run Vinext, or are considering it, put these questions to the people who build it:
First, is @vitejs/plugin-rsc at 0.5.37 or newer? Projects made with vinext init carry it as a dev dependency, so it must be upgraded alongside Vinext.
Second, does any middleware guard public files or images? If so, has someone added the runWorkerFirst settings to the existing config?
Third, which cached responses depend on a credential, such as an API key header? Has someone checked that those keys are separate for each caller?
A framework's promises are only as strong as the tests that check them. Ask which behaviours your platform change quietly removed.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare (cloudflare/vinext on GitHub).
