deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-x744-4wpc-v9h2
Package: github.com/docker/docker (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel, CWE-863: Incorrect Authorization
Vulnerable versions: < 29.3.1
Patched in: unpatched

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)
GitHub Security Advisory: GHSA-x744-4wpc-v9h2
Package: github.com/moby/moby (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel, CWE-863: Incorrect Authorization
Vulnerable versions: < 29.3.1
Patched in: unpatched

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)
GitHub Security Advisory: GHSA-pxq6-2prw-chj9
Package: github.com/moby/moby/v2 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: < 2.0.0-beta.8
Patched in: 2.0.0-beta.8

Summary: Moby has an Off-by-one error in its plugin privilege validation

Details:
## Summary

A security vulnerability has been detected that allows [plugins](https://docs.docker.com/engine/extend/legacy_plugins/) privilege validation to be bypassed during `docker plugin install`. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.

Plugins that request exactly one privilege are also affected, because no comparison is performed at all.

## Impact

**If plugins are not in use, there is no impact.**

When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.

Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.

Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.

**For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.**

## Workarounds

If unable to update immediately:
- Do not install plugins from untrusted sources
- Carefully review all privileges requested during `docker plugin install`
- Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
- Avoid relying on plugin privilege approval as the only control boundary for sensitive environments

## Credits

- Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)
GitHub Security Advisory: GHSA-pxq6-2prw-chj9
Package: github.com/moby/moby (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: < 29.3.1
Patched in: unpatched

Summary: Moby has an Off-by-one error in its plugin privilege validation

Details:
## Summary

A security vulnerability has been detected that allows [plugins](https://docs.docker.com/engine/extend/legacy_plugins/) privilege validation to be bypassed during `docker plugin install`. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.

Plugins that request exactly one privilege are also affected, because no comparison is performed at all.

## Impact

**If plugins are not in use, there is no impact.**

When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.

Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.

Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.

**For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.**

## Workarounds

If unable to update immediately:
- Do not install plugins from untrusted sources
- Carefully review all privileges requested during `docker plugin install`
- Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
- Avoid relying on plugin privilege approval as the only control boundary for sensitive environments

## Credits

- Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)
GitHub Security Advisory: GHSA-pxq6-2prw-chj9
Package: github.com/docker/docker (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: < 29.3.1
Patched in: unpatched

Summary: Moby has an Off-by-one error in its plugin privilege validation

Details:
## Summary

A security vulnerability has been detected that allows [plugins](https://docs.docker.com/engine/extend/legacy_plugins/) privilege validation to be bypassed during `docker plugin install`. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.

Plugins that request exactly one privilege are also affected, because no comparison is performed at all.

## Impact

**If plugins are not in use, there is no impact.**

When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.

Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.

Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.

**For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.**

## Workarounds

If unable to update immediately:
- Do not install plugins from untrusted sources
- Carefully review all privileges requested during `docker plugin install`
- Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
- Avoid relying on plugin privilege approval as the only control boundary for sensitive environments

## Credits

- Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)
GitHub Security Advisory: GHSA-4vq8-7jfc-9cvp
Package: github.com/docker/docker (GO)
Severity: LOW (CVSS 3.3)
CWE: CWE-909: Missing Initialization of Resource
Vulnerable versions: <= 25.0.12
Patched in: 25.0.13

Summary: Moby firewalld reload removes bridge network isolation

Details:
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as Docker, or Docker Engine.

Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.

### Impact

The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".

When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.

Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.

Containers running in networks created with `--internal` or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.

Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.

### Patches

Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.

### Workarounds
After reloading firewalld, either:
- Restart the docker daemon,
- Re-create bridge networks, or
- Use rootless mode.

### References
https://firewalld.org/
https://firewalld.org/documentation/howto/reload-firewalld.html
GitHub Security Advisory: GHSA-q4q8-7f2j-9h9f
Package: github.com/lxc/incus/v6 (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 6.23.0
Patched in: 6.23.0

Summary: Incus has an abitrary file write through its systemd-creds options

Details:
### Summary
Incus instances have an option to provide credentials to systemd in the guest. For containers, this is handled through a shared directory.
An attacker can use the name of a systemd credential to escape that directory and overwrite arbitrary files on the host system.

This can in turn be used to perform local privilege escalation or cause a DoS.

### Details
An attacker can set a configuration key named something like `systemd.credential.../../../../../../root/.bashrc` to cause Incus to write outside of the `credentials` directory associated with the container. This makes use of the fact that the Incus syntax for such credentials is `systemd.credential.XYZ` where `XYZ` can itself contain more periods.

While it's not possible to read any data this way, it's possible to write to arbitrary files as root, enabling both privilege escalation and denial of service attacks.

### Credit
This issue was discovered and reported by the team at [7asecurity](https://7asecurity.com/)
GitHub Security Advisory: GHSA-453r-g2pg-cxxq
Package: github.com/lxc/incus/v6/cmd/incus (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 6.23.0
Patched in: 6.23.0

Summary: Local Incus UI web server vulnerable to nuthentication bypass

Details:
### Summary
The web server spawned by `incus webui` incorrectly validates the authentication token such that an invalid value will be accepted.

### Details
`incus webui` runs a local web server on a random localhost port. For authentication, it provides the user with a URL containing an authentication token. When accessed with that token, Incus creates a cookie persisting that token without needing to include it in subsequent HTTP requests.

While the Incus client correctly validates the value of the cookie, it does not correctly validate the token when passed int the URL.
This allows for an attacker able to locate and talk to the temporary web server on localhost to have as much access to Incus as the user who ran `incus webui`.

This can lead to privilege escalation by another local user or an access to the user's Incus instances and possibly system resources by a remote attack able to trick the local user into interacting with the Incus UI web server.

### Credit
This issue was discovered and reported by the team at [7asecurity](https://7asecurity.com/)
GitHub Security Advisory: GHSA-83xr-5xxr-mh92
Package: github.com/lxc/incus (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 0.7.0
Patched in: unpatched

Summary: Incus vulnerable to arbitrary file read and write through pongo templates

Details:
### Summary
Instance template files can be used to cause arbitrary read or writes as root on the host server.

### Details
Incus allows for pongo2 templates within instances which can be used at various times in the instance lifecycle to template files inside of the instance. This particular implementation of pongo2 within Incus allowed for file read/write but with the expectation that the pongo2 chroot feature would isolate all such access to the instance's filesystem.

This was allowed such that a template could theoretically read a file and then generate a new version of said file.

Unfortunately the chroot isolation mechanism is entirely skipped by pongo2 leading to easy access to the entire system's filesystem with root privileges.

### Credit
This issue was discovered and reported by the team at [7asecurity](https://7asecurity.com/)
GitHub Security Advisory: GHSA-83xr-5xxr-mh92
Package: github.com/lxc/incus/v6 (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 6.23.0
Patched in: 6.23.0

Summary: Incus vulnerable to arbitrary file read and write through pongo templates

Details:
### Summary
Instance template files can be used to cause arbitrary read or writes as root on the host server.

### Details
Incus allows for pongo2 templates within instances which can be used at various times in the instance lifecycle to template files inside of the instance. This particular implementation of pongo2 within Incus allowed for file read/write but with the expectation that the pongo2 chroot feature would isolate all such access to the instance's filesystem.

This was allowed such that a template could theoretically read a file and then generate a new version of said file.

Unfortunately the chroot isolation mechanism is entirely skipped by pongo2 leading to easy access to the entire system's filesystem with root privileges.

### Credit
This issue was discovered and reported by the team at [7asecurity](https://7asecurity.com/)
GitHub Security Advisory: GHSA-prh4-vhfh-24mj
Package: github.com/goharbor/harbor (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-312: Cleartext Storage of Sensitive Information, CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 2.14.0, < 2.14.3
Patched in: 2.14.3

Summary: Harbor: LDAP password and OIDC secret are not redacted in the audit log

Details:
### Impact
Harbor write configuration payload to audit log when configuration change, the ldap_search_password and oidc_client_secret will be logged in the audit log without redacted

### Patches
Harbor v2.15.0, v2.14.3, v2.13.5

### Workarounds
Disable audit log configure event in Harbor Web Console: Go to Administration -> Configuration -> Enable Audit Log Event Type -> Uncheck "Update Configuration" and click "Save" Button.
GitHub Security Advisory: GHSA-prh4-vhfh-24mj
Package: github.com/goharbor/harbor (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-312: Cleartext Storage of Sensitive Information, CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 2.13.0, < 2.13.5
Patched in: 2.13.5

Summary: Harbor: LDAP password and OIDC secret are not redacted in the audit log

Details:
### Impact
Harbor write configuration payload to audit log when configuration change, the ldap_search_password and oidc_client_secret will be logged in the audit log without redacted

### Patches
Harbor v2.15.0, v2.14.3, v2.13.5

### Workarounds
Disable audit log configure event in Harbor Web Console: Go to Administration -> Configuration -> Enable Audit Log Event Type -> Uncheck "Update Configuration" and click "Save" Button.
GitHub Security Advisory: GHSA-55q8-2gwx-29pc
Package: github.com/ellanetworks/core (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: Ella Core Panics during NAS Authentication Response/Failure with missing IEs

Details:
## Summary

Ella Core panics when processing Authentication Response and Authentication Failure NAS message missing IEs. 

## Impact

An attacker able to send crafted NAS messages to Ella Core can crash the process, causing service disruption for all connected subscribers. No authentication is required.

## Fix

Added IE presence verification to NAS message handling.
GitHub Security Advisory: GHSA-87j9-m7x6-hvw2
Package: github.com/ellanetworks/core (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: Ella Core has Privilege Escalation via Database Restore by NetworkManager role

Details:
## Summary

The NetworkManager role was granted backup and restore permission. The restore endpoint accepted any valid SQLite file without verifying its contents.

## Impact

A NetworkManager could replace the production database with a tampered copy to escalate to Admin, gaining access to user management, audit logs, debug endpoints, and operator identity configuration that the role was explicitly denied.

## Fix 

Backup and restore permissions have been removed from the NetworkManager role.
GitHub Security Advisory: GHSA-9h59-p45g-445h
Package: github.com/ellanetworks/core (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-833: Deadlock
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: Ella Core has a Denial of Service via SCTP connection cleanup deadlock 

Details:
## Summary

A deadlock in the AMF's SCTP notification handler causes the entire AMF control plane to hang until the process is restarted. 

## Impact

An attacker with access to the N2 interface can cause Ella Core to hang, resulting in a denial of service for all subscribers.

## Fix

Add deferred Radio cleanup in serveConn SCTP server so that every connection exit path removes the radio. Remove the stale-entry scan from SCTP Notification handling.
GitHub Security Advisory: GHSA-f2f3-9cx3-wcmf
Package: github.com/ellanetworks/core (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: Ella Core panics when processing a crafted NGAP LocationReport message

Details:
## Summary

Ella Core panics when processing a specially crafted NGAP LocationReport message.

## Impact

An attacker able to send crafted NGAP messages to Ella Core can crash the process, causing service disruption for all connected subscribers.

## Fix 

Add guards in NGAP Location Report handler.
GitHub Security Advisory: GHSA-g9ww-x58f-9g6m
Package: github.com/edgelesssys/contrast (GO)
Severity: HIGH (CVSS 8.4)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 1.18.0
Patched in: 1.18.0

Summary: Contrast BadAML injection allows arbitrary code execution

Details:
# BadAML

BadAML is an AML injection attack that exploits the ACPI interface and allows arbitrary code execution in a confidential VM. The attack was first published in 2024:

- <https://blackhat.com/eu-24/briefings/schedule/#aml-injection-attacks-on-confidential-vms-42723>
- <https://dl.acm.org/doi/pdf/10.1145/3[PII_REDACTED]123>

## Impact

An attacker with control over the host (which is assumed in the attacker model of Contrast) can execute malicious AML code to gain arbitrary code execution within the confidential guest.

AML is byte code embedded in ACPI tables that are passed from the host (QEMU) to the guest firmware (OVMF), and then passed from OVMF to the Linux kernel. The Linux kernel has an interpreter that executes the AML code. An attacker can craft a table with malicious AML code and the kernel will execute it. AML is Turing-complete and the interpreter has access to the full guest memory, including private pages.

See the [paper](https://dl.acm.org/doi/pdf/10.1145/3[PII_REDACTED]123) for a detailed description and background of the attack.

Note that this is not a vulnerability specific to Contrast, but rather a generic vulnerability in Confidential Computing setups that use the ACPI interface.

## Affected platforms

This issue affects the SNP platforms supported by Contrast: `Metal-QEMU-SNP` and `Metal-QEMU-SNP-GPU`.
Users on these platforms should switch to the fixed Contrast version immediately.

`Metal-QEMU-TDX` isn't affected, as the content of the ACPI tables is covered by the runtime measurements (measured into RTMR 0 by OVMF) on Intel TDX.

## Patches

A sandbox similar to the one proposed in the paper has been implemented in the Linux kernel used by Contrast. The sandbox denies access to private memory pages by doing a page table lookup on every read/write by the AML interpreter.

This mitigates the attack completely: While an attacker can still run AML code, the code cannot read or modify private memory pages. Shared pages are readable/writable by the host hypervisor anyway.
GitHub Security Advisory: GHSA-cpj3-3r2f-xj59
Package: github.com/openbao/openbao (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: < 0.0.0[PII_REDACTED]3417-6e2b2dd84f0e
Patched in: 0.0.0[PII_REDACTED]3417-6e2b2dd84f0e

Summary: OpenBao has Reflected XSS in its OIDC authentication error message

Details:
### Impact

OpenBao installations that have an OIDC/JWT authentication method enabled and a role with `callback_mode=direct` configured are vulnerable to XSS via the  `error_description` parameter on the page for a failed authentication.

This allows an attacker access to the token used in the Web UI by a victim.

### Patches
The `error_description` parameter has been replaced with a static error message in v2.5.2

### Workarounds
The vulnerability can be mitigated by removing any roles with `callback_mode` set to `direct`.