deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-69xg-f649-w5g2
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-683: Function Call With Incorrect Order of Arguments
Vulnerable versions: >= 8.0.2, < 8.6.39
Patched in: 8.6.39

Summary: Parse Server OAuth2 adapter app ID validation sends wrong token to introspection endpoint

Details:
### Impact

The OAuth2 authentication adapter does not correctly validate app IDs when `appidField` and `appIds` are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request.

Deployments using the OAuth2 adapter with `appidField` and `appIds` configured are affected.

### Patches

The fix corrects the parameter alignment in the OAuth2 adapter's app ID validation method to match the expected interface, ensuring the correct access token is sent to the introspection endpoint.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-69xg-f649-w5g2
- Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.13
- Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.39
GitHub Security Advisory: GHSA-69xg-f649-w5g2
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-683: Function Call With Incorrect Order of Arguments
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.13
Patched in: 9.6.0-alpha.13

Summary: Parse Server OAuth2 adapter app ID validation sends wrong token to introspection endpoint

Details:
### Impact

The OAuth2 authentication adapter does not correctly validate app IDs when `appidField` and `appIds` are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request.

Deployments using the OAuth2 adapter with `appidField` and `appIds` configured are affected.

### Patches

The fix corrects the parameter alignment in the OAuth2 adapter's app ID validation method to match the expected interface, ensuring the correct access token is sent to the introspection endpoint.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-69xg-f649-w5g2
- Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.13
- Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.39
GitHub Security Advisory: GHSA-9vvh-2768-c8vp
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Discord guild reaction ingress could bypass users and roles allowlists

Details:
## Summary
In affected versions of `openclaw`, Discord reaction ingestion for guild channels did not enforce the same member users and roles allowlist checks used for normal inbound guild messages. A non-allowlisted guild member could still trigger reaction events that were accepted and queued as trusted system events for the target session.

## Impact
This is an authorization bypass in the Discord allowlist path. Reaction text could be injected into downstream session context even when the reacting guild member was not permitted by the configured users or roles allowlist.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `< 2026.3.11`
- Fixed in: `2026.3.11`

## Technical Details
The reaction ingress authorization path enforced DM, group, guild, and channel policy checks, but it did not apply the member-level users and roles allowlist gate that normal guild-message preflight uses. Accepted reactions were then enqueued as trusted system events for the routed session.

