The TanStack Start server-function XSS

1. 1

   A server function is an HTTP endpoint on your own origin.

   TanStack Start lets you write server functions: code that runs on the server, which your pages call over HTTP. By default the call goes to an internal endpoint under /_serverFn/, with the function's id in the path and the header x-tsr-serverFn: true.

   The endpoint lives on your app's own origin, next to your pages and your session cookie. A server function can be called by POST or by GET, with the payload in the query string.4

   path

   /_serverFn/<id>

   header

   x-tsr-serverFn: true

   methods

   GET or POST

   origin

   your app's own

2. 2

   The payload should carry one public field: data.

   The server decodes the serialized payload with Seroval's fromJSON, runs the middleware and the function, then serializes the result back to the browser.

   The only field meant to cross from the browser is data, the function's argument. Anything else in the object was written by whoever built the request, which need not be your page.

   decoder

   Seroval fromJSON

   public field

   data

   set by the server

   context, method

   other fields

   chosen by the caller

3. 3

   Before the fix, the whole object crossed the boundary.

   The handler took the entire decoded payload, set context and method on it, and passed it on. Inside createServerFn that object was spread (...opts) into the internal middleware context, so every extra field became internal state.

   This is mass assignment: trusting a client-built object as if the server had built it, instead of copying across only the allowed fields. The advisory puts it plainly: payload fields can reach “internal middleware state instead of limiting them to public input fields.”4

   handed on

   the whole payload

   in createServerFn

   ...opts spread in

   extra fields

   became internal state

   should cross

   data only

4. 4

   An error path built its reply from that state.

   The handler picked the function's result over its error, and had a “not found” branch that built an HTTP response from fields of the result object. It set Content-Type: application/json first and spread the supplied headers after it, so a caller-supplied value could override the JSON default.

   our reading of the fix diff The header order comes from the fix's diff. The advisory itself says only that there was “an error path where attacker content persists.”2

   picked

   result over error

   first

   Content-Type: application/json

   then

   ...headers from the result

   last writer

   the caller

5. 5

   Server functions answer GET, so the payload fits in a link.

   Because a server function can be called by GET with its payload in the query string, the whole crafted request fits in one URL on your site. The attacker sends that link by email, in a chat or from another website.

   Building it needs no account and no access to your app. What it does need is a victim who opens it: that is the “user interaction required” in the score.4

   method

   GET

   payload

   in the query string

   account needed

   no

   victim must

   open the link

6. 6

   The reply comes back as HTML, from your own origin.

   The victim's browser navigates to https://your-app/_serverFn/…. The reply really does come from your app, and it is labelled with an HTML content type, so the browser renders it as a page.

   Labelled application/json, the same bytes would have been shown as inert text. One header decided whether the attacker's content was data or a document.

   expected

   application/json, shown as text

   served

   text/html

   from

   your app's own URL

   browser

   renders it as a page

7. 7

   Script runs with the victim's session.

   Because the page is on your origin, the attacker's script runs with the same access as the signed-in user: it can read same-origin data and page contents, and make authenticated requests as them. Cookies without the HttpOnly flag are exposed too.

   That is the “scope changed” in the vector: the flaw is in the server, but the code runs in the victim's browser. Any public app on an affected version, on React, Solid or Vue, had such an endpoint. No server compromise is described.4

   runs as

   the signed-in user

   can

   read same-origin data

   can

   make authenticated requests

   cookies

   exposed unless HttpOnly

   server

   not compromised

8. 8

   The fix: an allowlist on the way in, JSON on the way out.

   Commit d521abd71c (pull request #8573, merged 30 Sep at 17:29:55 UTC) builds the action's input explicitly as { data, context, method } in the HTTP handler, the SSR path and the serialization adapter. Nothing else from the payload crosses.

   It also prefers the error over the result, forces Content-Type: application/json on not-found replies after applying headers, returns non-object results only when they are real responses or primitives, and turns any other handler output into a generic 500.2

   input

   { data, context, method }

   error vs result

   error first

   not-found reply

   JSON, forced last

   other output

   generic 500

The numbered markers on the diagram match the steps.