CVE-2026-128121: Regular Expression Injection in SvelteKit Vercel Route Configuration via @sveltejs/adapter-vercel and @sveltejs/adapter-static

SvelteKit is an application framework powered by Svelte that utilizes modular adapters to compile and package web applications for specific deployment targets. Two of these official adapters, @sveltejs/adapter-vercel and @sveltejs/adapter-static (when targeting the Vercel platform), generate platform-specific routing configurations during the application build step. These configurations are written to .vercel/output/config.json and define how the Vercel edge network processes incoming HTTP requests, resolves static assets, and executes redirects.

A vulnerability tracked as CVE-2026-128121 (and GHSA-jf9x-2fg2-hx4w) exists in @sveltejs/adapter-vercel prior to versions 6.3.5 and 7.0.2, as well as @sveltejs/adapter-static prior to versions 3.0.11 and 4.0.1. During the prerendering phase of a SvelteKit build, the framework crawls HTML anchor tags (<a>) rendered by the application to discover and statically generate pages and redirects. The affected adapters take these discovered pathnames and emit them directly into the src field of route rules inside the Vercel configuration file.

In Vercel's Build Output API specification, the src property of a route entry is evaluated as a PCRE-compatible regular expression rather than a literal string path. Because the adapters failed to escape regular expression metacharacters in crawled pathnames before writing them to the configuration file, any metacharacters present in a prerendered path are interpreted as active regular expression syntax by Vercel's request router.

This flaw is classified under CWE-116 (Improper Encoding or Escaping of Output) and CWE-625 (Permissive Regular Expression). If an application prerenders pages containing user-controlled or externally sourced links, an attacker can craft a URL path containing regular expression operators such as alternation (|) or wildcards (.*). When deployed to Vercel, the resulting permissive regular expression matches arbitrary application paths, allowing the attacker to override routing precedence and expose unintended content or redirect behavior.

The root cause of CVE-2026-128121 lies in the static_vercel_config() function within packages/adapter-vercel/index.js and the corresponding Vercel platform configuration handler in packages/adapter-static/platforms.js. When SvelteKit executes its build process, it populates builder.prerendered.pages and builder.prerendered.redirects with a map of URL pathnames discovered by its internal crawler or explicitly specified in the application configuration.

To ensure consistent trailing-slash behavior and honor custom redirects on Vercel, the adapters iterate over these prerendered collections to construct the routes array for .vercel/output/config.json. Each generated rule maps an incoming request pattern (src) to either a target destination (dest) or an HTTP redirect (status: 308 with a Location header). Prior to the patch, the adapters assigned the raw path and counterpart_route strings directly to the src property without sanitization.

When the Vercel edge routing engine parses .vercel/output/config.json, it compiles each src string into a regular expression anchored to the start and end of the request pathname. If a crawled pathname contains characters with special meaning in regular expressions—specifically ., *, +, ?, ^, $, {, }, (, ), |, [, ], or \—those characters alter the structure of the compiled expression.

A notable technical complexity in remediating this flaw involves the preprocessing logic executed by Vercel's internal route compiler before evaluating the regular expression. Standard backslash escaping (e.g., converting . to \., $ to \$, or / to \/) fails to secure the pattern reliably due to two platform-specific behaviors:

1. Vercel automatically appends an end-of-string anchor ($) to a src pattern only if the string does not already terminate with the $ character. If a path ending in a literal dollar sign is escaped as \$, the string still ends with the character $, causing Vercel to omit the trailing anchor and allowing prefix matching.
2. Vercel normalizes forward slashes during route compilation and strips backslashes preceding slashes, converting \/ back into /, which can corrupt escape sequences when backslashes themselves are adjacent to path separators.

Consequently, preventing regular expression injection in Vercel route configurations requires encoding metacharacters into a representation that carries no syntactic meaning during Vercel's string normalization checks while still evaluating as literal characters within the regular expression engine.

