deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qp7p-654g-cw7p
Package: hono (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: < 4.12.18
Patched in: 4.12.18

Summary: Hono has CSS Declaration Injection via Style Object Values in JSX SSR

Details:
### Summary

The JSX renderer escapes `style` attribute object values for HTML but not for CSS. Untrusted input in a `style` object value or property name can therefore inject additional CSS declarations into the rendered `style` attribute. The impact is limited to CSS and does not allow JavaScript execution or HTML attribute breakout.

### Details

`style` object values are serialized into a CSS declaration list and escaped for HTML attribute context only. Characters that act as CSS declaration boundaries — such as `;`, comment markers, quoted strings, and block delimiters — are valid in HTML attribute content and can extend a value beyond its assigned property.

This issue arises when untrusted input is interpolated into a JSX `style` object and rendered server-side.

### Impact

An attacker who can control the value or property name of a `style` object may inject arbitrary CSS declarations. This may lead to:

- Visual manipulation of the page, including full-viewport overlays usable for phishing
- Outbound requests to attacker-controlled hosts via CSS resource references such as `url(...)`
- Hijacking of UI affordances through layout, positioning, or visibility changes

This issue affects applications that render JSX on the server with `style` object values or property names derived from untrusted input.
GitHub Security Advisory: GHSA-hm8q-7f3q-5f36
Package: hono (NPM)
Severity: LOW (CVSS 3.8)
CWE: CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: < 4.12.18
Patched in: 4.12.18

Summary: Hono has improper validation of NumericDate claims (exp, nbf, iat) in JWT verify()

Details:
### Summary

Improper validation of the JWT NumericDate claims `exp`, `nbf`, and `iat` in `hono/utils/jwt` allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches `verify()` — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control.

### Details

The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected:

- A falsy numeric value short-circuited the presence check.
- A non-finite numeric value compared as never-after-now and never-expired.
- A non-numeric type produced NaN comparisons that evaluated false.

This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value.

### Impact

An actor able to issue tokens accepted by the application may craft tokens whose `exp`, `nbf`, or `iat` claims silently bypass time-based enforcement. This may lead to:

- Tokens treated as never expiring even with `exp` configured on the verifier.
- Tokens with a future `nbf` accepted as currently valid.
- Tokens with a future `iat` accepted as legitimately issued.

Deployments using a well-formed token issuer and protecting the signing key are not affected.
GitHub Security Advisory: GHSA-j658-c2gf-x6pq
Package: velocityjs (NPM)
Severity: HIGH (CVSS 8.3)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 2.1.5
Patched in: unpatched

Summary: Velocity.js has a Prototype Pollution vulnerability through #set path assignment

Details:
### Summary
A prototype pollution vulnerability was discovered in Velocity.js <= 2.1.5. This issue occurs during the processing of #set directives in Velocity templates. If an application renders a template controlled by an attacker, it is possible to modify Object.prototype, potentially leading to Denial of Service (DoS) or Remote Code Execution (RCE) depending on the server environment.

### Details
The root cause is located in the #set path assignment logic within the source code:
- File: /src/compile/set.ts 
- Issue: The engine accepts arbitrary path keys and performs assignments using the logic `(baseRef as Record<string, unknown>)[key] = val`.


Because there is no validation or filtering to block sensitive keys such as \_\_proto\_\_, constructor, or prototype, an attacker can traverse the prototype chain and pollute the global Object.prototype.

### PoC
```javascript
const {render} = require('velocityjs');
delete Object.prototype.polluted;
console.log({}.polluted); // ""
render('#set($__proto__.polluted = "hacked")', {});
console.log({}.polluted); // "hacked"
delete Object.prototype.polluted;
```

### Impact
- Vulnerability Type: Prototype Pollution
- Who is impacted: Any application that renders Velocity templates where the template content can be influenced or controlled by untrusted users.
- Severity: High. Prototype pollution can often be used to bypass security controls, cause application crashes (DoS), or be chained with other vulnerabilities to achieve code execution.
GitHub Security Advisory: GHSA-p77w-8qqv-26rm
Package: hono (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-524: Use of Cache Containing Sensitive Information
Vulnerable versions: < 4.12.18
Patched in: 4.12.18

Summary: Hono's Cache Middleware ignores Vary: Authorization / Vary: Cookie leading to cross-user cache leakage

Details:
### Summary

Cache Middleware does not skip caching for responses that declare per-user variance via `Vary: Authorization` or `Vary: Cookie`. As a result, a response cached for one authenticated user may be served to subsequent requests from different users.

### Details

The Cache Middleware skips caching when a response carries `Vary: *`, certain `Cache-Control` directives (`private`, `no-store`, `no-cache`), or `Set-Cookie`. However, `Vary: Authorization` and `Vary: Cookie` — the standard signals defined in RFC 9110 / RFC 9111 to indicate per-user responses — are not treated as cache-skip reasons.

This issue arises when applications use the Cache Middleware on endpoints that return user-specific data and rely on `Vary: Authorization` or `Vary: Cookie` to scope the response per user, without also setting `Cache-Control: private`.

### Impact

A user may receive a cached response that was originally generated for a different authenticated user. This may lead to:

- Disclosure of personally identifiable information or other user-specific data present in the response body
- Inconsistent or incorrect behavior in user-specific endpoints

This issue affects applications that use the Cache Middleware on endpoints whose responses vary by `Authorization` or `Cookie` and that do not also set `Cache-Control: private`.
GitHub Security Advisory: GHSA-fv7c-fp4j-7gwp
Package: @babel/plugin-transform-modules-systemjs (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 8.0.0-alpha.0, <= 8.0.0-alpha.12
Patched in: 8.0.0-alpha.13

Summary: @babel/plugin-transform-modules-systemjs generates arbitrary code when compiling malicious input

Details:
### Impact

Using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code.

Known affected plugins are:
- `@babel/plugin-transform-modules-systemjs`
- `@babel/preset-env` when using the [`modules: "systemjs"` option](https://babel.dev/docs/babel-preset-env#modules), as it delegates to `@babel/plugin-transform-modules-systemjs`

No other plugins under the `@babel` namespace are impacted.

**Users that only compile trusted code are not impacted.**

### Patches

The vulnerability has been fixed in `@babel/plugin-transform-modules-systemjs@7.29.4`.

Babel also released `@babel/preset-env@7.29.5`, updating its `@babel/plugin-transform-modules-systemjs` dependency, to simplify forcing the update if you are using `@babel/preset-env` directly.

### Workarounds

- Pin `@babel/parser` to v7.11.5. The downgrade will completely disable string module name parsing, but it would also disable other new language features and the build pipeline may fail as a result. Only do so if you are working on a legacy codebase and can not upgrade `@babel/plugin-transform-modules-systemjs` to v7.29.4.
- Do not use the `modules: "systemjs"` option, migrate the codebase to native ES Modules or any other module formats.

### Credits
Babel thanks Daniel Cervera for reporting the vulnerability.
GitHub Security Advisory: GHSA-fv7c-fp4j-7gwp
Package: @babel/plugin-transform-modules-systemjs (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 7.12.0, <= 7.29.3
Patched in: 7.29.4

Summary: @babel/plugin-transform-modules-systemjs generates arbitrary code when compiling malicious input

Details:
### Impact

Using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code.

Known affected plugins are:
- `@babel/plugin-transform-modules-systemjs`
- `@babel/preset-env` when using the [`modules: "systemjs"` option](https://babel.dev/docs/babel-preset-env#modules), as it delegates to `@babel/plugin-transform-modules-systemjs`

No other plugins under the `@babel` namespace are impacted.

**Users that only compile trusted code are not impacted.**

### Patches

The vulnerability has been fixed in `@babel/plugin-transform-modules-systemjs@7.29.4`.

Babel also released `@babel/preset-env@7.29.5`, updating its `@babel/plugin-transform-modules-systemjs` dependency, to simplify forcing the update if you are using `@babel/preset-env` directly.

### Workarounds

- Pin `@babel/parser` to v7.11.5. The downgrade will completely disable string module name parsing, but it would also disable other new language features and the build pipeline may fail as a result. Only do so if you are working on a legacy codebase and can not upgrade `@babel/plugin-transform-modules-systemjs` to v7.29.4.
- Do not use the `modules: "systemjs"` option, migrate the codebase to native ES Modules or any other module formats.

### Credits
Babel thanks Daniel Cervera for reporting the vulnerability.
GitHub Security Advisory: GHSA-35mw-5vvr-vrxc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: >= 2026.3.22, < 2026.4.5
Patched in: 2026.4.5

Summary: OpenClaw contains a symlink traversal vulnerability

Details:
OpenClaw versions 2026.3.22 before 2026.4.5 contain a symlink traversal vulnerability in remote marketplace repository path handling that allows attackers to escape the expected repository root. Attackers can exploit this by providing crafted symlink paths to access files outside the intended repository directory.
GitHub Security Advisory: GHSA-526f-jxpj-jmg2
Package: thrift (NPM)
Severity: HIGH (CVSS 7.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.22.0
Patched in: unpatched

Summary: Apache Thrift vulnerable to Path Traversal, HTTP Request/Response Splitting, Uncontrolled Resource Consumption

Details:
Origin Validation Error, Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'), Uncontrolled Resource Consumption vulnerability in Apache Thrift.

This issue affects Apache Thrift: before 0.23.0.

Users are recommended to upgrade to version [0.23.0](https://github.com/apache/thrift/releases/tag/v0.23.0), which fixes the issue.
GitHub Security Advisory: GHSA-v39h-62p7-jpjc
Package: fast-uri (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: <= 3.1.1
Patched in: 3.1.2

Summary: fast-uri vulnerable to host confusion via percent-encoded authority delimiters

Details:
### Impact

`fast-uri` v3.1.1 and earlier decodes percent-encoded authority delimiters (`%40` as `@`, `%3A` as `:`) inside the host component and serializes them back as raw characters. This changes the URI structure, turning a hostname into userinfo plus a different host.

For example, `http://trusted.com%40evil.com/` normalizes to `http://trusted.com@evil.com/`, which reparses as host `evil.com` with userinfo `trusted.com`.

Applications that normalize untrusted URLs before host allowlist checks, redirect validation, or outbound request routing can be steered to a different authority than the original URL appeared to contain.

### Patches

Upgrade to `fast-uri` >= 3.1.2.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-mpm8-cx2p-626q
Package: electerm (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: >= 3.0.6, < 3.8.15
Patched in: 3.8.15

Summary: Electerm users can run dangrous code through link or command line

Details:
### Impact
_Arbitrary local code execution via deep links, CLI `--opts`, or crafted shortcuts. Affected users: electerm installs that accept protocol URLs or CLI options (affected versions listed in the original report). Exploit requires clicking a crafted `electerm://...` link or opening a crafted shortcut/command that launches electerm with attacker-controlled `opts`._

### Patches
Fixed in version > 3.8.8

Commits:

- https://github.com/electerm/electerm/commit/8a6a17951e96d715f5a231532bbd8303fe208700
- https://github.com/electerm/electerm/commit/a79e06f4a1f0ac6376c3d2411ef4690fa0377742

### Workarounds
- Disable or unregister electerm protocol handlers (Deep Link settings) and avoid clicking `electerm://` links.
- Do not run electerm with untrusted `--opts` arguments or open `.lnk` / `.desktop` files from untrusted sources.
- Restrict which users can launch electerm on shared machines and avoid leaving electerm installed in locations reachable by other users.
- As a temporary measure, run electerm in a confined account or sandbox (non-admin user) to reduce impact.

### Resources
- Report / credit: https://github.com/Curly-Haired-Baboon
- Electerm releases: https://github.com/electerm/electerm/releases
GitHub Security Advisory: GHSA-q4p8-8j9m-8hxj
Package: electerm (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: <= 3.7.8
Patched in: 3.7.9

Summary: Electerm Security Vulnerability: RCE via malicious SSH server filename in openFileWithEditor

Details:
### Impact

A code execution (RCE) vulnerability exists in electerm's SFTP open with system editor or "Edit with custom editor" feature. When a user opts to edit a file using open with system editor or open with a custom editor, the filename is passed directly into a command line without sanitization.

A malicious actor controlling the SSH server or user OS can exploit this by crafting a filename containing shell metacharacters. If a victim subsequently attempts to edit this file, the injected commands are executed on their machine with the user's privileges. This could allow the attacker to run arbitrary code, install malware, or move laterally within the network.

<img width="1792" height="817" alt="1" src="https://github.com/user-attachments/assets/ddf78890-e95d-4fe7-981e-f86887677e8b" />
<img width="1648" height="941" alt="2" src="https://github.com/user-attachments/assets/cca2295b-2053-4d99-a464-be51eac2f5be" />

### Patches

Fixed in version >= 3.7.9

- https://github.com/electerm/electerm/commit/24ce7103e264cffe6eb5476c0506a2379e6f8333

### Workarounds

Until a patch is available, it is strongly recommended to:  
- Refrain from using the open with system editor  or "Edit with custom editor" feature when connected to untrusted or unfamiliar SSH servers.  
- Consider using the built-in editor for viewing files, as this path may not be vulnerable to the same injection.  
- If the feature must be used, ensure connections are exclusively established with trusted servers and perform rigorous filename validation before editing.

### Resources

- [electerm GitHub Repository](https://github.com/electerm/electerm)
GitHub Security Advisory: GHSA-37j4-88rp-2f6h
Package: electerm (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: <= 3.8.15
Patched in: unpatched

Summary: Electerm's full process.env exposed to renderer via window.pre.env

Details:
### Impact

The `getConstants()` IPC handler in `src/app/lib/ipc-sync.js` serialises the entire `process.env` object and sends it to the renderer. The data is stored as `window.pre.env` and is accessible from any JavaScript running in the renderer (e.g., via the DevTools console or a compromised webview context).

On developer and CI machines, `process.env` routinely contains secrets such as:

- `AWS_SECRET_ACCESS_KEY` / `AWS_SESSION_TOKEN`
- `GITHUB_TOKEN` / `NPM_TOKEN`
- `OPENAI_API_KEY` / `DOCKER_AUTH`
- Internal service credentials, API keys, and database URLs

An attacker who achieves any JavaScript execution within the renderer—for example, through a malicious plugin, a cross-site scripting (XSS) flaw, or the terminal hyperlink execution chain—can trivially exfiltrate these secrets to a remote server, leading to cloud account compromise, supply chain attacks, and lateral movement. The exposure is visible even without any code execution by simply opening the "Info" modal in the application, though that requires local access.

### Patches

A patch is yet to be available.

### Workarounds

Until a patch is released:
- Avoid launching electerm with sensitive environment variables set. Use shell scripts or a dedicated terminal profile that clears secrets before starting the application.
- Do not install plugins from untrusted sources, and audit any installed plugins for network access.
- Keep the renderer context as locked down as possible: disable the remote debugging port, and do not paste untrusted code into the DevTools console.

### Resources
- [electerm GitHub Repository](https://github.com/electerm/electerm)
- [electerm Security Policy](https://github.com/electerm/electerm/security)
- Vulnerability details originally reported by external researcher (confirmed on v3.7.9, Win10).
GitHub Security Advisory: GHSA-fwf6-j56g-m97c
Package: electerm (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'), CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 3.8.15
Patched in: unpatched

Summary: Electerm has an unvalidated shell.openExternal that allows arbitrary protocol execution via terminal link click

Details:
### Impact

Electerm's terminal hyperlink handler passes any URL clicked in the terminal directly to `shell.openExternal` without any protocol validation.

When a user connects to a malicious SSH server, the attacker can print a crafted URI in the terminal output. If the victim clicks the link, `shell.openExternal` executes it using the operating system's default protocol handler.

This can be abused to:
- Trigger dangerous protocol handlers (`ms-msdt:`, `search-ms:`) for code execution
- Open local files or network shares (`file://`, UNC paths) to leak NTLM hashes or exfiltrate data
- Launch any installed application associated with a custom URI scheme

An attacker who controls terminal output (e.g., via a malicious SSH server, compromised remote host, or malicious plugin rendering terminal content) can thus achieve arbitrary code execution or local file access on the victim's machine, requiring only that the victim clicks a displayed link.

### Patches

As of electerm v3.7.9, no official patch has been released. Users should monitor the project’s [GitHub releases](https://github.com/electerm/electerm/releases) and [security page](https://github.com/electerm/electerm/security) for an update addressing this issue.

### Workarounds

Until a patch is available:
- Do not click on any links displayed in terminal sessions connected to untrusted servers.
- If possible, disable hyperlink rendering in electerm's terminal settings.
- Use a terminal multiplexer (e.g., tmux) or a separate terminal application that filters URI schemes when working with untrusted hosts.
- Consider running electerm in a restricted environment (sandbox, AppArmor, SELinux) that limits the spawning of protocol handlers.

### Resources

- [electerm GitHub Repository](https://github.com/electerm/electerm)
- [electerm Security Policy](https://github.com/electerm/electerm/security)
- Vulnerability details originally reported by external researcher (confirmed on v3.7.9, Win10).
GitHub Security Advisory: GHSA-f77v-9vpc-6pjm
Package: electerm (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Vulnerable versions: < 3.7.16
Patched in: 3.7.16

Summary: Electerm runWidget has a path traversal that leads to arbitrary code execution

Details:
### Impact
The `runWidget` function in `src/app/widgets/load-widget.js` constructs a file path by directly concatenating user‑supplied widget identifiers without any sanitisation:

```javascript
const file = `widget-${widgetId}.js`
const widget = require(path.join(__dirname, file))
```

Because `runWidget` is exposed to the renderer process via an asynchronous IPC handler with no input validation, an attacker who achieves JavaScript execution inside the renderer (for example, through a malicious plugin or a cross‑site scripting flaw in the built‑in webview) can abuse a **path traversal** (`../`) to load and execute an arbitrary JavaScript file anywhere on the victim’s filesystem. This gives the attacker local code execution with the full privileges of the electerm process, leading to complete system compromise.

### Patches

Fixed in version >= 3.7.16

### Workarounds
Until a patch is released:
- Do not install or run untrusted plugins.
- Avoid loading arbitrary web content inside electerm’s embedded webview (for example, disable any features that fetch and display remote HTML).
- Run electerm in a sandboxed environment (e.g., with `bubblewrap` on Linux, AppArmor/SELinux profiles, or Windows sandboxed app execution) to limit the impact of any code execution.

### Resources
- [electerm GitHub Repository](https://github.com/electerm/electerm)
- [electerm Security Policy](https://github.com/electerm/electerm/security)
- Vulnerability details originally reported by external researcher (PoC confirmed on v3.7.9, Win10).
GitHub Security Advisory: GHSA-q3j6-qgpj-74h6
Package: fast-uri (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 3.1.0
Patched in: 3.1.1

Summary: fast-uri vulnerable to path traversal via percent-encoded dot segments

Details:
### Impact

`fast-uri` v3.1.0 and earlier decodes percent-encoded path separators (`%2F`) and dot segments (`%2E`) before applying dot-segment removal in `normalize()` and `equal()`. This makes encoded path data behave like real `/` and `..`, so distinct URIs collapse onto the same normalized path.

For example, `http://example.com/public/%2e%2e/admin` normalizes to `http://example.com/admin`, and `equal()` considers them the same URI.

Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed. A path that looks confined under an allowed prefix can normalize to a different location.

### Patches

Upgrade to `fast-uri` >= 3.1.1.

### Workarounds

None. Upgrade to the patched version.