deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wwwc-f646-vj2j
Package: openclaw (NPM)
Severity: MODERATE (CVSS 7.7)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2026.4.10
Patched in: 2026.4.10

Summary: Duplicate Advisory: OpenClaw: Browser press/type interaction routes missed complete navigation guard coverage

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-536q-mj95-h29h. This link is maintained to preserve external references.

### Original Description
OpenClaw before 2026.4.10 contains an incomplete navigation guard vulnerability that allows attackers to trigger navigation without complete SSRF policy enforcement. Browser press/type style interactions, including pressKey and type submit flows, can bypass post-action security checks to execute unauthorized navigation.
GitHub Security Advisory: GHSA-3g8h-86w9-wvmq
Package: next (NPM)
Severity: LOW (CVSS 3.7)
CWE: CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js's Middleware / Proxy redirects can be cache-poisoned

Details:
### Impact

Next.js uses the `x-nextjs-data` request header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.

When that happened, the middleware/proxy could treat the request as a data request and replace the standard `Location` redirect header with the internal `x-nextjs-redirect` header. Browsers do not follow `x-nextjs-redirect`, so the response became an unusable redirect for normal clients.

If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a `Location` header, causing a denial of service for that redirect path until the cache entry expired or was purged.

### Affected scenarios

This affects applications that:
- use middleware or proxy redirects
- are deployed behind a caching CDN or reverse proxy
- allow 3xx responses on those paths to be cached without differentiating internal data requests from normal requests

### Fix

The fix stops trusting `x-nextjs-data` by itself for middleware redirect handling. A request is now treated as an internal data request only when it is validated as such by internal routing state, preserving legitimate data-request redirect behavior while preventing external header injection from changing normal redirect responses.

### Workarounds

Before upgrading, users can reduce risk by:
- configuring the CDN or reverse proxy to vary its cache key on `x-nextjs-data` for affected responses
GitHub Security Advisory: GHSA-3g8h-86w9-wvmq
Package: next (NPM)
Severity: LOW (CVSS 3.7)
CWE: CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data
Vulnerable versions: >= 12.2.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js's Middleware / Proxy redirects can be cache-poisoned

Details:
### Impact

Next.js uses the `x-nextjs-data` request header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.

When that happened, the middleware/proxy could treat the request as a data request and replace the standard `Location` redirect header with the internal `x-nextjs-redirect` header. Browsers do not follow `x-nextjs-redirect`, so the response became an unusable redirect for normal clients.

If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a `Location` header, causing a denial of service for that redirect path until the cache entry expired or was purged.

### Affected scenarios

This affects applications that:
- use middleware or proxy redirects
- are deployed behind a caching CDN or reverse proxy
- allow 3xx responses on those paths to be cached without differentiating internal data requests from normal requests

### Fix

The fix stops trusting `x-nextjs-data` by itself for middleware redirect handling. A request is now treated as an internal data request only when it is validated as such by internal routing state, preserving legitimate data-request redirect behavior while preventing external header injection from changing normal redirect responses.

### Workarounds