The vulnerability was addressed in commit 2ed61a6aa3ac230b89e3528654c587847d1525a0 on the main branch and backported to the version 2 release line in commit 0a2e58cbccdd46cac20aa5af4e2edf17e0da11dd (via Pull Request #17620). The fix introduces a dedicated escaping utility, escape_src(), and applies it whenever prerendered paths are converted into Vercel src patterns.

In packages/adapter-vercel/utils.js (and duplicated in packages/adapter-static/platforms.js), the maintainers implemented escape_src() using hexadecimal character escapes (\xHH) rather than standard backslash prefixes:

/**
 * Escapes a pathname so that it can be matched literally by a Vercel route `src` regex
 * @param {string} pathname
 */
export function escape_src(pathname) {
	// hex escapes rather than backslash escapes, since Vercel only appends the `$` anchor
	// if `src` doesn't already end with `$`, and it replaces `\/` with `/`
	return pathname.replace(
		/[.*+?^${}()|[\]\\]/g,
		(char) => `\\x${char.charCodeAt(0).toString(16).padStart(2, '0')}`
	);
}

By replacing every character in the character class /[.*+?^${}()|[\]\\]/g with its two-digit hexadecimal ASCII representation prefixed by \x, characters like $ (ASCII 0x24) become \x24 and \ (ASCII 0x5c) becomes \x5c. Because the resulting string ends with 4 rather than $, Vercel's route compiler consistently appends the trailing $ anchor. Similarly, because literal backslashes are converted to \x5c, a sequence such as \/b is transformed into \x5c/b, preventing Vercel from stripping the backslash during slash normalization.

In packages/adapter-vercel/index.js, static_vercel_config() was updated to wrap all prerendered redirect paths and trailing-slash counterpart routes with escape_src():

--- a/packages/adapter-vercel/index.js
+++ b/packages/adapter-vercel/index.js
@@ -575,8 +581,10 @@ function static_vercel_config(builder, config, dir) {
 	/** @type {import('./index.js').ImagesConfig | undefined} */
 	const images = config.images;
 
-	for (let [src, redirect] of builder.prerendered.redirects) {
-		if (src.replace(/\/$/, '') === redirect.location.replace(/\/$/, '')) {
+	for (const [path, redirect] of builder.prerendered.redirects) {
+		let src = escape_src(path);
+
+		if (path.replace(/\/$/, '') === redirect.location.replace(/\/$/, '')) {
 			// ignore the extreme edge case of a `/foo` -> `/foo/` redirect,
 			// which would only arise if the response was generated by a
 			// `handle` hook or outside the app altogether (since you
@@ -608,8 +616,8 @@ function static_vercel_config(builder, config, dir) {
 			}
 
 			prerendered_redirects.push(
-				{ src: path, dest: counterpart_route },
-				{ src: counterpart_route, status: 308, headers: { Location: path } }
+				{ src: escape_src(path), dest: counterpart_route },
+				{ src: escape_src(counterpart_route), status: 308, headers: { Location: path } }
 			);
 		}

> [!NOTE] > Notice that in the first loop over builder.prerendered.redirects, the comparison path.replace(/\/$/, '') === redirect.location.replace(/\/$/, '') continues to operate on the unescaped path variable so that trailing-slash equivalence checks are not distorted by escaping, while src holds the escaped pattern emitted to the configuration.

To verify fix completeness and guard against regressions, unit tests were added in packages/adapter-vercel/test/utils.spec.js testing alternation injection (/account/x|.*), quantifier injection (/blog/(a)[b]{1}+?), anchor boundaries (/a$, /^a), and backslash-slash sequences (/a\/b). The hexadecimal escaping mechanism completely neutralizes all standard PCRE/JavaScript regular expression metacharacters within the ASCII range.

Exploiting CVE-2026-128121 requires a specific set of application architectural conditions, reflected in its High Attack Complexity (AC:H) rating. First, the target application must be built with SvelteKit using an affected version of @sveltejs/adapter-vercel or @sveltejs/adapter-static configured for Vercel. Second, the application must have prerendering enabled (export const prerender = true or prerender = 'auto') on one or more routes. Third, during the build-time prerender crawl, the application must render HTML links (<a href="...">) whose paths can be influenced by untrusted input, and the application must handle those dynamic routes during prerendering (for example, via a fallback/catch-all parameter [...rest] or dynamic route [slug] that returns a valid 200 OK or 3xx Redirect response instead of failing the build on a 404 error).

When these prerequisites are satisfied, an attacker can execute an attack through the following sequence:

1. Payload Injection: The attacker submits content to the application data source (such as a CMS, database, markdown comment, or user profile) containing an anchor tag pointing to an internal path embedded with regular expression metacharacters:

   <a href="/profile/view|.*">View User Profile</a>

2. Prerender Crawl and Route Emission: During the next CI/CD deployment build, SvelteKit's prerender crawler parses the rendered HTML, discovers the /profile/view|.* link, and requests it from the internal build server. If the route resolves or triggers a trailing-slash normalization/redirect, static_vercel_config() emits an unescaped entry into .vercel/output/config.json:

   {
     "src": "/profile/view|.*",
     "dest": "/profile/view|.*"
   }

   Or, in the case of trailing-slash redirect generation:

   {
     "src": "/profile/view|.*/",
     "status": 308,
     "headers": { "Location": "/profile/view|.*" }
   }

3. Route Hijacking on Vercel: Once deployed, Vercel compiles /profile/view|.* into the regular expression ^/profile/view|.*$. Because the alternation operator | has lower precedence than concatenation, the expression splits into two branches: ^/profile/view or .*$. The second branch (.*$) matches any URL pathname on the domain.

Because prerendered redirect and rewrite rules are placed early in the Vercel routing table before general serverless function catch-all handlers, incoming requests to unrelated paths (such as /, /api/data, or /_app/immutable/entry/start.js) match the injected rule. Depending on how the application handles theprerendered route, this causes the edge router to serve the prerendered response or redirect for /profile/view|.* in place of the intended route, or map unauthorized paths to static outputs.

CVE-2026-128121 is assigned a CVSS v3.1 base score of 5.9 (Medium) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. The Attack Vector is Network (AV:N) with No Privileges Required (PR:N) and No User Interaction (UI:N), as the attacker supplies the malicious link over the network prior to a build and routing subversion subsequently affects all requests automatically at the edge layer.

The primary security impact according to the CVSS vector is High Confidentiality loss (C:H), while Integrity (I:N) and Availability (A:N) are scored as None in the official vector. When a permissive regular expression is injected into .vercel/output/config.json, the routing table no longer enforces strict 1:1 path matching for static prerendered pages and redirects. By crafting regular expressions that match specific path prefixes or patterns, an attacker can cause requests to resolve to unintended destination paths or bypass expected routing boundaries, exposing sensitive prerendered content or application behavior outside the intended path.

Furthermore, in practical deployment scenarios, injecting broad wildcard patterns such as |.* into builder.prerendered.redirects can disrupt normal site routing by redirecting or rewriting requests meant for dynamic SSR endpoints or JavaScript bundle assets (/_app/immutable/...) to the attacker's prerendered route. However, because exploitation cannot mutate server-side data or execute arbitrary code on the Vercel runtime, server integrity remains unaffected.

At the time of publication, there is no evidence of active exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public weaponized exploits or Nuclei detection templates exist.

Development teams using SvelteKit deployed to Vercel via @sveltejs/adapter-vercel or @sveltejs/adapter-static should upgrade to the patched package versions immediately and trigger a fresh build and deployment so that .vercel/output/config.json is regenerated with hexadecimal metacharacter escaping.

The vulnerability is resolved in the following versions:

• @sveltejs/adapter-vercel: 6.3.5 (for the 6.x release line) and 7.0.2 (for the 7.x release line)
• @sveltejs/adapter-static: 3.0.11 (for the 3.x release line) and 4.0.1 (for the 4.x release line)
• @sveltejs/kit: 2.70.4 and 3.1.1 (repository monorepo tags corresponding to the fixes)

To update the adapters via npm, execute the appropriate command for your major version branch:

# For @sveltejs/adapter-vercel v6 or v7
npm install @sveltejs/adapter-vercel@^6.3.5
npm install @sveltejs/adapter-vercel@^7.0.2
 
# For @sveltejs/adapter-static v3 or v4
npm install @sveltejs/adapter-static@^3.0.11
npm install @sveltejs/adapter-static@^4.0.1

If an immediate dependency upgrade is not possible, teams can implement the following workarounds and defense-in-depth measures:

1. Restrict Prerender Crawling: Configure kit.prerender.crawl = false in svelte.config.js if automatic link discovery is not required, and explicitly define known safe prerender entry points in kit.prerender.entries.
2. Validate Dynamic Route Parameters: In dynamic or catch-all route load functions (+page.server.js or +page.js), strictly validate params against an allowlist of expected characters (e.g., /^[a-zA-Z0-9-_]+$/) and throw a 404 error via SvelteKit's error(404) helper if regular expression metacharacters are present.
3. Audit Build Output in CI/CD: Inspect the generated .vercel/output/config.json file prior to deploying to Vercel to verify that no routes[].src entries derived from prerendered pages contain unescaped regular expression operators.