Regex Renegade: Turning Seroval Serialization into a DoS Weapon

In the modern JavaScript ecosystem, specifically within the realm of Server-Side Rendering (SSR), we have a distinct problem: JSON.stringify is stupid. It doesn't know what a Set is. It chokes on Map. And it certainly doesn't know what to do with a RegExp. Enter seroval. It's the magic glue that promises to take any JavaScript value on the server, turn it into a string, and hydrate it back to life on the client (or vice versa).

This kind of magic is irresistible to developers building complex frameworks like SolidJS or Qwik. Why write manual parsers when seroval can serialize the entire state of your application with one function call? It sounds perfect. It sounds efficient. It sounds like a massive attack surface wrapped in a convenient package.

Whenever a library promises to deserialize complex objects automatically, my ears perk up. Serialization libraries are notoriously difficult to secure because they are essentially interpreters. They take a string of data and instruct the runtime to allocate memory and instantiate objects based on that data. If you don't put guardrails on that process, you are handing the keys to the memory allocator directly to the attacker.

The vulnerability in seroval (CVE-2026-23956) is a classic case of "Trusting the Input." When seroval encounters a serialized structure representing a Regular Expression, it blindly reconstructs it using the new RegExp(pattern, flags) constructor. In versions 1.4.0 and below, it did this without asking any questions.

There were no checks on the length of the pattern string. There were no checks on the complexity of the pattern. There wasn't even a default setting to say, "Hey, maybe let's not deserialize executable logic from an untrusted user." This omission created two distinct avenues for a Denial of Service (DoS) attack.

First, the Memory Exhaustion path. A RegExp object in V8 (the engine behind Node.js and Chrome) isn't just a string; it's a compiled state machine. If you feed the constructor a multi-megabyte string, the engine tries to compile it, consuming vast amounts of RAM. Do this enough times, or with a large enough payload, and the application hits its memory limit and dies.

Second, and more elegantly, the ReDoS (Regular Expression Denial of Service) path. Because the attacker controls the pattern, they can inject patterns known to cause "catastrophic backtracking." This happens when the regex engine tries to match a string against a complex pattern with nested quantifiers (like (a+)+$). If the match fails, the engine tries every possible permutation of paths through the NFA (Nondeterministic Finite Automaton). This complexity is exponential. A short string of 30 characters can lock up a CPU core for minutes. In a single-threaded Node.js environment, that means the entire server stops responding.

Let's look at why this happened. In the vulnerable versions, the deserialization logic was effectively a straight pipeline from the raw string to the constructor. There were no "sanity checks." The code simply identified that a node was a RegExp and instantiated it.

The fix, introduced in commit ce9408ebc87312fcad345a73c172212f2a798060, is a masterclass in "Oh, right, users are evil." The maintainers introduced a hard limit and a feature flag system. Here is a breakdown of the critical changes:

// The new sanity check introduced in the patch
export const MAX_REGEXP_SOURCE_LENGTH = 20000;
 
// ... inside the deserializer ...
if (source.length > MAX_REGEXP_SOURCE_LENGTH) {
  throw new SerovalMalformedNodeError('RegExp source is too long');
}

But the length check alone isn't enough to stop ReDoS (you can write a server-killing regex in less than 20 characters). The more important change was the introduction of Feature Flags. They implemented a bitmask system where specific features must be explicitly enabled or disabled.

// Bitmask for features
export const Feature = {
  // ... other flags ...
  RegExp: 0x20, // The specific bit for Regex support
};
 
// Checking the flag before processing
if (features & Feature.RegExp) {
   // process RegExp
} else {
   throw new SerovalUnsupportedNodeError(...);
}

This shifts the security model from "Allow Everything" to "Opt-in Risk." If a developer doesn't explicitly need to serialize Regex (and let's be honest, who really does in a standard payload?), it should be disabled by default or at least easily strippable.

Exploiting this is trivially easy if you can find an endpoint that accepts seroval serialized data. This is common in "Islands Architecture" frameworks where server state is serialized into the HTML and then rehydrated on the client, or in RPC-like calls where the client sends state back to the server.

Scenario: The ReDoS Bomb

We don't need to send a 1GB payload to crash the server. We just need to abuse the Event Loop. Since Node.js is single-threaded, if we can make the main thread busy calculating a regex match for 10 seconds, the server processes exactly zero other requests during that time.

The Payload: We craft a JSON-like object that seroval will parse. We inject a RegExp designed for catastrophic backtracking.

// Conceptual payload structure for Seroval
const payload = {
  t: 1, // Type identifier for RegExp in Seroval internals
  source: "(a+)+$", // The Evil Regex
  flags: "" 
};
 
// The string to match against (sent separately or assumed present in logic)
const targetString = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!";

When seroval deserializes this, it creates new RegExp('(a+)+$'). If the application logic then uses this regex against any user input (or if we can trick the application into matching it against a string we also provide), the CPU spikes to 100%.

Scenario: The Memory Bomb

Alternatively, we can just be blunt. We generate a string of 50 million 'A's. We wrap that in the Seroval format claiming it's a RegExp pattern. The server receives the request, parses the JSON, and attempts to compile a state machine for a 50MB regex pattern. V8 will panic, the garbage collector will scream, and the process will likely crash with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed.

It is easy to dismiss DoS as "annoying" rather than "critical" compared to RCE (Remote Code Execution). However, in the context of modern microservices and serverless functions, DoS is a financial weapon.

If an attacker can crash your server with a single request, they can take down your business logic. If you are running on auto-scaling infrastructure (like AWS Lambda or Kubernetes HPA), this attack turns into a Denial of Wallet. Your infrastructure detects the high CPU load or the crashed instances and spins up new ones. The attacker crashes those too. You end up paying for thousands of compute hours that did nothing but choke on a regex.

Furthermore, because seroval is often used in the hydration process of SSR frameworks, this vulnerability could potentially be triggered just by visiting a URL if the URL parameters are parsed into state. This makes it a low-effort, high-impact vector for griefers and competitors alike.

If you are using seroval or seroval-plugins, you need to update immediately. The patch is available in version 1.4.1.

Immediate Action: Update your package.json:

npm install seroval@latest

Code hardening: Even after patching, you should ask yourself: "Do I actually need to serialize Regular Expressions?" If the answer is no (and it usually is), explicitly disable the feature. The new version allows you to turn off specific features via a bitmask.

import { fromJSON, Feature } from 'seroval';
 
// Disable RegExp deserialization entirely
const myData = fromJSON(userInput, {
  disabledFeatures: Feature.RegExp
});

This is the only way to be 100% safe. A regex limit of 20,000 characters (the new default) prevents memory exhaustion, but it doesn't strictly prevent ReDoS if the attacker is clever enough to write a short, deadly pattern. Disabling the feature removes the attack surface entirely.