I stumbled upon CVE-2025-55182 while skimming through fresh vulnerability reports. React Server Components, Flight protocol, some weird deserialization stuff. At first glance it looked like one of those bugs that sound scary but never really work outside a lab.

Still, something felt off. The description mentioned $@ deserialization, then handling, Chunk states. That combination immediately raised a red flag. This didn’t look theoretical. It looked exploitable.

The public PoC was incomplete and messy, so instead of trying to adapt it, I just opened Go and started writing my own implementation to see where it breaks. It didn’t take long.

The first Next.js 15.x target responded exactly how I hoped. Then another one did. And another. Some of them were clearly production systems. No auth, no crashes, no noise. Just clean code execution inside the normal RSC request flow.

At that point it was obvious this wasn’t an edge case. A lot of real-world apps were vulnerable.

I added a proper check mode to avoid blind exploitation, version detection, batch scanning, proxies, stealth options. Not because I planned to weaponize it, but because testing one URL at a time quickly became pointless.

What surprised me the most was how silent the whole thing was. The servers didn’t panic, didn’t log anything interesting, didn’t even slow down. The exploit blended perfectly into regular React Server Component traffic.

Later I added a memory-only shell that lives until process restart. No files, no disk artifacts. Just because it naturally followed from understanding how deep the bug goes.

In the end, I published a Go PoC for CVE-2025-55182 on GitHub. Strictly for research and authorized testing. But this whole thing is a good reminder - once you mess up deserialization in a framework used by millions, the blast radius is massive.

GitHub: https://github.com/keklick1337/CVE-2025-55182-golang-PoC