deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-56p5-8mhr-2fph
Package: liquidjs (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 10.25.2
Patched in: 10.25.3

Summary: LiquidJS: Root restriction bypass for partial and layout loading through symlinked templates

Details:
### Summary

LiquidJS enforces partial and layout root restrictions using the resolved pathname string, but it does not resolve the canonical filesystem path before opening the file. A symlink placed inside an allowed partials or layouts directory can therefore point to a file outside that directory and still be loaded.

### Details

For `{% include %}`, `{% render %}`, and `{% layout %}`, LiquidJS checks whether the candidate path is inside the configured partials or layouts roots before reading it. That check is path-based, not realpath-based.

Because of that, a file like `partials/link.liquid` passes the directory containment check as long as its pathname is under the allowed root. If `link.liquid` is actually a symlink to a file outside the allowed root, the filesystem follows the symlink when the file is opened and LiquidJS renders the external target.

So the restriction is applied to the path string that was requested, not to the file that is actually read.

This matters in environments where an attacker can place templates or otherwise influence files under a trusted template root, including uploaded themes, extracted archives, mounted content, or repository-controlled template trees.

### PoC

```js
const { Liquid } = require('liquidjs');
const fs = require('fs');

fs.rmSync('/tmp/liquid-root', { recursive: true, force: true });
fs.mkdirSync('/tmp/liquid-root', { recursive: true });

fs.writeFileSync('/tmp/secret-outside.liquid', 'SECRET_OUTSIDE');
fs.symlinkSync('/tmp/secret-outside.liquid', '/tmp/liquid-root/link.liquid');

const engine = new Liquid({ root: ['/tmp/liquid-root'] });

engine.parseAndRender('{% render "link.liquid" %}')
  .then(console.log);
// SECRET_OUTSIDE
```

### Impact

If an attacker can place or influence symlinks under a trusted partials or layouts directory, they can make LiquidJS read and render files outside the intended template root. In practice this can expose arbitrary readable files reachable through symlink targets.
GitHub Security Advisory: GHSA-r5rp-j6wh-rvv4
Package: hono (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 4.12.12
Patched in: 4.12.12

Summary: Hono: Non-breaking space prefix bypass in cookie name handling in getCookie()

Details:
## Summary

A discrepancy between browser cookie parsing and `parse()` handling allows cookie prefix protections to be bypassed.

Cookie names that are treated as distinct by the browser may be normalized to the same key by `parse()`, allowing attacker-controlled cookies to override legitimate ones.

## Details

Browsers follow RFC 6265bis and only trim SP (`0x20`) and HTAB (`0x09`) from cookie names. Other characters, such as the non-breaking space (`U+00A0`), are preserved as part of the cookie name.

For example, the browser treats the following cookies as distinct:

```
"dummy-cookie"
"\u00a0dummy-cookie"
```

However, `parse()` previously used JavaScript's `trim()`, which removes a broader set of characters including `U+00A0`. As a result, both names are normalized to:

```
"dummy-cookie"
```

This mismatch allows attacker-controlled cookies with a `U+00A0` prefix to shadow or override legitimate cookies when accessed via `getCookie()`.

## Impact

An attacker who can set cookies (e.g., via a man-in-the-middle on a non-secure page or other injection vector) can bypass cookie prefix protections and override sensitive cookies.

This may lead to:

* Bypassing `__Secure-` and `__Host-` prefix protections
* Overriding cookies that rely on the Secure attribute
* Session fixation or session hijacking depending on application usage

This issue affects applications that rely on `getCookie()` for security-sensitive cookie handling.
GitHub Security Advisory: GHSA-xpcf-pg52-r92g
Package: hono (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Vulnerable versions: < 4.12.12
Patched in: 4.12.12

Summary: Hono has incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses

Details:
## Summary

`ipRestriction()` does not canonicalize IPv4-mapped IPv6 client addresses (e.g. `::ffff:127.0.0.1`) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior.

## Details

The middleware classifies client addresses based on their textual form. Addresses containing "`:`" are treated as IPv6, including IPv4-mapped IPv6 addresses such as `::ffff:127.0.0.1`. These addresses are not normalized to IPv4 before matching.

As a result:

* IPv4 static rules (e.g. `127.0.0.1`) do not match because the raw string differs
* IPv4 CIDR rules (e.g. `127.0.0.0/8`, `10.0.0.0/8`) are skipped because the address is treated as IPv6

For example, with:

`denyList: ['127.0.0.1']`

a request from `127.0.0.1` may be represented as `::ffff:127.0.0.1` and bypass the deny rule.

This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses.

## Impact

Applications that rely on IPv4-based `ipRestriction()` rules may incorrectly allow or deny requests.

In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.
GitHub Security Advisory: GHSA-26pp-8wgv-hjvm
Package: hono (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Vulnerable versions: < 4.12.12
Patched in: 4.12.12

Summary: Hono missing validation of cookie name on write path in setCookie()

Details:
## Summary

Cookie names are not validated on the write path when using `setCookie()`, `serialize()`, or `serializeSigned()` to generate Set-Cookie headers.

While certain cookie attributes such as domain and path are validated, the cookie name itself may contain invalid characters.

This results in inconsistent handling of cookie names between parsing (read path) and serialization (write path).

## Details

When applications use `setCookie()`, `serialize()`, or `serializeSigned()` with a user-controlled cookie name, invalid values (e.g., containing control characters such as `\r` or `\n`) can be used to construct malformed `Set-Cookie` header values.

For example:

```
Set-Cookie: legit
X-Injected: evil=value
```

However, in modern runtimes such as Node.js and Cloudflare Workers, such invalid header values are rejected and result in a runtime error before the response is sent.

As a result, the reported header injection / response splitting behavior could not be reproduced in these environments.

## Impact

Applications that pass untrusted input as the cookie name to `setCookie()`, `serialize()`, or `serializeSigned()` may encounter runtime errors due to invalid header values.

In tested environments, malformed `Set-Cookie` headers are rejected before being sent, and the reported header injection behavior could not be reproduced.

This issue primarily affects correctness and robustness rather than introducing a confirmed exploitable vulnerability.
GitHub Security Advisory: GHSA-xf4j-xp2r-rqqx
Package: hono (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 4.0.0, <= 4.12.11
Patched in: 4.12.12

Summary: Hono: Path traversal in toSSG() allows writing files outside the output directory

Details:
## Summary

A path traversal issue in `toSSG()` allows files to be written outside the configured output directory during static site generation. When using dynamic route parameters via `ssgParams`, specially crafted values can cause generated file paths to escape the intended output directory.

## Details

The static site generation process creates output files based on route paths derived from application routes and parameters. When `ssgParams` is used to provide values for dynamic routes, those values are used to construct output file paths. If these values contain traversal sequences (e.g. `..`), the resulting output path may resolve outside the configured output directory. As a result, files may be written to unintended locations instead of being confined within the specified output directory.

For example:
 
```ts
import { Hono } from 'hono'
import { toSSG, ssgParams } from 'hono/ssg'

const app = new Hono()

app.get('/:id', ssgParams([{ id: '../pwned' }]), (c) => {
  return c.text('pwned')
})

toSSG(app, fs, { dir: './static' })
```

In this case, the generated output path may resolve outside `./static`, resulting in a file being written outside the intended output directory.

## Impact

An attacker who can influence values passed to `ssgParams` during the build process may be able to write files outside the intended output directory.

Depending on the build and deployment environment, this may:

* overwrite unintended files
* affect generated artifacts
* impact deployment outputs or downstream tooling

This issue is limited to build-time static site generation and does not affect request-time routing.
GitHub Security Advisory: GHSA-wmmm-f939-6g9c
Package: hono (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 4.12.12
Patched in: 4.12.12

Summary: Hono: Middleware bypass via repeated slashes in serveStatic

Details:
## Summary

A path handling inconsistency in `serveStatic` allows protected static files to be accessed by using repeated slashes (`//`) in the request path.

When route-based middleware (e.g., `/admin/*`) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass.

## Details

The routing layer and `serveStatic` handle repeated slashes differently.

For example:

```
/admin/secret.txt => matches /admin/*
/admin//secret.txt => may not match /admin/*
```

However, `serveStatic` may interpret both paths as the same file location (e.g., `admin/secret.txt`) and return the file.

This inconsistency allows a request such as:

```
GET //admin/secret.txt
```

to bypass middleware registered on `/admin/*` and access protected files.

The issue has been fixed by rejecting paths that contain repeated slashes, ensuring consistent behavior between route matching and static file resolution.

## Impact

An attacker can access static files that are intended to be protected by route-based middleware by using repeated slashes in the request path.

This can lead to unauthorized access to sensitive files under the static root.

This issue affects applications that rely on serveStatic together with route-based middleware for access control.
GitHub Security Advisory: GHSA-92pp-h63x-v22m
Package: @hono/node-server (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.19.13
Patched in: 1.19.13

Summary: @hono/node-server: Middleware bypass via repeated slashes in serveStatic

Details:
## Summary

A path handling inconsistency in `serveStatic` allows protected static files to be accessed by using repeated slashes (`//`) in the request path.

When route-based middleware (e.g., `/admin/*`) is used for authorization, the router may not match paths containing repeated slashes, while `serveStatic` resolves them as normalized paths. This can lead to a middleware bypass.

## Details

The routing layer and `serveStatic` handle repeated slashes differently.

For example:

- `/admin/secret.txt` => matches `/admin/*`
- `//admin/secret.txt` => may not match `/admin/*`

This inconsistency allows a request such as:

```
GET //admin/secret.txt
```

to bypass middleware registered on `/admin/*` and access protected files.

## Impact

An attacker can access static files that are intended to be protected by route-based middleware by using repeated slashes in the request path.

This can lead to unauthorized access to sensitive files under the static root.

This issue affects applications that rely on `serveStatic` together with route-based middleware for access control.
GitHub Security Advisory: GHSA-7853-gqqm-vcwx
Package: openclaw-claude-bridge (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-276: Incorrect Default Permissions, CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: <= 1.1.1
Patched in: 2.0.0

Summary: openclaw-claude-bridge: sandbox is not effective - `--allowed-tools ""` does not restrict available tools

Details:
## Affected

openclaw-claude-bridge v1.1.0

## Issue

v1.1.0 spawns the Claude Code CLI subprocess with `--allowed-tools ""` and the release notes + README claim this **"disables all CLI tools"** for sandboxing. This claim is incorrect.

Per the Claude Code CLI documentation, `--allowed-tools` (alias `--allowedTools`) is an **auto-approve allowlist** of tools that execute without permission prompts — NOT a restriction on which tools are available. The correct flag to restrict the available tool set is `--tools`:

> `--tools <tools...>`  Specify the list of available tools from the built-in set. **Use `""` to disable all tools**, `"default"` to use all tools, or specify tool names (e.g. `"Bash,Edit,Read"`).

## Impact

- All CLI tools (Read/Write/Bash/WebFetch/...) remain nominally available to the spawned subprocess.
- Actual execution behavior in `--print` non-interactive mode depends on undocumented CLI defaults (may auto-deny, may error out, may hang).
- Users who deploy the bridge behind any interface that forwards untrusted prompts (e.g., publicly exposed OpenClaw gateway, automated pipelines with web-fetched context, agents that consume tool results from other systems) may be relying on a sandbox that does not exist.

The README explicitly makes a security claim the code does not uphold, creating a false sense of safety for downstream operators. If the underlying CLI behavior changes in a future version to auto-allow tools in `--print` mode, prompt-injection attacks could trigger arbitrary Read/Write/Bash operations in the gateway's process context.

## Patches

Fixed in [v1.1.1](https://github.com/SeaL773/openclaw-claude-bridge/releases/tag/v1.1.1) (commit 8a296f5) by switching to `--tools ""`. The environment variable was also renamed from `CLAUDE_ALLOWED_TOOLS` to `CLAUDE_TOOLS` to match the flag.

## Workarounds

Setting `CLAUDE_ALLOWED_TOOLS` on v1.1.0 has no mitigating effect. Upgrade to v1.1.1 or manually edit `dist/cli-bridge.js` to replace `--allowed-tools` with `--tools`.

## References

- Fix: https://github.com/SeaL773/openclaw-claude-bridge/commit/8a296f5
- v1.1.1 notes: https://github.com/SeaL773/openclaw-claude-bridge/releases/tag/v1.1.1
- Claude Code CLI reference: https://docs.claude.com/en/docs/claude-code/cli-reference

## Credit

Found during a second-round code review.
GitHub Security Advisory: GHSA-65w6-pf7x-5g85
Package: @delmaredigital/payload-puck (NPM)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 0.6.23
Patched in: 0.6.23

Summary: @delmaredigital/payload-puc is missing authorization on /api/puck/* CRUD endpoints allows unauthenticated access to Puck-registered collections

Details:
### Impact

All `/api/puck/*` CRUD endpoint handlers registered by `createPuckPlugin()` called Payload's local API with the default `overrideAccess: true`, bypassing all collection-level access control. The `access` option passed to `createPuckPlugin()` and any `access` rules defined on Puck-registered collections were silently ignored on these endpoints.

An unauthenticated remote attacker could:

- List all documents (including drafts) in any Puck-registered collection
- Read any document by ID (including drafts)
- Create new documents with arbitrary field values
- Update any document (including bypassing field-level access rules)
- Delete any document
- Read version history and restore arbitrary versions

**In typical installations**, the affected scope is the collection backing the website's pages (default slug: `pages`). For most users this means an attacker could read, modify, create, or delete every page on the website — including unpublished drafts and version history.

**Scope is limited to collections explicitly registered with `createPuckPlugin()`** — the endpoints validate the collection slug against an allowlist, so attackers cannot pivot to other Payload collections such as `users`, `media`, or business data not exposed to the plugin. The auto-created `puck-templates`, `puck-ai-prompts`, and `puck-ai-context` collections are also outside the allowlist; they have their own dedicated endpoints with separate authentication.

Other endpoints in the plugin (AI, styles, prompts, context, and the Next.js API route factories in `src/api/`) were unaffected — they had their own authentication checks.

### Patches

Fixed in **0.6.23**. All endpoint handlers in `src/endpoints/index.ts` now pass `overrideAccess: false` and forward `req` to Payload's local API, so collection-level access rules are evaluated against the current user.

### Workarounds

If you cannot upgrade immediately, place a reverse-proxy or middleware authentication check in front of `/api/puck/*` to require an authenticated session before requests reach the plugin's handlers.
GitHub Security Advisory: GHSA-gpj5-g38j-94v9
Package: drizzle-orm (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 1.0.0-beta.2, < 1.0.0-beta.20
Patched in: 1.0.0-beta.20

Summary: Drizzle ORM has SQL injection via improperly escaped SQL identifiers

Details:
### Summary

Drizzle ORM improperly escaped quoted SQL identifiers in its dialect-specific `escapeName()` implementations. In affected versions, embedded identifier delimiters were not escaped before the identifier was wrapped in quotes or backticks.

As a result, applications that pass attacker-controlled input to APIs that construct SQL identifiers or aliases, such as `sql.identifier()`, `.as()`, may allow an attacker to terminate the quoted identifier and inject SQL.

### Affected components

The issue affects the identifier escaping logic used by the PostgreSQL, MySQL, SQLite, SingleStore, and Gel dialects.

### Impact

This issue only affects applications that pass untrusted runtime input into identifier or alias construction. Common examples include dynamic sorting, dynamic report builders, and CTE or alias names derived from request parameters.

Depending on the database dialect, query context, and database permissions, successful exploitation may enable blind or direct data disclosure, schema enumeration, query manipulation, privilege escalation, or destructive operations.

Applications that use only static schema objects, or that strictly map user input through an allowlist of known column or alias names, are not affected.

### Details

In affected versions, `escapeName()` wrapped the identifier but did not escape the quote delimiter inside the identifier value:

- PostgreSQL / SQLite / Gel: `"` was not doubled to `""`
- MySQL / SingleStore: `` ` `` was not doubled to `` `` ``

Because of this, crafted input containing the dialect-specific identifier delimiter could break out of the quoted identifier and be interpreted as SQL syntax.

A representative vulnerable pattern is dynamic sorting using untrusted input:

```ts
const sortField = req.query.sort || 'id';

const rows = await db
  .select()
  .from(users)
  .orderBy(sql.identifier(sortField));
GitHub Security Advisory: GHSA-gpj5-g38j-94v9
Package: drizzle-orm (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.45.2
Patched in: 0.45.2

Summary: Drizzle ORM has SQL injection via improperly escaped SQL identifiers

Details:
### Summary

Drizzle ORM improperly escaped quoted SQL identifiers in its dialect-specific `escapeName()` implementations. In affected versions, embedded identifier delimiters were not escaped before the identifier was wrapped in quotes or backticks.

As a result, applications that pass attacker-controlled input to APIs that construct SQL identifiers or aliases, such as `sql.identifier()`, `.as()`, may allow an attacker to terminate the quoted identifier and inject SQL.

### Affected components

The issue affects the identifier escaping logic used by the PostgreSQL, MySQL, SQLite, SingleStore, and Gel dialects.

### Impact

This issue only affects applications that pass untrusted runtime input into identifier or alias construction. Common examples include dynamic sorting, dynamic report builders, and CTE or alias names derived from request parameters.

Depending on the database dialect, query context, and database permissions, successful exploitation may enable blind or direct data disclosure, schema enumeration, query manipulation, privilege escalation, or destructive operations.

Applications that use only static schema objects, or that strictly map user input through an allowlist of known column or alias names, are not affected.

### Details

In affected versions, `escapeName()` wrapped the identifier but did not escape the quote delimiter inside the identifier value:

- PostgreSQL / SQLite / Gel: `"` was not doubled to `""`
- MySQL / SingleStore: `` ` `` was not doubled to `` `` ``

Because of this, crafted input containing the dialect-specific identifier delimiter could break out of the quoted identifier and be interpreted as SQL syntax.

A representative vulnerable pattern is dynamic sorting using untrusted input:

```ts
const sortField = req.query.sort || 'id';

const rows = await db
  .select()
  .from(users)
  .orderBy(sql.identifier(sortField));
GitHub Security Advisory: GHSA-g4v2-qx3q-4p64
Package: parse-server (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 7.0.0, < 8.6.75
Patched in: 8.6.75

Summary: Parse Server's Endpoint `/sessions/me` bypasses `_Session` `protectedFields`

Details:
### Impact

The `GET /sessions/me` endpoint returns `_Session` fields that the server operator explicitly configured as protected via the `protectedFields` server option. Any authenticated user can retrieve their own session's protected fields with a single request. The equivalent `GET /sessions` and `GET /sessions/:objectId` endpoints correctly strip protected fields.

### Patches

The `GET /sessions/me` handler now re-fetches the session with the caller's auth context after validating the session token, ensuring `protectedFields` and CLP apply consistently with other session endpoints.

### Workarounds

None.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-g4v2-qx3q-4p64
- Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10406
- Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10407