deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-v895-833r-8c45
Package: github.com/fleetdm/fleet/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.81.0
Patched in: 4.81.0

Summary: Fleet's Apple MDM profile delivery has second-order SQL Injection that can compromise the database

Details:
### Summary

A critical second-order SQL Injection vulnerability in Fleet's Apple MDM profile delivery pipeline could allow an attacker with a valid MDM enrollment certificate to exfiltrate or modify the contents of the Fleet database, including user credentials, API tokens, and device enrollment secrets.

### Impact

If Apple MDM is enabled, an attacker controlling an enrolled device can send a malicious UDID during the MDM Authenticate check-in. The UDID is stored safely via parameterized queries, but is later interpolated directly into SQL when the async worker processes the job. This enables blind, boolean-based, and UNION-based SQL injection across four simultaneous subqueries.

Because Fleet's database driver is configured with `multiStatements=true`, the attacker can also execute stacked queries, enabling arbitrary writes to the database. This includes inserting new admin accounts, modifying configuration, deploying malicious profiles or scripts to managed devices, and deleting data.

Exploitation requires a valid SCEP-issued enrollment certificate (mTLS), but any enrolled device, including attacker-controlled devices, can exploit this vulnerability.

This issue does not affect instances where Apple MDM is disabled.

### Workarounds

If an immediate upgrade is not possible, affected Fleet users should temporarily disable Apple MDM.

### For more information

If there are any questions or comments about this advisory:

Send an email to [security@fleetdm.com](mailto:security@fleetdm.com)

