CVE-2026-102989: TanStack Router: Unauthenticated reflected XSS in TanStack Start server-function responses

The server-function transport lets request payload fields flow into internal middleware state, when only public input fields should be accepted. A malformed payload can leave an attacker-controlled result in the error path. Response handling then treats a response-shaped object as a real HTTP response. The attacker thereby controls the HTML the app returns from its own origin.

The attack needs no login. It needs a victim to open a crafted URL pointing at a server function, normally under /_serverFn/*. The script then runs with the victim's session on that origin. It can read same-origin data the visitor can see and send requests with the visitor's authority, which is why the scope is marked changed and confidentiality and integrity impact are high.

Any public TanStack Start app that uses server functions is exposed, whether or not the developer wrote an unsafe handler themselves, because the flaw is in the framework transport.

These packages are affected from 1.143.12 up to, but not including, the patched version:

• @tanstack/start-server-core before 1.169.39
• @tanstack/react-start before 1.168.60
• @tanstack/solid-start before 1.168.57
• @tanstack/vue-start before 1.168.56

Check what your lockfile resolves, including transitive copies:

npm ls @tanstack/start-server-core @tanstack/react-start

Upgrade each package to its patched version: @tanstack/start-server-core 1.169.39, @tanstack/react-start 1.168.60, @tanstack/solid-start 1.168.57, @tanstack/vue-start 1.168.56. For example:

npm install @tanstack/[email protected]

The fix limits client-supplied server-function input to public fields and validates responses at the server boundary.

The advisory also suggests temporary mitigations, which it says are not a complete fix. On the server-function path, an edge or WAF rule can block requests that lack the literal x-tsr-serverFn: true header, and browser document navigations such as Sec-Fetch-Mode: navigate or Accept: text/html. A restrictive Content Security Policy on those responses also helps. The header is client-controlled and is not authentication, so test the rules against your legitimate GET and POST server functions.

Review access logs for requests to the server-function path (usually /_serverFn/*) that arrive as browser navigations, with Sec-Fetch-Mode: navigate or Accept: text/html, or that lack the x-tsr-serverFn: true header. Legitimate calls come from your own client code, so document-style requests with odd payloads in the query string are suspect. Look for server-function responses with an HTML content type. Check CSP violation reports if you collect them.

Impact

An unauthenticated attacker can craft a URL to a server function in an affected TanStack Start app. If someone opens the link, the app can return attacker-controlled HTML from its own origin and run the attacker's JavaScript there. The script can access same-origin data available to that visitor and make requests with their authority.

Cause

The server-function transport can pass request payload fields into internal middleware state instead of limiting them to public input fields. A malformed payload can leave an attacker-controlled result in the error path. Response handling can then treat a response-shaped object as an HTTP response.

Affected versions

Published versions of @tanstack/start-server-core, @tanstack/react-start, @tanstack/solid-start, and @tanstack/vue-start from 1.143.12 up to, but not including, their respective patched versions are affected. The patched versions are @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected], and @tanstack/[email protected].

Fix

The fix limits client-supplied server-function input to public fields and validates responses at the server boundary. Upgrade to the corresponding patched package version.

Temporary mitigations

For the configured server-function path, usually /_serverFn/*, an edge or WAF rule can consider blocking requests without the literal x-tsr-serverFn: true header and browser document navigations such as Sec-Fetch-Mode: navigate or Accept: text/html. A restrictive Content Security Policy on server-function responses can provide another browser-side restriction. These are mitigation suggestions, not a complete fix. The header is client-controlled and is not authentication. Test rules against legitimate GET and POST server functions and use a matching version-specific backport where possible.

Credits

Lovable helped us discover and report this issue. We thank them for their help.