deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-jcc7-9wpm-mj36
Package: next (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-1385: Missing Origin Validation in WebSockets
Vulnerable versions: >= 16.0.1, < 16.1.7
Patched in: 16.1.7

Summary: Next.js: null origin can bypass dev HMR websocket CSRF checks

Details:
## Summary
In `next dev`, cross-site protections for internal development endpoints could treat `Origin: null` as a bypass case even when [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins) is configured. This could allow privacy-sensitive or opaque browser contexts, such as sandboxed documents, to access privileged internal dev-server functionality unexpectedly.

## Impact
If a developer visits attacker-controlled content while running an affected `next dev` server with [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins) configured, attacker-controlled browser code may be able to connect to internal development endpoints and interact with sensitive dev-server functionality that should have remained blocked.

This issue affects development mode only. It does not affect `next start`, and it does not expose internal debugging functionality to the network by default.

## Patches
Fixed by validating `Origin: null` through the same cross-site origin-allowance checks used for other origins on internal development endpoints.

## Workarounds
If upgrade is not immediately possible:
- Do not expose `next dev` to untrusted networks.
- If you use [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins), reject requests and websocket upgrades with `Origin: null` for internal dev endpoints at your proxy.
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/compiler (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 17.0.0-next.0, <= 18.2.14
Patched in: unpatched

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/compiler (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 19.0.0-next.0, < 19.2.20
Patched in: 19.2.20

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/core (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 17.0.0-next.0, <= 18.2.14
Patched in: unpatched

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/core (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 19.0.0-next.0, < 19.2.20
Patched in: 19.2.20

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-3w3w-pxmm-2w2j
Package: crypto-js (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-330: Use of Insufficiently Random Values, CWE-331: Insufficient Entropy
Vulnerable versions: = 3.2.0
Patched in: 3.2.1

Summary: crypto-js uses insecure random numbers

Details:
The crypto-js package 3.2.0 for Node.js generates random numbers by concatenating the string "0." with an integer, which makes the output more predictable than necessary.
GitHub Security Advisory: GHSA-vr7j-g7jv-h5mp
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-276: Incorrect Default Permissions, CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: <= 2026.2.15
Patched in: 2026.2.17

Summary: OpenClaw session transcript files were created without forced user-only permissions

Details:
`openclaw` created new session transcript JSONL files with overly broad default permissions in affected releases. On multi-user hosts, other local users or processes could read transcript contents, including secrets that might appear in tool output.

## Affected Packages / Versions

- Package: `openclaw` (`npm`)
- Affected versions: `<= 2026.2.15`
- First fixed version: `2026.2.17`
- Current latest npm release checked during verification: `2026.3.13` (not affected)

## Impact

Session transcript JSONL files are created under the local OpenClaw session store. In affected releases, newly created transcript files did not force user-only permissions, so transcript contents could be readable by other local users depending on the host environment and umask behavior.

## Fix

New transcript files are now created with `0o600` permissions. Existing transcript permission drift is also remediated by the security audit fix flow.

Verified in code:

- `src/config/sessions/transcript.ts:82` writes new transcript files with `mode: 0o600`
- `src/config/sessions/sessions.test.ts:303` includes regression coverage asserting `0o600`

## Fix Commit(s)

- `095d[PII_REDACTED]67e1b76fa5bb09d4ddf7c8a57c`

## Release Note

This fix first shipped in `2026.2.17` and is present in the current npm release `2026.3.13`.
GitHub Security Advisory: GHSA-g2f6-pwvx-r275
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 2026.3.12
Patched in: 2026.3.13

Summary: OpneClaw accepts unsanitized iMessage attachment paths which allowed SCP remote-path command injection

Details:
### Summary
`openclaw` versions `<= 2026.3.12` accepted unsanitized iMessage remote attachment paths when staging files over SCP, allowing shell metacharacters in the remote path operand.

### Affected Packages / Versions
- Package: `openclaw` (`npm`)
- Affected versions: `<= 2026.3.12`
- Fixed version: `2026.3.13`

### Details
The vulnerable path was the remote attachment staging flow in `src/auto-reply/reply/stage-sandbox-media.ts`. When `ctx.MediaRemoteHost` was set, OpenClaw staged the attachment by spawning `/usr/bin/scp` against `<remoteHost>:<remotePath>`. In affected releases, the remote host was normalized but the remote attachment path was not validated for shell metacharacters before being passed to the SCP remote operand. A sender-controlled iMessage attachment filename containing shell metacharacters could therefore trigger command execution on the configured remote host when remote attachment staging was enabled.

This issue is in scope under OpenClaw's trust model because it crosses an inbound content boundary into host command execution on a configured remote attachment host.

### Fix
`openclaw@2026.3.13` validates the SCP remote path before spawning `scp`. Current code calls `normalizeScpRemotePath(...)` and rejects paths containing shell metacharacters instead of passing them through to the remote shell.

Regression coverage exists in `src/auto-reply/reply.stage-sandbox-media.scp-remote-path.test.ts` (`rejects remote attachment filenames with shell metacharacters before spawning scp`).

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

Thanks @lintsinghua for reporting.
GitHub Security Advisory: GHSA-jq3f-vjww-8rq7
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 2026.3.12
Patched in: 2026.3.13

Summary: OpenClaw Telegram webhook request bodies were read before secret validation, enabling unauthenticated resource exhaustion

Details:
### Summary
`openclaw` versions `<= 2026.3.12` read and buffered Telegram webhook request bodies before validating `x-telegram-bot-api-secret-token`. This let unauthenticated callers force up to the configured webhook body limit of pre-auth body I/O and JSON parse work per request.

### Affected Packages / Versions
- Package: `openclaw` (`npm`)
- Affected versions: `<= 2026.3.12`
- Fixed version: `2026.3.13`

### Details
The vulnerable path was the standalone Telegram webhook listener in `src/telegram/webhook.ts`. In affected releases, the request handler accepted `POST` requests, called `readJsonBodyWithLimit(...)`, and only then checked the Telegram secret header. Because the secret validation happened after body reading, an unauthenticated caller could make the server spend memory, socket time, and JSON parse work on requests that should have been rejected before any body processing.

This issue is in scope under OpenClaw's trust model because the Telegram webhook endpoint accepts untrusted network traffic and the secret header is the authentication boundary for that ingress path.

### Fix
`openclaw@2026.3.13` validates the Telegram webhook secret before any body I/O. Current code reads the header, rejects invalid requests immediately with `401`, and only calls `readJsonBodyWithLimit(...)` after `hasValidTelegramWebhookSecret(...)` succeeds.

Regression coverage exists in `src/telegram/webhook.test.ts` (`rejects unauthenticated requests before reading the request body`).

### Fix Commit(s)
- `7e49e98f79073b11134beac27fdff547ba5a4a02`

Thanks @space08 for reporting.
GitHub Security Advisory: GHSA-63f5-hhc7-cx6p
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 2026.3.12
Patched in: 2026.3.13

Summary: OpenClaw bootstrap setup codes could be replayed to escalate pending pairing scopes before approval

Details:
### Summary
`openclaw` versions `<= 2026.3.12` allowed bootstrap setup codes to be replayed before approval, which could widen the scopes on a pending device pairing request.

### Affected Packages / Versions
- Package: `openclaw` (`npm`)
- Affected versions: `<= 2026.3.12`
- Fixed version: `2026.3.13`

### Details
The vulnerable path was bootstrap token verification in `src/infra/device-bootstrap.ts`. In affected releases, a valid bootstrap setup code could be verified more than once before the pairing request was approved. That allowed a second verification attempt to mutate a pending device pairing and request broader scopes, including escalation from a lower operator scope to `operator.admin`, before an approver finalized the pairing.

This issue is in scope under OpenClaw's trust model because bootstrap setup codes are an authentication primitive for device pairing and the replay changed the privileges granted to the pending device.

### Fix
`openclaw@2026.3.13` makes bootstrap setup codes single-use. Current code consumes the bootstrap token record on the first successful verification, so replay attempts fail before pending scopes can be widened.

Regression coverage exists in `src/infra/device-pairing.test.ts` (`rejects bootstrap token replay before pending scope escalation can be approved`).

### Fix Commit(s)
- `1803d16d5cec970c54b0e1ac46b31b1cbade335c`

Thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-xwcj-hwhf-h378
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 2026.3.12
Patched in: 2026.3.13

Summary: OpenClaw Telegram media fetch errors exposed bot tokens in logged file URLs

Details:
### Summary
`openclaw` versions `<= 2026.3.12` could include raw Telegram bot tokens in media fetch error strings when inbound Telegram media downloads failed.

### Affected Packages / Versions
- Package: `openclaw` (`npm`)
- Affected versions: `<= 2026.3.12`
- Fixed version: `2026.3.13`

### Details
The vulnerable path was `fetchRemoteMedia()` in `src/media/fetch.ts`. In affected releases, fetch and HTTP error paths embedded the original Telegram file URL into `MediaFetchError` messages. For Telegram media, those URLs can include `/file/bot<TOKEN>/...`, so the resulting error strings could leak bot tokens into logs, console output, or any downstream error surface that rendered the exception text.

This issue is in scope under OpenClaw's trust model because the leaked secret is an OpenClaw-operated integration credential, not a user-supplied third-party secret.

### Fix
`openclaw@2026.3.13` redacts sensitive media URLs before constructing fetch error messages. Current code routes the source URL and follow-on error paths through `redactMediaUrl()` / `redactSensitiveText()`, so Telegram bot tokens are no longer emitted in those error strings.

Regression coverage exists in `src/media/fetch.test.ts` (`redacts Telegram bot tokens from fetch failure messages` and `redacts Telegram bot tokens from HTTP error messages`).

### Fix Commit(s)
- `7a53eb7ea8295b08be137e231c9a98c1a79b5cd5`

Thanks @space08 for reporting.