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.
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.
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/start-server-core@1.169.39, @tanstack/react-start@1.168.60, @tanstack/solid-start@1.168.57, and @tanstack/vue-start@1.168.56.
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.
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.
Lovable helped us discover and report this issue. We thank them for their help.
{
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:22:20Z",
"nvd_published_at": "2026-10-13T17:17:14Z",
"severity": "CRITICAL"
}