TanStack Start XSS: Your Server Functions Need Browser Security Checks

A team may carefully review its rendered pages while assuming that server-function responses are consumed only by application code. Browsers can navigate to URLs directly, and error responses can travel through different code paths than successful API calls. Those boundaries deserve explicit testing.

What the TanStack advisory describes

TanStack published GHSA-qx66-fv34-fjm8 on September 30, 2026. It describes an unauthenticated reflected XSS issue in Start server-function responses: opening a crafted link could make an affected application return attacker-controlled HTML and execute JavaScript under the application's origin. Read TanStack's advisory and package-specific fixes.

The advisory lists fixes in @tanstack/react-start 1.168.60, @tanstack/solid-start 1.168.57, @tanstack/vue-start 1.168.56, and @tanstack/start-server-core 1.169.39. Affected ranges start at 1.143.12 and end before each package's fix. Check the resolved server-core dependency as well as the top-level framework package.

Why a trusted origin makes the response dangerous

Browser code running under your site's origin can interact with resources available to the visitor. An HttpOnly cookie helps prevent direct cookie reads, but it does not stop same-origin script from making requests with the visitor's session. That is why fixing the response-generation flaw matters even when cookie flags look correct.

In your own application review, include ordinary page navigation, API calls, malformed input, and error handling. Decide what content type each route should return and make that decision explicit. A successful JSON response on the happy path does not prove that every failure path returns the same safe representation.

Patch first, then verify the browser boundary

1. Update the affected Start packages to their fixed versions or compatible later releases. Inspect the lockfile and deployed dependency tree, then rebuild.
2. Exercise legitimate server functions and error paths in staging. Verify the content type and ensure untrusted input cannot become executable HTML.
3. Check the security headers on the server-function responses themselves. An HTML page's policy does not automatically establish the policy for a separate document returned by another endpoint.
4. Roll out a restrictive CSP with compatibility testing, and retain regression tests for the affected routes after the immediate update is complete.

TanStack discusses edge filtering and restrictive CSP as temporary mitigations. It also cautions that a client-controlled server-function header is not authentication. Treat these controls as supplementary measures while deploying the package fix.

How BlackSight helps test beyond the landing page

BlackSight's web scanner checks for supported XSS and configuration issues on reachable routes. Its headers scanner can reveal absent or weak browser protections. Include server-function URLs and representative application paths in the review, rather than using a clean homepage result as evidence for the entire application.

For APIs, Pro settings let you provide definitions and verified authentication, with active tests limited to explicitly approved operations. Route coverage and suitable request inputs determine what a scan can exercise. A generic scan is not a guarantee that this particular framework transport flaw will be detected.

The useful workflow is to patch the package, verify the vulnerable boundary in application tests, and re-scan the deployed responses for supported findings. Use our staged CSP rollout guide to turn a missing-header finding into an enforced policy that your application can sustain.