deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-75g8-rv7v-32f7
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: >= 2.0.0, < 2.9.3
Patched in: 2.9.3

Summary: n8n has Unauthenticated Expression Evaluation via Form Node

Details:
## Impact
A second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host.

The vulnerability requires a specific workflow configuration to be exploitable:
1. A form node with a field interpolating a value provided by an unauthenticated user, e.g. a form submitted value.
2. The field value must begin with an `=` character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content.
For example, a workflow uses a multi-step Form where a downstream Form node renders user-provided input back in an HTML field and precedes it with an `=` sign:
`=<h2>Thank you, {{ $input.first().json[\"Name\"] }}!</h2>`

There is no practical reason for a workflow designer to prefix a field with `=` intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance.

Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability.

Due to these real-world constraints — the unlikely workflow configuration, the need for an additional sandbox escape, and the difficulty of discovery — we have assessed the severity as High rather than Critical, diverging from the base CVSS score to better reflect actual exploitability.

## Patches
The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Review usage of form nodes manually for above mentioned preconditions.
- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.
- Disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-75g8-rv7v-32f7
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: < 1.123.22
Patched in: 1.123.22

Summary: n8n has Unauthenticated Expression Evaluation via Form Node

Details:
## Impact
A second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host.

The vulnerability requires a specific workflow configuration to be exploitable:
1. A form node with a field interpolating a value provided by an unauthenticated user, e.g. a form submitted value.
2. The field value must begin with an `=` character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content.
For example, a workflow uses a multi-step Form where a downstream Form node renders user-provided input back in an HTML field and precedes it with an `=` sign:
`=<h2>Thank you, {{ $input.first().json[\"Name\"] }}!</h2>`

There is no practical reason for a workflow designer to prefix a field with `=` intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance.

Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability.

Due to these real-world constraints — the unlikely workflow configuration, the need for an additional sandbox escape, and the difficulty of discovery — we have assessed the severity as High rather than Critical, diverging from the base CVSS score to better reflect actual exploitability.

