deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-fcjp-h8cc-6879
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 2.11.15
Patched in: 2.11.15

Summary: NATS is vulnerable to MQTT hijacking via Client ID

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an MQTT client interface.

### Problem Description

Sessions and Messages can by hijacked via MQTT Client ID malfeasance.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.

### Resources

 * This document is canonically: <https://advisories.nats.io/CVE/secnote-2026-06.txt>
 * GHSA advisory: <https://github.com/nats-io/nats-server/security/advisories/GHSA-fcjp-h8cc-6879>
 * MITRE CVE entry: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-33215>
GitHub Security Advisory: GHSA-52jh-2xxh-pwh6
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 2.12.0-RC.1, < 2.12.5
Patched in: 2.12.5

Summary: NATS Server panic via malicious compression on leafnode port

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

When configured to accept leafnode connections (for a hub/spoke topology of multiple nats-servers), then the default configuration allows for negotiating compression; a malicious remote NATS server can trigger a server panic via that compression.

### Problem Description

If the nats-server has the "leafnode" configuration enabled (not default), then anyone who can connect can crash the nats-server by triggering a panic. This happens pre-authentication and requires that compression be enabled (which it is, by default, when leafnodes are used).

Context: a NATS server can form various clustering topologies, including local clusters, and superclusters of clusters, but leafnodes allow for separate administrative domains to link together with limited data communication; eg, a server in a moving vehicle might use a local leafnode for agents to connect to, and sync up to a central service as and when available. The leafnode configuration here is where the central server allows other NATS servers to connect into it, almost like regular NATS clients. Documentation examples typically use port 7422 for leafnode communications.

### Affected Versions

Version 2, prior to v2.11.14 or v2.12.5

### Workarounds

Disable compression on the leafnode port:

```
leafnodes {
  port: 7422
  compression: off
}
```
GitHub Security Advisory: GHSA-52jh-2xxh-pwh6
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 2.11.14
Patched in: 2.11.14

Summary: NATS Server panic via malicious compression on leafnode port

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

When configured to accept leafnode connections (for a hub/spoke topology of multiple nats-servers), then the default configuration allows for negotiating compression; a malicious remote NATS server can trigger a server panic via that compression.

### Problem Description

If the nats-server has the "leafnode" configuration enabled (not default), then anyone who can connect can crash the nats-server by triggering a panic. This happens pre-authentication and requires that compression be enabled (which it is, by default, when leafnodes are used).

Context: a NATS server can form various clustering topologies, including local clusters, and superclusters of clusters, but leafnodes allow for separate administrative domains to link together with limited data communication; eg, a server in a moving vehicle might use a local leafnode for agents to connect to, and sync up to a central service as and when available. The leafnode configuration here is where the central server allows other NATS servers to connect into it, almost like regular NATS clients. Documentation examples typically use port 7422 for leafnode communications.

### Affected Versions

Version 2, prior to v2.11.14 or v2.12.5

### Workarounds

Disable compression on the leafnode port:

```
leafnodes {
  port: 7422
  compression: off
}
```
GitHub Security Advisory: GHSA-x6g4-f6q3-fqvv
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: HIGH (CVSS 7.4)
CWE: CWE-215: Insertion of Sensitive Information Into Debugging Code
Vulnerable versions: >= 2.12.0-RC.1, < 2.12.6
Patched in: 2.12.6

Summary: NATS credentials are exposed in monitoring port via command-line argv

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an optional monitoring port, which provides access to sensitive data.  The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.


### Problem Description

If a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.

The `/debug/vars` end-point contains an unredacted copy of argv.

### Patches

Fixed in nats-server 2.12.6 & 2.11.15

### Workarounds

The NATS Maintainers are bemused at the concept of someone deploying a real configuration using `--pass` to avoid a config file, but also enabling monitoring.

Configure credentials inside a configuration file instead of via argv.

Do not enable the monitoring port if using secrets in argv.

Best practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.
GitHub Security Advisory: GHSA-x6g4-f6q3-fqvv
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: HIGH (CVSS 7.4)
CWE: CWE-215: Insertion of Sensitive Information Into Debugging Code
Vulnerable versions: < 2.11.15
Patched in: 2.11.15

Summary: NATS credentials are exposed in monitoring port via command-line argv

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an optional monitoring port, which provides access to sensitive data.  The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.


