deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-c442-97qw-j6c6
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.10
Patched in: 9.6.0-alpha.10

Summary: Parse Server has a SQL injection via query field name when using PostgreSQL

Details:
### Impact

An attacker with access to the master key can inject malicious SQL via crafted field names used in query constraints when Parse Server is configured with PostgreSQL as the database. The field name in a `$regex` query operator is passed to PostgreSQL using unparameterized string interpolation, allowing the attacker to manipulate the SQL query. While the master key controls what can be done through the Parse Server abstraction layer, this SQL injection bypasses Parse Server entirely and operates at the database level.

This vulnerability only affects Parse Server deployments using PostgreSQL.

### Patches

The fix applies proper SQL identifier escaping to field names in the query handler and hardens query field name validation to reject malicious field names for all query types.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-c442-97qw-j6c6
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.10
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.36
GitHub Security Advisory: GHSA-8wq8-6859-qx77
Package: @backstage/plugin-scaffolder-backend (NPM)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 3.1.0, < 3.1.5
Patched in: 3.1.5

Summary: @backstage/plugin-scaffolder-backend: Possible exposure of defaultEnvironment secrets using dry-run endpoint

Details:
### Impact                                                                                                                                                                         
                                         
  Authenticated users with permission to execute scaffolder dry-runs can gain access to server-configured environment secrets through the dry-run API response. Secrets are properly 
  redacted in log output but not in all parts of the response payload.
                                                                                                                                                                                     
  Deployments that have configured `scaffolder.defaultEnvironment.secrets` are affected.
                          
  ### Patches                            

  This is patched in `@backstage/plugin-scaffolder-backend` version 3.1.5
  ### Workarounds

  Remove or empty the `scaffolder.defaultEnvironment.secrets` configuration from `app-config.yaml`. Alternatively, restrict access to the scaffolder dry-run functionality via the
  permissions framework.

  ### References

  - [Backstage Scaffolder Backend documentation](https://backstage.io/docs/features/software-templates/)
GitHub Security Advisory: GHSA-qp4c-xg64-7c6x
Package: @backstage/plugin-auth-backend (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.27.1
Patched in: 0.27.1

Summary: @backstage/plugin-auth-backend: SSRF in experimental CIMD metadata fetch

Details:
### Impact                                                                                                                                                                         
                                                           
  A Server-Side Request Forgery (SSRF) vulnerability exists in `@backstage/plugin-auth-backend` when `auth.experimentalClientIdMetadataDocuments.enabled` is set to `true`. The CIMD 
  metadata fetch validates the initial `client_id` hostname against private IP ranges but does not apply the same validation after HTTP redirects.
                          
  The practical impact is limited. The attacker cannot read the response body from the internal request, cannot control request headers or method, and the feature must be explicitly
   enabled via an experimental flag that is off by default. Deployments that restrict `allowedClientIdPatterns` to specific trusted domains are not affected.

  ### Patches

  Patched in `@backstage/plugin-auth-backend` version `0.27.1`. The fix disables HTTP redirect following when fetching CIMD metadata documents.

  ### Workarounds

  Disable the experimental CIMD feature by removing or setting `auth.experimentalClientIdMetadataDocuments.enabled` to `false` in your app-config. This is the default configuration.
   Alternatively, restrict `allowedClientIdPatterns` to specific trusted domains rather than using the default wildcard pattern.

  ### References

  - [IETF Client ID Metadata Document draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)
  - [MCP Authorization Specification - Client ID Metadata Documents](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents)
GitHub Security Advisory: GHSA-wqvh-63mv-9w92
Package: @backstage/plugin-auth-backend (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation, CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 0.27.1
Patched in: 0.27.1

Summary: @backstage/plugin-auth-backend: OAuth redirect URI allowlist bypass

Details:
### Impact

The experimental OIDC provider in `@backstage/plugin-auth-backend` is vulnerable to a redirect URI allowlist bypass. Instances that have enabled experimental Dynamic Client Registration or Client ID Metadata Documents and configured `allowedRedirectUriPatterns` are affected.

A specially crafted redirect URI can pass the allowlist validation while resolving to an attacker-controlled host. If a victim approves the resulting OAuth consent request, their authorization code is sent to the attacker, who can exchange it for a valid access token.

This requires victim interaction and that one of the experimental features is explicitly enabled, which is not the default.

### Patches

Upgrade to `@backstage/plugin-auth-backend` version 0.27.1 or later.

### Workarounds

Disable experimental Dynamic Client Registration and Client ID Metadata Documents features if they are not required.

### References

- [RFC 6749 Section 3.1.2 - Redirection Endpoint](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2)
GitHub Security Advisory: GHSA-c7hf-c5p5-5g6h
Package: uptime-kuma (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.0.0, <= 2.1.3
Patched in: 2.2.0

Summary: Uptime Kuma is Missing Authorization Checks on Ping Badge Endpoint, Leaks Ping times of monitors without needing to be on a status page

Details:
## Summary

The `GET /api/badge/:id/ping/:duration?` endpoint in `server/routers/api-router.js` does not verify that the requested monitor belongs to a public group. All other badge endpoints check `AND public = 1` in their SQL query before returning data. The ping endpoint skips this check entirely, allowing unauthenticated users to extract average ping/response time data for private monitors.

## Affected Code

File: `server/routers/api-router.js`, approximately line 304

The ping badge endpoint directly calls `UptimeCalculator.getUptimeCalculator(requestedMonitorId)` without first checking if the monitor is public. Compare with the status badge endpoint (~line 148) which correctly queries:
```sql
SELECT monitor_group.monitor_id FROM monitor_group, `group`
WHERE monitor_group.group_id = `group`.id
AND monitor_group.monitor_id = ?
AND public = 1
```

## Protected vs Vulnerable Endpoints

| Endpoint | Has public=1 check? |
|----------|-------------------|
| /api/badge/:id/status | Yes |
| /api/badge/:id/uptime/:duration? | Yes |
| /api/badge/:id/avg-response/:duration? | Yes |
| /api/badge/:id/cert-exp | Yes |
| /api/badge/:id/response | Yes |
| /api/badge/:id/ping/:duration? | **No — vulnerable** |

## PoC

1. Install Uptime Kuma (tested on latest v2 stable via Docker)
2. Create an HTTP(s) monitor (e.g., monitoring http://localhost:3001)
3. Do NOT add the monitor to any public status page or group
4. Wait for heartbeats to accumulate (~5 minutes)
5. Query unauthenticated:
```bash
curl http://localhost:3001/api/badge/1/status   → returns N/A (correct, monitor is private)
curl http://localhost:3001/api/badge/1/ping/24  → returns "Avg. Ping (24h): 10ms" (LEAKED)
```

## Impact

An unauthenticated attacker can:
- Enumerate private monitor IDs
- Extract average response time data for private monitors
- Infer existence and reachability of internal monitored services

## Suggested Fix

Add the same public monitor check before the UptimeCalculator call:
```javascript
let publicMonitor = await R.getRow(`
    SELECT monitor_group.monitor_id FROM monitor_group, \`group\`
    WHERE monitor_group.group_id = \`group\`.id
    AND monitor_group.monitor_id = ?
    AND public = 1
`, [requestedMonitorId]);

if (!publicMonitor) {
    badgeValues.message = "N/A";
    badgeValues.color = badgeConstants.naColor;
}
```

<img width="1228" height="710" alt="Screenshot 2026-02-24 at 4 49 40 PM" src="https://github.com/user-attachments/assets/80aeae2d-be08-449f-8b39-c50da7aaedba" />

<img width="1271" height="770" alt="File Alons til View He" src="https://github.com/user-attachments/assets/d50c9a00-282a-4b79-b5e1-f77afde9223a" />
GitHub Security Advisory: GHSA-8j2w-6fmm-m587
Package: openclaw (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: <= 2026.2.25
Patched in: 2026.2.26

Summary: OpenClaw: /api/channels gateway-auth boundary bypass via path canonicalization mismatch

Details:
### Summary
Gateway auth for plugin channel endpoints can be bypassed when path canonicalization differs between the gateway guard and plugin handler routing.

### Details
On affected versions, `server-http` only applies gateway auth when raw `requestPath` matches exactly:
- `/api/channels`
- `/api/channels/*`

If a plugin handler canonicalizes path input (for example `decodeURIComponent(pathname).toLowerCase()`), requests like:
- `/API/channels/nostr/default/profile`
- `/api/channels%2Fnostr%2Fdefault%2Fprofile`
can be interpreted as `/api/channels/*` by the plugin, while the gateway auth guard is skipped.

### Impact
Authentication boundary bypass for plugin channel HTTP routes under canonicalization mismatch conditions. Unauthorized callers may access plugin channel APIs that are expected to require gateway auth.

CWE: CWE-288 (Authentication Bypass Using an Alternate Path or Channel)
CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N` (Base 5.3, Moderate)
GitHub Security Advisory: GHSA-v8cg-4474-49v8
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.2.25
Patched in: 2026.2.26

Summary: OpenClaw: Slack system events bypass sender authorization in member and message subtype handlers

Details:
### Summary
Slack `member_*` and `message` subtype system events (`message_changed`, `message_deleted`, `thread_broadcast`) were not consistently enforcing sender authorization before enqueueing system events.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published version: `2026.2.25`
- Affected range: `<= 2026.2.25`
- Planned patched version: `2026.2.26` (pre-set for publish-readiness)

### Technical Details
Slack system-event handlers in `src/slack/monitor/events/members.ts` and `src/slack/monitor/events/messages.ts` enqueued events after channel checks without shared sender authorization. Deployments relying on Slack DM allowlists (`dmPolicy` / `allowFrom`) or per-channel `users` allowlists could receive unauthorized system-event ingress from non-allowlisted senders.

The fix routes those handlers through `authorizeAndResolveSlackSystemEventContext(...)` and fails closed when message subtype sender identity cannot be resolved.

### Fix Commit(s)
- `3d30ba18a2aba1e1b302e77ff33145c3b06c01c8`

### Release Process Note
`patched_versions` is pre-set to `>= 2026.2.26` so once npm `2026.2.26` is published, this advisory can be published without further field edits.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-qcc4-p59m-p54m
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.0)
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.2.25
Patched in: 2026.2.26

Summary: OpenClaw: Sandbox dangling-symlink alias handling could bypass workspace-only write boundary

Details:
### Summary
A sandbox boundary-validation gap in symlink alias handling allowed certain workspace-only write paths to be treated as in-boundary even when they could resolve outside the workspace/sandbox root.

### Affected Packages / Versions
- Package: npm `openclaw`
- Affected versions: `<= 2026.2.25`
- Latest published npm version included in affected range: `2026.2.25` (checked on February 26, 2026)
- Patched version (pre-set for release): `2026.2.26`

### Technical Details
In affected versions, dangling symlink hops could be accepted during boundary checks under missing-target conditions. For workspace-only write flows (including `apply_patch`), this could allow writes to resolve outside the configured workspace/sandbox boundary.

The fix resolves symlink targets through existing ancestors and fails closed when canonical resolution escapes the configured boundary.

### Impact
- Boundary-confined write operations could be redirected outside the configured workspace/sandbox root.
- Primary impact is integrity of host-side files reachable from that path resolution.

### Fix Commit(s)
- `4fd29a35bb85a1898ebff518364c467058b50e14`

### Release Process Note
`patched_versions` is pre-set to the planned next release (`2026.2.26`) so once npm `2026.2.26` is published, the advisory can be published without further field edits.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-mgrq-9f93-wpp5
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: <= 2026.2.25
Patched in: 2026.2.26

Summary: OpenClaw: workspace path guard bypass on non-existent out-of-root symlink leaf

Details:
### Summary
`openclaw` had a workspace boundary bypass in workspace-only path validation: when an in-workspace symlink pointed outside the workspace to a non-existent leaf, the first write could pass validation and create the file outside the workspace.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Vulnerable versions: `<= 2026.2.25`
- Patched versions: `>= 2026.2.26` (pre-set for next planned release)
- Latest published npm version at update time: `2026.2.25`

### Details
The boundary check path resolved aliases in a way that allowed a non-existent out-of-root symlink target to pass the initial validation window. A first write through the guarded workspace path could therefore escape the workspace boundary.

The fix hardens canonical boundary resolution so missing-leaf alias paths are evaluated against canonical containment, while preserving valid in-root aliases. This closes the first-write escape condition without regressing valid in-root alias usage.

### Fix Commit(s)
- `46eba86b45e9db05b7b792e914c4fe0de1b40a23`
- `1aef45bc060b28a0af45a67dc66acd36aef763c9`

### Release Process Note
`patched_versions` is pre-set to the planned next release (`2026.2.26`). Once npm release `2026.2.26` is published, this advisory can be published directly.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-gp3q-wpq4-5c5h
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.2.25
Patched in: 2026.2.26

Summary: OpenClaw: LINE group allowlist scope mismatch with DM pairing-store entries

Details:
### Summary
In specific LINE configurations, sender IDs approved through DM pairing could also satisfy group allowlist checks when operators expected group sender access to be scoped only to explicit group allowlists.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published version at triage/update time: `2026.2.25`
- Affected: `<= 2026.2.25`
- Patched: `>= 2026.2.26` (planned next release)

### Impact
This is a group-authorization scope mismatch. DM pairing-store entries could influence group sender authorization in allowlist mode.

### Technical Details
Root cause: group allowlist composition inherited pairing-store entries intended for DM approvals. Under default DM pairing policy, a DM-paired sender could match group allowlist checks.

Fixes on `main`:
- isolate group allowlist composition from pairing-store entries
- centralize shared DM/group allowlist composition to preserve DM-only pairing behavior
- add regression coverage for LINE and Mattermost policy paths

### Fix Commit(s)
- `8bdda7a651c21e98faccdbbd73081e79cffe8be0`
- `892a9c24b0f6118729ab5b5f5499b1a7e792dd15` (follow-up refactor hardening)

### Release Process Note
`patched_versions` is pre-set to `>= 2026.2.26` so once npm `2026.2.26` is published, this advisory can be published directly without additional version-field edits.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-g7cr-9h7q-4qxq
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-289: Authentication Bypass by Alternate Name
Vulnerable versions: <= 2026.3.7
Patched in: 2026.3.8

Summary: OpenClaw's MS Teams sender allowlist bypass when route allowlist is configured and sender allowlist is empty

Details:
OpenClaw's Microsoft Teams plugin widened group sender authorization when a team/channel route allowlist was configured but `groupAllowFrom` was empty. Before the fix, a matching route allowlist entry could cause the message handler to synthesize wildcard sender authorization for that route, allowing any sender in the matched team/channel to bypass the intended `groupPolicy: "allowlist"` sender check.

This does not affect default unauthenticated access, but it does weaken a documented Teams group authorization boundary and can allow unauthorized group senders to trigger replies in allowlisted Teams routes.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.7`
- Affected range: `<= 2026.3.7`
- Fixed in released version: `2026.3.8`

## Fix Commit(s)

- `88aee9161e0e6d32e810a25711e32a808a1777b2`

## Release Verification

- Verified fixed in GitHub release `v2026.3.8` published on March 9, 2026.
- Verified `npm view openclaw version` resolves to `2026.3.8`.
- Verified the release contains the regression test covering the Teams route-allowlist sender-bypass case and that the test passes against the `v2026.3.8` tree.

Thanks @zpbrent for reporting.
GitHub Security Advisory: GHSA-vhwf-4x96-vqx2
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: <= 2026.3.7
Patched in: 2026.3.8

Summary: OpenClaw's skills-install-download can be redirected outside the tools root by rebinding the validated base path

Details:
OpenClaw's skills download installer validated the intended per-skill tools root lexically, but later reused that mutable path while downloading and copying the archive into place. If a local attacker could rebind that tools-root path between validation and the final write, the installer could be redirected to write outside the intended tools directory.

The fix pins the canonical per-skill tools root immediately after validation and derives later download/copy paths from that canonical root, so rebinding the lexical path fails closed instead of redirecting the write.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Latest published vulnerable version: `2026.3.7`
- Affected range: `<= 2026.3.7`
- Fixed in released version: `2026.3.8`

## Fix Commit(s)

- `9abf014f3502009faf9c73df5ca2cff719e54639`

## Release Verification

- Verified fixed in GitHub release `v2026.3.8` published on March 9, 2026.
- Verified `npm view openclaw version` resolves to `2026.3.8`.
- Verified the release contains the regression test covering tools-root rebinding and that the test passes against the `v2026.3.8` tree.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-8g75-q649-6pv6
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-285: Improper Authorization, CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: <= 2026.3.7
Patched in: 2026.3.8

Summary: OpenClaw's system.run approvals did not bind mutable script operands across approval and execution

Details:
OpenClaw's `system.run` approval flow did not bind mutable interpreter-style script operands across approval and execution.

A caller could obtain approval for an execution such as `sh ./script.sh`, rewrite the approved script before execution, and then execute different content under the previously approved command shape. The approved `argv` values remained the same, but the mutable script operand content could drift after approval.

Latest published npm version verified vulnerable: `2026.3.7`

The initial March 7, 2026 fix in `c76d29208bf6a7f058d2cf582519d28069e42240` added approval binding for shell scripts and a narrow interpreter set, but follow-up maintainer review on March 8, 2026 found that `bun` and `deno` script operands still did not produce `mutableFileOperand` snapshots.

A complete fix shipped on March 9, 2026 in `cf3a479bd1204f62eef7dd82b4aa328749ae6c91`, which binds approved `bun` and `deno run` script operands to on-disk file snapshots and denies post-approval script drift before execution.

## Affected Packages / Versions

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

## Fix Commit(s)

- `c76d29208bf6a7f058d2cf582519d28069e42240`
- `cf3a479bd1204f62eef7dd82b4aa328749ae6c91`

## Release Verification

- npm `2026.3.7` remains vulnerable.
- npm `2026.3.8` contains the completed fix.

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-j7mm-f4rv-6q6q
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 8.6.35
Patched in: 8.6.35

Summary: Parse Server has a protected fields bypass via LiveQuery subscription WHERE clause

Details:
### Impact

An attacker can exploit LiveQuery subscriptions to infer the values of protected fields without directly receiving them. By subscribing with a WHERE clause that references a protected field (including via dot-notation or `$regex`), the attacker can observe whether LiveQuery events are delivered for matching objects. This creates a boolean oracle that leaks protected field values. The attack affects any class that has both `protectedFields` configured in Class-Level Permissions and LiveQuery enabled.

### Patches

The fix adds validation of the LiveQuery subscription WHERE clause against the class's protected fields, mirroring the existing REST API validation. If a subscription's WHERE clause references a protected field directly, via dot-notation, or inside `$or` / `$and` / `$nor` operators, the subscription is rejected with a permission error. This is applied during subscription creation, so existing event delivery paths are not affected.

### Workarounds

Disable LiveQuery for classes that use `protectedFields` in their Class-Level Permissions, or remove `protectedFields` from classes that require LiveQuery.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-j7mm-f4rv-6q6q
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.35