Package Instance

Axios is Vulnerable to Denial of Service via __proto__ Key in mergeConfig
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.

Axios: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams
# Vulnerability Disclosure: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams

## Summary

The `encode()` function in `lib/helpers/AxiosURLSearchParams.js` contains a character mapping (`charMap`) at line 21 that **reverses** the safe percent-encoding of null bytes. After `encodeURIComponent('\x00')` correctly produces the safe sequence `%00`, the charMap entry `'%00': '\x00'` converts it back to a raw null byte.

This is a clear encoding defect: every other charMap entry encodes in the safe direction (literal → percent-encoded), while this single entry decodes in the opposite (dangerous) direction.

**Severity:** Low (CVSS 3.7)
**Affected Versions:** All versions containing this charMap entry
**Vulnerable Component:** `lib/helpers/AxiosURLSearchParams.js:21`

## CWE

- **CWE-626:** Null Byte Interaction Error (Poison Null Byte)
- **CWE-116:** Improper Encoding or Escaping of Output

## CVSS 3.1

**Score: 3.7 (Low)**

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

| Metric | Value | Justification |
|---|---|---|
| Attack Vector | Network | Attacker controls input parameters remotely |
| Attack Complexity | High | Standard axios request flow (`buildURL`) uses its own `encode` function which does NOT have this bug. Only triggered via direct `AxiosURLSearchParams.toString()` without an encoder, or via custom `paramsSerializer` delegation |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No user interaction required |
| Scope | Unchanged | Impact limited to HTTP request URL |
| Confidentiality | None | No confidentiality impact |
| Integrity | Low | Null byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser |
| Availability | None | No availability impact |

## Vulnerable Code

**File:** `lib/helpers/AxiosURLSearchParams.js`, lines 13-26

```javascript
function encode(str) {
  const charMap = {
    '!': '%21',     // literal → encoded (SAFE direction)
    "'": '%27',     // literal → encoded (SAFE direction)
    '(': '%28',     // literal → encoded (SAFE direction)
    ')': '%29',     // literal → encoded (SAFE direction)
    '~': '%7E',     // literal → encoded (SAFE direction)
    '%20': '+',     // standard transformation (SAFE)
    '%00': '\x00',  // LINE 21: encoded → raw null byte (UNSAFE direction!)
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20|%00/g, function replacer(match) {
    return charMap[match];
  });
}
```

### Why the Standard Flow Is NOT Affected

```javascript
// buildURL.js:36 — uses its OWN encode function (lines 14-20), not AxiosURLSearchParams's
const _encode = (options && options.encode) || encode;  // buildURL's encode

// buildURL.js:53 — passes buildURL's encode to AxiosURLSearchParams
new AxiosURLSearchParams(params, _options).toString(_encode);  // external encoder used

// AxiosURLSearchParams.js:48 — when encoder is provided, internal encode is NOT used
const _encode = encoder ? function(value) { return encoder.call(this, value, encode); } : encode;
//                                                                              ^^^^^^
//                                           internal encode passed as 2nd arg but only used if
//                                           the external encoder explicitly delegates to it
```

## Proof of Concept

```javascript
import AxiosURLSearchParams from './lib/helpers/AxiosURLSearchParams.js';
import buildURL from './lib/helpers/buildURL.js';

// Test 1: Direct AxiosURLSearchParams (VULNERABLE path)
const params = new AxiosURLSearchParams({ file: 'test\x00.txt' });
const result = params.toString();  // NO encoder → uses internal encode with charMap
console.log('Direct toString():', JSON.stringify(result));
// Output: "file=test\u0000.txt" (contains raw null byte)
console.log('Hex:', Buffer.from(result).toString('hex'));
// Output: 66696c653d74657374002e747874  (00 = null byte)

// Test 2: Via buildURL (NOT vulnerable — standard axios flow)
const url = buildURL('http://example.com/api', { file: 'test\x00.txt' });
console.log('Via buildURL:', url);
// Output: http://example.com/api?file=test%00.txt  (%00 preserved safely)
```

## Verified PoC Output

```
Direct toString(): "file=test\u0000.txt"
Contains raw null byte: true
Hex: 66696c653d74657374002e747874

Via buildURL: http://example.com/api?file=test%00.txt
Contains raw null byte: false
Contains safe %00: true
```

## Impact Analysis

**Primary impact is limited** because the standard axios request flow is not affected. However:

- **Direct API users:** Applications using `AxiosURLSearchParams` directly for custom serialization are affected
- **Custom paramsSerializer:** A `paramsSerializer.encode` that delegates to the internal encoder triggers the bug
- **Code defect signal:** The directional inconsistency in charMap is a clear coding error with no legitimate use case

If null bytes reach a downstream C-based parser, impacts include URL truncation, WAF bypass, and log injection.

## Recommended Fix

Remove the `%00` entry from charMap and update the regex:

```javascript
function encode(str) {
  const charMap = {
    '!': '%21',
    "'": '%27',
    '(': '%28',
    ')': '%29',
    '~': '%7E',
    '%20': '+',
    // REMOVED: '%00': '\x00'
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20/g, function replacer(match) {
    //                                           ^^^^ removed |%00
    return charMap[match];
  });
}
```