## Patches
The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Review usage of form nodes manually for above mentioned preconditions.
- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.
- Disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-jhp4-jvq3-w5xr
Package: parse-dashboard (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1289: Improper Validation of Unsafe Equivalence in Input
Vulnerable versions: >= 7.3.0-alpha.42, < 9.0.0-alpha.8
Patched in: 9.0.0-alpha.8

Summary: Parse Dashboard Has a Cache Key Collision that Leaks Master Key to Read-Only Sessions

Details:
### Impact

The `ConfigKeyCache` uses the same cache key for both master key and read-only master key when resolving function-typed keys. Under specific timing conditions, a read-only user can receive the cached full master key, or a regular user can receive the cached read-only master key.

### Patches

The fix uses distinct cache keys for master key and read-only master key.

### Workarounds

Avoid using function-typed master keys, or remove the `agent` configuration block from your dashboard configuration.

### Resources

- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-jhp4-jvq3-w5xr
- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
GitHub Security Advisory: GHSA-3534-xp88-25rc
Package: parse-dashboard (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 7.3.0-alpha.42, < 9.0.0-alpha.8
Patched in: 9.0.0-alpha.8

Summary: Parse Dashboard is Missing CSRF Protection for its Agent Endpoint

Details:
### Impact

The AI Agent API endpoint (`POST /apps/:appId/agent`) lacks CSRF protection. An attacker can craft a malicious page that, when visited by an authenticated dashboard user, submits requests to the agent endpoint using the victim's session.

### Patches

The fix adds CSRF middleware to the agent endpoint and embeds a CSRF token in the dashboard page.

### Workarounds

Remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected.

### Resources

- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-3534-xp88-25rc
- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
GitHub Security Advisory: GHSA-cvwj-6c9h-jg6v
Package: parse-dashboard (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 7.3.0-alpha.42, <= 9.0.0-alpha.7
Patched in: 9.0.0-alpha.8

Summary: Parse Dashboard is Missing Authorization for its Agent Endpoint

Details:
### Impact

The AI Agent API endpoint (`POST /apps/:appId/agent`) does not enforce authorization. Authenticated users scoped to specific apps can access any other app's agent endpoint by changing the app ID in the URL. Read-only users are given the full master key instead of the read-only master key and can supply write permissions in the request body to perform write and delete operations.

Affected are only dashboards with `agent` configuration enabled.

### Patches

The fix adds per-app authorization checks and restricts read-only users to the `readOnlyMasterKey` with write permissions stripped server-side.

### Workarounds

Remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected.

### Resources

- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-cvwj-6c9h-jg6v
- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
GitHub Security Advisory: GHSA-qwc3-h9mg-4582
Package: parse-dashboard (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 7.3.0-alpha.42, < 9.0.0-alpha.8
Patched in: 9.0.0-alpha.8

Summary: Parse Dashboard has incomplete authentication on AI Agent endpoint

Details:
### Impact

The AI Agent API endpoint (POST `/apps/:appId/agent`) lacks authentication. Unauthenticated remote attackers can send requests to the endpoint and perform arbitrary database operations against any connected Parse Server using the master key.

### Patches

The fix adds authentication middleware to the agent endpoint.

### Workarounds

Remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected.

### Resources

- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-qwc3-h9mg-4582
- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
GitHub Security Advisory: GHSA-c6rr-7pmc-73wc
Package: @ensdomains/ens-contracts (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 1.6.2
Patched in: unpatched

Summary: ENS DNSSEC Oracle Vulnerable to RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation

Details:
### Impact

The `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher's 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.

Affected contracts

Contract | Address | Status
-- | -- | --
RSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf[PII_REDACTED]6c5C1e96 | Vulnerable
RSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable
DNSSECImpl | 0x0fc[PII_REDACTED]E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms
DNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point




### Patches

The bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587


### Workarounds

- Deploy the patched contracts
- Point DNSSECImpl.setAlgorithm to the deployed contract

### Resources

https://github.com/ensdomains/ens-contracts-bug-62248-pr-509
GitHub Security Advisory: GHSA-xh87-mx6m-69f3
Package: hono (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-290: Authentication Bypass by Spoofing, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 4.12.0, < 4.12.2
Patched in: 4.12.2

Summary: Hono is Vulnerable to Authentication Bypass by IP Spoofing in AWS Lambda ALB conninfo

Details:
## Summary

When using the AWS Lambda adapter (`hono/aws-lambda`) behind an Application Load Balancer (ALB), the `getConnInfo()` function incorrectly selected the first value from the `X-Forwarded-For` header.

Because AWS ALB appends the real client IP address to the end of the `X-Forwarded-For` header, the first value can be attacker-controlled.

This could allow IP-based access control mechanisms (such as the `ipRestriction` middleware) to be bypassed.

## Details

In ALB environments, AWS appends the actual client IP address to the end of any existing `X-Forwarded-For` header value. However, the previous implementation of `getConnInfo()` extracted the leftmost IP address:

```ts
address = xff.split(',')[0].trim()
```

If a client sent:

```
X-Forwarded-For: <spoofed-ip>
```

ALB would forward:

```
X-Forwarded-For: <spoofed-ip>, <real-client-ip>
```

Since the implementation selected the first value, the spoofed IP address was trusted. This affected applications using:

```ts
ipRestriction(getConnInfo, { allowList: [...] })
```

or any custom middleware relying on `getConnInfo(c).remote.address` for authorization decisions.

The issue only affects deployments using the AWS Lambda adapter behind an ALB. API Gateway (v1/v2) and Lambda Function URLs are not affected, as they use AWS-provided source IP values from `requestContext`.

## Impact

An unauthenticated remote attacker could bypass IP-based access restrictions by supplying a crafted `X-Forwarded-For` header. This may allow access to resources that were intended to be restricted by IP address.

Only applications deployed behind an ALB and relying on `getConnInfo()` for IP-based authorization are affected.
GitHub Security Advisory: GHSA-fm8c-6m29-rp6j
Package: repostat (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.0.1
Patched in: 1.0.1

Summary: repostat: Reflected Cross-Site Scripting (XSS) via repo prop in RepoCard

Details:
### Impact
The `RepoCard` component is vulnerable to Reflected Cross-Site Scripting (XSS). The vulnerability occurs because the component uses React's `dangerouslySetInnerHTML` to render the repository name (`repo` prop) during the loading state without any sanitization. 

If a developer using this package passes unvalidated user input directly into the `repo` prop (for example, reading it from a URL query parameter), an attacker can execute arbitrary JavaScript in the context of the user's browser.

### Proof of Concept
```jsx
import { RepoCard } from 'repostat';

function App() {
  const params = new URLSearchParams(window.location.search);
  const maliciousRepo = params.get('repo') || 'facebook/react';

  return <RepoCard repo={maliciousRepo} token="YOUR_TOKEN" />;
}
```

### Remediation
Update to version 1.0.1. The use of dangerouslySetInnerHTML has been removed, and the repo prop is now safely rendered using standard React JSX data binding, which automatically escapes HTML entities.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 3.1.3
Patched in: 3.1.3

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 4.0.0, < 4.2.4
Patched in: 4.2.4

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 5.0.0, < 5.1.7
Patched in: 5.1.7

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
GitHub Security Advisory: GHSA-3ppc-4f35-3m26
Package: minimatch (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 6.0.0, < 6.2.1
Patched in: 6.2.1

Summary: minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

Details:
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.