deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-353c-v8x9-v7c3
Package: mcp-framework (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.2.21
Patched in: 0.2.22

Summary: MCP-Framework: Unbounded memory allocation in readRequestBody allows denial of service via HTTP transport

Details:
### Summary

The `readRequestBody()` function in `src/transports/http/server.ts` concatenates HTTP request body chunks into a string with no size limit, allowing a remote unauthenticated attacker to crash the server via memory exhaustion with a single large HTTP POST request.

### Details

**File:** `src/transports/http/server.ts`, lines 224-240

```typescript
private async readRequestBody(req: IncomingMessage): Promise<any> {
    return new Promise((resolve, reject) => {
      let body = '';
      req.on('data', (chunk) => {
        body += chunk.toString();   // No size limit
      });
      req.on('end', () => {
        try {
          const parsed = body ? JSON.parse(body) : null;
          resolve(parsed);
        } catch (error) {
          reject(error);
        }
      });
      req.on('error', reject);
    });
  }
```

A `maxMessageSize` configuration value exists in `DEFAULT_HTTP_STREAM_CONFIG` (4MB, defined in `src/transports/http/types.ts` line 124) but is never enforced in `readRequestBody()`. This creates a false sense of security.

### PoC

Local testing with 50MB POST payloads against the vulnerable `readRequestBody()` function:

| Trial | Payload | RSS growth | Time | Result |
|-------|---------|-----------|------|--------|
| 1 | 50MB | +197MB | 42ms | Vulnerable |
| 2 | 50MB | +183MB | 46ms | Vulnerable |
| 3 | 50MB | +15MB | 43ms | Vulnerable |
| 4 | 50MB | +14MB | 32ms | Vulnerable |
| 5 | 50MB | +65MB | 38ms | Vulnerable |

Reproducibility: 5/5 (100%)

### Impact

- **Denial of Service:** Any mcp-framework HTTP server can be crashed by a single large POST request to /mcp
- **No authentication required:** readRequestBody() executes before any auth checks (auth is opt-in, default is no auth)
- **Dead config:** maxMessageSize exists but is never enforced, giving a false sense of security
- **Affected:** All applications using mcp-framework HttpStreamTransport (60,000 weekly npm downloads)

**CWE-770:** Allocation of Resources Without Limits or Throttling
**Suggested CVSS 3.1:** 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

### Suggested Fix

Enforce `maxMessageSize` in `readRequestBody()`:

```typescript
private async readRequestBody(req: IncomingMessage): Promise<any> {
    const maxSize = this._config.maxMessageSize || 4 * 1024 * 1024;
    return new Promise((resolve, reject) => {
      let body = '';
      let size = 0;
      req.on('data', (chunk) => {
        size += chunk.length;
        if (size > maxSize) {
          req.destroy();
          reject(new Error('Request body too large'));
          return;
        }
        body += chunk.toString();
      });
      // ...
    });
  }
```

### Disclosure Timeline

This report follows coordinated disclosure. I request a 90-day window before public disclosure.

**Reporter:** Raza Sharif, CyberSecAI Ltd (contact@agentsign.dev)
GitHub Security Advisory: GHSA-5vjq-5jmg-39xq
Package: renovate (NPM)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 43.65.0, < 43.102.11
Patched in: 43.102.11

Summary: Renovate affected by remote code execution was possible using the bazel-module or bazelisk managers, when using lockFileMaintenance

Details:
When using [`lockFileMaintenance`](https://docs.renovatebot.com/configuration-options/#lockfilemaintenance) using the [bazel-module](https://docs.renovatebot.com/modules/manager/bazel-module/) or [bazelisk](https://docs.renovatebot.com/modules/manager/bazelisk/) managers between Renovate [43.65.0](https://github.com/renovatebot/renovate/releases/tag/43.65.0) (2026-03-12) and [43.102.11](https://github.com/renovatebot/renovate/releases/tag/43.102.11) (2026-04-02), there was the opportunity for remote code execution from a malicious dependency, _if the Bazel module executes code that relies on a dependency_.

As this is an "unsafe" execution path, we have disabled this by default, and self-hosted administrators must add it to the [`allowedUnsafeExecutions`](https://docs.renovatebot.com/self-hosted-configuration/#allowedunsafeexecutions) allowlist.

It is recommended to review whether you have enabled this functionality for these managers, and if so, whether any dependency updates may have led to remote code execution.

## Impact

If Renovate suggested an update to a malicious dependency, _and_ that dependency is referenced as part of the `bazel mod deps` call - for instance as part of a `ctx.execute` call - this would call attacker-controlled code.

This could lead to [insider attackers](https://docs.renovatebot.com/security-and-permissions/#execution-of-code-insider-attack) and [outside attackers](https://docs.renovatebot.com/security-and-permissions/#execution-of-code-outsider-attack), executing code that is distributed as part of the package.
 
## Patches

This is patched in [43.102.11](https://github.com/renovatebot/renovate/releases/tag/43.102.11).

This does not affect any versions of [Mend Renovate Self-Hosted](https://www.mend.io/renovate/).

## Workarounds

- Upgrade your Renovate version
- Disable `lockFileMaintenance` for these managers

## Why did this happen?

This was missed in code review (as part of https://github.com/renovatebot/renovate/pull/41507).
GitHub Security Advisory: GHSA-rr7j-v2q5-chgv
Package: langsmith (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-359: Exposure of Private Personal Information to an Unauthorized Actor, CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 0.5.18
Patched in: 0.5.19

Summary: LangSmith SDK: Streaming token events bypass output redaction

Details:
## Summary

The LangSmith SDK's output redaction controls (hideOutputs in JS, hide_outputs in Python) do not apply to streaming token events. When an LLM run produces streaming output, each chunk is recorded as a new_token event containing the raw token value. These events bypass the redaction pipeline entirely — prepareRunCreateOrUpdateInputs (JS) and _hide_run_outputs (Python) only process the inputs and outputs fields on a run, never the events array. As a result, applications relying on output redaction to prevent sensitive LLM output from being stored in LangSmith will still leak the full streamed content via run events.

## Details

**Both JS and Python SDKs are affected.** The same pattern exists in both:

- **JS SDK**: `traceable.ts:997-1003` and `traceable.ts:1044-1050`
- **Python SDK**: `run_helpers.py:1924` and `run_helpers.py:1996`

In both SDKs, `new_token` events with raw `kwargs.token` values are added during streaming, and the redaction pipeline (`hideOutputs` in JS, `hide_outputs` in Python) only processes `inputs`/`outputs` — never `events`.
GitHub Security Advisory: GHSA-458j-xx4x-4375
Package: hono (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 4.12.14
Patched in: 4.12.14

Summary: hono Improperly Handles JSX Attribute Names Allows HTML Injection in hono/jsx SSR

Details:
## Summary

Improper handling of JSX attribute names in hono/jsx allows malformed attribute keys to corrupt the generated HTML output.

When untrusted input is used as attribute keys during server-side rendering, specially crafted keys can break out of attribute or tag boundaries and inject unintended HTML.

## Details

When rendering JSX elements to HTML strings, attribute values are escaped, but attribute names (keys) were previously inserted into the output without validation.

If an attribute name contains characters such as `"`, `>`, or whitespace, it can alter the structure of the generated HTML.

For example, malformed attribute names can:

* Break out of the current attribute and introduce unintended additional attributes
* Break out of the current HTML tag and inject new elements into the output

This issue arises when untrusted input (such as query parameters or form data) is used as JSX attribute keys during server-side rendering.

## Impact

An attacker who can control attribute keys used in JSX rendering may inject unintended attributes or HTML elements into the generated output.

This may lead to:

* Injection of unexpected HTML attributes
* Corruption of the HTML structure
* Potential cross-site scripting (XSS) if combined with unsafe usage patterns

This issue affects applications that pass untrusted input as JSX attribute keys during server-side rendering.
GitHub Security Advisory: GHSA-39q2-94rc-95cp
Package: dompurify (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-783: Operator Precedence Logic Error
Vulnerable versions: <= 3.3.3
Patched in: 3.4.0

Summary: DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

Details:
## Summary
In `src/purify.ts:1117-1123`, `ADD_TAGS` as a function (via `EXTRA_ELEMENT_HANDLING.tagCheck`) bypasses `FORBID_TAGS` due to short-circuit evaluation.

The condition:
```
!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])
```
When `tagCheck(tagName)` returns `true`, the entire condition is `false` and the element is kept — `FORBID_TAGS[tagName]` is never evaluated.

## Inconsistency
This contradicts the attribute-side pattern at line 1214 where `FORBID_ATTR` explicitly wins first:
```
if (FORBID_ATTR[lcName]) { continue; }
```
For tags, FORBID should also take precedence over ADD.

## Impact
Applications using both `ADD_TAGS` as a function and `FORBID_TAGS` simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

## Suggested Fix
Check `FORBID_TAGS` before `tagCheck`:
```
if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }
```

## Affected Version
v3.3.3 (commit 883ac15)
GitHub Security Advisory: GHSA-3p68-rc4w-qgx5
Package: axios (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.31.0
Patched in: 0.31.0

Summary: Axios has a NO_PROXY Hostname Normalization Bypass that Leads to SSRF

Details:
Axios does not correctly handle hostname normalization when checking `NO_PROXY` rules.
Requests to loopback addresses like `localhost.` (with a trailing dot) or `[::1]` (IPv6 literal) skip `NO_PROXY` matching and go through the configured proxy.

This goes against what developers expect and lets attackers force requests through a proxy, even if `NO_PROXY` is set up to protect loopback or internal services.

According to [RFC 1034 §3.1](https://datatracker.ietf.org/doc/html/rfc1034#section-3.1) and [RFC 3986 §3.2.2](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2), a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level, `localhost.` is the same as `localhost`. 
However, Axios does a literal string comparison instead of normalizing hostnames before checking `NO_PROXY`. This causes requests like `http://localhost.:8080/` and `http://[::1]:8080/` to be incorrectly proxied.

This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections.

---

**PoC**

```js
import http from "http";
import axios from "axios";

const proxyPort = 5300;

http.createServer((req, res) => {
  console.log("[PROXY] Got:", req.method, req.url, "Host:", req.headers.host);
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("proxied");
}).listen(proxyPort, () => console.log("Proxy", proxyPort));

process.env.HTTP_PROXY = `http://127.0.0.1:${proxyPort}`;
process.env.NO_PROXY = "localhost,127.0.0.1,::1";

async function test(url) {
  try {
    await axios.get(url, { timeout: 2000 });
  } catch {}
}

setTimeout(async () => {
  console.log("\n[*] Testing http://localhost.:8080/");
  await test("http://localhost.:8080/"); // goes through proxy

  console.log("\n[*] Testing http://[::1]:8080/");
  await test("http://[::1]:8080/"); // goes through proxy
}, 500);
```

**Expected:** Requests bypass the proxy (direct to loopback).
**Actual:** Proxy logs requests for `localhost.` and `[::1]`.

---

**Impact**

* Applications that rely on `NO_PROXY=localhost,127.0.0.1,::1` for protecting loopback/internal access are vulnerable.
* Attackers controlling request URLs can:

  * Force Axios to send local traffic through an attacker-controlled proxy.
  * Bypass SSRF mitigations relying on NO\_PROXY rules.
  * Potentially exfiltrate sensitive responses from internal services via the proxy.
  
  
---

**Affected Versions**

* Confirmed on Axios **1.12.2** (latest at time of testing).
* affects all versions that rely on Axios’ current `NO_PROXY` evaluation.

---

**Remediation**
Axios should normalize hostnames before evaluating `NO_PROXY`, including:

* Strip trailing dots from hostnames (per RFC 3986).
* Normalize IPv6 literals by removing brackets for matching.
GitHub Security Advisory: GHSA-mvvv-v22x-xqwp
Package: @nocobase/plugin-workflow-request (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2.0.37
Patched in: 2.0.37

Summary: NocoBase has SSRF in Workflow HTTP Request and Custom Request Plugins

Details:
## Summary

NocoBase's workflow HTTP request plugin and custom request action plugin make server-side HTTP requests to user-provided URLs without any SSRF protection. An authenticated user can access internal network services, cloud metadata endpoints, and localhost.

## Vulnerable Code

### 1. Workflow HTTP Request Plugin

**`packages/plugins/@nocobase/plugin-workflow-request/src/server/RequestInstruction.ts` lines 117-128:**
```typescript
return axios.request({
  url: trim(url),  // User-controlled, no validation
  method,
  headers,
  params,
  timeout,
  ...(method.toLowerCase() !== 'get' && data != null
    ? { data: transformer ? await transformer(data) : data }
    : {}),
});
```

The `url` at line 98 comes directly from user workflow configuration with only whitespace trimming.

### 2. Custom Request Action Plugin

**`packages/plugins/@nocobase/plugin-action-custom-request/src/server/actions/send.ts` lines 172-198:**
```typescript
const axiosRequestConfig = {
  baseURL: ctx.origin,
  ...options,
  url: getParsedValue(url, variables),  // User-controlled via template
  headers: { ... },
  params: getParsedValue(arrayToObject(params), variables),
  data: getParsedValue(toJSON(data), variables),
};
const res = await axios(axiosRequestConfig);  // No IP validation
```

## Missing Protections

- No `request-filtering-agent` or SSRF library (confirmed via grep across entire codebase)
- No private IP range filtering
- No cloud metadata endpoint blocking
- No URL scheme validation
- No DNS rebinding protection

## Attack Scenario

1. Authenticated user creates a workflow with HTTP Request node
2. Sets URL to `http://169.254.169.254/latest/meta-data/iam/security-credentials/`
3. Triggers the workflow
4. Server fetches AWS metadata and returns IAM credentials in workflow execution logs

Alternatively via Custom Request action:
1. Create custom request with URL `http://127.0.0.1:5432` or `http://10.0.0.1:8080/admin`
2. Execute the action
3. Server makes request to internal service

## Impact

- **Cloud metadata theft**: AWS/GCP/Azure credentials via metadata endpoints
- **Internal network access**: Scan and interact with services on private IP ranges
- **Database access**: Connect to localhost databases (PostgreSQL, Redis, etc.)
- **Authentication required**: Yes (authenticated user), but any workspace member can create workflows
GitHub Security Advisory: GHSA-9vq7-9h42-j88h
Package: @samanhappy/mcphub (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 0.11.0
Patched in: 0.11.0

Summary: MCPHub has an authentication bypass

Details:
MCPHub in versions below 0.11.0 is vulnerable to authentication bypass. Some endpoints are not protected by authentication middleware, allowing an unauthenticated attacker to perform actions in the name of other users and using their privileges.
GitHub Security Advisory: GHSA-43fj-qp3h-hrh5
Package: @sync-in/server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: <= 2.1.0
Patched in: 2.2.0

Summary: Sync-in Server has Username Enumeration via Timing Attack

Details:
### Summary
The `/api/auth/login` endpoint contains a logic flaw that allows unauthenticated remote attackers to enumerate valid usernames by measuring the application's response time.

### Details
The logic flaw can be located at the below point in source:
https://github.com/Sync-in/server/blob/7868bb2b3025f92e6c[PII_REDACTED][PII_REDACTED]b2/backend/src/applications/users/services/users-queries.service.ts#L91-L95

Endpoints used for authentication should respond to the user with a consistent cadence, preventing remote actors from deriving sensitive information about an application based on backend behavior. In the case of authentication endpoints, this timing discrepancy is often caused by short-circuiting due to the lack of a matched user to compare against - as is the case with Sync-in.

### Validation
TickTock Enum (Burp Suite Extension) was utilized to validate this finding. Authentication attempts with a valid username see a response from the application at around 350-400ms on average, while invalid usernames are returned at only 95-100ms on average.
<img width="1302" height="284" alt="image" src="https://github.com/user-attachments/assets/31eeb72a-c3c2-4057-ac69-c0c92f0bbd4e" />

### Impact
An unauthenticated remote attacker can enumerate valid usernames. This significantly weakens the application's security posture by facilitating targeted brute-force attacks, stuffing, social engineering, and a suite of other more targeted attacks.
GitHub Security Advisory: GHSA-j8j5-7r4h-vj2g
Package: dbgate-web (NPM)
Severity: LOW (CVSS 3.5)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 7.1.5
Patched in: 7.1.5

Summary: DbGate has cross site scripting via the  SVG Icon String Handler component

Details:
A security vulnerability has been detected in DbGate up to 7.1.4. This affects an unknown function of the file packages/web/src/icons/FontIcon.svelte of the component SVG Icon String Handler. Such manipulation of the argument applicationIcon leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 7.1.5 mitigates this issue. It is advisable to upgrade the affected component.
GitHub Security Advisory: GHSA-26wg-9xf2-q495
Package: novu/api (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.15.0
Patched in: 3.15.0

Summary: Novu has a XSS sanitization bypass

Details:
### Summary

XSS sanitization is incomplete, some attributes are missing such as `oncontentvisibilityautostatechange=`. This allows for the email preview to render HTML that executes arbitrary JavaScript,

### Details

Sanitization is implemented here:
https://github.com/novuhq/novu/blob/next/libs/application-generic/src/services/sanitize/sanitizer.service.ts

With `allowedAttributes: false`, all attributes are allowed through `sanitize-html`. Even dangerous ones like `oncontentvisibilityautostatechange=`. The `DANGEROUS_ATTRIBUTES` array tries to handle this by denying more attributes after the fact, but this list is incomplete. I copied all well-known payloads from:
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
And found that the `oncontentvisibilityautostatechange=` attribute isn't detected. 

PS. there seems to also be another even more lax sanitizer here, but I wasn't able to figure out where it is used:
https://github.com/novuhq/novu/blob/next/packages/framework/src/utils/sanitize.utils.ts

### PoC

1. Create a new workflow and add an *Email* step
2. In the body, write the following HTML code:

```html
<a oncontentvisibilityautostatechange="alert(window.origin)" style="display:block;content-visibility:auto">
```

3. Wait a second and notice the XSS popup showing the current origin:

<img width="1515" height="610" alt="image" src="https://github.com/user-attachments/assets/7d519a50-3bed-4f04-b78c-9c[PII_REDACTED]" />

https://dashboard.novu.co/env/dev_env_gVtdgDEhgf1CetwX/workflows/onboarding-demo-workflow_wf_gVtdh2uV0h7j3ffK/steps/email-step_st_gVtqdgIrOkYVvP9F/editor

### Impact

This may look like a Self-XSS similar to https://github.com/novuhq/novu/security/advisories/GHSA-w8vm-jx29-52fr, but it can be more impactful. First of all, if multiple users can access this dashboard, the link above can directly bring the to the email step editor to trigger the XSS.
An attacker can also use the Google/GitHub OAuth flows without completing the code callback step, and send that URL to the victim to intentionally log the vicitm into the attacker's account. If the attacker has prepared an XSS payload there, they will now be allowed to view it, so it triggers.
GitHub Security Advisory: GHSA-4x48-cgf9-q33f
Package: @novu/api (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 3.15.0
Patched in: 3.15.0

Summary: Novu has SSRF via conditions filter webhook bypasses validateUrlSsrf() protection

Details:
## Summary

The conditions filter webhook at `libs/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts` line 261 sends POST requests to user-configured URLs using raw `axios.post()` with no SSRF validation. The HTTP Request workflow step in the same codebase correctly uses `validateUrlSsrf()` which blocks private IP ranges. The conditions webhook was not included in this protection.

## Root Cause

`conditions-filter.usecase.ts` line 261:
```typescript
return await axios.post(child.webhookUrl, payload, config).then((response) => {
  return response.data as Record<string, unknown>;
});
```

No call to `validateUrlSsrf()`. The `webhookUrl` comes from the workflow condition configuration with zero validation.

## Protected Code (for contrast)

`execute-http-request-step.usecase.ts` line 130:
```typescript
const ssrfValidationError = await validateUrlSsrf(url);
if (ssrfValidationError) {
  // blocked
}
```

This function resolves DNS and checks against private ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16). It exists in the codebase but is not applied to the conditions webhook path.

## Proof of Concept

1. Create a workflow with a condition step
2. Configure the condition's webhook URL to `http://169.254.169.254/latest/meta-data/iam/security-credentials/`
3. Trigger the workflow by sending a notification event
4. The worker evaluates the condition and calls `axios.post()` to the metadata endpoint
5. The response data is stored in execution details and accessible via the execution details API

## Impact

Full-read SSRF. The response body is returned as `Record<string, unknown>` for condition evaluation and stored in the execution details `raw` field. The `GET /execution-details` API returns this data.

The POST method limits some metadata endpoints (GCP requires GET, Azure requires GET), but AWS IMDSv1 accepts POST and returns credentials. Internal services accepting POST are also reachable.

## Suggested Fix

Extract `validateUrlSsrf()` to a shared utility and call it before the axios.post in conditions-filter.usecase.ts:

```typescript
const ssrfError = await validateUrlSsrf(child.webhookUrl);
if (ssrfError) {
  throw new Error('Webhook URL blocked by SSRF protection');
}
return await axios.post(child.webhookUrl, payload, config)...
```