deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mf3j-86qx-cq5j
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.0-alpha.14
Patched in: 9.5.0-alpha.14

Summary: Parse Server has Regular Expression Denial of Service (ReDoS) via `$regex` query in LiveQuery

Details:
### Impact

A malicious client can subscribe to a LiveQuery with a crafted `$regex` pattern that causes catastrophic backtracking, blocking the Node.js event loop. This makes the entire Parse Server unresponsive, affecting all clients. Any Parse Server deployment with LiveQuery enabled is affected. The attacker only needs the application ID and JavaScript key, both of which are public in client-side apps.

This only affects LiveQuery subscription matching, which evaluates regex in JavaScript on the Node.js event loop. Normal REST and GraphQL queries are not affected because their regex is evaluated by the database engine.

### Patches

Regex evaluation in LiveQuery subscription matching now runs in an isolated VM context with a configurable timeout via a new Parse Server option `liveQuery.regexTimeout, with defaults 100 ms. A regex that exceeds the timeout is treated as non-matching.

The protection adds approximately 50 microseconds of overhead per regex evaluation. For most applications this is negligible, but it can add up if there is a very large number of LiveQuery subscriptions that use `$regex` on the same class. For example, 10,000 concurrent regex subscriptions would add approximately 500ms of processing time per object save event on that class. Set `liveQuery.regexTimeout: 0` to disable the protection and use native regex evaluation without overhead.

### Workarounds

Use the `beforeSubscribe` Cloud Code hook to reject any LiveQuery subscription that contains a `$regex` operator. Note that this also blocks the LiveQuery `startsWith`, `endsWith`, and `contains` query methods, as they use `$regex` internally.

```js
// Repeat for each class that is used with LiveQuery
Parse.Cloud.beforeSubscribe('MyClass', request => {
  const where = request.query._where || {};
  for (const value of Object.values(where)) {
    if (value?.$regex) {
      throw new Parse.Error(Parse.Error.OPERATION_FORBIDDEN, '$regex not allowed in LiveQuery subscriptions');
    }
  }
});
```

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mf3j-86qx-cq5j
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.14
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.11
GitHub Security Advisory: GHSA-9q36-67vc-rrwg
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-284: Improper Access Control, CWE-693: Protection Mechanism Failure, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: Sandboxed /acp spawn requests could initialize host ACP sessions

Details:
### Summary
Sandboxed requester sessions could reach host-side ACP session initialization through `/acp spawn`.

OpenClaw already blocked `sessions_spawn({ runtime: "acp" })` from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first.

### Affected Packages / Versions
- npm package: `openclaw`
- Affected versions: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

### Details
ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in `src/agents/acp-spawn.ts` already denied sandboxed requesters, but `/acp spawn` in `src/auto-reply/reply/commands-acp/lifecycle.ts` called `initializeSession(...)` without first applying the same restriction.

In affected versions, an already authorized sender in a sandboxed session could use `/acp spawn` to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available.

### Fix Commit(s)
- `61000b8e4ded919ca1a825d4700db4cb3fdc56e3`

### Fix Details
The fix introduced a shared ACP runtime-policy guard in `src/agents/acp-spawn.ts` and reused it from the `/acp spawn` handler in `src/auto-reply/reply/commands-acp/lifecycle.ts` before any ACP backend initialization. Regression coverage was added in `src/auto-reply/reply/commands-acp.test.ts` to prove sandboxed `/acp spawn` requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged.

### Release Process Note
Patched version is pre-set to `2026.3.7` so the advisory can be published once that npm release is available.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-9q2p-vc84-2rwm
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-436: Interpretation Conflict, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: system.run allow-always persistence included shell-commented payload tails

Details:
OpenClaw's `system.run` allowlist analysis did not honor POSIX shell comment semantics when deriving `allow-always` persistence entries.

A caller in `security=allowlist` mode who received an `allow-always` decision could submit a shell command whose tail was commented out at runtime, for example by using an unquoted `#` before a chained payload. The runtime shell would execute only the pre-comment portion, but allowlist persistence could still analyze and store the non-executed tail as a trusted follow-up command.

Latest published npm version: `2026.3.2`

