deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 7.0.0, < 7.4.7
Patched in: 7.4.7

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 8.0.0, < 8.0.5
Patched in: 8.0.5

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 9.0.0, < 9.0.6
Patched in: 9.0.6

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 10.0.0, < 10.2.1
Patched in: 10.2.1

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-hhfx-5x8j-f5f6
Package: payload (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 3.75.0
Patched in: 3.75.0

Summary: Payload: Server-Side Request Forgery (SSRF) in External File URL Uploads

Details:
### Impact

A Server-Side Request Forgery (SSRF) vulnerability exists in Payload's external file upload functionality. When processing external URLs for file uploads, insufficient validation of HTTP redirects could allow an authenticated attacker to access internal network resources.

**Users are affected if ALL of these are true**:

- Payload version < v3.75.0
- At least one collection with `upload` enabled
- A user has `create` access to that upload-enabled collection

An authenticated user with upload collection write permissions could potentially access internal services. Response content from internal services could be retrieved through the application.

### Patches

This vulnerability has been patched in v3.75.0. Users should upgrade to v3.75.0 or later.

### Workarounds

If users cannot upgrade immediately, they can mitigate this vulnerability by disabling external file uploads via the `disableExternalFile` upload collection option, or by restricting `create` access on upload-enabled collections to **trusted users only**.
GitHub Security Advisory: GHSA-378v-28hj-76wf
Package: bn.js (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 5.0.0, < 5.2.3
Patched in: 5.2.3

Summary: bn.js affected by an infinite loop

Details:
This affects versions of the package bn.js before 4.12.3 and 5.2.3. Calling maskn(0) on any BN instance corrupts the internal state, causing toString(), divmod(), and other methods to enter an infinite loop, hanging the process indefinitely.
GitHub Security Advisory: GHSA-378v-28hj-76wf
Package: bn.js (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 4.12.3
Patched in: 4.12.3

Summary: bn.js affected by an infinite loop

Details:
This affects versions of the package bn.js before 4.12.3 and 5.2.3. Calling maskn(0) on any BN instance corrupts the internal state, causing toString(), divmod(), and other methods to enter an infinite loop, hanging the process indefinitely.
GitHub Security Advisory: GHSA-g4xw-jxrg-5f6m
Package: next-mdx-remote (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 4.3.0, < 6.0.0
Patched in: 6.0.0

Summary: next-mdx-remote affected by arbitrary code execution in React server-side rendering of untrusted MDX content

Details:
The serialize function used to compile MDX in next-mdx-remote is vulnerable to arbitrary code execution due to insufficient sanitization of MDX content.
GitHub Security Advisory: GHSA-cxpw-2g23-2vgw
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 2026.2.17
Patched in: 2026.2.19

Summary: OpenClaw: ACP prompt-size checks missing in local stdio bridge could reduce responsiveness with very large inputs

Details:
## Vulnerability

The ACP bridge accepted very large prompt text blocks and could assemble oversized prompt payloads before forwarding them to `chat.send`.

Because ACP runs over local stdio, this mainly affects local ACP clients (for example IDE integrations) that send unusually large inputs.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.17`
- Patched version: `2026.2.18` (planned next release)

## Impact

- Local ACP sessions may become less responsive when very large prompts are submitted
- Larger-than-expected model usage/cost when oversized text is forwarded
- No privilege escalation and no direct remote attack path in the default ACP model

## Affected Components

- `src/acp/event-mapper.ts`
- `src/acp/translator.ts`

## Remediation

- Enforce a 2 MiB prompt-text limit before concatenation
- Count inter-block newline separator bytes during pre-concatenation size checks
- Keep final outbound message-size validation before `chat.send`
- Avoid stale active-run session state when oversized prompts are rejected
- Add regression tests for oversize rejection and active-run cleanup

## Fix Commit(s)

- `732e53151e8fbdfc0501182ddb0e900878bdc1e3`
- `ebcf19746f5c500a41817e03abecadea8655654a`
- `63e39d7f57ac4ad4a5e38d17e7394ae7c4dd0b9c`

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-9jmq-xgjm-p8c2
Package: @sync-in/server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.9.3
Patched in: 1.9.3

Summary: Sync-in Server has a stored cross-site scripting (XSS) vulnerability

Details:
A Stored Cross-Site Scripting (XSS) vulnerability in Sync-in Server before 1.9.3 allows an authenticated attacker to execute arbitrary JavaScript in a victim's browser. By uploading a crafted SVG file containing a malicious payload, an attacker can access and exfiltrate sensitive information, including the user's session cookies.
GitHub Security Advisory: GHSA-49pc-8936-wvfp
Package: lettermint (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-488: Exposure of Data Element to Wrong Session
Vulnerable versions: < 1.5.1
Patched in: 1.5.1

Summary: Lettermint Node.js SDK leaks email properties to unintended recipients when client instance is reused

Details:
### Impact
Email properties (such as to, subject, html, text, and attachments) are not reset between sends when a single client instance is reused across multiple .send() calls. This can cause properties from a previous send to leak into a subsequent one, potentially delivering content or recipient addresses to unintended parties. Applications sending emails to different recipients in sequence — such as transactional flows like password resets or notifications — are affected.

### Patches
Yes, the issue has been patched. Users should upgrade to v1.5.1 or later.

### Workarounds
If upgrading immediately is not possible, instantiate a new client for each send:
```js
const client = new Lettermint({ apiKey: process.env.LETTERMINT_API_KEY });
await client.email.to('...').subject('...').html('...').send();
```

This ensures no state is carried over between sends.
GitHub Security Advisory: GHSA-w45g-5746-x9fp
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2026.2.17
Patched in: 2026.2.19

Summary: OpenClaw hardened cron webhook delivery against SSRF

Details:
## Affected Packages / Versions

- `openclaw` npm package versions `<= 2026.2.17`.

## Vulnerability
Cron webhook delivery in `src/gateway/server-cron.ts` used `fetch()` directly, so webhook targets could reach private/metadata/internal endpoints without SSRF policy checks.

## Fix Commit(s)
- `99db4d13e`
- `35851cdaf`

Thanks @Adam55A-code for reporting.
GitHub Security Advisory: GHSA-r6h2-5gqq-v5v6
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 2026.2.18
Patched in: 2026.2.19

Summary: OpenClaw: Reject symlinks in local skill packaging script

Details:
## Vulnerability

`skills/skill-creator/scripts/package_skill.py` (a local helper script used when authors package skills) previously followed symlinks while building `.skill` archives.

If an author runs this script on a crafted local skill directory containing symlinks to files outside the skill root, the resulting archive can include unintended file contents.

## Severity and Exposure

- **Severity: Low**
- **Execution context:** local/manual workflow only (skill author packaging step)
- **No remote trigger:** this is not reachable via normal OpenClaw gateway/chat runtime paths
- **No extraction Zip Slip in this finding:** this issue is limited to packaging-time symlink following

## Impact

- Potential unintentional disclosure of local files from the packaging machine into a generated `.skill` artifact.
- Requires local execution of the packaging script on attacker-controlled skill contents.

## Affected Components

- `skills/skill-creator/scripts/package_skill.py`

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Latest published version during triage: `2026.2.17`
- Vulnerable version range: `<= 2026.2.17`
- Planned patched version (next release): `2026.2.18`

## Remediation

- Reject symlinks during skill packaging.
- Add regression tests for symlink file and symlink directory cases.
- Update packaging guidance to document the symlink restriction.

## Fix Commit(s)

- `c275932aa4230fb7a8212fe1b9d2a18424874b3f`
- `ee1d6427b544ccadd73e02b1630ea5c29ba9a9f0`

## Related PR

- https://github.com/openclaw/openclaw/pull/20796

## Release Process Note

`patched_versions` is pre-set to the planned next release (`2026.2.18`). Once npm `openclaw@2026.2.18` is published, this advisory is ready to publish without additional edits.

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-wh94-p5m6-mr7j
Package: openclaw (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2026.2.18
Patched in: 2026.2.18

Summary: OpenClaw Discord moderation authorization used untrusted sender identity in tool-driven flows

Details:
## Overview

Discord moderation action handling (`timeout`, `kick`, `ban`) used sender identity from request parameters in tool-driven flows, instead of trusted runtime sender context.

## Impact

In setups where Discord moderation actions are enabled and the bot has the necessary guild permissions, a non-admin user could request moderation actions by spoofing sender identity fields.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Latest published affected version (as of 2026-02-19): `2026.2.17`
- Affected range: `<=2026.2.17`
- Fixed in planned next release: `2026.2.18`

## Fix

- Moderation authorization now uses trusted sender context (`requesterSenderId`) instead of untrusted action params.
- Added permission checks for required guild capabilities per action.

## Fix Commit(s)

- `775816035ecc6bb243843f8000c9a58ff609e32d`

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-2g4f-4pwh-qvx6
Package: ajv (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 6.14.0
Patched in: 6.14.0

Summary: ajv has ReDoS when using `$data` option

Details:
ajv (Another JSON Schema Validator) through version 8.17.1 is vulnerable to Regular Expression Denial of Service (ReDoS) when the `$data` option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax (`$data` reference), which is passed directly to the JavaScript `RegExp()` constructor without validation. An attacker can inject a malicious regex pattern (e.g., `\"^(a|a)*$\"`) combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with `$data`: true for dynamic schema validation.
GitHub Security Advisory: GHSA-2g4f-4pwh-qvx6
Package: ajv (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 7.0.0-alpha.0, < 8.18.0
Patched in: 8.18.0

Summary: ajv has ReDoS when using `$data` option

Details:
ajv (Another JSON Schema Validator) through version 8.17.1 is vulnerable to Regular Expression Denial of Service (ReDoS) when the `$data` option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax (`$data` reference), which is passed directly to the JavaScript `RegExp()` constructor without validation. An attacker can inject a malicious regex pattern (e.g., `\"^(a|a)*$\"`) combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with `$data`: true for dynamic schema validation.
GitHub Security Advisory: GHSA-8v38-pw62-9cw2
Package: url-parse (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.0.0, < 1.5.7
Patched in: 1.5.7

Summary: url-parse Incorrectly parses URLs that include an '@'

Details:
A specially crafted URL with an '@' sign but empty user info and no hostname, when parsed with url-parse, url-parse will return the incorrect href. In particular,

```js
parse(\"http://@/127.0.0.1\")
```
Will return:
```yaml
{
 slashes: true,
 protocol: 'http:',
 hash: '',
 query: '',
 pathname: '/127.0.0.1',
 auth: '',
 host: '',
 port: '',
 hostname: '',
 password: '',
 username: '',
 origin: 'null',
 href: 'http:///127.0.0.1'
 }
```
If the 'hostname' or 'origin' attributes of the output from url-parse are used in security decisions and the final 'href' attribute of the output is then used to make a request, the decision may be incorrect.
GitHub Security Advisory: GHSA-rqff-837h-mm52
Package: url-parse (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 0.1.0, < 1.5.6
Patched in: 1.5.6

Summary: Authorization bypass in url-parse

Details:
Authorization Bypass Through User-Controlled Key in NPM url-parse prior to 1.5.6.
GitHub Security Advisory: GHSA-6c9j-x93c-rw6j
Package: openclaw (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-203: Observable Discrepancy
Vulnerable versions: <= 2026.2.17
Patched in: 2026.2.19

Summary: OpenClaw safeBins file-existence oracle information disclosure

Details:
An information disclosure vulnerability in OpenClaw's `tools.exec.safeBins` approval flow allowed a file-existence oracle.

When safe-bin validation examined candidate file paths, command allow/deny behavior could differ based on whether a path already existed on the host filesystem. An attacker could probe for file presence by comparing outcomes for existing vs non-existing filenames.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.17`
- Latest published vulnerable version at triage time: `2026.2.17`
- Planned patched version: `2026.2.18`

## Impact
Attackers with access to this execution surface could infer whether specific files exist (for example secrets/config files), enabling filesystem enumeration and improving follow-on attack planning.

## Fix
The safe-bin policy was changed to deterministic argv-only validation without host file-existence checks. File-oriented flags are blocked for safe-bin mode (for example `sort -o`, `jq -f`, `grep -f`), and trusted-path checks remain enforced.

## Fix Commit(s)
- `bafdbb6f112409a65decd3d4e7350fbd637c7754`

Found using [MCPwner](https://github.com/Pigyon/MCPwner)

Thanks @nedlir for reporting.
GitHub Security Advisory: GHSA-4685-c5cp-vp95
Package: openclaw (NPM)
Severity: LOW (CVSS 3.6)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-184: Incomplete List of Disallowed Inputs
Vulnerable versions: <= 2026.2.17
Patched in: 2026.2.19

Summary: OpenClaw safeBins stdin-only bypass via sort output and recursive grep flags

Details:
## Summary
`tools.exec.safeBins` could be bypassed for filesystem access when `sort` output flags (`-o` / `--output`) or recursive `grep` flags were allowed through safe-bin execution paths.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.17`
- Patched versions: `>= 2026.2.19`
- Latest published version at triage time: `2026.2.17`

## Impact
In deployments that enabled `tools.exec.safeBins`, an attacker with access to command execution flows could turn intended stdin-only safe-bin usage into file writes (`sort -o`) or recursive file reads (`grep -R`).

## Fix Commit(s)
- `2c05cbb43e48ebad03626d3125746fb1b9a8520f`

Found using [MCPwner](https://github.com/Pigyon/MCPwner)

Thanks @nedlir for reporting.