deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mjf5-7g4m-gx5w
Package: storybook (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-1385: Missing Origin Validation in WebSockets
Vulnerable versions: >= 8.1.0, < 8.6.17
Patched in: 8.6.17

Summary: Storybook Dev Server is Vulnerable to WebSocket Hijacking

Details:
### Summary

The WebSocket functionality in Storybook's dev server, used to create and update stories, is vulnerable to WebSocket hijacking. This vulnerability **only affects the Storybook dev server; production builds are not impacted**.

### Details

Exploitation requires a developer to visit a malicious website while their local Storybook dev server is running. Because the WebSocket connection does not validate the origin of incoming connections, a malicious site can silently send WebSocket messages to the local instance without any further user interaction.

If a Storybook dev server is intentionally exposed publicly (e.g. for design reviews or stakeholder demos) the risk is higher, as no malicious site visit is required. Any unauthenticated attacker can send WebSocket messages to it directly.

The vulnerability affects the WebSocket message handlers for creating and saving stories, which can be exploited via unauthorized WebSocket connections to achieve persistent XSS or Remote Code Execution (RCE).

_Note: recent versions of Chrome have some protections against this, but Firefox does not._

### Impact
This vulnerability can lead to supply chain compromise. Key risks include:

- **Remote Code Execution**: The vulnerability can allow attackers to execute malicious code, with the extent of impact depending on the configuration. Server-side RCE is possible in non-default configurations, such as when stories are executed via portable stories in JSDOM, potentially allowing attackers to exfiltrate credentials and environment variables, access source code and the filesystem, establish backdoors, or pivot to internal network resources.
- **Persistent XSS**: Malicious payloads are written directly into story source files. If the malicious payload is committed to version control, it becomes part of the codebase and can propagate to deployed Storybook documentation sites, affecting developers and stakeholders who view them.
- **Supply Chain Propagation**: If the modified source files are committed, injected code can spread to other team members via git, execute in CI/CD pipelines, and affect shared component libraries used across multiple projects.

### Affected versions

8.1 and above. While the exploitable functionality was introduced in 8.1, the patch has been applied to 7.x as a precautionary measure given the underlying WebSocket behaviour.

### Recommended actions
Update to one of the patched versions: `7.6.23`, `8.6.17`, `9.1.19`, `10.2.10`.
GitHub Security Advisory: GHSA-4q3h-vp4r-prv2
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 8.6.2
Patched in: 8.6.3

Summary: Parse Server: Account takeover via JWT algorithm confusion in Google auth adapter

Details:
### Impact

An unauthenticated attacker can forge a Google authentication token with `alg: "none"` to log in as any user linked to a Google account, without knowing their credentials. All deployments with Google authentication enabled are affected.

### Patches

The fix hardcodes the expected `RS256` algorithm instead of trusting the JWT header, and replaces the Google adapter's custom key fetcher with `jwks-rsa` which rejects unknown key IDs.

### Workarounds

Disable Google authentication until you can upgrade.

### References

- GitHub advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4q3h-vp4r-prv2
- Fixed in Parse Server 9.3.1-alpha.4: https://github.com/parse-community/parse-server/releases/tag/9.3.1-alpha.4
- Fixed in Parse Server 8.6.3: https://github.com/parse-community/parse-server/releases/tag/8.6.3
GitHub Security Advisory: GHSA-4q3h-vp4r-prv2
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 9.0.0, <= 9.3.1-alpha.3
Patched in: 9.3.1-alpha.4

Summary: Parse Server: Account takeover via JWT algorithm confusion in Google auth adapter

Details:
### Impact

An unauthenticated attacker can forge a Google authentication token with `alg: "none"` to log in as any user linked to a Google account, without knowing their credentials. All deployments with Google authentication enabled are affected.

### Patches

The fix hardcodes the expected `RS256` algorithm instead of trusting the JWT header, and replaces the Google adapter's custom key fetcher with `jwks-rsa` which rejects unknown key IDs.

### Workarounds

Disable Google authentication until you can upgrade.

### References

- GitHub advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4q3h-vp4r-prv2
- Fixed in Parse Server 9.3.1-alpha.4: https://github.com/parse-community/parse-server/releases/tag/9.3.1-alpha.4
- Fixed in Parse Server 8.6.3: https://github.com/parse-community/parse-server/releases/tag/8.6.3
GitHub Security Advisory: GHSA-663h-2vr3-ghrj
Package: yapi-vendor (NPM)
Severity: HIGH (CVSS 7.4)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 1.12.0
Patched in: unpatched

Summary: yapi disables TLS/SSL certificate validation via rejectUnauthorized: false in Axios HTTPS agent

Details:
An issue pertaining to CWE-295: Improper Certificate Validation was discovered in YMFE yapi v1.12.0. The application disables TLS/SSL certificate validation by setting 'rejectUnauthorized': false in the HTTPS agent configuration for Axios requests
GitHub Security Advisory: GHSA-xh43-g2fq-wjrj
Package: @angular/ssr (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 19.0.0-next.0, < 19.2.21
Patched in: 19.2.21

Summary: Angular SSR has an Open Redirect via X-Forwarded-Prefix

Details:
An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash.

When an Angular SSR application is deployed behind a proxy that passes the `X-Forwarded-Prefix` header, an attacker can provide a value starting with three slashes (e.g., `///evil.com`).

1. The application processes a redirect (e.g., from a router `redirectTo` or i18n locale switch).
2. Angular receives `///evil.com` as the prefix.
3. It strips one slash, leaving `//evil.com`.
4. The resulting string is used in the `Location` header.
5. Modern browsers interpret `//` as a protocol-relative URL, redirecting the user from `https://your-app.com` to `https://evil.com`.


### Impact
This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:
- **Scale:** A single request can poison a high-traffic route, impacting all users until the cache expires.
- **SEO Poisoning:** Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
- **Trust:** Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

### Attack Preconditions

- The application must use Angular SSR.
- The application must have routes that perform internal redirects.
- The infrastructure (Reverse Proxy/CDN) must pass the `X-Forwarded-Prefix` header to the SSR process without sanitization.
- The cache must not vary on the `X-Forwarded-Prefix` header.

### Patches
- 21.2.0-rc.1
- 21.1.5
- 20.3.17
- 19.2.21

### Workarounds
Until the patch is applied, developers should sanitize the `X-Forwarded-Prefix` header in their`server.ts` before the Angular engine processes the request:

```ts
app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

```

### Resources
- [Report](https://github.com/angular/angular-cli/issues/32501)
- [Fix](https://github.com/angular/angular-cli/pull/32521)
GitHub Security Advisory: GHSA-xh43-g2fq-wjrj
Package: @angular/ssr (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 20.0.0-next.0, < 20.3.17
Patched in: 20.3.17

Summary: Angular SSR has an Open Redirect via X-Forwarded-Prefix

Details:
An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash.

When an Angular SSR application is deployed behind a proxy that passes the `X-Forwarded-Prefix` header, an attacker can provide a value starting with three slashes (e.g., `///evil.com`).

1. The application processes a redirect (e.g., from a router `redirectTo` or i18n locale switch).
2. Angular receives `///evil.com` as the prefix.
3. It strips one slash, leaving `//evil.com`.
4. The resulting string is used in the `Location` header.
5. Modern browsers interpret `//` as a protocol-relative URL, redirecting the user from `https://your-app.com` to `https://evil.com`.


### Impact
This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:
- **Scale:** A single request can poison a high-traffic route, impacting all users until the cache expires.
- **SEO Poisoning:** Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
- **Trust:** Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

### Attack Preconditions

- The application must use Angular SSR.
- The application must have routes that perform internal redirects.
- The infrastructure (Reverse Proxy/CDN) must pass the `X-Forwarded-Prefix` header to the SSR process without sanitization.
- The cache must not vary on the `X-Forwarded-Prefix` header.

### Patches
- 21.2.0-rc.1
- 21.1.5
- 20.3.17
- 19.2.21

### Workarounds
Until the patch is applied, developers should sanitize the `X-Forwarded-Prefix` header in their`server.ts` before the Angular engine processes the request:

```ts
app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

```

### Resources
- [Report](https://github.com/angular/angular-cli/issues/32501)
- [Fix](https://github.com/angular/angular-cli/pull/32521)
GitHub Security Advisory: GHSA-xh43-g2fq-wjrj
Package: @angular/ssr (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 21.0.0-next.0, < 21.1.5
Patched in: 21.1.5

Summary: Angular SSR has an Open Redirect via X-Forwarded-Prefix

Details:
An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash.

When an Angular SSR application is deployed behind a proxy that passes the `X-Forwarded-Prefix` header, an attacker can provide a value starting with three slashes (e.g., `///evil.com`).

1. The application processes a redirect (e.g., from a router `redirectTo` or i18n locale switch).
2. Angular receives `///evil.com` as the prefix.
3. It strips one slash, leaving `//evil.com`.
4. The resulting string is used in the `Location` header.
5. Modern browsers interpret `//` as a protocol-relative URL, redirecting the user from `https://your-app.com` to `https://evil.com`.


### Impact
This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:
- **Scale:** A single request can poison a high-traffic route, impacting all users until the cache expires.
- **SEO Poisoning:** Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
- **Trust:** Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

### Attack Preconditions

- The application must use Angular SSR.
- The application must have routes that perform internal redirects.
- The infrastructure (Reverse Proxy/CDN) must pass the `X-Forwarded-Prefix` header to the SSR process without sanitization.
- The cache must not vary on the `X-Forwarded-Prefix` header.

### Patches
- 21.2.0-rc.1
- 21.1.5
- 20.3.17
- 19.2.21

### Workarounds
Until the patch is applied, developers should sanitize the `X-Forwarded-Prefix` header in their`server.ts` before the Angular engine processes the request:

```ts
app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

```

### Resources
- [Report](https://github.com/angular/angular-cli/issues/32501)
- [Fix](https://github.com/angular/angular-cli/pull/32521)
GitHub Security Advisory: GHSA-xh43-g2fq-wjrj
Package: @angular/ssr (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 21.2.0-next.0, < 21.2.0-rc.0
Patched in: 21.2.0-rc.1

Summary: Angular SSR has an Open Redirect via X-Forwarded-Prefix

Details:
An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash.

When an Angular SSR application is deployed behind a proxy that passes the `X-Forwarded-Prefix` header, an attacker can provide a value starting with three slashes (e.g., `///evil.com`).

1. The application processes a redirect (e.g., from a router `redirectTo` or i18n locale switch).
2. Angular receives `///evil.com` as the prefix.
3. It strips one slash, leaving `//evil.com`.
4. The resulting string is used in the `Location` header.
5. Modern browsers interpret `//` as a protocol-relative URL, redirecting the user from `https://your-app.com` to `https://evil.com`.


### Impact
This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:
- **Scale:** A single request can poison a high-traffic route, impacting all users until the cache expires.
- **SEO Poisoning:** Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
- **Trust:** Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

### Attack Preconditions

- The application must use Angular SSR.
- The application must have routes that perform internal redirects.
- The infrastructure (Reverse Proxy/CDN) must pass the `X-Forwarded-Prefix` header to the SSR process without sanitization.
- The cache must not vary on the `X-Forwarded-Prefix` header.

### Patches
- 21.2.0-rc.1
- 21.1.5
- 20.3.17
- 19.2.21

### Workarounds
Until the patch is applied, developers should sanitize the `X-Forwarded-Prefix` header in their`server.ts` before the Angular engine processes the request:

```ts
app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

```

### Resources
- [Report](https://github.com/angular/angular-cli/issues/32501)
- [Fix](https://github.com/angular/angular-cli/pull/32521)
GitHub Security Advisory: GHSA-5rq4-664w-9x2c
Package: basic-ftp (NPM)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 5.2.0
Patched in: 5.2.0

Summary: Basic FTP has Path Traversal Vulnerability in its downloadToDir() method

Details:
The `basic-ftp` library contains a path traversal vulnerability in the `downloadToDir()` method. A malicious FTP server can send directory listings with filenames containing path traversal sequences (`../`) that cause files to be written outside the intended download directory.


## Source-to-Sink Flow

```
1. SOURCE: FTP server sends LIST response
└─> "-rw-r--r-- 1 user group 1024 Jan 20 12:00 ../../../etc/passwd"

2. PARSER: parseListUnix.ts:100 extracts filename
└─> file.name = "../../../etc/passwd"

3. VALIDATION: parseListUnix.ts:101 checks
└─> if (name === "." || name === "..") ❌ (only filters exact matches)
└─> "../../../etc/passwd" !== "." && !== ".." ✅ PASSES

4. SINK: Client.ts:707 uses filename directly
└─> const localPath = join(localDirPath, file.name)
└─> join("/safe/download", "../../../etc/passwd")
└─> Result: "/safe/download/../../../etc/passwd" → resolves to "/etc/passwd"

5. FILE WRITE: Client.ts:512 opens file
└─> fsOpen(localPath, "w") → writes to /etc/passwd (outside intended directory)
```

## Vulnerable Code

**File**: `src/Client.ts:707`

```typescript
protected async _downloadFromWorkingDir(localDirPath: string): Promise<void> {
await ensureLocalDirectory(localDirPath)
for (const file of await this.list()) {
const localPath = join(localDirPath, file.name) // ⚠️ VULNERABLE
// file.name comes from untrusted FTP server, no sanitization
await this.downloadTo(localPath, file.name)
}
}
```

**Root Cause**:
- Parser validation (`parseListUnix.ts:101`) only filters exact `.` or `..` entries
- No sanitization of `../` sequences in filenames
- `path.join()` doesn't prevent traversal, `fs.open()` resolves paths


# Impact

A malicious FTP server can:
- Write files to arbitrary locations on the client filesystem
- Overwrite critical system files (if user has write access)
- Potentially achieve remote code execution

## Affected Versions

- **Tested**: v5.1.0
- **Likely**: All versions (code pattern exists since initial implementation)

## Mitigation

**Workaround**: Do not use `downloadToDir()` with untrusted FTP servers.

**Fix**: Sanitize filenames before use:

```typescript
import { basename } from 'path'

// In _downloadFromWorkingDir:
const sanitizedName = basename(file.name) // Strip path components
const localPath = join(localDirPath, sanitizedName)
```
GitHub Security Advisory: GHSA-2p9h-rqjw-gm92
Package: n8n (NPM)
Severity: HIGH (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: >= 2.10.0, < 2.10.1
Patched in: 2.10.1

Summary: n8n Vulnerable to Stored XSS via Various Nodes

Details:
## Impact
An authenticated user with permission to create or modify workflows could inject arbitrary scripts into pages rendered by the n8n application using different techniques on various nodes (Form Trigger node, Chat Trigger node, Send & Wait node, Webhook Node, and Chat Node). Scripts injected by a malicious workflow execute in the browser of any user who visits the affected page, enabling session hijacking and account takeover.

## Patches
The issues have 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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Webhook node by adding `n8n-nodes-base.webhook` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

## Credit
Reporters:
- @ori-ron
- @Aikido-Security
- @nil340
- Pawel Bednarz from the NATO Cyber Security Centre (NCSC)
GitHub Security Advisory: GHSA-2p9h-rqjw-gm92
Package: n8n (NPM)
Severity: HIGH (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: >= 2.0.0, < 2.9.3
Patched in: 2.9.3

Summary: n8n Vulnerable to Stored XSS via Various Nodes

Details:
## Impact
An authenticated user with permission to create or modify workflows could inject arbitrary scripts into pages rendered by the n8n application using different techniques on various nodes (Form Trigger node, Chat Trigger node, Send & Wait node, Webhook Node, and Chat Node). Scripts injected by a malicious workflow execute in the browser of any user who visits the affected page, enabling session hijacking and account takeover.

## Patches
The issues have 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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Webhook node by adding `n8n-nodes-base.webhook` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

## Credit
Reporters:
- @ori-ron
- @Aikido-Security
- @nil340
- Pawel Bednarz from the NATO Cyber Security Centre (NCSC)
GitHub Security Advisory: GHSA-2p9h-rqjw-gm92
Package: n8n (NPM)
Severity: HIGH (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: < 1.123.22
Patched in: 1.123.22

Summary: n8n Vulnerable to Stored XSS via Various Nodes

Details:
## Impact
An authenticated user with permission to create or modify workflows could inject arbitrary scripts into pages rendered by the n8n application using different techniques on various nodes (Form Trigger node, Chat Trigger node, Send & Wait node, Webhook Node, and Chat Node). Scripts injected by a malicious workflow execute in the browser of any user who visits the affected page, enabling session hijacking and account takeover.

## Patches
The issues have 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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Webhook node by adding `n8n-nodes-base.webhook` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

## Credit
Reporters:
- @ori-ron
- @Aikido-Security
- @nil340
- Pawel Bednarz from the NATO Cyber Security Centre (NCSC)