Join #fleet in [[osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)](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-jhf3-xxhw-2wpp
Package: github.com/go-git/go-git/v5 (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-191: Integer Underflow (Wrap or Wraparound), CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.0.0, <= 5.17.0
Patched in: 5.17.1

Summary: go-git: Maliciously crafted idx file can cause asymmetric memory consumption

Details:
### Impact

A vulnerability has been identified in which a maliciously crafted `.idx` file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a Denial of Service (DoS) condition.

Exploitation requires write access to the local repository's `.git` directory, it order to create or alter existing `.idx` files. 

### Patches

Users should upgrade to `v5.17.1`, or the latest `v6` [pseudo-version](https://go.dev/ref/mod#pseudo-versions), in order to mitigate this vulnerability.

### Credit

The go-git maintainers thank @kq5y for finding and reporting this issue privately to the `go-git` project.
GitHub Security Advisory: GHSA-x2f5-332j-9xwq
Package: github.com/docker/model-runner (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.1.25
Patched in: 1.1.25

Summary: Docker Model Runner OCI Registry Client Vulnerable to Server-Side Request Forgery (SSRF)

Details:
## Summary
Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's `WWW-Authenticate` header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., `http://127.0.0.1:3000/`), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the caller. Additionally, the token exchange mechanism can relay data from internal services back to the attacker-controlled registry via the `Authorization: Bearer` header.

## Patches
Fixed in Docker Model Runner v1.1.25
Docker Desktop users should update to 4.67.0 or later, which includes the fixed Model Runner.

## Workarounds
For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.

## Impact
An unprivileged container or a malicious OCI registry that the user performed a pull from might issue GET requests to host-local services (localhost, internal network)
GitHub Security Advisory: GHSA-gm2x-2g9h-ccm8
Package: github.com/go-git/go-git/v5 (GO)
Severity: LOW (CVSS 2.8)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: <= 5.17.0
Patched in: 5.17.1

Summary: go-git missing validation decoding Index v4 files leads to panic

Details:
### Impact

`go-git`’s index decoder for format version 4 fails to validate the path name prefix length before applying it to the previously decoded path name. A maliciously crafted index file can trigger an out-of-bounds slice operation, resulting in a runtime panic during normal index parsing.

This issue only affects Git index format version 4. Earlier formats (`go-git` supports only `v2` and `v3`) are not vulnerable to this issue.

An attacker able to supply a crafted `.git/index` file can cause applications using go-git to panic while reading the index. If the application does not recover from panics, this results in process termination, leading to a denial-of-service (DoS) condition.

Exploitation requires the ability to modify or inject a Git index file within the local repository in disk. This typically implies write access to the `.git` directory.

### Patches

Users should upgrade to `v5.17.1`, or the latest `v6` [pseudo-version](https://go.dev/ref/mod#pseudo-versions), in order to mitigate this vulnerability.

### Credit

go-git maintainers thank @kq5y for finding and reporting this issue privately to the `go-git` project.
GitHub Security Advisory: GHSA-cp8r-8jvw-v3qg
Package: github.com/0xJacky/Nginx-UI (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 1.99
Patched in: unpatched

Summary: nginx-ui Vulnerable to DoS via Negative Integer Input in Logrotate Interval

Details:
### Summary
An input validation vulnerability in the logrotate configuration allows an authenticated user to cause a complete Denial of Service (DoS). By submitting a negative integer for the rotation interval, the backend enters an infinite loop or an invalid state, rendering the web interface unresponsive.

### Details
The vulnerability exists in the handler for the POST /api/settings endpoint. Specifically, the logrotate.interval field is accepted as a signed integer without lower-bound verification. When a negative value is processed by the backend logic responsible for scheduling or calculating the next rotation, it triggers a non-terminating loop. This consumes CPU resources and prevents the Go web server from handling further concurrent requests.

**Environment:**
- OS: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)
- nginx-ui version: 2.3.3 (513) e5da6dd (go1.26.0 linux/amd64)
- Deployment: Docker container
- Run Command: 
```
docker run -dit \
  --name=nginx-ui \
  --restart=always \
  -v /mnt/user4/appdata/nginx:/etc/nginx \
  -v /mnt/user4/appdata/nginx-ui:/etc/nginx-ui \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 8080:80 -p 8443:443 \
  uozi/nginx-ui:latest
```

### PoC
1. Authenticate to the nginx-ui dashboard.
2. Send a POST request to /api/settings (using Burp Suite, Postman, or curl).
3. Set the payload as follows:
```
.
.
.
{
  "logrotate": {
    "enabled": true,
    "cmd": "logrotate /etc/logrotate.d/nginx",
    "interval": -1
  }
}
.
.
.
```
4. Observe that the web server stops responding to all subsequent requests immediately after the injection.
<img width="1041" height="390" alt="image" src="https://github.com/user-attachments/assets/b746a91a-dd63-4f5e-b1a8-382b9d08e181" />

### Impact
This is a High-availability vulnerability (CWE-20: Improper Input Validation). Any authenticated user with access to settings can permanently hang the service.

A patched version of nginx-ui  is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.
GitHub Security Advisory: GHSA-jjwv-57xh-xr6r
Package: github.com/gotenberg/gotenberg/v8 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 8.29.0
Patched in: 8.29.0

Summary: Gotenberg has Chromium deny-list bypass via case-insensitive URL scheme (bypass of GHSA-rh2x-ccvw-q7r3)

Details:
### Impact

The fix introduced in version 8.1.0 for GHSA-rh2x-ccvw-q7r3 (CVE-2024-21527) can be bypassed using mixed-case or uppercase URL schemes.

The default `--chromium-deny-list` value is `^file:(?!//\/tmp/).*`. This regex is anchored to lowercase `file:` at the start. However, per RFC 3986 Section 3.1, URI schemes are case-insensitive. Chromium normalizes the scheme to lowercase before navigation, so a URL like `FILE:///etc/passwd` or `File:///etc/passwd` bypasses the deny-list check but still gets resolved by Chromium as `file:///etc/passwd`.

The root cause is in `pkg/gotenberg/filter.go` — the `FilterDeadline` function compiles the deny-list regex with `regexp2.MustCompile(denied.String(), 0)`, where `0` means no flags (case-sensitive). Since the regex pattern itself doesn't include a `(?i)` flag, matching is strictly case-sensitive.

This affects both the URL endpoint and HTML conversion (via iframes, link tags, etc.).

### Steps to Reproduce

1. Start Gotenberg with default settings:

```bash
docker run --rm -p 3000:3000 gotenberg/gotenberg:8.26.0 gotenberg
```

2. Read `/etc/passwd` via the URL endpoint using an uppercase scheme:

```bash
curl -X POST 'http://localhost:3000/forms/chromium/convert/url' \
  --form 'url=FILE:///etc/passwd' -o output.pdf
```

3. Open `output.pdf` — it contains the contents of `/etc/passwd`.

4. Alternatively, create an `index.html`:

```html
<iframe src="FILE:///etc/passwd" width="100%" height="100%"></iframe>
```

Then convert it:

```bash
curl -X POST 'http://localhost:3000/forms/chromium/convert/html' \
  -F 'files=@index.html' -o output.pdf
```

5. The resulting PDF contains `/etc/passwd` contents.

Mixed-case variants like `File:`, `fILE:`, `fiLE:` etc. all work as well.

### Root Cause

- `pkg/modules/chromium/chromium.go` defines the default deny-list as `^file:(?!//\/tmp/).*`
- `pkg/gotenberg/filter.go` compiles this with `regexp2.MustCompile(denied.String(), 0)` — flag `0` means case-sensitive
- `pkg/modules/chromium/events.go` uses `FilterDeadline` to check intercepted request URLs against the deny-list
- Chromium normalizes URL schemes to lowercase, so `FILE:///etc/passwd` becomes `file:///etc/passwd` after the deny-list check has already passed

### Suggested Fix

Change the default deny-list regex to use a case-insensitive flag:

```
(?i)^file:(?!//\/tmp/).*
```

Or apply case-insensitive matching in `FilterDeadline` when compiling the regex.

### Severity

This is effectively the same impact as CVE-2024-21527 — unauthenticated arbitrary file read from the Gotenberg container. An attacker can leak environment variables, configuration, credentials, and other sensitive data.
GitHub Security Advisory: GHSA-44p7-9xx4-hf2g
Package: golang.org/x/image (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.38.0
Patched in: 0.38.0

Summary: Go Images vulnerable to an out-of-memory error via a crafted TIFF file

Details:
A maliciously crafted TIFF file can cause image decoding to attempt to allocate up 4GiB of memory, causing either excessive resource consumption or an out-of-memory error.
GitHub Security Advisory: GHSA-5353-f8fq-65vc
Package: github.com/QuantumNous/new-api (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 0.10.0, <= 0.11.9-alpha.1
Patched in: unpatched

Summary: New API has passkey-based secure step-up verification bypass for root-only channel secret disclosure

Details:
## Summary

A logic flaw in the universal secure verification flow allows an authenticated user with a registered passkey to satisfy secure verification without completing a WebAuthn assertion.

## Affected versions

>= v0.10.0

## Description

The `POST /api/verify` endpoint supports multiple secure verification methods, including passkeys. When the request body contains `{"method":"passkey"}`, the server only checks whether the authenticated account has a passkey record on file and then marks the secure verification session as complete. It does not verify that the requester successfully completed a WebAuthn assertion.

As a result, an authenticated user who already has a valid session and a registered passkey can satisfy the secure verification requirement without performing the intended passkey challenge/response flow.

## Impact

In the upstream project, this issue affects actions protected by `SecureVerificationRequired()`. At the time of publication, the confirmed upstream impact is the root-only `POST /api/channel/:id/key` endpoint, which returns stored channel secrets.

Successful exploitation requires:
- an already authenticated session for the target account, and
- a registered passkey on that account.

No full login bypass or cross-account privilege escalation has been confirmed in the upstream codebase. However, the issue defeats the intended step-up verification control for affected privileged actions.

## Workarounds

Until a patched release is applied:
- do not rely on passkey as the step-up method for privileged secure-verification actions;
- require TOTP/2FA for those actions where operationally possible; or
- temporarily restrict access to affected secure-verification-protected endpoints.
GitHub Security Advisory: GHSA-56mx-8g9f-5crf
Package: github.com/lxc/incus/v6 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 6.18.0
Patched in: 6.19.0

Summary: Incus vulnerable to local privilege escalation through custom storage volumes

Details:
### Impact
This affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user.

The most common case for this would be systems using `incus-user` with the less privileged `incus` group to provide unprivileged users with an isolated restricted access to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges.

### Patches
A patch for this issue is available here: https://github.com/lxc/incus/pull/2642

The first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools.

### Workarounds
Permissions can be manually restricted until a patched version of Incus is deployed.

This is done with:

```
chmod 0700 /var/lib/incus/storage-pools/*/*
chmod 0711 /var/lib/incus/storage-pools/*/buckets*
chmod 0711 /var/lib/incus/storage-pools/*/container*
```

Those are the same permissions which will be applied by the patched Incus for both new and existing storage pools.

### References
This was reported publicly on Github by here: https://github.com/lxc/incus/issues/2641
GitHub Security Advisory: GHSA-46wh-3698-f2cx
Package: github.com/traefik/traefik/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: >= 3.7.0-ea.1, < 3.7.0-ea.3
Patched in: 3.7.0-ea.3

Summary: Traefik: Deny Rule Bypass via Unauthenticated Malicious gRPC Requests in gRPC-Go Dependency (CVE-2026-33186)

Details:
## Summary

There is a potential vulnerability in Traefik due to its dependency on an affected version of gRPC-Go (CVE-2026-33186).

A remote, unauthenticated attacker can send gRPC requests with a malformed HTTP/2 `:path` pseudo-header omitting the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server routes such requests correctly, path-based authorization interceptors evaluate the raw non-canonical path and fail to match "deny" rules, allowing the request to bypass the policy entirely if a fallback "allow" rule is present.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.42
- https://github.com/traefik/traefik/releases/tag/v3.6.12
- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3

## For more information

If there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

<details>
<summary>Original Description</summary>

### Summary
This CVE hits traefik until Version 3.6.11 and 2.11.41.
gRPC-Go has an authorization bypass via missing leading slash in :path
### Details
As described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3
### PoC
Update library version in 
https://github.com/traefik/traefik/blob/67c64ed9b25fbb90f1086977a62827133a7aa01b/go.mod#L108
### Impact
Is described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3

</details>


----------
GitHub Security Advisory: GHSA-46wh-3698-f2cx
Package: github.com/traefik/traefik/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: >= 3.0.0-beta3, < 3.6.12
Patched in: 3.6.12

Summary: Traefik: Deny Rule Bypass via Unauthenticated Malicious gRPC Requests in gRPC-Go Dependency (CVE-2026-33186)

Details:
## Summary

There is a potential vulnerability in Traefik due to its dependency on an affected version of gRPC-Go (CVE-2026-33186).

A remote, unauthenticated attacker can send gRPC requests with a malformed HTTP/2 `:path` pseudo-header omitting the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server routes such requests correctly, path-based authorization interceptors evaluate the raw non-canonical path and fail to match "deny" rules, allowing the request to bypass the policy entirely if a fallback "allow" rule is present.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.42
- https://github.com/traefik/traefik/releases/tag/v3.6.12
- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3

## For more information

If there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

<details>
<summary>Original Description</summary>

### Summary
This CVE hits traefik until Version 3.6.11 and 2.11.41.
gRPC-Go has an authorization bypass via missing leading slash in :path
### Details
As described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3
### PoC
Update library version in 
https://github.com/traefik/traefik/blob/67c64ed9b25fbb90f1086977a62827133a7aa01b/go.mod#L108
### Impact
Is described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3

</details>


----------
GitHub Security Advisory: GHSA-46wh-3698-f2cx
Package: github.com/traefik/traefik/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 2.11.42
Patched in: 2.11.42

Summary: Traefik: Deny Rule Bypass via Unauthenticated Malicious gRPC Requests in gRPC-Go Dependency (CVE-2026-33186)

Details:
## Summary

There is a potential vulnerability in Traefik due to its dependency on an affected version of gRPC-Go (CVE-2026-33186).

A remote, unauthenticated attacker can send gRPC requests with a malformed HTTP/2 `:path` pseudo-header omitting the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server routes such requests correctly, path-based authorization interceptors evaluate the raw non-canonical path and fail to match "deny" rules, allowing the request to bypass the policy entirely if a fallback "allow" rule is present.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.42
- https://github.com/traefik/traefik/releases/tag/v3.6.12
- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3

## For more information

If there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

<details>
<summary>Original Description</summary>

### Summary
This CVE hits traefik until Version 3.6.11 and 2.11.41.
gRPC-Go has an authorization bypass via missing leading slash in :path
### Details
As described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3
### PoC
Update library version in 
https://github.com/traefik/traefik/blob/67c64ed9b25fbb90f1086977a62827133a7aa01b/go.mod#L108
### Impact
Is described in https://github.com/advisories/GHSA-p77j-4mvh-x3m3

</details>


----------
GitHub Security Advisory: GHSA-65xw-vw82-r86x
Package: github.com/antchfx/xpath (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 1.3.6
Patched in: 1.3.6

Summary: XPath: Boolean expression infinite loop leads to denial of service via CPU exhaustion

Details:
Boolean expressions that evaluate to true can cause an infinite loop in logicalQuery.Select, leading to 100% CPU usage. This can be triggered by top-level selectors such as "1=1" or "true()".