deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-x6jc-phwx-hp32
Package: github.com/lxc/incus/v6 (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: < 6.21.0
Patched in: 6.21.0

Summary: Incus container environment configuration newline injection

Details:
### Summary
A user with the ability to launch a container with a custom YAML configuration (e.g a member of the ‘incus’ group) can create an environment variable containing newlines, which can be used to add additional configuration items in the container’s `lxc.conf` due to the newline injection. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host.

### Details
When passing environment variables in the config block of a new container, values are not checked for the presence of newlines [1], which can result in newline injection inside the generated container `lxc.conf`. This can be used to set arbitrary additional configuration items, such as `lxc.hook.pre-start`. By exploiting this, a user with the ability to launch a container with an arbitrary config can achieve arbitrary command execution as root on the host.

Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable directory for the validation step (e.g /tmp). This can be confirmed with a second container with /tmp mounted from the host (A privileged action for validation only).

[1] https://github.com/lxc/incus/blob/HEAD/internal/server/instance/drivers/driver_lxc.go#L1081

### PoC
A proof-of-concept script exploiting this vulnerability can be found attached, named environment_newline_injection.sh, showing arbitrary command execution, which will write a file to the root filesystem (`/newline_injection_command_exec_poc`)

Manual Reproduction steps:
1. Launch a new container with a configuration file containing a multiline YAML string as an environment variable value, such as in the listing below.
2. Observe that the lxc.conf (`/run/incus/user-1000_poc/lxc.conf` in my case) contains an additional `lxc.hook.pre-start` item
3. Observe the creation of the file in the host root directory, with contents proving command execution as root.

```
incus launch images:alpine/edge --ephemeral poc << EOF
config:
  environment.FOO: |-
    abc
    lxc.hook.pre-start = /bin/sh -c "id > /newline_injection_command_exec_poc"
EOF
```

### Impact
A user with the ability to launch a container with a custom YAML configuration (e.g a member of the ‘incus’ group) can achieve arbitrary command execution on the host.

### Attachments
[environment_newline_injection.sh](https://github.com/user-attachments/files/24473682/environment_newline_injection.sh)
[environment_newline_injection.patch](https://github.com/user-attachments/files/24473685/environment_newline_injection.patch)
GitHub Security Advisory: GHSA-3f24-pcvm-5jqc
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-287: Improper Authentication, CWE-295: Improper Certificate Validation
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS has mTLS verify_and_map authentication bypass via incorrect Subject DN matching

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.

One authentication model supported is mTLS, deriving the NATS client identity from properties of the TLS Client Certificate.

### Problem Description

When using mTLS for client identity, with `verify_and_map` to derive a NATS identity from the client certificate's Subject DN, certain patterns of RDN would not be correctly enforced, allowing for authentication bypass.

This does require a valid certificate from a CA already trusted for client certificates, and `DN` naming patterns which the NATS maintainers consider highly unlikely.

So this is an unlikely attack. Nonetheless, administrators who have been very sophisticated in their `DN` construction patterns might conceivably be impacted.

### Affected Versions

Fixed in nats-server 2.12.6 & 2.11.15

### Workarounds

Developers should review their CA issuing practices.
GitHub Security Advisory: GHSA-pwx7-fx9r-hr4h
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS Server: Incomplete Stripping of Nats-Request-Info Header Allows Identity Spoofing

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 offers a `Nats-Request-Info:` message header, providing information about a request.

### Problem Description

The NATS message header `Nats-Request-Info:` is supposed to be a guarantee of identity by the NATS server, but the stripping of this header from inbound messages was not fully effective.

An attacker with valid credentials for any regular client interface could thus spoof their identity to services which rely upon this header.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.
GitHub Security Advisory: GHSA-9983-vrx2-fg9c
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-285: Improper Authorization
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS JetStream has an authorization bypass through its Management API

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 persistent storage feature, JetStream, has a management API which has many features, amongst which are backup and restore.

### Problem Description

Users with JetStream admin API access to restore one stream could restore to other stream names, impacting data which should have been protected against them.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

If developers have configured users to have limited JetStream restore permissions, temporarily remove those permissions.
GitHub Security Advisory: GHSA-55h8-8g96-x4hj
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-287: Improper Authentication, CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS: Leafnode connections allow spoofing of Nats-Request-Info identity headers

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 allows hub/spoke topologies using "leafnode" connections by other nats-servers.  NATS messages can have headers.

### Problem Description

The nats-server offers a `Nats-Request-Info:` message header, providing information about a request.  This is supposed to provide enough information to allow for account/user identification, such that NATS clients could make their own decisions on how to trust a message, provided that they trust the nats-server as a broker.

A leafnode connecting to a nats-server is not fully trusted unless the system account is bridged too.  Thus identity claims should not have propagated unchecked.

Thus NATS clients relying upon the Nats-Request-Info: header could be spoofed.

Does not directly affect the nats-server itself, but the CVSS Confidentiality and Integrity scores are based upon what a hypothetical client might choose to do with this NATS header.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.
GitHub Security Advisory: GHSA-8r68-gvr4-jh7j
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS  is vulnerable to pre-auth DoS through WebSockets client service

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 offers a WebSockets client service, used in deployments where browsers are the NATS clients.

### Problem Description

A malicious client which can connect to the WebSockets port can cause unbounded memory use in the nats-server before authentication; this requires sending a corresponding amount of data.

This is a milder variant of [NATS-advisory-ID 2026-02](https://advisories.nats.io/CVE/secnote-2026-02.txt) (aka CVE-2026-27571; GHSA-qrvq-68c2-7grw).
That earlier issue was a compression bomb, this vulnerability is not. Attacks against this new issue thus require significant client bandwidth.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

Disable websockets if not required for project deployment.
GitHub Security Advisory: GHSA-vprv-35vv-q339
Package: github.com/nats-io/nats-server (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS has pre-auth server panic via leafnode handling

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 allows hub/spoke topologies using "leafnode" connections by other nats-servers.

### Problem Description

A client which can connect to the leafnode port can crash the nats-server with a certain malformed message pre-authentication.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

1. Disable leafnode support if not needed.
2. Restrict network connections to your leafnode port, if plausible without compromising the service offered.

### References

 * This document is canonically: <https://advisories.nats.io/CVE/secnote-2026-10.txt>
 * GHSA advisory: <https://github.com/nats-io/nats-server/security/advisories/GHSA-vprv-35vv-q339>
 * MITRE CVE entry: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-33218>
GitHub Security Advisory: GHSA-jxxm-27vp-c3m5
Package: github.com/nats-io/nats-server (GO)
Severity: HIGH (CVSS 7.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS allows MQTT clients to bypass ACL checks

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

When using ACLs on message subjects, these ACLs were not applied in the `$MQTT.>` namespace, allowing MQTT clients to bypass ACL checks for MQTT subjects.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

None.
GitHub Security Advisory: GHSA-v722-jcv5-w7mc
Package: github.com/nats-io/nats-server (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-256: Plaintext Storage of a Password
Vulnerable versions: > 0
Patched in: unpatched

Summary: NATS has MQTT plaintext password disclosure

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

For MQTT deployments using usercodes/passwords: MQTT passwords are incorrectly classified as a non-authenticating identity statement (JWT) and exposed via monitoring endpoints.

### Affected Versions

Any version before v2.12.6 or v2.11.15

### Workarounds

Ensure monitoring end-points are adequately secured.

Best practice remains to not expose the monitoring endpoint to the Internet or other untrusted network users.
GitHub Security Advisory: GHSA-52jh-2xxh-pwh6
Package: github.com/nats-io/nats-server (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: > 0
Patched in: unpatched

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-vchx-5pr6-ffx2
Package: github.com/flannel-io/flannel (GO)
Severity: HIGH (CVSS 7.5)
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: <= 0.28.1
Patched in: 0.28.2

Summary: Flannel has cross-node remote code execution via extension backend BackendData injection

Details:
### Background
The Flannel project includes an experimental Extension backend that allows users to easily prototype new backend types. This backend uses shell commands stored in Kubernetes annotations to configure network connectivity on the node.

Note: consumers are only affected by this vulnerability if they use the experimental Extension backend. Other backends such as vxlan and wireguard are unaffected.

### Vulnerability
This Extension backend is vulnerable to a command injection that allows an attacker who can set Kubernetes Node annotations to achieve root-level arbitrary command execution on every flannel node in the cluster.

The Extension backend's SubnetAddCommand and SubnetRemoveCommand receive attacker-controlled data via stdin (from the `flannel.alpha.coreos.com/backend-data` Node annotation). The content of this annotation is unmarshalled and piped directly to a shell command without checks.

### Impact
Kubernetes clusters using Flannel with the Extension backend are affected by this vulnerability. Other backends such as vxlan and wireguard are unaffected.

### Patches
This is fixed in version v0.28.2.

### Workaround 
If consumers cannot update to a patched version, then use Flannel with another backend such as vxlan or wireguard.

### Credits
Flannel would like to thank  Shachar Tal from Palo Alto Networks for reporting this vulnerability.
GitHub Security Advisory: GHSA-m2h6-4xpq-qw3m
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 4.81.1
Patched in: 4.81.1

Summary: A Fleet team maintainer can transfer hosts from any team via missing source team authorization

Details:
### Summary

A broken access control vulnerability in Fleet's host transfer API allows a team maintainer to transfer hosts from any team into their own team, bypassing team isolation boundaries. Once transferred, the attacker gains full control over the stolen hosts, including the ability to execute scripts with root privileges.

### Impact

The host transfer endpoints verify that the caller has write permission to the destination team but do not check whether the caller has any permission over the source team of the hosts being transferred.

Once hosts are transferred, the attacker's team MDM configuration is automatically applied to the stolen devices, and the attacker can execute scripts on them with root privileges. In multi-tenant Fleet deployments where teams represent business units, departments, or customers, this breaks all team isolation guarantees. A bulk transfer variant allows stealing all matching hosts fleet-wide in a single request.

Exploitation requires authentication as a team maintainer or team admin.

### Workarounds

There is no workaround for this issue short of upgrading to a patched version. Organizations concerned about exploitation should audit host transfer activity in their Fleet logs for any unexpected team reassignments.

### For more information

If there are any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @secfox-ai for responsibly reporting this issue.
GitHub Security Advisory: GHSA-x34h-54cw-9825
Package: github.com/nektos/act (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 0.2.85
Patched in: 0.2.86

Summary: act: actions/cache server allows malicious cache injection

Details:
act's built-in actions/cache server listens to connections on all interfaces and allows anyone who can connect to it — including someone anywhere on the internet — to create caches with arbitrary keys and retrieve all existing caches. If one can predict which cache keys will be used by local actions, one can create malicious caches containing whatever files one pleases, most likely allowing arbitrary remote code execution within the Docker container.

## Discovery

Discovered while discussing [forgejo/runner#294](https://code.forgejo.org/forgejo/runner/issues/294).

## Proposed Mitigation

It was discussed to append a secret to `ACTIONS_CACHE_URL` to retain compatibility with GitHub's cache action and still allow authorization. Forgejo is considering also encoding which repo is currently being run in CI into the secret in the URL to prevent unrelated repos using the same (probably global) runner from seeing each other's caches.
GitHub Security Advisory: GHSA-99hj-44vg-hfcp
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.43.5-0[PII_REDACTED]2849-bbc1aef2987d
Patched in: 4.43.5-0[PII_REDACTED]2849-bbc1aef2987d

Summary: Fleet's unbounded request body read allows remote Denial of Service

Details:
### Summary

Fleet contained multiple unauthenticated HTTP endpoints that read request bodies without enforcing a size limit. An unauthenticated attacker could exploit this behavior by sending large or repeated HTTP payloads, causing excessive memory allocation and resulting in a denial-of-service (DoS) condition.

### Impact

An unauthenticated attacker could cause the Fleet server process to exhaust available memory and restart by sending oversized or repeated HTTP requests to affected endpoints.

This vulnerability impacts **availability only**. There is:

- No exposure of sensitive data
- No authentication bypass
- No privilege escalation
- No integrity impact

### Workarounds

If upgrading immediately is not possible, the following mitigations can reduce exposure:

- Apply request body size limits at a reverse proxy or load balancer (e.g., NGINX, Envoy).
- Restrict network access to endpoints to known IP ranges where feasible.
- Monitor memory usage and restart frequency for abnormal patterns.

### For More Information

If there are any questions or concerns about this advisory, please contact us at:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)

### Credits

Fleet thanks @fuzzztf for responsibly reporting this issue.
GitHub Security Advisory: GHSA-3458-r943-hmx4
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 4.43.5-0[PII_REDACTED]2849-bbc1aef2987d
Patched in: 4.43.5-0[PII_REDACTED]2849-bbc1aef2987d

Summary: Fleet: Password reset tokens remain valid after password change for 24 hours

Details:
### Summary

A vulnerability in Fleet’s password management logic could allow previously issued password reset tokens to remain valid after a user changes their password. As a result, a stale password reset token could be reused to reset the account password even after a defensive password change.

### Impact

If an attacker had prior access to a valid password reset token, they could reuse that token within its validity window to reset the user’s password after the user has already changed it. This could result in temporary account takeover.

Exploitation requires prior compromise of a password reset token and is further constrained by the token’s 24-hour expiration period. The issue does not allow discovery of reset tokens, does not bypass authentication on its own, and does not affect accounts without an existing valid reset token.

### Workarounds

Until patched, users who believe a password reset token may have been exposed should wait for the token to expire before reusing the account, or contact a Fleet administrator to invalidate active sessions.

### For more information

If there are any questions or comments about this advisory:

Email Fleet at [security@fleetdm.com](mailto:security@fleetdm.com)  
Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)

### Credits

Fleet thanks @fuzzztf for responsibly reporting this issue.
GitHub Security Advisory: GHSA-x744-4wpc-v9h2
Package: github.com/moby/moby/v2 (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel, CWE-863: Incorrect Authorization
Vulnerable versions: < 2.0.0-beta.8
Patched in: 2.0.0-beta.8

Summary: Moby has AuthZ plugin bypass when provided oversized request bodies

Details:
## Summary

A security vulnerability has been detected that allows attackers to bypass [authorization plugins (AuthZ)](https://docs.docker.com/engine/extend/plugins_authorization/) under specific circumstances. The base likelihood of this being exploited is low.

This is an incomplete fix for [CVE-2024-41110](https://github.com/moby/moby/security/advisories/GHSA-v23v-6jw2-98fq).

## Impact

**If you don't use AuthZ plugins, you are not affected.**

Using a specially-crafted API request, an attacker could make the Docker daemon forward the request to an authorization plugin without the body. The authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

Anyone who depends on authorization plugins that introspect the request body to make access control decisions is potentially impacted.

## Workarounds

If unable to update immediately:
- Avoid using AuthZ plugins that rely on request body inspection for security decisions.
- Restrict access to the Docker API to trusted parties, following the principle of least privilege.

## Credits

- 1seal / Oleh Konko ([@1seal](https://github.com/1seal))
- Cody (c@wormhole.guru)
- Asim Viladi Oglu Manizada (@manizada)

## Resources

- [CVE-2024-41110 / GHSA-v23v-6jw2-98fq](https://github.com/moby/moby/security/advisories/GHSA-v23v-6jw2-98fq)