## Resources

- [CWE-626: Null Byte Interaction Error](https://cwe.mitre.org/data/definitions/626.html)
- [CWE-116: Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html)
- [OWASP: Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code)
- [Axios GitHub Repository](https://github.com/axios/axios)

## Timeline

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

Allocation of Resources Without Limits or Throttling in Axios
## Summary

Axios versions `1.7.0` through `1.15.x` did not enforce configured request and response size limits when requests were sent with the `fetch` adapter. Applications that selected `adapter: 'fetch'`, or ran in environments where axios resolved to the fetch adapter, could receive or send bodies larger than `maxContentLength` or `maxBodyLength` despite those limits being explicitly configured.

This can cause resource exhaustion in server-side usage when a malicious or compromised server returns an oversized response, when an attacker can supply a large `data:` URL, or when an application forwards attacker-controlled request bodies through axios while relying on `maxBodyLength` as a boundary.

## Impact

The impact is availability-only. Affected applications may process, buffer, or transmit data beyond the configured limit, potentially exhausting memory, CPU, or network resources.

This does not affect axios’s default unlimited behaviour by itself: `maxContentLength` and `maxBodyLength` default to `-1`. The vulnerability exists when an application has configured finite limits and expects axios to enforce them.

Server-side runtimes are the primary concern. Browser impact is generally constrained by the browser process and browser fetch behavior, and should not be described as server process exhaustion.

## Affected Functionality

Affected functionality includes requests using the built-in `fetch` adapter with finite `maxContentLength` or `maxBodyLength` values.

Relevant configurations include:

- `adapter: 'fetch'`
- `adapter: ['fetch', ...]` when `fetch` is selected
- environments where neither `xhr` nor `http` is available and axios falls back to `fetch`
- custom fetch environments configured through `env.fetch`

Unaffected functionality includes:

- Node.js default `http` adapter enforcement
- versions before the fetch adapter was introduced
- configurations that do not rely on finite axios size limits

## Technical Details

In vulnerable versions, `lib/adapters/fetch.js` destructured request config without `maxContentLength` or `maxBodyLength`. The adapter dispatched `fetch()` and then materialized the response through `text()`, `arrayBuffer()`, `blob()`, or related resolvers without checking the configured response limit.

The fix in `e5540dc` added:

- `maxContentLength` and `maxBodyLength` reads in `lib/adapters/fetch.js`
- upfront `data:` URL decoded-size checks
- outbound body-size checks before dispatch
- `Content-Length` response pre-checks
- streaming response enforcement
- fallback checks for environments without `ReadableStream`
- regression tests in `tests/unit/adapters/fetch.test.js`

## Proof of Concept of Attack

```js
import http from 'node:http';
import axios from 'axios';

const server = http.createServer((req, res) => {
  let received = 0;

  req.on('data', chunk => {
    received += chunk.length;
  });

  req.on('end', () => {
    res.end(JSON.stringify({ received }));
  });
});

await new Promise(resolve => server.listen(0, resolve));
const url = `http://127.0.0.1:${server.address().port}/`;

await axios.post(url, 'A'.repeat(2 * 1024 * 1024), {
  adapter: 'fetch',
  maxBodyLength: 1024
});

// Vulnerable versions succeed and the server receives 2097152 bytes.
// Fixed versions reject with ERR_BAD_REQUEST.

server.close();
```

## Workarounds

Use the Node.js `http` adapter for server-side requests where finite size limits are security-relevant.

Validate or cap attacker-controlled request bodies before passing them to axios.

Reject or strictly allowlist attacker-controlled URL schemes, especially `data:` URLs, before calling axios.

<details>
<summary>Original Report</summary>

### Summary
When Axios is used with adapter: 'fetch', configured body/response size limits are not enforced. This allows oversized uploads/downloads (including data: URLs) despite explicit limits, which can lead to memory/resource exhaustion in server-side usage.

### Details
maxBodyLength and maxContentLength are not applied in the fetch adapter flow:
  - lib/adapters/fetch.js (146-160): config destructuring does not include these controls.
  - lib/adapters/fetch.js (220-234): request is dispatched with fetch() without request-size enforcement.
  - lib/adapters/fetch.js (267-283): response is materialized via text(), arrayBuffer(), blob(), etc. without response-size checks.
By contrast, the HTTP adapter enforces both limits.

### PoC
  Environment:
  - Axios main at commit f7a4ee2
  - Node v24.2.0

Steps:
  1. Start an HTTP server that counts received bytes and echoes {received}.
  2. Send 2 MiB with:
      - adapter: 'fetch'
      - maxBodyLength: 1024
  3. Request a 4 KiB data: URL with:
      - adapter: 'fetch'
      - maxContentLength: 16

Expected secure behavior: both requests rejected.
 Observed:
  - Upload: success, server received 2097152
  - data: response: success, length 4096

### Impact
Type: DoS / resource exhaustion due to limit bypass.
Impacted: applications using Axios fetch adapter as a server-side security control boundary for untrusted request/response sizes.
</details>

---

Axios is vulnerable to DoS attack through lack of data size check
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'`.

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.