deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5fw2-mwhh-9947
Package: flowise (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Unauthenticated TTS endpoint accepts arbitrary credential IDs — enables API credit abuse via stored credentials

Details:
### Summary

The text-to-speech generation endpoint (`POST /api/v1/text-to-speech/generate`) is whitelisted (no auth) and accepts a `credentialId` directly in the request body. When called without a `chatflowId`, the endpoint uses the provided `credentialId` to decrypt the stored credential (e.g., OpenAI or ElevenLabs API key) and generate speech.

### Root Cause

```typescript
// packages/server/src/controllers/text-to-speech/index.ts:58-64
} else {
    // Use TTS config from request body
    provider = bodyProvider
    credentialId = bodyCredentialId  // ← attacker-controlled credential ID
    voice = bodyVoice
    model = bodyModel
}
```

### Docker Validation

`POST /api/v1/text-to-speech/generate` with arbitrary `credentialId` in body: endpoint processes request, sends SSE `tts_start` event, only fails when credential doesn't exist — proves code path runs without authentication.

### Impact

- Use victim's API keys (OpenAI, ElevenLabs, Azure, Google) without authorization
- Burn API credits on the victim's account
- Generate unlimited speech content at victim's expense
- Combined with credential ID leak from Finding 2, this is trivially exploitable

### Suggested Fix

Remove the TTS endpoint from `WHITELIST_URLS` or validate that the credential belongs to the chatflow being used:

```typescript
// Only allow credentialId when it matches the chatflow's TTS configuration
if (!chatflowId) {
    return res.status(401).json({ message: 'Authentication required' })
}
```

---

## References

- `packages/server/src/controllers/text-to-speech/index.ts` lines 10-162
- `packages/server/src/utils/constants.ts` line 41 (whitelist entry)

## Credits
- Shinobi Security - https://github.com/shinobisecurity
GitHub Security Advisory: GHSA-w47f-j8rh-wx87
Package: flowise (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Public chatflow endpoints return unsanitized flowData including plaintext API keys, passwords, and credential IDs

Details:
### Summary

The `GET /api/v1/public-chatflows/:id` endpoint returns the full chatflow object **without sanitization** for public chatflows. Docker validation revealed this is worse than initially assessed: the `sanitizeFlowDataForPublicEndpoint` function does NOT exist in the released v3.0.13 Docker image. Both `public-chatflows` AND `public-chatbotConfig` return completely raw flowData including credential IDs, plaintext API keys, and password-type fields.

### Root Cause

```typescript
// packages/server/src/controllers/chatflows/index.ts:218-220
const chatflow = await chatflowsService.getChatflowById(req.params.id)
if (!chatflow) return res.status(StatusCodes.NOT_FOUND).json(...)
if (chatflow.isPublic) return res.status(StatusCodes.OK).json(chatflow) // ← NO sanitization!
```

### Docker Validation (v3.0.13)

Created public chatflow with credential IDs and passwords in flowData:
```json
{
  "flowData": "{\"nodes\":[{\"data\":{\"credential\":\"e92a39bf-...\",\"inputs\":{\"password\":\"sk-supersecretkey123\",\"apiKey\":\"should-not-leak\"}}}]}"
}
```

The `sanitizeFlowDataForPublicEndpoint` function only exists in unreleased HEAD, and even there, only `public-chatbotConfig` calls it — `public-chatflows` never does.

### Impact

- **Credential IDs** leaked — enables OAuth2 token theft chain (Finding 1)
- **Plaintext API keys and passwords** leaked — direct third-party account compromise
- **Node configurations** leaked — reveals internal architecture and endpoint URLs
- Both `public-chatflows` and `public-chatbotConfig` are affected in the released version

### Suggested Fix

Apply sanitization to both public endpoints:

```typescript
const sanitized = sanitizeFlowDataForPublicEndpoint(chatflow)
return res.status(StatusCodes.OK).json(sanitized)
```

Ensure the sanitization function strips all `credential`, `password`, `apiKey`, and `secretKey` fields from `flowData`.

---

## References

- `packages/server/src/controllers/chatflows/index.ts` lines 209-236
- `packages/server/src/utils/sanitizeFlowData.ts` lines 11-34 (exists only in unreleased HEAD)

## Credits
- Shinobi Security - https://github.com/shinobisecurity
GitHub Security Advisory: GHSA-92jp-89mq-4374
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 2026.2.21, < 2026.4.10
Patched in: 2026.4.10

Summary: OpenClaw: Sandbox noVNC helper route exposed interactive browser session credentials

Details:
## Summary

Sandbox noVNC helper route exposed interactive browser session credentials.

## Affected Packages / Versions

- Package: `openclaw`
- Ecosystem: npm
- Affected versions: `>= 2026.2.21 < 2026.4.10`
- Patched versions: `>= 2026.4.10`

## Impact

The sandbox noVNC helper route could be reached without the intended bridge authentication, exposing an interactive browser session surface.

## Technical Details

The fix gates the sandbox noVNC helper route behind bridge authentication.

## Fix

The issue was fixed in #63882. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.

## Fix Commit(s)

- `8dfbf3268bd224b7377d1ecca77a[PII_REDACTED]85`
- PR: #63882

## Release Process Note

Users should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.

## Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.
GitHub Security Advisory: GHSA-f3g8-9xv5-77gv
Package: @saltcorn/server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 1.4.6
Patched in: 1.4.6

Summary: Saltcorn: Open Redirect in `POST /auth/login` due to incomplete `is_relative_url` validation (backslash bypass)

Details:
### Summary
Saltcorn validates the post-login `dest` parameter with a string check that only blocks `:/` and `//`. Because all WHATWG-compliant browsers normalise backslashes (`\`) to forward slashes (`/`) for special schemes, a payload such as `/\evil.com/path` slips through `is_relative_url()`, is emitted unchanged in the HTTP `Location` header, and causes the browser to navigate cross-origin to an attacker-controlled domain. The bug is reachable on a default install and only requires a victim who can be tricked into logging in via a crafted Saltcorn URL.

### Details
Vulnerable function: `packages/server/routes/utils.js:393-395`

```js
const is_relative_url = (url) => {
  return typeof url === "string" && !url.includes(":/") && !url.includes("//");
};
```

The function's intent is to allow only same-origin redirects, but the allow-list only checks for two literal substrings. It does not handle:
- backslash characters, which WHATWG URL parsing (used by every modern browser) treats as forward slashes for the special schemes `http`, `https`, `ftp`, `ws`, `wss`. A URL parser fed `/\evil.com/path` with a base of `http://victim/` resolves to `http://evil.com/path`.
- non-`http(s):` schemes that do not contain `:/`. The strings `javascript:alert(1)`, `data:text/html,...`, `vbscript:...` all pass.

Vulnerable callsite: `packages/server/auth/routes.js:1371-1376`

```js
} else if (
  (req.body || {}).dest &&
  is_relative_url(decodeURIComponent((req.body || {}).dest))
) {
  res.redirect(decodeURIComponent((req.body || {}).dest));
} else res.redirect("/");
```

The body's `dest` is URL-decoded twice (once by body-parser, once by the explicit `decodeURIComponent`) and the same value is passed to `res.redirect`. Express 5's `res.redirect` runs the value through `encodeurl@2.0.0`, whose whitelist character class `[^\x21\x23-\x3B\x3D\x3F-\x5F\x61-\x7A\x7C\x7E]` includes `\x5C` (backslash). The backslash is therefore not percent-encoded and ends up verbatim in the `Location` response header.

### PoC
[poc.zip](https://github.com/user-attachments/files/26678853/poc.zip)

Please extract the uploaded compressed file before proceeding
1. ./setup.sh
2. ./poc.sh

<img width="419" height="71" alt="스크린샷 2026-04-13 오후 11 44 36" src="https://github.com/user-attachments/assets/9c919ed4-167b-47e3-9873-733f97b44bf0" />

### Impact
Any user who can be lured into clicking a Saltcorn login URL crafted by the attacker will, after submitting their valid credentials, be redirected to an attacker-controlled origin. The redirect happens under the trusted Saltcorn domain, so the user has no visual cue that they are about to leave the site. Realistic abuse patterns:

- Credential phishing — the attacker's site renders a forged "session expired, please log in again" prompt to capture the password the user just typed.
GitHub Security Advisory: GHSA-xrxf-jgv3-qmrm
Package: @openai/codex (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 0.23.0
Patched in: unpatched

Summary: OpenAI Codex CLI enables code execution through malicious MCP (Model Context Protocol) configuration files

Details:
A vulnerability was identified in OpenAI Codex CLI v0.23.0 and before that enables code execution through malicious MCP (Model Context Protocol) configuration files. The attack is triggered when a user runs the codex command inside a malicious or compromised repository. Codex automatically loads project-local .env and .codex/config.toml files without requiring user confirmation, allowing attackers to embed arbitrary commands that execute immediately.
GitHub Security Advisory: GHSA-xr8f-h2gw-9xh6
Package: @better-auth/oauth-provider (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.7.0-beta.0, <= 1.7.0-beta.1
Patched in: unpatched

Summary: OAuth 2.1 Provider: Unprivileged users can register OAuth clients

Details:
### Am I affected?

  You're affected if all of the following are true:

  - Using @better-auth/oauth-provider at version specified below 
  - You configured clientPrivileges in the plugin options expecting it to gate who can create OAuth clients
  - The /oauth2/create-client or /admin/oauth2/create-client endpoints are reachable by authenticated users you don't fully trust

  If clientPrivileges is not configured, this bug has no security consequence for your deployment

  ---
  ### Summary

  The clientPrivileges option documents a create action, but the OAuth client creation endpoints did not invoke the hook before persisting new clients. Deployments that configured clientPrivileges to restrict client registration were not actually restricted — any authenticated user could reach the create endpoints and register an OAuth client with attacker-chosen redirect URIs and metadata.

 Non-create operations (read, list, update, delete, rotate) enforced the hook correctly. Only the create path was missing the check.

### Impact

  - Unauthorized registration of OAuth clients by any authenticated user, under deployments that expected clientPrivileges to block them.
  - Attacker-controlled redirect_uris on those clients enable phishing flows that present as registered first-party applications.
  - If the SERVER_ONLY admin creation endpoint is also exposed to low-privilege users (a separate deployment misconfiguration), additional sensitive fields including `skip_consent` become writable.

### Patches

Fixed in `@better-auth/oauth-provider@1.6.5` Both create endpoints now call the clientPrivileges hook with action "create" before persisting the client record.

### Workarounds

  If you cannot upgrade immediately:

  - Block the /oauth2/create-client and /admin/oauth2/create-client routes at your reverse proxy or middleware layer for any user who should not be able to register clients.
  - Do not expose the admin creation endpoint (it is SERVER_ONLY by design and should not be reachable by end-user sessions).
GitHub Security Advisory: GHSA-xr8f-h2gw-9xh6
Package: @better-auth/oauth-provider (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.4.8-beta.7, < 1.6.5
Patched in: 1.6.5

Summary: OAuth 2.1 Provider: Unprivileged users can register OAuth clients

Details:
### Am I affected?

  You're affected if all of the following are true:

  - Using @better-auth/oauth-provider at version specified below 
  - You configured clientPrivileges in the plugin options expecting it to gate who can create OAuth clients
  - The /oauth2/create-client or /admin/oauth2/create-client endpoints are reachable by authenticated users you don't fully trust

  If clientPrivileges is not configured, this bug has no security consequence for your deployment

  ---
  ### Summary

  The clientPrivileges option documents a create action, but the OAuth client creation endpoints did not invoke the hook before persisting new clients. Deployments that configured clientPrivileges to restrict client registration were not actually restricted — any authenticated user could reach the create endpoints and register an OAuth client with attacker-chosen redirect URIs and metadata.

 Non-create operations (read, list, update, delete, rotate) enforced the hook correctly. Only the create path was missing the check.

### Impact

  - Unauthorized registration of OAuth clients by any authenticated user, under deployments that expected clientPrivileges to block them.
  - Attacker-controlled redirect_uris on those clients enable phishing flows that present as registered first-party applications.
  - If the SERVER_ONLY admin creation endpoint is also exposed to low-privilege users (a separate deployment misconfiguration), additional sensitive fields including `skip_consent` become writable.

### Patches

Fixed in `@better-auth/oauth-provider@1.6.5` Both create endpoints now call the clientPrivileges hook with action "create" before persisting the client record.

### Workarounds

  If you cannot upgrade immediately:

  - Block the /oauth2/create-client and /admin/oauth2/create-client routes at your reverse proxy or middleware layer for any user who should not be able to register clients.
  - Do not expose the admin creation endpoint (it is SERVER_ONLY by design and should not be reachable by end-user sessions).
GitHub Security Advisory: GHSA-29qv-4j9f-fjw5
Package: mathjs (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: >= 13.1.1, < 15.2.0
Patched in: 15.2.0

Summary: Unsafe object property setter in mathjs

Details:
### Impact
This security vulnerability allowed executing arbitrary JavaScript via the expression parser of mathjs. You can be affected when you have an application where users can evaluate arbitrary expressions using the mathjs expression parser.

### Patches
The issue was introduced in mathjs `v13.1.1`, and patched in mathjs `v15.2.0`.

### Workarounds
There is no workaround without upgrading to `v15.2.0`.

### References
You can find out more via the commit fixing this issue: https://github.com/josdejong/mathjs/commit/513ab2a0e01004af91b31aada68fae8a821326ad (part of PR https://github.com/josdejong/mathjs/pull/3656).
GitHub Security Advisory: GHSA-45q2-gjvg-7973
Package: @angular/platform-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 18.2.14
Patched in: unpatched

Summary: Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

Details:
### Impact

A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)

**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)

### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method  (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs. 


### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21

### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

```js
app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

```
### References
- [Fix](https://github.com/angular/angular/pull/68194)
GitHub Security Advisory: GHSA-45q2-gjvg-7973
Package: @angular/platform-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 19.0.0-next.0, < 19.2.21
Patched in: 19.2.21

Summary: Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

Details:
### Impact

A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)

**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)

### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method  (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs. 


### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21

### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

```js
app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

```
### References
- [Fix](https://github.com/angular/angular/pull/68194)
GitHub Security Advisory: GHSA-45q2-gjvg-7973
Package: @angular/platform-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 20.0.0-next.0, < 20.3.19
Patched in: 20.3.19

Summary: Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

Details:
### Impact

A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)

**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)

### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method  (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs. 


### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21

### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

```js
app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

```
### References
- [Fix](https://github.com/angular/angular/pull/68194)