Remember when server responses were just JSON? Such simple times. Now we have React Server Components shipping serialized component trees over the “Flight” wire protocol, and your Burp tabs are giving you what looks like a cat walked across a keyboard.

If you’re testing Next.js apps (or the smaller base of Waku, Shopify Hydrogen, and RedwoodJS users), you’ve seen text/x-component responses. You’ve squinted at them, extracted a JWT manually, and wondered what you were doing with your life. This extension helps with your squinting.

React Server Components (RSC) let components execute on the server rather than the client. The server renders components, fetches data directly from databases or APIs, and sends a serialized representation to the client which reduces bundle size and round trips.

To do this, React uses an internal serialization format called the Flight protocol. It's a line-based, streamable format that encodes component trees, data payloads, and references to client components, looking something like <chunkid>:<payload_marker><serialized_data>.

So What

The Flight protocol has some interesting implications on the application surface:

• Deserialization risks. Flight payloads are parsed server-side. The recent React2Shell vulnerability (CVE-2025-55182, CVSS 10.0, December 2025) demonstrated RCE via crafted Flight payloads exploiting unsafe deserialization. If you're testing RSC apps, check that it's been updated!
• Server Actions are RPC endpoints. When developers add 'use server', the framework creates a callable endpoint. These are POST requests with a Next-Action header and arguments serialized in the body—they need the same auth/authz scrutiny as any API endpoint. Check out the Burp Suite extension Next.js Server Action Analyzer.
• Serialized data leaks. Component trees can embed data you wouldn't expect in a response: route params, database records, internal URLs, tokens, etc

What The Extension Does

The RSC Parser extension deserializes Flight protocol responses and surfaces the interesting bits:

• Route parameters — The /users/:userId/settings stuff. Of IDOR interest
• Sensitive values — JWTs, API keys, tokens. Detected by format, so that x7_temp_val field hiding a JWT is highlighted
• Entity arrays — Those 25-record user lists that probably shouldn’t include everyone’s phone number
• Server actions — The $F references pointing to RPC endpoints begging for auth bypass testing
• Text content — Internal details hiding in plain sight

Installation

Jython. Set your Python environment in Extender > Options, then load nextjs-rsc-parser.py.

Interface

Four tabs in the HTTP Proxy page when viewing RSC responses for some human-readable output, raw JSON, and keyword based security things.

Right-click gives you chunk URL extraction, component analysis, and export options.

Practical Applications

Route params with UUIDs or sequential IDs are good for access control testing. Server actions ($Fa, $Fb, etc.) are RPC endpoints. Fuzz them for missing auth checks.

Entity arrays showing up with more records than your test user should see is another obvious one. URLs buried in text content might reveal that environment someone forgot to lock down.

None of this is revolutionary but this extension lets you get insight into the application faster.

Final Thought

React’s architectural decisions have created attack surface that looks like gibberish to humans and standard tooling. This extension helps makes it legible. Though the React authors will probably invent something new to parse next month anyway.

Check it out at https://github.com/Adversis/nextjs-rsc-parser