Fixed on `main` on March 7, 2026 in `939b18475d734ed75173f59507e3ebbdfe1992b7` by teaching shell tokenization and chain/pipeline analysis to stop at unquoted shell comments, so allow-always persistence now tracks only commands that the shell can actually execute. Normal real chained commands and quoted `#` literals continue to work.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

## Fix Commit(s)

- `939b18475d734ed75173f59507e3ebbdfe1992b7`

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-hfpr-jhpq-x4rm
Package: openclaw (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: `operator.write` chat.send could reach admin-only config writes

Details:
### Summary
A gateway client authenticated with `operator.write` could route `/config set` or `/config unset` through `chat.send` and reach persistent config mutation even though direct config RPC methods are admin-scoped.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.2`
- Affected range: `<= 2026.3.2`
- Patched in: `2026.3.7`

### Details
Before the fix, `chat.send` ran slash commands in an internal gateway-chat context with `CommandAuthorized: true`, and `/config` write paths only checked command authorization plus `commands.config` / `channels.<provider>.configWrites` gates. That allowed an authenticated `operator.write` gateway client to bridge into persistent config writes even though direct `config.*` RPC methods remain `operator.admin` scoped.

The fix keeps command functionality intact while restoring the intended scope boundary:
- persistent `/config set|unset` writes routed through gateway `chat.send` now require `operator.admin`
- read-only `/config show` remains available to normal write-scoped gateway clients
- normal messaging-channel `/config` behavior remains unchanged

### Impact
This is a real authorization mismatch, but exploitability requires an already authenticated gateway client with `operator.write`, `chat.send` access, and `/config` command support enabled. Maintainer severity is set to medium because the bug is a scoped control-plane privilege mismatch rather than a broad unauthenticated or generic remote compromise. The main consequence is unintended persistent config mutation.

### Fix Commit(s)
- `5f8f58ae25e2a78f31b06edcf26532d634ca554e`

### Release Process Note
npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-r6qf-8968-wj9q
Package: openclaw (NPM)
Severity: LOW (CVSS 5.3)
CWE: CWE-436: Interpretation Conflict, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: system.run wrapper-depth boundary could skip shell approval gating

Details:
OpenClaw's `system.run` dispatch-wrapper handling applied different depth-boundary rules to shell-wrapper approval detection and execution planning.

With exactly four transparent dispatch wrappers such as repeated `env` invocations before `/bin/sh -c`, the approval classifier could stop treating the command as a shell wrapper at the depth boundary while execution planning still unwrapped through to the shell payload. In `security=allowlist` mode, that mismatch could skip the expected approval-required path for the shell wrapper invocation.

Latest published npm version: `2026.3.2`

Fixed on `main` on March 7, 2026 in `2fc95a7cfc1eb[PII_REDACTED]b0251b6d51fb1c0b0` by keeping shell-wrapper classification active at the configured dispatch depth boundary and only failing closed beyond that boundary. This aligns approval gating with the execution plan. Legitimate shallow dispatch-wrapper usage continues to work.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

## Fix Commit(s)

- `2fc95a7cfc1eb[PII_REDACTED]b0251b6d51fb1c0b0`

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-6mgf-v5j7-45cr
Package: openclaw (NPM)
Severity: HIGH (CVSS 9.3)
CWE: CWE-116: Improper Encoding or Escaping of Output, CWE-184: Incomplete List of Disallowed Inputs, CWE-522: Insufficiently Protected Credentials
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: fetch-guard forwards custom authorization headers across cross-origin redirects

Details:
OpenClaw's `fetchWithSsrFGuard(...)` followed cross-origin redirects while preserving arbitrary caller-supplied headers except for a narrow denylist (`Authorization`, `Proxy-Authorization`, `Cookie`, `Cookie2`). This allowed custom authorization headers such as `X-Api-Key`, `Private-Token`, and similar sensitive headers to be forwarded to a different origin after a redirect.

The fix switches cross-origin redirect handling from a narrow sensitive-header denylist to a safe-header allowlist, so only benign headers such as content negotiation and cache validators survive an origin change.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.2`
- Patched version: `2026.3.7`
- Latest published npm version at patch time: `2026.3.2`

## Impact

A remote service that could trigger a redirect across origins could receive custom authorization credentials attached by OpenClaw callers. This can expose API keys, bearer-style custom headers, or private token headers intended only for the original destination.

## Fix Commit(s)

- `46715371b0612a6f9114dffd1466941ac476cef5`

## Verification

- `pnpm check` passed
- `pnpm test:fast` passed
- Focused redirect regression tests passed
- `pnpm exec vitest run --config vitest.gateway.config.ts` still has unrelated current-`main` failures in `src/gateway/server-channels.test.ts` and `src/gateway/server-methods/agents-mutate.test.ts`

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @Rickidevs for reporting.
GitHub Security Advisory: GHSA-pjvx-rx66-r3fg
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw: Cross-account sender authorization expansion in `/allowlist ... --store` account scoping

Details:
### Summary
`/allowlist ... --store` resolved the selected channel `accountId` for reads, but store writes still dropped that `accountId` and wrote into the legacy unscoped pairing allowlist store.

Because default-account reads still merge legacy unscoped entries, a store entry intended for one account could silently authorize the same sender on the `default` account.

This is a real cross-account sender-authorization scoping bug. Severity is set to **medium** because exploitation requires an already-authorized user who can run `/allowlist` edits.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published version checked: `2026.3.2`
- Affected versions: `<= 2026.3.2`
- Fixed on `main`: March 7, 2026 in `70da80bcb5574a[PII_REDACTED]d2ebb2abf882e73`
- Patched release: `2026.3.7`

### Details
The affected path was:
- `src/auto-reply/reply/commands-allowlist.ts:386-393` resolved `accountId` and read store state with it
- `src/auto-reply/reply/commands-allowlist.ts:697-702` and `src/auto-reply/reply/commands-allowlist.ts:730-733` wrote store state without passing `accountId`
- `src/pairing/pairing-store.ts:231-234` and `src/pairing/pairing-store.ts:534-554` still merged legacy unscoped allowlist entries into the `default` account

The fix scopes `/allowlist ... --store` writes to the resolved account and clears legacy default-account store entries on removal so legacy reads no longer create cross-account authorization bleed-through.

### Impact
- Vulnerability class: improper authorization scoping / incorrect authorization
- Exploitation requires: an already-authorized sender who can run `/allowlist` edits
- Security effect: unintended authorization expansion from one channel account into `default`

### Fix Commit(s)
- `70da80bcb5574a[PII_REDACTED]d2ebb2abf882e73` — scope `/allowlist ... --store` writes by account and clean up legacy default-account removals

### Release Process Note
npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-3h2q-j2v4-6w5r
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-184: Incomplete List of Disallowed Inputs, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw's system.run allowlist approval parsing missed PowerShell encoded-command wrappers

Details:
OpenClaw's `system.run` shell-wrapper detection did not recognize PowerShell `-EncodedCommand` forms as inline-command wrappers.

In `allowlist` mode, a caller with access to `system.run` could invoke `pwsh` or `powershell` using `-EncodedCommand`, `-enc`, or `-e`, and the request would fall back to plain argv analysis instead of the normal shell-wrapper approval path. This could allow a PowerShell inline payload to execute without the approval step that equivalent `-Command` invocations would require.

Latest published npm version: `2026.3.2`

Fixed on `main` on March 7, 2026 in `1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d` by recognizing PowerShell encoded-command aliases during shell-wrapper parsing, so allowlist mode continues to require approval for those payloads. Normal approved PowerShell wrapper flows continue to work.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

## Fix Commit(s)

- `1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d`

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-j425-whc4-4jgc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-15: External Control of System or Configuration Setting, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw's `system.run` env override filtering allowed dangerous helper-command pivots

Details:
### Summary
`system.run` env override sanitization allowed dangerous override-only helper-command pivots to reach subprocesses. A caller who could invoke `system.run` with `env` overrides could bypass allowlist/approval intent by steering an allowlisted tool through helper-command or config-loading environment variables such as `GIT_SSH_COMMAND`, editor/pager hooks, and `GIT_CONFIG_*` / `NPM_CONFIG_*`.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.2`
- Affected range: `<= 2026.3.2`
- Patched in: `2026.3.7`

### Details
Before the fix, `src/infra/host-env-security.ts` blocked only a narrow set of override-only environment variables. Dangerous request-scoped overrides such as `GIT_SSH_COMMAND` and prefix families such as `GIT_CONFIG_*` and `NPM_CONFIG_*` could still survive `sanitizeSystemRunEnvOverrides(...)` / `sanitizeHostExecEnv(...)` and reach the spawned process.

That mattered for `system.run` allowlist and approval flows because approval evaluation was tied to the reviewed binary/argv, while the launched process could still inherit attacker-controlled env overrides that changed helper-command execution or config resolution. For allowlisted tools such as `git`, this allowed behavior outside the reviewed command semantics.

The fix extends the shared TypeScript and macOS policy to block dangerous override-only exact keys and prefixes while preserving trusted inherited base-environment behavior.

### Impact
This is a real protection-bypass issue, but exploitation requires an already tool-enabled caller who can invoke `system.run` and supply `env` overrides. In affected deployments, that caller could bypass allowlist/approval intent and trigger helper-command execution or config-loading behavior that is not represented by the approved command line. Maintainer severity is set to medium because the bug still requires that existing execution capability; the vulnerability is the mismatch between reviewed command semantics and the actual spawned-process behavior.

### Fix Commit(s)
- `e27bbe4982439da6864160fd1b66445058f74801`

### Release Process Note
npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey and @SnailSploit for reporting.
GitHub Security Advisory: GHSA-6rmx-gvvg-vh6j
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts, CWE-799: Improper Control of Interaction Frequency
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw's hooks count non-POST requests toward auth lockout

Details:
OpenClaw's hooks HTTP handler counted hook authentication failures before rejecting unsupported HTTP methods. An unauthenticated client could send repeated non-`POST` requests (for example `GET`) with an invalid token to consume the hook auth failure budget and trigger the temporary lockout window for that client key.

The fix moves the hook method gate ahead of auth-failure accounting so unsupported methods return `405 Method Not Allowed` without incrementing the hook auth limiter.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.2`
- Patched version: `2026.3.7`
- Latest published npm version at patch time: `2026.3.2`

## Impact

An unauthenticated network client that could reach `/hooks/*` could temporarily lock out legitimate webhook delivery when requests collapsed to the same hook auth client key, such as shared proxy or NAT topologies. Impact is limited to temporary availability loss for hook-triggered wake or automation delivery.

## Fix Commit(s)

- `44820dceadac65ac7c0ce8fc0ffba8c2bd9fae89`

## Verification

- `pnpm check` passed
- `pnpm test:fast` passed
- focused hook regression tests passed
- `pnpm exec vitest run --config vitest.gateway.config.ts` still has unrelated current-`main` failures in `src/gateway/server-channels.test.ts` and `src/gateway/server-methods/agents-mutate.test.ts`

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @JNX03 for reporting.
GitHub Security Advisory: GHSA-rchv-x836-w7xp
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.1)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 2026.3.2
Patched in: 2026.3.7

