GHSA-9M65-766C-R333: Seroval hardens deserialization flags to address type confusion

Vulnerability

GHSA-9M65-766C-R333 and CVE-2026-23737 describe a deserialization type-confusion issue in seroval as used by TanStack Start. The reported impact is not just incorrect object reconstruction; crafted payloads can be interpreted as privileged or executable types and thereby trigger unintended server functions. In the affected application model, that is especially dangerous because execution can occur after deserialization, bypassing request-scoped middleware, authorization hooks, and audit logging that normally wrap explicit server-function entry points.

The patch evidence points to the root problem being overly permissive type restoration. Several serialized outputs change their feature bitmask from 31 to 63, and the compatibility documentation now states that RegExp serialization/deserialization is disabled unless Feature.RegExp is explicitly enabled. That is consistent with a vulnerability class where the decoder accepted more type forms than were safe by default, allowing attacker-controlled payloads to cross trust boundaries as richer runtime objects than intended.

[VULNERABLE]
exports[`DOMException > toJSON > supports DOMException 1`] = "{\"t\":{\"t\":25,\"i\":0,\"s\":{\"name\":{\"t\":1,\"s\":\"Example\"},\"message\":{\"t\":1,\"s\":\"This is an example message.\"}},\"c\":\"seroval-plugins/web/DOMException\"},\"f\":31,\"m\":[]}";

[PATCHED]
exports[`DOMException > toJSON > supports DOMException 1`] = "{\"t\":{\"t\":25,\"i\":0,\"s\":{\"name\":{\"t\":1,\"s\":\"Example\"},\"message\":{\"t\":1,\"s\":\"This is an example message.\"}},\"c\":\"seroval-plugins/web/DOMException\"},\"f\":63,\"m\":[]}";

Because the supplied commit digest does not include the core deserializer source itself, the exact exploit primitive cannot be proven from code alone here. However, the combination of advisory text, version bump to seroval 1.4.2, changed feature flags, and newly documented opt-in behavior for risky types is source-grounded evidence of a deserialization hardening fix rather than a purely cosmetic release update. See the referenced commit ce9408ebc87312fcad345a73c172212f2a798060.

Patch

The patch updates dependent packages to seroval 1.4.2 / seroval-plugins 1.4.2 and changes compatibility guidance so that RegExp is no longer generally supported by default. The documentation now explicitly says Feature.RegExp must be enabled; otherwise deserialization throws unsupported-type errors. This is a meaningful security posture change because it converts a previously available complex type into an explicit opt-in capability.

Snapshot changes also show a systematic feature-mask expansion from 31 to 63 across multiple web plugin types such as AbortSignal, CustomEvent, and DOMException. That suggests the wire format now carries stricter or more explicit feature metadata during serialization/deserialization. In addition, some payload structures were simplified, for example removing explicit size metadata from Blob JSON and removing object shape counters in CustomEvent snapshots. Those changes are consistent with reducing ambiguous reconstruction state and tightening decoder expectations.

[VULNERABLE]
| `RegExp` | ✅ | ✅ | ✅ |

[PATCHED]
- `RegExp`
  - Disables serialization (and deserialization) of `RegExp`
| `RegExp` | ❓[^6] | ❓[^6] | ❓[^6] |
[^6]: `Feature.RegExp` must be enabled, otherwise throws an `SerovalUnsupportedTypeError` and `SerovalUnsupportedNodeError`.

From a patch-design perspective, this is the right direction: move dangerous or ambiguity-prone runtime types behind explicit feature gates, and make the serialized format advertise capabilities more precisely. The official advisory is at GitHub Advisory, with NVD tracking at NVD.

Review

Pros

• The patch appears to address the vulnerability at the serialization contract level rather than only adding application-side filtering. Disabling RegExp by default and requiring Feature.RegExp is a concrete reduction in attack surface.
• Feature-mask changes across multiple snapshots indicate a systematic protocol update, not a one-off special case for a single plugin type.
• Version alignment to seroval@1.4.2 and seroval-plugins@1.4.2 reduces dependency skew and makes the security boundary easier to reason about.
• The new behavior fails closed for unsupported types by throwing explicit errors, which is preferable to permissive coercion during deserialization.

Cons

• The provided diff is mostly documentation, package metadata, and snapshot output. It does not expose the core deserializer implementation change, so independent verification of the exact root-cause fix is limited.
• The evidence strongly supports hardening, but it is difficult to determine whether all dangerous type-confusion paths are closed or only the currently known gadget classes.
• Changing feature flags and default support can be breaking for consumers that relied on prior behavior, especially if they deserialize cross-boundary payloads without explicit feature configuration.
• The patch summary ties the issue to unintended function execution in TanStack Start, but the available code snippets are in seroval/plugin snapshots, so end-to-end middleware-bypass prevention is inferred rather than directly demonstrated in the diff.

Verdict

Root-cause.

Based on the available sources, this patch most likely fixes the vulnerability at its actual trust-boundary origin: unsafe deserialization of rich types. The key signal is not the package bump itself, but the semantic change to default type support and feature gating, especially for RegExp, combined with broad serialized-format updates across plugin test snapshots. That pattern matches a root-cause remediation where the decoder is no longer allowed to reconstruct certain attacker-controlled types unless the application explicitly opts in.

Confidence is moderate, not maximal, because the supplied commit digest omits the core implementation files where the deserialization checks were likely added. Still, for engineering review purposes, the patch should be treated as a substantive security fix rather than a bandaid. Teams using TanStack Start or any seroval-backed deserialization boundary should upgrade to the patched release and audit any explicit feature enablement that re-opens complex type support.

References: commit ce9408ebc87312fcad345a73c172212f2a798060, GitHub Advisory, NVD CVE-2026-23737, supplemental report.