## Fix
OpenClaw now applies the same users and roles allowlist enforcement to guild reaction ingress that it already applies to normal inbound guild messages. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-vh9h-29pq-r5m8
Package: locutus (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 3.0.13
Patched in: 3.0.14

Summary: Locutus vulnerable to RCE via unsanitized input in create_function()

Details:
## Summary

The `create_function(args, code)` function passes both parameters directly to the `Function` constructor without any sanitization, allowing arbitrary code execution.

This is distinct from CVE-2026-29091 (GHSA-fp25-p6mj-qqg6) which was `call_user_func_array` using `eval()` in v2.x. This finding affects `create_function` using `new Function()` in v3.x.

## Root Cause

`src/php/funchand/create_function.ts:17`:
```typescript
return new Function(...params, code)
```

Zero input validation on either parameter.

## PoC

```javascript
const { create_function } = require('locutus/php/funchand/create_function');
const rce = create_function('', 'return require("child_process").execSync("id").toString()');
console.log(rce());
// Output: uid=501(user) gid=20(staff) ...
```

Confirmed on locutus v3.0.11, Node.js v24.13.1.

## Impact

Full RCE when an attacker can control either argument to `create_function()`. 597K weekly npm downloads.

## Suggested Fix

Remove `create_function` or replace `new Function()` with a safe alternative. PHP itself deprecated `create_function()` in PHP 7.2 for the same reason.

## Response

Thanks for the report.

We confirmed that `php/funchand/create_function` was still present through `locutus@3.0.13` and that it exposed dynamic code execution via `new Function(...)`.

While this was intended behavior, `create_function()` inherently needs to be unsafe in order for it to work, `create_function()` was deprecated in PHP 7.2 and removed in PHP 8.0. Given that Locutus' parity target today is 8.3, this function shouldn't have been in Locutus at all anymore.

We fixed this in `locutus@3.0.14` by removing `php/funchand/create_function` entirely. That matches our PHP 8.3 parity target more closely: . 

We also updated `php/var/var_export` so closures now export using the PHP 8-style `\Closure::__set_state(array(...))` form instead of referencing the removed API.

Release:
- npm: `locutus@3.0.14`
- GitHub release: https://github.com/locutusjs/locutus/releases/tag/v3.0.14

Credit to @ByamB4 for the report.
GitHub Security Advisory: GHSA-qvr7-g57c-mrc7
Package: openclaw (NPM)
Severity: LOW (CVSS 2.5)
CWE: CWE-636: Not Failing Securely ('Failing Open')
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode

Details:
## Summary
In affected versions of `openclaw`, local gateway helper credential resolution treated configured but unavailable `gateway.auth.token` and `gateway.auth.password` SecretRefs as if they were unset and could fall back to `gateway.remote.*` credentials in local mode.

## Impact
This could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
The local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked "absent" to the helper layer.

## Fix
OpenClaw now tracks whether the local auth input is configured separately from whether it resolves successfully. In local mode, remote fallback is allowed only when the matching local auth input is truly unset. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-mj4p-rc52-m843
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Sandbox staged writes could escape the verified parent directory before commit

Details:
## Summary
In affected versions of `openclaw`, sandbox fs-bridge writes validated the destination before commit, but temporary file creation and population were not pinned to a verified parent directory. A raced parent-path alias change could cause the staged temp file to be created outside the intended writable mount before the final guarded replace step.

## Impact
This is a sandbox boundary bypass affecting integrity and availability within the writable mount scope. Attacker-controlled bytes could be written outside the intended validated path before the final guarded step ran.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
The older staging flow created and wrote the temporary file using target-directory shell path operations before the final replace step revalidated the destination. That meant the last guard protected only the final rename, not the earlier temp-file materialization path.

## Fix
OpenClaw now resolves a pinned mount root plus relative parent path, creates the temporary file inside the verified parent directory, and performs the final atomic replace from that pinned directory context. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-jf6w-m8jw-jfxc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Write-scoped callers could reach admin-only session reset logic through `agent`

Details:
## Summary
In affected versions of `openclaw`, a gateway caller with `operator.write` could issue `agent` requests containing `/new` or `/reset` and reach the same reset path used by the admin-only `sessions.reset` RPC.

## Impact
On gateways where a caller is intentionally granted `operator.write` but not `operator.admin`, that caller could reset targeted conversation state through `agent` slash commands. This crosses the documented method-scope boundary between write-scoped messaging and admin-only session mutation.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
Scope checks were enforced only on the outer RPC method. The `agent` slash-command path reused admin-only reset logic internally, so a write-scoped caller could reach session-reset mutation without holding `operator.admin`.

## Fix
OpenClaw no longer routes conversation `/new` and `/reset` through the admin-only `sessions.reset` entry point. Reset logic now lives in a shared service, while `sessions.reset` remains admin-only. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-qc36-x95h-7j53
Package: openclaw (NPM)
Severity: HIGH (CVSS 8.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity

Details:
## Summary
In affected versions of `openclaw`, node-host `system.run` approvals did not bind a mutable file operand for some script runners, including forms such as `tsx` and `jiti`. An attacker could obtain approval for a benign script-runner command, rewrite the referenced script on disk, and have the modified code execute under the already approved run context.

## Impact
Deployments that rely on node-host `system.run` approvals for script integrity could execute rewritten local code after operator approval. This can lead to unintended local code execution as the OpenClaw runtime user.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `< 2026.3.11`
- Fixed in: `2026.3.11`

## Technical Details
The approval planner only tracked mutable script operands for a hardcoded set of interpreters and runtime forms. Commands such as `tsx ./run.ts` and `jiti ./run.ts` fell through without a bound file snapshot, so the final pre-execution revalidation step was skipped.

## Fix
OpenClaw now fails closed for approval-backed interpreter and runtime commands unless it can bind exactly one concrete local file operand, and it extends direct-file binding coverage for additional runtime forms. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-8jhh-jcqg-mj5p
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Channel commands could bypass account-scoped `configWrites` restrictions

Details:
## Summary
In affected versions of `openclaw`, channel-initiated config mutations were authorized against the originating account's `configWrites` policy but did not consistently re-check the targeted account scope. An authorized sender on one account could mutate protected sibling-account configuration when the target account had `configWrites: false`.

## Impact
This is an account-scoped policy bypass inside a single gateway deployment. Channel commands such as `/config set channels.<provider>.accounts.<id>...` and config-backed `/allowlist ... --config --account <id>` could modify protected sibling-account configuration.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
The mutation path validated the origin account scope but did not consistently authorize every resolved target scope. Ambiguous collection and root writes under `channels` and `channels.<provider>.accounts` could therefore reach protected account configuration from channel command surfaces.

## Fix
OpenClaw now authorizes config mutations against both the origin scope and each resolved target scope, and it rejects ambiguous root and collection writes from channel commands unless the caller is an internal gateway client with `operator.admin`. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-rw39-5899-8mxp
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.1)
CWE: CWE-436: Interpretation Conflict, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Node-host approvals could show misleading shell payloads instead of the executed argv

Details:
## Summary
In affected versions of `openclaw`, node-host `system.run` approvals could display only an extracted shell payload such as `jq --version` while execution still ran a different outer wrapper argv such as `./env sh -c 'jq --version'`.

## Impact
This is an approval-integrity bug. An attacker who could place or select a local wrapper binary and induce a wrapper-shaped command could get local code executed after the operator approved misleading command text.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
Wrapper resolution normalized executables by basename and extracted inner shell payload text for approval display, while execution still preserved the full wrapper argv. Approval storage and UI therefore showed text that did not match the exact command OpenClaw would execute.

## Fix
OpenClaw now binds approvals to the exact executed argv and keeps extracted shell payload text only as secondary preview data. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-xf99-j42q-5w5p
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.3)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Unbound interpreter and runtime commands could bypass node-host approval integrity

