deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-x6fw-778m-wr9v
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 8.6.10
Patched in: 8.6.10

Summary: Parse Server: JWT audience validation bypass in Google, Apple, and Facebook authentication adapters

Details:
### Impact

The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (`clientId` for Google/Apple, `appIds` for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.

- For Google and Apple, the vulnerability is exploitable when the server does not configure `clientId`. The adapters accepted this as valid and simply skipped audience validation.
- For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated `appIds` only for Standard Login (Graph API), but the Limited Login JWT path never passed `appIds` as the audience to JWT verification.

### Patches

The fix enforces `clientId` (Google/Apple) and `appIds` (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.

### Workarounds

- Google / Apple: Ensure `clientId` is set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions.
- Facebook Limited Login: There is no workaround. The unpatched adapter does not pass `appIds` to JWT audience validation, so the only mitigation is to upgrade.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10
GitHub Security Advisory: GHSA-x6fw-778m-wr9v
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.0-alpha.11
Patched in: 9.5.0-alpha.11

Summary: Parse Server: JWT audience validation bypass in Google, Apple, and Facebook authentication adapters

Details:
### Impact

The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (`clientId` for Google/Apple, `appIds` for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.

- For Google and Apple, the vulnerability is exploitable when the server does not configure `clientId`. The adapters accepted this as valid and simply skipped audience validation.
- For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated `appIds` only for Standard Login (Graph API), but the Limited Login JWT path never passed `appIds` as the audience to JWT verification.

### Patches

The fix enforces `clientId` (Google/Apple) and `appIds` (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.

### Workarounds

- Google / Apple: Ensure `clientId` is set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions.
- Facebook Limited Login: There is no workaround. The unpatched adapter does not pass `appIds` to JWT audience validation, so the only mitigation is to upgrade.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10
GitHub Security Advisory: GHSA-q5q9-2rhp-33qw
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.3.1-alpha.3, < 9.5.0-alpha.10
Patched in: 9.5.0-alpha.10

Summary: Parse Server: GraphQL `__type` introspection bypass via inline fragments when public introspection is disabled

Details:
### Impact

When `graphQLPublicIntrospection` is disabled, `__type` queries nested inside inline fragments (e.g. `... on Query { __type(name:"User") { name } })` bypass the introspection control, allowing unauthenticated users to perform type reconnaissance. `__schema` introspection is not affected.

### Patches

The check was changed from a flat iteration over root-level selections to a recursive walk of all selection sets, detecting `__type` inside inline fragments at any depth.

### Workarounds

Require master key authentication at the network layer (e.g. reverse proxy) for the GraphQL endpoint.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q5q9-2rhp-33qw
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.10
GitHub Security Advisory: GHSA-hwx8-q9cg-mqmc
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.0-alpha.9
Patched in: 9.5.0-alpha.9

Summary: Parse Server: File metadata endpoint bypasses `beforeFind` / `afterFind` trigger authorization

Details:
### Impact

The file metadata endpoint (GET `/files/:appId/metadata/:filename`) does not enforce `beforeFind` / `afterFind` file triggers. When these triggers are used as access-control gates, the metadata endpoint bypasses them entirely, allowing unauthorized access to file metadata.

This affects any deployment that relies on `Parse.Cloud.beforeFind(Parse.File, ...)` to restrict file access. Only file metadata (user-defined key-value pairs set via addMetadata) is exposed; file content remains protected.

### Patches

The metadata handler now runs `beforeFind` and `afterFind` triggers and returns HTTP 403 when a trigger denies access.

### Workarounds

Disable the `metadata` endpoint by overriding the route with a middleware that rejects all requests:

```js
// Add before mounting Parse Server
app.get('/parse/files/:appId/metadata/:filename', (req, res) => {
  res.status(403).json({ error: 'Forbidden' });
});
```

Adjust the path prefix (`/parse`) to match your mountPath.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hwx8-q9cg-mqmc
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.9
GitHub Security Advisory: GHSA-hwx8-q9cg-mqmc
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 8.6.9
Patched in: 8.6.9

Summary: Parse Server: File metadata endpoint bypasses `beforeFind` / `afterFind` trigger authorization

Details:
### Impact

The file metadata endpoint (GET `/files/:appId/metadata/:filename`) does not enforce `beforeFind` / `afterFind` file triggers. When these triggers are used as access-control gates, the metadata endpoint bypasses them entirely, allowing unauthorized access to file metadata.

This affects any deployment that relies on `Parse.Cloud.beforeFind(Parse.File, ...)` to restrict file access. Only file metadata (user-defined key-value pairs set via addMetadata) is exposed; file content remains protected.

### Patches

The metadata handler now runs `beforeFind` and `afterFind` triggers and returns HTTP 403 when a trigger denies access.

### Workarounds

Disable the `metadata` endpoint by overriding the route with a middleware that rejects all requests:

```js
// Add before mounting Parse Server
app.get('/parse/files/:appId/metadata/:filename', (req, res) => {
  res.status(403).json({ error: 'Forbidden' });
});
```

Adjust the path prefix (`/parse`) to match your mountPath.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hwx8-q9cg-mqmc
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.9
GitHub Security Advisory: GHSA-hm3f-q6rw-m6wh
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.0-alpha.8
Patched in: 9.5.0-alpha.8

Summary: Parse Server: `PagesRouter` path traversal allows reading files outside configured pages directory

Details:
### Impact

The `PagesRouter` static file serving route is vulnerable to a path traversal attack that allows unauthenticated reading of files outside the configured `pagesPath` directory. The boundary check uses a string prefix comparison without enforcing a directory separator boundary. An attacker can use path traversal sequences to access files in sibling directories whose names share the same prefix as the pages directory (e.g. `pages-secret` starts with `pages`).

This affects any Parse Server deployment with the `pages` feature enabled (`pages.enableRouter: true`). Exploitation requires a sibling directory of `pagesPath` whose name begins with the same string as the pages directory name.

### Patches

The fix enforces a path separator boundary in the check, ensuring resolved paths must be strictly inside the `pagesPath` directory.

### Workarounds

Ensure the `pagesPath` directory has no sibling directories whose names begin with the same prefix. For example, if `pagesPath` is `/srv/pages`, ensure no directory like `/srv/pages-backup` or `/srv/pages_old` exists alongside it.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hm3f-q6rw-m6wh
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.8
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.8
GitHub Security Advisory: GHSA-hm3f-q6rw-m6wh
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 8.6.8
Patched in: 8.6.8

Summary: Parse Server: `PagesRouter` path traversal allows reading files outside configured pages directory

Details:
### Impact

The `PagesRouter` static file serving route is vulnerable to a path traversal attack that allows unauthenticated reading of files outside the configured `pagesPath` directory. The boundary check uses a string prefix comparison without enforcing a directory separator boundary. An attacker can use path traversal sequences to access files in sibling directories whose names share the same prefix as the pages directory (e.g. `pages-secret` starts with `pages`).

This affects any Parse Server deployment with the `pages` feature enabled (`pages.enableRouter: true`). Exploitation requires a sibling directory of `pagesPath` whose name begins with the same string as the pages directory name.

### Patches

The fix enforces a path separator boundary in the check, ensuring resolved paths must be strictly inside the `pagesPath` directory.

### Workarounds

Ensure the `pagesPath` directory has no sibling directories whose names begin with the same prefix. For example, if `pagesPath` is `/srv/pages`, ensure no directory like `/srv/pages-backup` or `/srv/pages_old` exists alongside it.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hm3f-q6rw-m6wh
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.8
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.8
GitHub Security Advisory: GHSA-726g-59wr-cj4c
Package: @budibase/server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.23.32
Patched in: 3.23.32

Summary: @budibase/server: Command Injection in PostgreSQL Dump Command

Details:
**Location**: `packages/server/src/integrations/postgres.ts:529-531`  

#### Description
The PostgreSQL integration constructs shell commands using user-controlled configuration values (database name, host, password, etc.) without proper sanitization. The password and other connection parameters are directly interpolated into a shell command.

#### Code Reference
```529:531:packages/server/src/integrations/postgres.ts
    const dumpCommand = `PGPASSWORD="${
      this.config.password
    }" pg_dump --schema-only "${dumpCommandParts.join(" ")}"`
```

#### Attack Vector
An attacker who can control database configuration values (e.g., through compromised credentials or configuration injection) can inject shell commands. For example:
- Password: `password"; malicious-command; echo "`
- Database name: `db"; rm -rf /; echo "`

#### Impact
- Remote code execution
- System compromise
- Data exfiltration

#### Recommendation
1. Use environment variables for sensitive values instead of command-line arguments
2. Validate and sanitize all configuration values
3. Use proper escaping for shell arguments
4. Consider using a PostgreSQL library's native dump functionality instead of shell commands

#### Example Fix
```typescript
import { execFile } from "child_process"
import { promisify } from "util"
const execFileAsync = promisify(execFile)

// Use execFile with proper argument handling
const env = {
  ...process.env,
  PGPASSWORD: this.config.password
}

const args = [
  "--schema-only",
  "--host", this.config.host,
  "--port", this.config.port.toString(),
  "--username", this.config.user,
  "--dbname", this.config.database
]

try {
  const { stdout } = await execFileAsync("pg_dump", args, { env })
  return stdout
} catch (error) {
  // Handle error
}
```
GitHub Security Advisory: GHSA-qr2g-p6q7-w82m
Package: @x402/svm (NPM)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 2.6.0
Patched in: 2.6.0

Summary: x402 SDK Security Advisory

Details:
### Impact

A security vulnerability exists in outdated versions of the x402 SDK.

This vulnerability does not affect users' private keys, smart contracts, or funds.

The issue impacts resource servers accepting payments on Solana when the facilitator is running a vulnerable version of the x402 SDK.

### Who Should Take Action

Facilitators that process payments on Solana must upgrade the x402 SDK to the patched versions listed below.

Clients are not required to upgrade.

Resource servers are not required to upgrade unless they operate their own facilitator (self-facilitate).

### Patches

Please update to the following package versions:
* Npm: @x402/svm >= 2.6.0
* Pypi: x402 >= 2.3.0
* Go: x402 >= 2.5.0
GitHub Security Advisory: GHSA-6f6w-6j58-rq76
Package: shescape (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 2.1.8
Patched in: 2.1.9

Summary: Withdrawn Advisory: Shescape has possible misidentification of shell due to link chains

Details:
## Withdrawn Advisory

This advisory has been withdrawn because it falls outside the https://github.com/ericcornelissen/shescape/blob/a2544a1c78cae19d0e81a485b997bf0b0fcc2c12/SECURITY.md#threat-model. This link is maintained to preserve external references.

## Original Description
### Impact

This impacts users of Shescape that configure their `shell` to point to a file on disk that is a link to a link. The precise result of being affected depends on the actual shell used and incorrect shell identified by Shescape.

In particular, an attacker may be able to bypass escaping for the shell being used. This can result, for example, in exposure of sensitive information, consider the following proof of concept (targeting Shescape v2):

```javascript
import fs from "node:fs";
import { exec } from "node:child_process";

import { Shescape } from "shescape";
import which from "which";

/* 1. Set up */
const shell = which.sync("bash");
const linkToShell = "./csh";
const linkToLink = "./link";

fs.rmSync(linkToLink, { force: true });
fs.rmSync(linkToShell, { force: true });
fs.symlinkSync(shell, linkToShell);
fs.symlinkSync(linkToShell, linkToLink);

/* 2. Misconfiguration */
const execOptions = {
  shell: linkToLink,
};

const shescape = new Shescape({
  shell: execOptions.shell,
});

/* 3. Payload */
const userInput = "a=:~";

/* 4. Attack example */
exec(
  `echo Hello ${shescape.escape(userInput)}`,
  { shell: execOptions.shell },
  (error, stdout) => {
    fs.rmSync(linkToLink);
    fs.rmSync(linkToShell);

    if (error) {
      console.error(`An error occurred: ${error}`);
    } else {
      console.log(stdout);
      // Output:  "Hello a=:/home/user"
    }
  },
);
```

### Patches

This problem has been patched in [v2.1.9](https://www.npmjs.com/package/shescape/v/2.1.9) which you can upgrade to now.

### Workarounds

If upgrading is not an option, either avoid using a shell or make sure the shell path you use is not a link to a link.

### References

- Shescape Pull Request [#2388](https://github.com/ericcornelissen/shescape/pull/2388)
- Shescape Release [v2.1.9](https://github.com/ericcornelissen/shescape/releases/tag/v2.1.9)

### For more information

- Comment on Pull Request [#2388](https://github.com/ericcornelissen/shescape/pull/2388)
- Open an issue at <https://github.com/ericcornelissen/shescape/issues> (New issue > Question)
GitHub Security Advisory: GHSA-c8m8-3jcr-6rj5
Package: @frangoteam/fuxa (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-321: Use of Hard-coded Cryptographic Key, CWE-798: Use of Hard-coded Credentials
Vulnerable versions: <= 1.2.11
Patched in: 1.3.0

Summary: FUXA has a hardcoded fallback JWT signing secret

Details:
FUXA used a static fallback JWT signing secret (`frangoteam751`) when no `secretCode` was configured.

If authentication was enabled without explicitly setting a custom secret, an attacker who knew the default value could forge valid JWT tokens and bypass authentication.

This issue has been addressed in version 1.3.0 by removing the static fallback and generating a secure random secret when no `secretCode` is provided.
GitHub Security Advisory: GHSA-84fx-pwf3-7777
Package: xcode-mcp-server (NPM)
Severity: LOW (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.3
Patched in: unpatched

Summary: xcode-mcp-server vulnerable to Command Injection

Details:
A vulnerability was found in r-huijts xcode-mcp-server up to f3419f00117aa9949e326f78cc940166c88f18cb. This affects the function registerXcodeTools of the file src/tools/xcode/index.ts of the component run_lldb. The manipulation of the argument args results in command injection. It is possible to launch the attack remotely. The exploit has been made public and could be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The patch is identified as 11f8d6bacadd153beee649f92a78a9dad761f56f. Applying a patch is advised to resolve this issue.
GitHub Security Advisory: GHSA-9cp7-3q5w-j92g
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-209: Generation of Error Message Containing Sensitive Information
Vulnerable versions: < 8.6.7
Patched in: 8.6.7

Summary: parse-server: Malformed `$regex` query leaks database error details in API response

Details:
### Impact

A malformed $regex query parameter (e.g. `[abc)` causes the database to return a structured error object that is passed unsanitized through the API response. This leaks database internals such as error messages, error codes, code names, cluster timestamps, and topology details. The vulnerability is exploitable by any client that can send query requests, depending on the deployment's permission configuration.

### Patches

The fix sanitizes database error objects so that only a generic `"An internal server error occurred"` message is returned to clients, while the detailed error is logged server-side. The fix respects the `enableSanitizedErrorResponse` server option.

### Workarounds

There is no workaround other than upgrading. The error leakage occurs in the query execution layer and cannot be mitigated through server configuration or client-side changes.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-9cp7-3q5w-j92g
- Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.6
- Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.7
GitHub Security Advisory: GHSA-9cp7-3q5w-j92g
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-209: Generation of Error Message Containing Sensitive Information
Vulnerable versions: >= 9.0.0, < 9.5.0-alpha.6
Patched in: 9.5.0-alpha.6

Summary: parse-server: Malformed `$regex` query leaks database error details in API response

Details:
### Impact

A malformed $regex query parameter (e.g. `[abc)` causes the database to return a structured error object that is passed unsanitized through the API response. This leaks database internals such as error messages, error codes, code names, cluster timestamps, and topology details. The vulnerability is exploitable by any client that can send query requests, depending on the deployment's permission configuration.

### Patches

The fix sanitizes database error objects so that only a generic `"An internal server error occurred"` message is returned to clients, while the detailed error is logged server-side. The fix respects the `enableSanitizedErrorResponse` server option.

### Workarounds

There is no workaround other than upgrading. The error leakage occurs in the query execution layer and cannot be mitigated through server configuration or client-side changes.

### Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-9cp7-3q5w-j92g
- Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.6
- Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.7
GitHub Security Advisory: GHSA-mjqr-5c55-g77h
Package: @perfood/couch-auth (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: <= 0.26.0
Patched in: unpatched

Summary: @perfood/couch-auth has an Observable Timing Discrepancy 

Details:
An Observable Timing Discrepancy in @perfood/couch-auth v0.26.0 allows attackers to access sensitive information via a timing side-channel.
GitHub Security Advisory: GHSA-qw8v-34ww-6q9p
Package: @perfood/couch-auth (NPM)
Severity: MODERATE (CVSS 9.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax
Vulnerable versions: <= 0.26.0
Patched in: unpatched

Summary: @perfood/couch-auth has a host header injection vulnerability

Details:
A host header injection vulnerability in the mailer component of @perfood/couch-auth v0.26.0 allows attackers to obtain reset tokens and execute an account takeover via spoofing the HTTP Host header.