Unauthenticated Reflected XSS in TanStack Start Server Functions (CVE-2026-102989)

A newly published GitHub Security Advisory (GHSA-qx66-fv34-fjm8) discloses an unauthenticated reflected XSS vulnerability in TanStack Start's server-function transport, tracked as CVE-2026-102989 with a CVSS score of 9.3 and a public proof-of-concept already available.

What happened

According to the advisory, TanStack Start's server-function transport can pass request payload fields into internal middleware state instead of restricting them to designated public input fields. A malformed payload can leave attacker-controlled data in the error path, and the response handler can then treat a response-shaped object as an actual HTTP response. The practical effect: an attacker can craft a URL to a server function in an affected app such that, if a victim opens it, the app reflects attacker-controlled HTML/JavaScript from its own origin.

Affected packages are @tanstack/start-server-core, @tanstack/react-start, @tanstack/solid-start, and @tanstack/vue-start, versions 1.143.12 up to (but not including) the patched releases: [email protected], [email protected], [email protected], and [email protected].

Why it matters

Because the attack requires no authentication and only needs the victim to click a link, this is a classic reflected-XSS delivery vector — but against a modern full-stack React/Solid/Vue framework's server-function layer rather than a traditional query parameter. Any logged-in user who opens a malicious link could have their session-scoped data accessed and their authority used to make same-origin requests. Given the 9.3 CVSS and public PoC, organizations running TanStack Start in production should treat this as actively exploitable now, not theoretical.

What defenders should do now

• Inventory any applications using @tanstack/start-server-core, react-start, solid-start, or vue-start and check versions against the affected range (1.143.12 to the patched versions above).
• Prioritize upgrading to the patched package versions — the advisory states the fix limits client-supplied server-function input to public fields and validates responses at the server boundary.
• As a temporary mitigation, consider an edge/WAF rule on the server-function path (commonly /_serverFn/*) that blocks requests lacking the x-tsr-serverFn: true header, or that look like browser document navigations (e.g. Sec-Fetch-Mode: navigate, Accept: text/html). Note the advisory's own caveat: this header is client-controlled and is not authentication — treat it as a speed bump, not a fix, and test rules against legitimate GET/POST server functions first.
• A restrictive Content-Security-Policy on server-function responses can add a browser-side backstop against script execution.
• Hunting angle: review logs for unusual or malformed requests to server-function endpoints, especially those missing expected framework headers or originating from direct browser navigation rather than XHR/fetch calls from the app itself.

Developing intel

This writeup is based solely on the GHSA advisory published 2026-10-15; no detection signature or query is included here since this is not a CVE-specific detection page. Monitor the original advisory for updates and refer to it directly for authoritative technical details: GHSA-qx66-fv34-fjm8.