deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4w7w-66w2-5vf9
Package: vite (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 6.4.1
Patched in: 6.4.2

Summary: Vite Vulnerable to Path Traversal in Optimized Deps `.map` Handling

Details:
### Summary

Any files ending with `.map` even out side the project can be returned to the browser.

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- have a sensitive content in files ending with `.map` and the path is predictable

### Details

In Vite v7.3.1, the dev server’s handling of `.map` requests for optimized dependencies resolves file paths and calls `readFile` without restricting `../` segments in the URL. As a result, it is possible to bypass the [`server.fs.strict`](https://vite.dev/config/server-options#server-fs-strict) allow list and retrieve `.map` files located outside the project root, provided they can be parsed as valid source map JSON.

### PoC
1. Create a minimal PoC sourcemap outside the project root
    ```bash
    cat > /tmp/poc.map <<'EOF'
    {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""}
    EOF
    ```
2. Start the Vite dev server (example)
    ```bash
    pnpm -C playground/fs-serve dev --host 127.0.0.1 --port 18080
    ```
3. Confirm that direct `/@fs` access is blocked by `strict` (returns 403)
    <img width="4004" height="1038" alt="image" src="https://github.com/user-attachments/assets/15a859a8-1dc6-4105-8d58-80527c0dd9ab" />
4. Inject `../` segments under the optimized deps `.map` URL prefix to reach `/tmp/poc.map`
    <img width="2790" height="846" alt="image" src="https://github.com/user-attachments/assets/5d02957d-2e6a-4c45-9819-3f024e0e81f2" />
GitHub Security Advisory: GHSA-4w7w-66w2-5vf9
Package: vite (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 7.0.0, <= 7.3.1
Patched in: 7.3.2

Summary: Vite Vulnerable to Path Traversal in Optimized Deps `.map` Handling

Details:
### Summary

Any files ending with `.map` even out side the project can be returned to the browser.

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- have a sensitive content in files ending with `.map` and the path is predictable

### Details

In Vite v7.3.1, the dev server’s handling of `.map` requests for optimized dependencies resolves file paths and calls `readFile` without restricting `../` segments in the URL. As a result, it is possible to bypass the [`server.fs.strict`](https://vite.dev/config/server-options#server-fs-strict) allow list and retrieve `.map` files located outside the project root, provided they can be parsed as valid source map JSON.

### PoC
1. Create a minimal PoC sourcemap outside the project root
    ```bash
    cat > /tmp/poc.map <<'EOF'
    {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""}
    EOF
    ```
2. Start the Vite dev server (example)
    ```bash
    pnpm -C playground/fs-serve dev --host 127.0.0.1 --port 18080
    ```
3. Confirm that direct `/@fs` access is blocked by `strict` (returns 403)
    <img width="4004" height="1038" alt="image" src="https://github.com/user-attachments/assets/15a859a8-1dc6-4105-8d58-80527c0dd9ab" />
4. Inject `../` segments under the optimized deps `.map` URL prefix to reach `/tmp/poc.map`
    <img width="2790" height="846" alt="image" src="https://github.com/user-attachments/assets/5d02957d-2e6a-4c45-9819-3f024e0e81f2" />
GitHub Security Advisory: GHSA-4w7w-66w2-5vf9
Package: vite (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 8.0.0, <= 8.0.4
Patched in: 8.0.5

Summary: Vite Vulnerable to Path Traversal in Optimized Deps `.map` Handling

Details:
### Summary

Any files ending with `.map` even out side the project can be returned to the browser.

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- have a sensitive content in files ending with `.map` and the path is predictable

### Details

In Vite v7.3.1, the dev server’s handling of `.map` requests for optimized dependencies resolves file paths and calls `readFile` without restricting `../` segments in the URL. As a result, it is possible to bypass the [`server.fs.strict`](https://vite.dev/config/server-options#server-fs-strict) allow list and retrieve `.map` files located outside the project root, provided they can be parsed as valid source map JSON.

### PoC
1. Create a minimal PoC sourcemap outside the project root
    ```bash
    cat > /tmp/poc.map <<'EOF'
    {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""}
    EOF
    ```
2. Start the Vite dev server (example)
    ```bash
    pnpm -C playground/fs-serve dev --host 127.0.0.1 --port 18080
    ```
3. Confirm that direct `/@fs` access is blocked by `strict` (returns 403)
    <img width="4004" height="1038" alt="image" src="https://github.com/user-attachments/assets/15a859a8-1dc6-4105-8d58-80527c0dd9ab" />
4. Inject `../` segments under the optimized deps `.map` URL prefix to reach `/tmp/poc.map`
    <img width="2790" height="846" alt="image" src="https://github.com/user-attachments/assets/5d02957d-2e6a-4c45-9819-3f024e0e81f2" />
GitHub Security Advisory: GHSA-v2wj-q39q-566r
Package: vite (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize, CWE-284: Improper Access Control
Vulnerable versions: >= 7.1.0, <= 7.3.1
Patched in: 7.3.2

Summary: Vite: `server.fs.deny` bypassed with queries

Details:
### Summary

The contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser.

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- the sensitive file exists in the allowed directories specified by [`server.fs.allow`](https://vite.dev/config/server-options#server-fs-allow)
- the sensitive file is denied with a pattern that matches a file by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny)

### Details

On the Vite dev server, files that should be blocked by `server.fs.deny` (e.g., `.env`, `*.crt`) can be retrieved with HTTP 200 responses when query parameters such as `?raw`, `?import&raw`, or `?import&url&inline` are appended.

### PoC

1. Start the dev server: `pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort`
2. Confirm that `server.fs.deny` is enforced (expect 403): `curl -i http://127.0.0.1:5175/src/.env | head -n 20`
   <img width="3944" height="1092" alt="image" src="https://github.com/user-attachments/assets/ecb9f2e0-e08f-4ac7-b194-e0f988c4cd4f" />
3. Confirm that the same files can be retrieved with query parameters (expect 200):
   <img width="2014" height="373" alt="image" src="https://github.com/user-attachments/assets/76bc2a6a-44f4-4161-ae47-eab5ae0c04a8" />
GitHub Security Advisory: GHSA-v2wj-q39q-566r
Package: vite (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize, CWE-284: Improper Access Control
Vulnerable versions: >= 8.0.0, <= 8.0.4
Patched in: 8.0.5

Summary: Vite: `server.fs.deny` bypassed with queries

Details:
### Summary

The contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser.

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- the sensitive file exists in the allowed directories specified by [`server.fs.allow`](https://vite.dev/config/server-options#server-fs-allow)
- the sensitive file is denied with a pattern that matches a file by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny)

### Details

On the Vite dev server, files that should be blocked by `server.fs.deny` (e.g., `.env`, `*.crt`) can be retrieved with HTTP 200 responses when query parameters such as `?raw`, `?import&raw`, or `?import&url&inline` are appended.

### PoC

1. Start the dev server: `pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort`
2. Confirm that `server.fs.deny` is enforced (expect 403): `curl -i http://127.0.0.1:5175/src/.env | head -n 20`
   <img width="3944" height="1092" alt="image" src="https://github.com/user-attachments/assets/ecb9f2e0-e08f-4ac7-b194-e0f988c4cd4f" />
3. Confirm that the same files can be retrieved with query parameters (expect 200):
   <img width="2014" height="373" alt="image" src="https://github.com/user-attachments/assets/76bc2a6a-44f4-4161-ae47-eab5ae0c04a8" />
GitHub Security Advisory: GHSA-p9ff-h696-f583
Package: vite (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 6.0.0, <= 6.4.1
Patched in: 6.4.2

Summary: Vite Vulnerable to Arbitrary File Read via Vite Dev Server WebSocket

Details:
### Summary

[`server.fs`](https://vite.dev/config/server-options#server-fs-strict) check was not enforced to the `fetchModule` method that is exposed in Vite dev server's WebSocket. 

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- WebSocket is not disabled by `server.ws: false`

Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.

### Details

If it is possible to connect to the Vite dev server’s WebSocket **without an `Origin` header**, an attacker can invoke `fetchModule` via the custom WebSocket event `vite:invoke` and combine `file://...` with `?raw` (or `?inline`) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., `export default "..."`).

The access control enforced in the HTTP request path (such as `server.fs.allow`) is not applied to this WebSocket-based execution path.

### PoC

1. Start the dev server on the target 
   Example (used during validation with this repository):
   ```bash
   pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173
   ```

2. Confirm that access is blocked via the HTTP path (example: arbitrary file)
   ```bash
   curl -i 'http://localhost:5173/@fs/etc/passwd?raw'
   ```
   Result: `403 Restricted` (outside the allow list)
   <img width="3898" height="1014" alt="image" src="https://github.com/user-attachments/assets/f6593377-549c-45d7-b562-5c19833438af" />

3. Confirm that the same file can be retrieved via the WebSocket path
   By connecting to the HMR WebSocket without an `Origin` header and sending a `vite:invoke` request that calls `fetchModule` with a `file://...` URL and `?raw`, the file contents are returned as a JavaScript module.
  <img width="1049" height="296" alt="image" src="https://github.com/user-attachments/assets/af969f7b-d34e-4af4-8adb-5e2b83b31972" />
  <img width="1382" height="955" alt="image" src="https://github.com/user-attachments/assets/6a230d2e-197a-4c9c-b373-d0129756d5d7" />
GitHub Security Advisory: GHSA-p9ff-h696-f583
Package: vite (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 7.0.0, <= 7.3.1
Patched in: 7.3.2

Summary: Vite Vulnerable to Arbitrary File Read via Vite Dev Server WebSocket

Details:
### Summary

[`server.fs`](https://vite.dev/config/server-options#server-fs-strict) check was not enforced to the `fetchModule` method that is exposed in Vite dev server's WebSocket. 

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- WebSocket is not disabled by `server.ws: false`

Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.

### Details

If it is possible to connect to the Vite dev server’s WebSocket **without an `Origin` header**, an attacker can invoke `fetchModule` via the custom WebSocket event `vite:invoke` and combine `file://...` with `?raw` (or `?inline`) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., `export default "..."`).

The access control enforced in the HTTP request path (such as `server.fs.allow`) is not applied to this WebSocket-based execution path.

### PoC

1. Start the dev server on the target 
   Example (used during validation with this repository):
   ```bash
   pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173
   ```

2. Confirm that access is blocked via the HTTP path (example: arbitrary file)
   ```bash
   curl -i 'http://localhost:5173/@fs/etc/passwd?raw'
   ```
   Result: `403 Restricted` (outside the allow list)
   <img width="3898" height="1014" alt="image" src="https://github.com/user-attachments/assets/f6593377-549c-45d7-b562-5c19833438af" />

3. Confirm that the same file can be retrieved via the WebSocket path
   By connecting to the HMR WebSocket without an `Origin` header and sending a `vite:invoke` request that calls `fetchModule` with a `file://...` URL and `?raw`, the file contents are returned as a JavaScript module.
  <img width="1049" height="296" alt="image" src="https://github.com/user-attachments/assets/af969f7b-d34e-4af4-8adb-5e2b83b31972" />
  <img width="1382" height="955" alt="image" src="https://github.com/user-attachments/assets/6a230d2e-197a-4c9c-b373-d0129756d5d7" />
GitHub Security Advisory: GHSA-p9ff-h696-f583
Package: vite (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 8.0.0, <= 8.0.4
Patched in: 8.0.5

Summary: Vite Vulnerable to Arbitrary File Read via Vite Dev Server WebSocket

Details:
### Summary

[`server.fs`](https://vite.dev/config/server-options#server-fs-strict) check was not enforced to the `fetchModule` method that is exposed in Vite dev server's WebSocket. 

### Impact

Only apps that match the following conditions are affected:

- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host))
- WebSocket is not disabled by `server.ws: false`

Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.

### Details

If it is possible to connect to the Vite dev server’s WebSocket **without an `Origin` header**, an attacker can invoke `fetchModule` via the custom WebSocket event `vite:invoke` and combine `file://...` with `?raw` (or `?inline`) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., `export default "..."`).

The access control enforced in the HTTP request path (such as `server.fs.allow`) is not applied to this WebSocket-based execution path.

### PoC

1. Start the dev server on the target 
   Example (used during validation with this repository):
   ```bash
   pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173
   ```

2. Confirm that access is blocked via the HTTP path (example: arbitrary file)
   ```bash
   curl -i 'http://localhost:5173/@fs/etc/passwd?raw'
   ```
   Result: `403 Restricted` (outside the allow list)
   <img width="3898" height="1014" alt="image" src="https://github.com/user-attachments/assets/f6593377-549c-45d7-b562-5c19833438af" />

3. Confirm that the same file can be retrieved via the WebSocket path
   By connecting to the HMR WebSocket without an `Origin` header and sending a `vite:invoke` request that calls `fetchModule` with a `file://...` URL and `?raw`, the file contents are returned as a JavaScript module.
  <img width="1049" height="296" alt="image" src="https://github.com/user-attachments/assets/af969f7b-d34e-4af4-8adb-5e2b83b31972" />
  <img width="1382" height="955" alt="image" src="https://github.com/user-attachments/assets/6a230d2e-197a-4c9c-b373-d0129756d5d7" />
GitHub Security Advisory: GHSA-xqv9-qr76-hfq2
Package: @elgentos/magento2-dev-mcp (NPM)
Severity: LOW (CVSS 5.3)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 1.0.2
Patched in: unpatched

Summary: @elgentos/magento2-dev-mcp vulnerable to command injection

Details:
A vulnerability was identified in elgentos magento2-dev-mcp up to 1.0.2. The affected element is the function executeMagerun2Command of the file src/index.ts. Such manipulation leads to os command injection. An attack has to be approached locally. The exploit is publicly available and might be used. The name of the patch is aa1ffcc0aea1b212c[PII_REDACTED]3af27df15ae9d. A patch should be applied to remediate this issue.
GitHub Security Advisory: GHSA-wx4p-jr66-jfp9
Package: @nor2/heim-mcp (NPM)
Severity: LOW (CVSS 5.3)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 0.1.3
Patched in: unpatched

Summary: @nor2/heim-mcp vulnerable to command injection

Details:
A vulnerability was determined in Nor2-io heim-mcp up to 0.1.3. Impacted is the function registerTools of the file src/tools.ts of the component new_heim_application/deploy_heim_application/deploy_heim_application_to_cloud. This manipulation causes os command injection. The attack requires local access. The exploit has been publicly disclosed and may be utilized. Patch name: c321d8af25f77668781e6ccb43a1336f9185df37. It is suggested to install a patch to address this issue. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.
GitHub Security Advisory: GHSA-36xv-jgw5-4q75
Package: @nestjs/core (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 11.1.17
Patched in: 11.1.18

Summary: @nestjs/core Improperly Neutralizes Special Elements in Output Used by a Downstream Component ('Injection')

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

[`SseStream._transform()`](https://github.com/nestjs/nest/blob/dea5279ef8fcb568de158003e4281759a2cd7675/packages/core/router/sse-stream.ts) interpolates `message.type` and `message.id` directly into Server-Sent Events text protocol output without sanitizing newline characters (`\r`, `\n`). Since the SSE protocol treats both `\r` and `\n` as field delimiters and `\n\n` as event boundaries, an attacker who can influence these fields through upstream data sources can inject arbitrary SSE events, spoof event types, and corrupt reconnection state. Spring Framework's own security patch ([6e97587](https://github.com/spring-projects/spring-framework/commit/6e9758700a4946be1dca85ca937ef2603e291301)) validates these same fields (`id`, `event`) for the same reason.

Actual impact:

- **Event spoofing**: Attacker forges SSE events with arbitrary `event:` types, causing client-side `EventSource.addEventListener()` callbacks to fire for wrong event types.
- **Data injection**: Attacker injects arbitrary `data:` payloads, potentially triggering XSS if the client renders SSE data as HTML without sanitization.
- **Reconnection corruption**: Attacker injects `id:` fields, corrupting the `Last-Event-ID` header on reconnection, causing the client to miss or replay events.
- **Attack precondition**: Requires the developer to map user-influenced data to the `type` or `id` fields of SSE messages. Direct HTTP request input does not reach these fields without developer code bridging the gap.
-
### Patches
_Has the problem been patched? What versions should users upgrade to?_

Patched in `@nestjs/core@11.1.18`
GitHub Security Advisory: GHSA-9jpj-g8vv-j5mf
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 2026.4.1
Patched in: 2026.4.2

Summary: OpenClaw: Gemini OAuth exposed the PKCE verifier through the OAuth state parameter

Details:
## Summary

Before OpenClaw 2026.4.2, the Gemini OAuth flow reused the PKCE verifier as the OAuth `state` value. Because the provider reflected `state` back in the redirect URL, the verifier could be exposed alongside the authorization code.

## Impact

Anyone who could capture the redirect URL could learn both the authorization code and the PKCE verifier, defeating PKCE's interception protection for that flow and enabling token redemption.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.4.1`
- Patched versions: `>= 2026.4.2`
- Latest published npm version: `2026.4.1`

## Fix Commit(s)

- `a26f4d0f3ef0757db6c6c40277cc06a5de76c52f` — separate OAuth state from the PKCE verifier

OpenClaw thanks @BG0ECV for reporting.
GitHub Security Advisory: GHSA-737v-mqg7-c878
Package: defu (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 6.1.4
Patched in: 6.1.5

Summary: defu: Prototype pollution via `__proto__` key in defaults argument

Details:
### Impact

Applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to `defu()` are vulnerable to prototype pollution.

A crafted payload containing a `__proto__` key can override intended default values in the merged result:

```js
import { defu } from 'defu'

const userInput = JSON.parse('{"__proto__":{"isAdmin":true}}')
const config = defu(userInput, { isAdmin: false })

config.isAdmin // true — attacker overrides the server default
```

### Root Cause

The internal `_defu` function used `Object.assign({}, defaults)` to copy the defaults object. `Object.assign` invokes the `__proto__` setter, which replaces the resulting object's `[[Prototype]]` with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing `__proto__` key guard in the `for...in` loop and land in the final result.

### Fix

Replace `Object.assign({}, defaults)` with object spread (`{ ...defaults }`), which uses `[[DefineOwnProperty]]` and does not invoke the `__proto__` setter.

### Affected Versions

<= 6.1.4

### Credits

Reported by [@BlackHatExploitation](https://github.com/BlackHatExploitation)