### Problem Description

If a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.

The `/debug/vars` end-point contains an unredacted copy of argv.

### Patches

Fixed in nats-server 2.12.6 & 2.11.15

### Workarounds

The NATS Maintainers are bemused at the concept of someone deploying a real configuration using `--pass` to avoid a config file, but also enabling monitoring.

Configure credentials inside a configuration file instead of via argv.

Do not enable the monitoring port if using secrets in argv.

Best practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.
GitHub Security Advisory: GHSA-8m2x-3m6q-6w8j
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.12.0-preview.1, < 2.12.6
Patched in: 2.12.6

Summary: NATS: Message tracing can be redirected to arbitrary subject

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server supports telemetry on messages, using the per-message NATS headers.

### Problem Description

A valid client which uses message tracing headers can indicate that the trace messages can be sent to an arbitrary valid subject, including those to which the client does not have publish permission.

The payload is a valid trace message and not chosen by the attacker.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.
GitHub Security Advisory: GHSA-8m2x-3m6q-6w8j
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.11.0, < 2.11.15
Patched in: 2.11.15

Summary: NATS: Message tracing can be redirected to arbitrary subject

Details:
### Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server supports telemetry on messages, using the per-message NATS headers.

### Problem Description

A valid client which uses message tracing headers can indicate that the trace messages can be sent to an arbitrary valid subject, including those to which the client does not have publish permission.

The payload is a valid trace message and not chosen by the attacker.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.
GitHub Security Advisory: GHSA-2mjq-54qg-7w6j
Package: github.com/kubernetes-csi/csi-driver-nfs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.0.0[PII_REDACTED]5231-316af2d86b91
Patched in: 0.0.0[PII_REDACTED]5231-316af2d86b91

Summary: NFS CSI driver for Kubernetes is Vulnerable to Path Traversal through Volume Identifier Parameter

