We paid $1 million to hackers to harden our firewall defenses.
Today we're telling the story of how we strengthened our WAF, disclosing a runtime mitigation layer for the first time, and how we partnered with
@Hacker0x01 to defend against React2Shell.
vercel.com/blog/our-mi...
⛩️ Waku v0.27.3 has been released.
- Dependency updates addressing the critical React Server Components security vulnerability
- Various small improvements
All users should update immediately: github.com/wakujs/waku/...
At some point in the future we will share details. For now we are withholding to allow the industry to protect themselves given the severity of the vulnerability
A critical vulnerability in React Server Components (CVE-2025-55182) affects React 19 and frameworks, including Next.js (CVE-2025-66478).
All users should upgrade to the latest patched version in their release line.
nextjs.org/blog/CVE-20...
Our thanks to the @react.dev team for informing us so that we could provide mitigation for our users.
bsky.app/profile/deno...
Thank you to the React and Next.js teams for involving us early and for the clear communication. We were able to patch our network ahead of disclosure to help keep our customers secure.
bsky.app/profile/netl...
There is critical vulnerability in React Server Components disclosed as CVE-2025-55182 that impacts React 19 and frameworks that use it.
A fix has been published in React versions 19.0.1, 19.1.2, and 19.2.1. We recommend upgrading immediately.
react.dev/blog/2025/12...
Basically make dynamic things as lazy as possible. Unwrapping them deeply where you likely have a good fallback UI that isn’t super generic and super high up
You can serialize a promise to a client component without awaiting it on the server. So you can pass the pending logged in value into a context provider and then `use` it deeply on the client with Suspense around wherever it is read
… with “use cache: private”
Even for high cardinality and user specific data we recommend passing the param or cookie or other runtime value into the “use cache” function as an argument. But sometimes that’s just not how a project is set up so you can opt into allowing these runtime values “on the inside” of a use cache…
… never read back from it.
Use cache private is sort of a different consideration. This is more about how you have your data fetching code factored. You might have a common data fetching utility that reads cookies internally. Because of this you can’t use it inside the other “use cache” types
Since this data isn’t going to be pre-rendered into a static shell you might want to make renders faster by server caching it in which case “use cache: remote” can make sense. But you should consider if the data will even have a decent cache utilization rate. No point in writing to a cache if you…
We are also looking at how we can support server caching in a way that is both local (latency free) and cheap (ideally cost free or on the order of how much you revalidate rather than read). It’s a hard problem but we’re very interested in solving it
… bigger role in future features where tags on the client allow very fine grained refetching.
At the moment we don’t server cache the default “use cache” on Vercel. So if a Cache Function is encountered outside of static pre-rendering it will be forgotten on the server. But again it’s still providing important information to the client router in some circumstances and will play a…
Also to be clear by default self hosted next doesn’t actually remotely store cache entries. You have to plug it into some service. Of course hosts for Next.js like Vercel can provide one for you as part of their integration with next
Part of this feature rollout that is hard is we have `unstable_cache` which is just a server caching API. And it’s so easy to assume that “use cache” is this API stabilized. But really it’s like “use cache” is entirely new and the storage engine for “…: remote” is the `unstable_cache` replacement
Yeah exactly
Also maybe you never revalidate by path. It’s a convenient API but it will over revalidate because it doesn’t target specific data updates
Forbidding cacheTag is good but you also need to consider revalidatePath. It’s unfortunate but every cache is implicitly tagged with the path of the segment it’s read from. You could sort of define your own semantics here though and say that a revalidatePath doesn’t expire these cache entries
But for teams that have solved this for ISR the same techniques can generally work for the use cache entries
There is still a ton of value here with the feature
… system coordinate. Since the cache information is powering ISR and prefetching in the client the high cardinality entries may not be worth also server caching (i.e. in redis) nor in local memory (because tag invalidation is hard)
Yup! If you self host you already have to manage this for ISR if you run more than one process. so the same kind of tag management is required for cache handlers. You can accomplish this by having a forgetful default cache (memory size zero) or by going remote and letting some other…
… paint then you can configure the app to achieve that
But we need to balance what is possible with what the framework nudges you towards. If it were trivial to make blocking routes most Next.js apps would be slow by default. We want the inverse. It’s fast by default but if you know you have a super fast backend or you care more about a single complete…
“I’m ok waiting for a more complete UI”
Yeah I think there is maybe an analog for the idea of opting into runtime prefetching. Maybe you want to opt into runtime “initial load”. This can’t ever be instant because we need the request data but if you express an intent to allow for this maybe that is the way to say…
We are still missing features that make client data fetching attractive like better pagination support and lazy loading UI that is not part of the initial page view or live updates. We are going to tackle of these cases soon