Details:
## Summary
In affected versions of `openclaw`, node-host `system.run` approvals could still execute rewritten local code for interpreter and runtime commands when OpenClaw could not bind exactly one concrete local file operand during approval planning.

## Impact
Deployments using node-host `system.run` approval mode could approve a benign local script and then execute different local code if that script changed before execution. This can lead to unintended local code execution as the OpenClaw runtime user.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
The approval flow treated some interpreter and runtime forms as approval-backed even when it could not honestly bind a single direct local script file. That left residual approval-integrity gaps for runtime forms outside the directly bound file set.

## Fix
OpenClaw now fails closed for approval-backed interpreter and runtime commands unless it can bind exactly one concrete local file operand, and it extends best-effort direct-file binding for additional runtime forms. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-4w7m-58cg-cmff
Package: openclaw (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Leaf subagents could steer sibling sessions across sandbox boundaries

Details:
## Summary
In affected versions of `openclaw`, sandboxed leaf subagents could still access the `subagents` control surface and resolve against the parent requester scope instead of remaining confined to their own session tree.

## Impact
A low-privilege sandboxed leaf worker could steer or kill a sibling run owned by the same requester and cause that sibling to execute with its own broader tool policy. This is a sandbox and session-scope boundary bypass.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
Leaf subagents retained the `subagents` tool, and subagent control requests were authorized against the parent requester scope rather than the caller's own spawned descendants. The control path prevented only self-targeting, not cross-sibling steering.

## Fix
OpenClaw now removes `subagents` control access from leaf subagents by default, scopes subagent control to the caller's own descendants, and rejects `steer` and `kill` requests that target runs outside that descendant tree. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-4jpw-hj22-2xmc
Package: openclaw (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Pairing-scoped device tokens could mint `operator.admin` and reach node RCE

Details:
## Summary
In affected versions of `openclaw`, a caller holding only `operator.pairing` could use `device.token.rotate` to mint a new token with broader scopes for an already paired device. If the target device was approved for `operator.admin`, the attacker could obtain an administrative token without already holding administrative scope.

## Impact
This is a critical authorization flaw. On deployments with connected node hosts or companion apps that expose `system.run`, the escalated token could then modify node execution approvals and reach real remote code execution on the node. Even without nodes, the flaw still granted unauthorized gateway-admin access.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.3.8`
- Fixed in: `2026.3.11`

## Technical Details
`device.token.rotate` accepted caller-supplied target scopes and validated them against the target device's approved scopes, but it did not constrain the newly minted scopes to the caller's own current scope set. That allowed a pairing-scoped caller to mint a broader token for an already paired administrative device.

## Fix
OpenClaw now enforces caller-scope subsetting in `device.token.rotate`, preventing callers from minting device tokens broader than the scopes they already hold. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-xw77-45gv-p728
Package: openclaw (NPM)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-269: Improper Privilege Management, CWE-285: Improper Authorization
Vulnerable versions: >= 2026.3.7, < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Plugin subagent routes could bypass gateway authorization with synthetic admin scopes

Details:
## Summary
In affected versions of `openclaw`, the plugin subagent runtime dispatched gateway methods through a synthetic operator client that always carried broad administrative scopes. Plugin-owned HTTP routes using `auth: "plugin"` could therefore trigger admin-only gateway actions without normal gateway authorization.

## Impact
This is a critical authorization bypass. An external unauthenticated request to a plugin-owned route could reach privileged subagent runtime methods and perform admin-only gateway actions such as deleting sessions, reading session data, or triggering agent execution.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `>= 2026.3.7, < 2026.3.11`
- Fixed in: `2026.3.11`

## Technical Details
The new plugin subagent runtime preserved neither the original caller's auth context nor least-privilege scope. Instead, it executed gateway dispatches through a fabricated operator client with administrative scopes, which was reachable from plugin-owned routes that intentionally bypass normal gateway auth so plugins can perform their own webhook verification.

## Fix
OpenClaw now preserves real authorization boundaries for plugin subagent calls instead of dispatching them through synthetic admin scopes. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.
GitHub Security Advisory: GHSA-xvx8-77m6-gwg6
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 2026.3.11
Patched in: 2026.3.11

Summary: OpenClaw: Sandbox `writeFile` commit could race outside the validated path

Details:
## Summary
In affected versions of `openclaw`, the sandbox fs-bridge `writeFile` commit step used an unanchored container path during the final move into place. An attacker racing parent-path changes inside the sandbox could redirect the committed file outside the validated sandbox path.

## Impact
This is a sandbox boundary bypass. In-sandbox code could win a time-of-check-time-of-use race and cause host-approved `writeFile` operations to land outside the validated writable path within the container mount namespace.

## Affected Packages and Versions
- Package: `openclaw` (npm)
- Affected versions: `< 2026.3.11`
- Fixed in: `2026.3.11`

## Technical Details
The hardening work for anchored remove, rename, and mkdir operations did not fully cover the `writeFile` commit path. The final `mv` still used the raw target path, leaving a race window between safety revalidation and the in-container commit step.

## Fix
OpenClaw now anchors the `writeFile` commit path to the canonical parent directory before the final move. The fix shipped in `openclaw@2026.3.11`.

## Workarounds
Upgrade to `2026.3.11` or later.