Summary: OpenClaw's dashboard leaked gateway auth material via browser URL/query and localStorage

Details:
OpenClaw's macOS Dashboard flow exposed Gateway authentication material to browser-controlled surfaces.

Before the fix, the macOS app appended the shared Gateway `token` and `password` to the Dashboard URL query string when opening the Control UI in the browser. The Control UI then imported the token and persisted it into browser `localStorage` under `openclaw.control.settings.v1`.

This expanded exposure of reusable Gateway admin credentials into browser address-bar/query surfaces and persistent script-readable storage.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Latest published version verified vulnerable: `2026.3.2`
- Affected range: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

## Impact

An attacker with access to browser-controlled surfaces or persistent browser storage could recover a valid Gateway admin token and reuse it against the OpenClaw management interface.

The exposure chain was:

1. macOS `Open Dashboard` constructed a URL with auth material.
2. The browser received that credential-bearing URL.
3. The Control UI imported the token from the URL.
4. The Control UI persisted the token in `localStorage`.

## Fix

The fix aligns the macOS Dashboard flow with the safer existing CLI/bootstrap pattern and removes persistent browser token storage:

- macOS Dashboard now passes the Gateway token via URL fragment instead of query parameters.
- macOS Dashboard no longer propagates the shared Gateway password into browser URLs.
- Control UI keeps Gateway tokens in memory only for the current tab.
- Control UI scrubs legacy persisted tokens from `openclaw.control.settings.v1` on load.
- Regression tests cover fragment transport, password omission, and token-scrubbing behavior.

## Fix Commit(s)

- `10d0e3f3ca92326df0ca071fabffe463742f263c` (March 7, 2026)

## Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @whiter6666 for reporting.