- GitHub's advisory describes reflected XSS (CVE-2026-102989) in TanStack Start server-function responses. A crafted link can run attacker script on an affected app's own origin.
- It affects four @tanstack start packages from 1.143.12 up to their patched versions. Server-function input was trusted too far, and responses were not validated at the server boundary.
- Upgrade to the patched versions and check lockfiles. WAF rules and a strict CSP are partial stopgaps only, per the advisory.
According to a GitHub advisory published on October 15, an attacker with no account can craft a URL that points at a server function in an affected TanStack Start app. If a person opens that link, the app can answer with the attacker's HTML from its own address. The browser then runs the attacker's script as if the site had written it.
The lesson here is simple. A server function feels like a private function call inside your own code. It is a public web address. Everything that arrives there is input from a stranger, including fields the framework meant for itself.
What the advisory says
The advisory is tracked as CVE-2026-102989. It covers reflected cross-site scripting (XSS) in server-function responses. Reflected means the attack needs a victim to open a crafted link.
Anyone can put the link together, with no login. It points at a server function in a vulnerable app. When a person clicks it, the app may reply with HTML the attacker wrote, served from the app's own address. The attacker's JavaScript then runs there.
The advisory says that script can read same-origin data the visitor is able to see. It can also send requests that carry the visitor's own authority. The attacker needs no account to start.
How the flaw works
TanStack Start lets front-end code call server code as if it were a local function. Behind the scenes, a transport layer carries the call's payload to the server. That layer has public input fields and internal middleware state.
The advisory says the transport can copy fields from the request payload into that internal state. Only the public input fields should have been allowed through. Send a deliberately broken payload, and the error-handling path can end up holding a result the attacker chose.
The last step is in response handling. The advisory says it can treat a response-shaped object as a real HTTP response. The attacker's object is sent back as if the server had written it.
In plain terms, the app trusted an object from outside because it was shaped like its own. Each step looks reasonable alone. Together they let a stranger write the reply.
Who is affected and what to install
The flaw sits in four published packages. Every release from 1.143.12 onward is affected until it reaches the patched version for that package. One is @tanstack/start-server-core. The others are the react-start, solid-start and vue-start packages under the same @tanstack name.
The patched versions are start-server-core 1.169.39, react-start 1.168.60, solid-start 1.168.57 and vue-start 1.168.56. The fix restricts what a client can send to the public fields only. It also validates responses at the server boundary, as the advisory puts it.
The advisory credits Lovable with helping to discover and report the issue. It does not say the flaw has been exploited.
A stopgap, with limits
For teams that cannot upgrade today, the advisory offers mitigations for the server-function path, usually /_serverFn/*. An edge or WAF (web application firewall) rule can consider blocking two patterns. The first is any call that omits the literal header x-tsr-serverFn: true. The second is an ordinary page navigation by a browser, which the advisory identifies by Sec-Fetch-Mode: navigate or Accept: text/html.
A strict Content Security Policy on server-function responses adds a second browser-side limit.
The advisory is direct about the limits. These are not a complete fix. The header is set by the client and is not authentication. Rules should be tested against legitimate GET and POST server functions.
Questions to put to your team
Ask whether any product, internal tool or agency-built site uses TanStack Start. Ask for the exact versions of the four packages in each lockfile, including those pulled in indirectly.
Ask who owns the edge rules, and whether anyone has tested them against real server-function traffic. Ask whether server-function responses carry a Content Security Policy at all.
Then ask what a script could reach if it ran as a logged-in user of each affected app. That answer sets how fast the upgrade should move.
A server function is a convenience for developers. To an attacker, it is a public door that happens to look like a function call.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