Details:
A vulnerability was discovered in the Kubernetes CSI Driver for NFS where the subDir parameter in volume identifiers was insufficiently validated. Attackers with the ability to create PersistentVolumes referencing the NFS CSI driver could craft volume identifiers containing path traversal sequences (../). During volume deletion or cleanup operations, the driver could operate on unintended directories outside the intended managed path within the NFS export. This may lead to deletion or modification of directories on the NFS server.
GitHub Security Advisory: GHSA-r9w3-57w2-gch2
Package: github.com/ory/hydra/v2 (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 2.3.1-0[PII_REDACTED]0106-0b84568fffcc
Patched in: 2.3.1-0[PII_REDACTED]0106-0b84568fffcc

Summary: Ory Hydra has a SQL injection via forged pagination tokens

Details:
## Description

Following Admin APIs in Ory Hydra are vulnerable to SQL injection due to flaws in its pagination implementation:

- listOAuth2Clients
- listOAuth2ConsentSessions
- listTrustedOAuth2JwtGrantIssuers

Pagination tokens are encrypted using the secret configured in `secrets.pagination`. If this value is not set, Hydra falls back to using `secrets.system`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection.

## Preconditions

This issue can be exploited when the following conditions are met:

- One or more **admin APIs** listed above are directly or indirectly accessible to the attacker
- The attacker can pass a raw pagination token to the affected API
- The configuration value `secrets.pagination` is set and known to the attacker, or `secrets.pagination` is not set and `secrets.system` is known to the attacker

## Impact

An attacker can execute arbitrary SQL queries through forged pagination tokens.

## Mitigation

As a first line of defense, immediately configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret, for example:

```
openssl rand -base64 32
```

Next, upgrade **Hydra** to the fixed version **as soon as possible**.
GitHub Security Advisory: GHSA-r9w3-57w2-gch2
Package: github.com/ory/hydra (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 1.11.10
Patched in: unpatched

Summary: Ory Hydra has a SQL injection via forged pagination tokens

Details:
## Description

Following Admin APIs in Ory Hydra are vulnerable to SQL injection due to flaws in its pagination implementation:

- listOAuth2Clients
- listOAuth2ConsentSessions
- listTrustedOAuth2JwtGrantIssuers

Pagination tokens are encrypted using the secret configured in `secrets.pagination`. If this value is not set, Hydra falls back to using `secrets.system`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection.

## Preconditions

This issue can be exploited when the following conditions are met:

- One or more **admin APIs** listed above are directly or indirectly accessible to the attacker
- The attacker can pass a raw pagination token to the affected API
- The configuration value `secrets.pagination` is set and known to the attacker, or `secrets.pagination` is not set and `secrets.system` is known to the attacker

## Impact

An attacker can execute arbitrary SQL queries through forged pagination tokens.

## Mitigation

As a first line of defense, immediately configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret, for example:

```
openssl rand -base64 32
```

Next, upgrade **Hydra** to the fixed version **as soon as possible**.
GitHub Security Advisory: GHSA-f35r-v9x5-r8mc
Package: github.com/QuantumNous/new-api (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 0.11.4-alpha.2
Patched in: 0.11.4-alpha.2

Summary: New API: IDOR in VideoProxy allows cross-user video content access via missing ownership check 

Details:
## Summary

The video proxy endpoint `GET /v1/videos/:task_id/content` is vulnerable to an Insecure Direct Object Reference (IDOR). Any authenticated user who knows another user's `task_id` can retrieve that user's generated video content because the handler queries tasks by `task_id` alone and does not verify ownership.

## Affected Component

- Endpoint: `GET /v1/videos/:task_id/content`
- Route middleware: `TokenOrUserAuth()`
- Vulnerable handler: `controller.VideoProxy`

## Details

`VideoProxy` fetches the task with:

```go
task, exists, err := model.GetByOnlyTaskId(taskID)
```

`GetByOnlyTaskId` performs a database lookup using only `task_id`:

```go
err = DB.Where("task_id = ?", taskId).First(&task).Error
```

The authenticated user's ID is available in request context, but `VideoProxy` does not use it. This allows any authenticated user to request `/v1/videos/<foreign_task_id>/content` and access another user's video if they know a valid task ID.

Other task-fetch paths already enforce ownership correctly via:

```go
model.GetByTaskId(userId, taskId)
```

## Impact

An authenticated attacker who knows another user's `task_id` can:

- Download video content belonging to another user
- Bypass tenant isolation for generated media assets
- Cause the server to fetch upstream video content for a task the attacker does not own

For Gemini tasks, the proxy also uses `task.PrivateData.Key` when contacting the upstream provider. In addition, full upstream response headers are forwarded back to the requester.

## Proof of Concept

```bash
curl -o stolen_video.mp4 \
  "https://<instance>/v1/videos/<victim_task_id>/content" \
  -H "Authorization: Bearer sk-<attacker_token>"
```

Expected result:

- Response returns `200 OK`
- Response body contains the victim's video content

## Recommended Fix

Replace the task lookup in `VideoProxy` with an ownership-checked query:

```go
userId := c.GetInt("id")
task, exists, err := model.GetByTaskId(userId, taskID)
```
GitHub Security Advisory: GHSA-4pmx-622h-x359
Package: github.com/mattermost/mattermost-plugin-playbooks (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.41.1-0[PII_REDACTED]4925-705f54a81841
Patched in: 1.41.1-0[PII_REDACTED]4925-705f54a81841

Summary: Mattermost fails to verify run_create permission for empty playbookId

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2 fail to verify run_create permission for empty playbookId, which allows team members to create unauthorized runs via the playbook run API. Mattermost Advisory ID: MMSA-2025-00542
GitHub Security Advisory: GHSA-c38g-mx2c-9wf2
Package: github.com/ory/keto (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.14.1-0[PII_REDACTED]0104-e4393662cd2e
Patched in: 0.14.1-0[PII_REDACTED]0104-e4393662cd2e

Summary: Ory Keto has a SQL injection via forged pagination tokens

Details:
## Description

The **GetRelationships API** in Ory Keto is vulnerable to SQL injection due to flaws in its pagination implementation.

Pagination tokens are encrypted using the secret configured in `secrets.pagination`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection. If this configuration value is not set, Keto falls back to a hard-coded default pagination encryption secret. Because this default value is publicly known, attackers can generate valid and malicious pagination tokens manually for installations where this secret is not set.

## Preconditions

This issue can be exploited when all of the following conditions are met:

- **GetRelationships API** is directly or indirectly accessible to the attacker
- The attacker can pass a raw pagination token to the affected API
- The configuration value `secrets.pagination` is not set or known to the attacker

## Impact

An attacker can execute arbitrary SQL queries through forged pagination tokens.

## Mitigation

As a first line of defense, **immediately** configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret, for example:

```
openssl rand -base64 32
```

Next, upgrade **Keto** to a fixed version **as soon as possible**.
GitHub Security Advisory: GHSA-hgx2-28f8-6g2r
Package: github.com/ory/kratos (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.3.1-0[PII_REDACTED]0106-9d[PII_REDACTED]
Patched in: 1.3.1-0[PII_REDACTED]0106-9d[PII_REDACTED]

Summary: Ory Kratos has a SQL injection via forged pagination tokens

Details:
## Description

The **ListCourierMessages** Admin API in Ory Kratos is vulnerable to SQL injection due to flaws in its pagination implementation.

Pagination tokens are encrypted using the secret configured in `secrets.pagination`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection. If this configuration value is not set, Kratos falls back to a default pagination encryption secret. Because this default value is publicly known, attackers can generate valid and malicious pagination tokens manually for installations where this secret is not set.

## Preconditions

This issue can be exploited when the following conditions are met:

- **ListCourierMessages API** is directly or indirectly accessible to the attacker
- The attacker can pass a raw pagination token to the affected API
- The configuration value `secrets.pagination` is not set or known to the attacker

## Impact

An attacker can execute arbitrary SQL queries through forged pagination tokens.

## Mitigation

As a first line of defense, **immediately** configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret, for example:

```
openssl rand -base64 32
```

Next, upgrade **Kratos** to a fixed version **as soon as possible**.
GitHub Security Advisory: GHSA-p224-6x5r-fjpm
Package: github.com/ory/oathkeeper (GO)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-23: Relative Path Traversal
Vulnerable versions: < 0.40.10-0[PII_REDACTED]4758-8e[PII_REDACTED]
Patched in: 0.40.10-0[PII_REDACTED]4758-8e[PII_REDACTED]

Summary: Ory Oathkeeper has a path traversal authorization bypass

Details:
## Description

Ory Oathkeeper is vulnerable to an authorization bypass via HTTP path traversal. An attacker can craft a URL containing path traversal sequences (e.g. `/public/../admin/secrets`) that resolves to a protected path after normalization, but is matched against a permissive rule because the raw, un-normalized path is used during rule evaluation.

## Preconditions

Ory Oathkeeper rules are typically configured with patterns like:

```
/public/<.*>   → allow unauthenticated access
/admin/<.*>    → require authentication
```

Without path normalization, a request to `/public/../admin/secrets` is matched against the raw path `/public/../admin/secrets`. This matches the `/public/<.*>` rule, bypassing the authentication required for `/admin/secrets`. After Ory Oathkeeper permits the request, the upstream server normalizes the path and serves the protected `/admin/secrets` resource.

## Mitigation

Going forward, Ory Oathkeeper normalizes the request path before performing rule matching and before forwarding. The path `/public/../admin/secrets` is normalized to `/admin/secrets`, which correctly matches the `/admin/<.*>` rule and triggers authentication.

As an immediate mitigation, all requests reaching Oathkeeper should be normalized, as described in the section below. Oathkeeper should be upgraded to a fixed version as soon as possible.

## Defense in depth: Cleaning paths before Oathkeeper

Even after this fix, it is good practice to normalize HTTP paths in the layers in front of Oathkeeper. This provides defense in depth and protects against similar bypasses in other components. The following examples show how to achieve this with common reverse proxies and CDNs.

### Nginx

Nginx normalizes paths by default when using `proxy_pass`. Alternatively, use `$uri` (which Nginx normalizes) rather than `$request_uri` in your matching rules.

### Envoy

Enable the `normalize_path` option (available since Envoy 1.14) to normalize the path components before matching and forwarding. See the <a href="https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path" target="_blank" rel="noopener noreferrer">Envoy docs on path normalization</a>.

### Cloudflare

Cloudflare normalizes URLs by default. In the Cloudflare dashboard, ensure **Normalize incoming URLs** is enabled under **Rules → Normalization**.
See the <a href="https://developers.cloudflare.com/rules/normalization/" target="_blank" rel="noopener noreferrer">Cloudflare URL normalization docs</a>.