Before upgrading, users can reduce risk by:
- configuring the CDN or reverse proxy to vary its cache key on `x-nextjs-data` for affected responses
GitHub Security Advisory: GHSA-mhwj-73qx-jqxm
Package: @theecryptochad/merge-guard (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 1.0.1
Patched in: 1.0.1

Summary: @theecryptochad/merge-guard has Prototype Pollution in its deepMerge() function

Details:
## Summary

`@theecryptochad/merge-guard` versions prior to 1.0.1 are vulnerable to Prototype Pollution via the `deepMerge()` function. An attacker who controls the source object can inject `__proto__` keys that mutate `Object.prototype`, affecting all objects in the Node.js runtime.

## Details

The `deepMerge()` function recursively merges two objects without sanitizing reserved property keys (`__proto__`, `constructor`, `prototype`). When a source object contains a `__proto__` key, its value is assigned to `target.__proto__`, which JavaScript engines interpret as a write to `Object.prototype`.

## Proof of Concept

```js
const { deepMerge } = require('@theecryptochad/merge-guard');
const payload = JSON.parse('{"__proto__":{"isAdmin":true}}');
deepMerge({}, payload);
console.log({}.isAdmin); // true — Object.prototype is polluted
```

## Impact

Any application using `deepMerge()` with untrusted input (e.g. user-supplied JSON from HTTP requests, WebSocket messages, or config files) is vulnerable. An attacker can inject arbitrary properties onto `Object.prototype`, enabling privilege escalation, application logic bypass, and property injection.

## Remediation

Upgrade to `@theecryptochad/merge-guard >= 1.0.1`, which adds an explicit blocklist:

```js
const BLOCKED = new Set(['__proto__', 'constructor', 'prototype']);
if (BLOCKED.has(key)) continue;
```

## References
- [CWE-1321: Improper Neutralization of Special Elements in Object Keys](https://cwe.mitre.org/data/definitions/1321.html)
- [OWASP: Prototype Pollution](https://owasp.org/www-community/attacks/Prototype_Pollution)
- [Fix commit](https://github.com/TheeCryptoChad/merge-guard/releases/tag/v1.0.1)
GitHub Security Advisory: GHSA-ffhc-5mcf-pf4q
Package: next (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js vulnerable to cross-site scripting in App Router applications using CSP nonces

Details:
### Impact

App Router applications that rely on CSP nonces can be vulnerable to stored cross-site scripting when deployed behind shared caches. In affected versions, malformed nonce values derived from request headers could be reflected into rendered HTML in an unsafe way, allowing an attacker to poison cached responses and cause script execution for later visitors.

### Fix

We now reject or ignore malformed nonce values before they are embedded into HTML and apply stricter nonce sanitization so request-derived nonce data cannot break out of the intended attribute context.

### Workarounds

If you cannot upgrade immediately, strip inbound `Content-Security-Policy` request headers from untrusted traffic.
GitHub Security Advisory: GHSA-ffhc-5mcf-pf4q
Package: next (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 13.4.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js vulnerable to cross-site scripting in App Router applications using CSP nonces

Details:
### Impact

App Router applications that rely on CSP nonces can be vulnerable to stored cross-site scripting when deployed behind shared caches. In affected versions, malformed nonce values derived from request headers could be reflected into rendered HTML in an unsafe way, allowing an attacker to poison cached responses and cause script execution for later visitors.

### Fix

We now reject or ignore malformed nonce values before they are embedded into HTML and apply stricter nonce sanitization so request-derived nonce data cannot break out of the intended attribute context.

### Workarounds

If you cannot upgrade immediately, strip inbound `Content-Security-Policy` request headers from untrusted traffic.
GitHub Security Advisory: GHSA-vfv6-92ff-j949
Package: next (NPM)
Severity: LOW (CVSS 3.7)
CWE: CWE-328: Use of Weak Hash
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js vulnerable to cache poisoning via collisions in React Server Component cache-busting

Details:
### Impact

React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the `_rsc` cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL.

### Fix

We strengthened the `_rsc` cache-busting mechanism to make practical collisions significantly harder and to better separate response variants that should not share cache entries.

### Workarounds

If you cannot upgrade immediately, ensure intermediary caches correctly honor `Vary` for RSC-related request headers, or disable shared caching for affected RSC responses until you can deploy a patched release.
GitHub Security Advisory: GHSA-vfv6-92ff-j949
Package: next (NPM)
Severity: LOW (CVSS 3.7)
CWE: CWE-328: Use of Weak Hash
Vulnerable versions: >= 13.4.6, < 15.5.16
Patched in: 15.5.16

Summary: Next.js vulnerable to cache poisoning via collisions in React Server Component cache-busting

Details:
### Impact

React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the `_rsc` cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL.

### Fix

We strengthened the `_rsc` cache-busting mechanism to make practical collisions significantly harder and to better separate response variants that should not share cache entries.

### Workarounds

If you cannot upgrade immediately, ensure intermediary caches correctly honor `Vary` for RSC-related request headers, or disable shared caching for affected RSC responses until you can deploy a patched release.
GitHub Security Advisory: GHSA-gx5p-jg67-6x7h
Package: next (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js has cross-site scripting in beforeInteractive scripts with untrusted input

Details:
### Impact

Applications that use `beforeInteractive` scripts together with untrusted content can be vulnerable to cross-site scripting. In affected versions, serialized script content was not escaped safely before being embedded into the document, which could allow attacker-controlled input to break out of the intended script context and execute arbitrary JavaScript in a visitor's browser.

### Fix

We now HTML-escape serialized `beforeInteractive` script content before embedding it into the page, preventing attacker-controlled content from breaking out of the inline script boundary.

### Workarounds

If you cannot upgrade immediately, do not pass untrusted data into `beforeInteractive` scripts. If that pattern is unavoidable, sanitize or escape the content before embedding it.
GitHub Security Advisory: GHSA-gx5p-jg67-6x7h
Package: next (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 13.0.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js has cross-site scripting in beforeInteractive scripts with untrusted input

Details:
### Impact

Applications that use `beforeInteractive` scripts together with untrusted content can be vulnerable to cross-site scripting. In affected versions, serialized script content was not escaped safely before being embedded into the document, which could allow attacker-controlled input to break out of the intended script context and execute arbitrary JavaScript in a visitor's browser.

### Fix

We now HTML-escape serialized `beforeInteractive` script content before embedding it into the page, preventing attacker-controlled content from breaking out of the inline script boundary.

### Workarounds

If you cannot upgrade immediately, do not pass untrusted data into `beforeInteractive` scripts. If that pattern is unavoidable, sanitize or escape the content before embedding it.
GitHub Security Advisory: GHSA-mg66-mrh9-m8jx
Package: next (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js vulnerable to Denial of Service via connection exhaustion in applications using Cache Components

Details:
### Impact

Applications using Partial Prerendering through the Cache Components feature can be vulnerable to connection exhaustion through crafted POST requests to a server action. In affected configurations, a malicious request can trigger a request-body handling deadlock that leaves connections open for an extended period, consuming file descriptors and server capacity until legitimate users are denied service.

### Fix

We now treat the header used for resuming Partial Prerendered requests as an internal-only header and strip it from untrusted incoming requests. This header should never be accepted directly from external clients.

### Workarounds

If you cannot upgrade immediately, block requests that would be handled by Next.js if they contain the `Next-Resume` header at the edge.
GitHub Security Advisory: GHSA-mg66-mrh9-m8jx
Package: next (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 15.0.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js vulnerable to Denial of Service via connection exhaustion in applications using Cache Components

Details:
### Impact

Applications using Partial Prerendering through the Cache Components feature can be vulnerable to connection exhaustion through crafted POST requests to a server action. In affected configurations, a malicious request can trigger a request-body handling deadlock that leaves connections open for an extended period, consuming file descriptors and server capacity until legitimate users are denied service.

### Fix

We now treat the header used for resuming Partial Prerendered requests as an internal-only header and strip it from untrusted incoming requests. This header should never be accepted directly from external clients.

### Workarounds

If you cannot upgrade immediately, block requests that would be handled by Next.js if they contain the `Next-Resume` header at the edge.
GitHub Security Advisory: GHSA-h64f-5h5j-jqjh
Package: next (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js has a Denial of Service in the Image Optimization API

Details:
### Impact

When self-hosting Next.js with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker could cause out-of-memory conditions by requesting large local assets from the `/_next/image` endpoint that match the `images.localPatterns` configuration (by default, all patterns are allowed).

- If you are using `images.localPatterns`, only the patterns in that array are impacted.
- If you are using `images.unoptimized: true`, you are NOT impacted.
- If you are using `images.loader: 'custom'`, you are NOT impacted.
- If you are using Vercel, you are NOT impacted.

### Fix

We now apply response size limits consistently to internal image fetches, not just external ones, and fail oversized responses before they can exhaust process memory.

This can be adjusted using the `images.maximumResponseBody` configuration.

### Workarounds

If you cannot upgrade immediately, avoid routing large local assets through `/_next/image`, disable image optimization for large or untrusted local files, or block image optimization access to those assets at the edge.

You can disable using the `images.localPatterns: []` configuration. This will still allow fetching remote images (which is not impacted).
GitHub Security Advisory: GHSA-h64f-5h5j-jqjh
Package: next (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 10.0.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js has a Denial of Service in the Image Optimization API

Details:
### Impact

When self-hosting Next.js with the default image loader, the Image Optimization API fetches local images entirely into memory without enforcing a maximum size limit. An attacker could cause out-of-memory conditions by requesting large local assets from the `/_next/image` endpoint that match the `images.localPatterns` configuration (by default, all patterns are allowed).

- If you are using `images.localPatterns`, only the patterns in that array are impacted.
- If you are using `images.unoptimized: true`, you are NOT impacted.
- If you are using `images.loader: 'custom'`, you are NOT impacted.
- If you are using Vercel, you are NOT impacted.

### Fix

We now apply response size limits consistently to internal image fetches, not just external ones, and fail oversized responses before they can exhaust process memory.

This can be adjusted using the `images.maximumResponseBody` configuration.

### Workarounds

If you cannot upgrade immediately, avoid routing large local assets through `/_next/image`, disable image optimization for large or untrusted local files, or block image optimization access to those assets at the edge.

You can disable using the `images.localPatterns: []` configuration. This will still allow fetching remote images (which is not impacted).
GitHub Security Advisory: GHSA-c4j6-fc7j-m34r
Package: next (NPM)
Severity: HIGH (CVSS 8.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js vulnerable to server-side request forgery in applications using WebSocket upgrades

Details:
### Impact

Self-hosted applications using the built-in Node.js server can be vulnerable to server-side request forgery through crafted WebSocket upgrade requests. An attacker can cause the server to proxy requests to arbitrary internal or external destinations, which may expose internal services or cloud metadata endpoints. Vercel-hosted deployments are not affected.

### Fix

We now apply the same safety checks to WebSocket upgrade handling that already existed for normal HTTP requests, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.

### Workarounds

If you cannot upgrade immediately, do not expose the origin server directly to untrusted networks. If WebSocket upgrades are not required, block them at your reverse proxy or load balancer, and restrict origin egress to internal networks and metadata services where possible.
GitHub Security Advisory: GHSA-c4j6-fc7j-m34r
Package: next (NPM)
Severity: HIGH (CVSS 8.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 13.4.13, < 15.5.16
Patched in: 15.5.16

Summary: Next.js vulnerable to server-side request forgery in applications using WebSocket upgrades

Details:
### Impact

Self-hosted applications using the built-in Node.js server can be vulnerable to server-side request forgery through crafted WebSocket upgrade requests. An attacker can cause the server to proxy requests to arbitrary internal or external destinations, which may expose internal services or cloud metadata endpoints. Vercel-hosted deployments are not affected.

### Fix

We now apply the same safety checks to WebSocket upgrade handling that already existed for normal HTTP requests, so upgrade requests are only proxied when routing has explicitly marked them as safe external rewrites.

### Workarounds

If you cannot upgrade immediately, do not expose the origin server directly to untrusted networks. If WebSocket upgrades are not required, block them at your reverse proxy or load balancer, and restrict origin egress to internal networks and metadata services where possible.
GitHub Security Advisory: GHSA-492v-c6pp-mqqv
Package: next (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 16.0.0, < 16.2.5
Patched in: 16.2.5

Summary: Next.js has a Middleware / Proxy bypass through dynamic route parameter injection

Details:
### Impact

Applications that rely on middleware to protect dynamic routes can be vulnerable to authorization bypass. In affected deployments, specially crafted query parameters can alter the dynamic route value seen by the page while leaving the visible path unchanged, which can allow protected content to be rendered without passing the expected middleware check.

### Fix

We now only honor internal route-parameter normalization in trusted routing flows and ignore externally supplied parameter encodings that should never have been accepted from ordinary requests.

### Workarounds

If you cannot upgrade immediately, enforce authorization in route or page logic instead of relying solely on middleware path matching.
GitHub Security Advisory: GHSA-492v-c6pp-mqqv
Package: next (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 15.4.0, < 15.5.16
Patched in: 15.5.16

Summary: Next.js has a Middleware / Proxy bypass through dynamic route parameter injection

Details:
### Impact

Applications that rely on middleware to protect dynamic routes can be vulnerable to authorization bypass. In affected deployments, specially crafted query parameters can alter the dynamic route value seen by the page while leaving the visible path unchanged, which can allow protected content to be rendered without passing the expected middleware check.

### Fix

We now only honor internal route-parameter normalization in trusted routing flows and ignore externally supplied parameter encodings that should never have been accepted from ordinary requests.

### Workarounds

If you cannot upgrade immediately, enforce authorization in route or page logic instead of relying solely on middleware path matching.