deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-m3c2-496v-cw3v
Package: github.com/gofiber/fiber/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 3.0.0
Patched in: 3.1.0

Summary: Fiber has an Arbitrary File Read in Static Middleware on Windows

Details:
### Summary

**Description**
A Path Traversal (CWE-22) vulnerability in Fiber allows a remote attacker to bypass the static middleware sanitizer and read arbitrary files on the server file system on Windows. This affects Fiber v3 through version 3.0.0. This has been patched in Fiber v3 version 3.1.0.
 
### Details
The vulnerability resides in `middleware/static/static.go` within the `sanitizePath` function. This function attempts to sanitize the requested path by checking for backslashes, decoding the URL, and then cleaning the path.

The vulnerability stems from two combined issues:
- The check for backslash characters happens before the URL decoding loop. If an attacker sends a double-encoded backslash, the initial check sees `%255C` and passes. The loop then decodes this into a single backslash.
- The function uses `path.Clean` to clean the resulting string. `path.Clean` is designed for slash-separated paths  and does not recognize backslashes as directory separators. Consequently, sequences like `..\..\` are treated as valid filenames.

When this sanitized path is later used, the backslashes are interpreted as valid separators, allowing the attacker to traverse up the directory tree.
```go
// pkg/static/static.go
func sanitizePath(p []byte, filesystem fs.FS) ([]byte, error) {
    ...
    // this check happens BEFORE decoding
    if bytes.IndexByte(p, '\\') >= 0 {
        ...
    } 
    // This loop decodes %255C to %5C to \
    for strings.IndexByte(s, '%') >= 0 {
        us, err := url.PathUnescape(s)
        ...
        s = us
    }
    // path.Clean only understands forward slashes (/)
    s = pathpkg.Clean("/" + s)
    ...
    return utils.UnsafeBytes(s), nil
}
```

### Impact

This impacts Fiber v3 prereleases through stable release version 3.0.0.

Successful exploitation requires the server to be using the static middleware on Windows, as this is the only OS where backslashes are treated as directory separators by the file system.

Exploitation allows directory traversal on the host server. An attacker can read arbitrary files within the scope of the application server context. Depending on permissions and deployment conditions, attackers may access sensitive files outside the web root, such as configuration files, source code, or system files. Leaking application secrets often leads to further compromise.

### Patches

This has been [patched](https://github.com/gofiber/fiber/pull/4064) in Fiber v3 version 3.1.0.  Users are strongly encouraged to update to the latest available release.
GitHub Security Advisory: GHSA-879p-475x-rqh2
Package: github.com/caddyserver/caddy/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 2.11.1
Patched in: 2.11.1

Summary: Caddy is vulnerable to cross-origin config application via local admin API /load 

Details:
commit: e0f8d9b2047af417d8faf354b675941f3dac9891 (as-of 2026-02-04)
channel: GitHub security advisory (per SECURITY.md)

## summary

The local caddy admin API (default listen `127.0.0.1:2019`) exposes a state-changing `POST /load` endpoint that replaces the entire running configuration.

When origin enforcement is not enabled (`enforce_origin` not configured), the admin endpoint accepts cross-origin requests (e.g., from attacker-controlled web content in a victim browser) and applies an attacker-supplied JSON config. this can change the admin listener settings and alter HTTP server behavior without user intent.

## Severity

Medium

Justification:
- The attacker can apply an arbitrary caddy config (integrity impact) by driving a victim’s local admin API.
- Exploitation requires a victim running caddy with the admin API enabled and visiting an attacker-controlled page (or otherwise issuing the request from an untrusted local client).

## Affected component

- `caddyconfig/load.go: adminLoad.handleLoad` (`/load` admin endpoint)
- Pinned callsite: https://github.com/caddyserver/caddy/blob/e0f8d9b2047af417d8faf354b675941f3dac9891/caddyconfig/load.go#L73

## Reproduction

Attachment: `poc.zip` (integration harness) with canonical and control runs.

```bash
unzip -q -o poc.zip -d poc
cd poc/poc-F-CADDY-ADMIN-LOAD-001
make test
```

Expected output (excerpt):

```
[CALLSITE_HIT]: adminLoad.handleLoad
[PROOF_MARKER]: http_code=200 admin_moved=true response_pwned=true
```

Control output (excerpt):

```
[NC_MARKER]: http_code=403 load_blocked=true admin_moved=false response_pwned=false
```

## Impact

An attacker can replace the running caddy configuration via the local admin API. Depending on the deployed configuration/modules, this can:
- Change admin listener settings (e.g., move the admin listener to a new address)
- Change HTTP server behavior (e.g., alter routes/responses)

## Suggested remediation

Ensure cross-origin web content cannot trigger `POST /load` on the local admin API by default, for example by:
- Enabling origin enforcement by default for unsafe methods, and/or
- Requiring an unguessable token for `/load` (and other state-changing admin endpoints).

[poc.zip](https://github.com/user-attachments/files/25079818/poc.zip)
[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079820/PR_DESCRIPTION.md)
GitHub Security Advisory: GHSA-qrvq-68c2-7grw
Package: github.com/nats-io/nats-server (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification), CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.4.1
Patched in: unpatched

Summary: nats-server websockets are vulnerable to pre-auth memory DoS

Details:
### Impact

The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression.  The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.

An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.

The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.

The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.

### Patches

This was released in nats-server without being highlighted as a security issue.  It should have been, this was an oversight.  Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.

This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.

### Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.

### References

This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).
GitHub Security Advisory: GHSA-qrvq-68c2-7grw
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification), CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.12.0-RC.1, < 2.12.3
Patched in: 2.12.3

Summary: nats-server websockets are vulnerable to pre-auth memory DoS

Details:
### Impact

The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression.  The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.

An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.

The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.

The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.

### Patches

This was released in nats-server without being highlighted as a security issue.  It should have been, this was an oversight.  Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.

This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.

### Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.

### References

This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).
GitHub Security Advisory: GHSA-qrvq-68c2-7grw
Package: github.com/nats-io/nats-server/v2 (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification), CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.11.12
Patched in: 2.11.12

Summary: nats-server websockets are vulnerable to pre-auth memory DoS

Details:
### Impact

The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression.  The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.

An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.

The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.

The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.

### Patches

This was released in nats-server without being highlighted as a security issue.  It should have been, this was an oversight.  Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.

This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.

### Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.

### References

This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).
GitHub Security Advisory: GHSA-gv8r-9rw9-9697
Package: github.com/traefik/traefik/v3 (GO)
Severity: HIGH (CVSS 10.0)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 3.6.7
Patched in: 3.6.8

Summary: Traefik affected by TLS ClientAuth Bypass on HTTP/3

Details:
### Summary

There is a potential vulnerability in Traefik managing HTTP/3 connections.

More details in the [CVE-2025-68121](https://nvd.nist.gov/vuln/detail/CVE-2025-68121).

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.37
- https://github.com/traefik/traefik/releases/tag/v3.6.8

## Workarounds

No workaround

## For more information

If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).
GitHub Security Advisory: GHSA-gv8r-9rw9-9697
Package: github.com/traefik/traefik/v2 (GO)
Severity: HIGH (CVSS 10.0)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 2.11.36
Patched in: 2.11.37

Summary: Traefik affected by TLS ClientAuth Bypass on HTTP/3

Details:
### Summary

There is a potential vulnerability in Traefik managing HTTP/3 connections.

More details in the [CVE-2025-68121](https://nvd.nist.gov/vuln/detail/CVE-2025-68121).

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.37
- https://github.com/traefik/traefik/releases/tag/v3.6.8

## Workarounds

No workaround

## For more information

If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).
GitHub Security Advisory: GHSA-gv8r-9rw9-9697
Package: github.com/traefik/traefik (GO)
Severity: HIGH (CVSS 10.0)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 1.7.34
Patched in: unpatched

Summary: Traefik affected by TLS ClientAuth Bypass on HTTP/3

Details:
### Summary

There is a potential vulnerability in Traefik managing HTTP/3 connections.

More details in the [CVE-2025-68121](https://nvd.nist.gov/vuln/detail/CVE-2025-68121).

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.37
- https://github.com/traefik/traefik/releases/tag/v3.6.8

## Workarounds

No workaround

## For more information

If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).
GitHub Security Advisory: GHSA-wfqv-66vq-46rm
Package: github.com/sigstore/cosign (GO)
Severity: LOW (CVSS 3.7)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 3.0.4
Patched in: 3.0.5

Summary: Cosign considered signatures valid with expired intermediate certificates when transparency log verification is skipped

Details:
## Summary

When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.

## Impact

No impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.

## Workarounds

Upgrade to the latest release, or verify the certificate chain out of band.

## Example to Reproduce

* Root CA certificate is valid from 12pm-2pm
* Intermediate CA certificate is valid from 12:30pm-1:30pm
* Leaf certificate is valid from 1pm-3pm - **Note that this is unlikely to happen in practice**, as a CA shouldn't issue a certificate that would be valid after the issuing CA certificate expires
* Signature generated at 2:30pm with a signed timestamp
* During verification, the leaf certificate's not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates
* The timestamp's time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf
* Even though the root and intermediate would be expired at 2:30pm, verification succeeds
GitHub Security Advisory: GHSA-j9wf-6r2x-hqmx
Package: github.com/centrifugal/centrifugo/v6 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 6.6.1
Patched in: 6.6.1

Summary: Centrifugo v6.6.0 dependency vulnerabilities

Details:
### Summary                                                                                                                                                                                              
                                                                                                                                                                                                           
  Centrifugo v6.6.0 binary is compiled with **Go 1.25.5** and                                                                                                                       
  statically links `github.com/quic-go/webtransport-go v0.9.0`, having **7 known                                                                                                                      
  CVEs**

  **Go standard library — compiled with Go 1.25.5:**

  | CVE | Severity | CVSS | Fixed In |
  |-----|----------|------|----------|
  | CVE-2025-68121 | **CRITICAL** | 10.0 | Go 1.25.7, 1.24.13 |
  | CVE-2025-61726 | HIGH | 7.5 | Go 1.25.6, 1.24.12 |
  | CVE-2025-61728 | MEDIUM | 6.5 | Go 1.25.6, 1.24.12 |
  | CVE-2025-61730 | MEDIUM | 5.3 | Go 1.25.6, 1.24.12 |

  **Direct dependency `github.com/quic-go/webtransport-go` — pinned at v0.9.0
  (`go.mod` line 34):**

  | CVE | Severity | CVSS | Fixed In |
  |-----|----------|------|----------|
  | CVE-2026-21434 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
  | CVE-2026-21435 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
  | CVE-2026-21438 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
GitHub Security Advisory: GHSA-6qr9-g2xw-cw92
Package: github.com/dagu-org/dagu (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 1.30.3
Patched in: unpatched

Summary: Dagu affected by unauthenticated RCE via inline DAG spec in default configuration

Details:
### Summary
Dagu's default configuration ships with authentication disabled. The `POST /api/v2/dag-runs` endpoint accepts an inline YAML spec and executes its shell commands immediately with no credentials required — any dagu instance reachable over the network is fully compromised by default.

### Details
`internal/service/app/config/loader.go:226` sets `AuthModeNone` as the default. With no auth mode configured, `internal/frontend/api/v2/handlers/api.go:520` returns `nil` from `requireExecute()` — all permission checks pass without a valid session.

The `POST /api/v2/dag-runs` endpoint accepts a `spec` field containing a full YAML DAG definition. The spec is parsed and the commands execute immediately on the host with no validation beyond YAML parsing.

### PoC
```bash
curl -s -X POST http://TARGET:8080/api/v2/dag-runs \
  -H "Content-Type: application/json" \
  -d '{"name":"poc","spec":"steps:\n  - name: rce\n    command: id > /tmp/pwned\n"}'
# Response: {"dagRunId":"<uuid>"}
# /tmp/pwned contains: uid=1000(dagu) gid=1000(dagu)
```
Confirmed on `ghcr.io/dagu-org/dagu:latest` with no configuration changes.

### Impact
Every dagu deployment using default settings — every Docker deployment, every install following the documentation, every instance without explicit `DAGU_AUTH_MODE` configuration — is fully compromised without credentials. An attacker with network access gets OS command execution as the dagu process user.
GitHub Security Advisory: GHSA-cgjg-p2m2-qm4p
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 5.3.2-0[PII_REDACTED]0648-6404ab29acc0
Patched in: 5.3.2-0[PII_REDACTED]0648-6404ab29acc0

Summary: Mattermost fails to enforce invite permissions when updating team settings

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to enforce invite permissions when updating team settings, which allows team administrators without proper permissions to bypass restrictions and add users to their team via API requests. Mattermost Advisory ID: MMSA-2025-00561
GitHub Security Advisory: GHSA-cgjg-p2m2-qm4p
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 11.2.0, < 11.2.2
Patched in: unpatched

Summary: Mattermost fails to enforce invite permissions when updating team settings

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to enforce invite permissions when updating team settings, which allows team administrators without proper permissions to bypass restrictions and add users to their team via API requests. Mattermost Advisory ID: MMSA-2025-00561
GitHub Security Advisory: GHSA-cgjg-p2m2-qm4p
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 10.11.0, < 10.11.10
Patched in: unpatched

Summary: Mattermost fails to enforce invite permissions when updating team settings

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to enforce invite permissions when updating team settings, which allows team administrators without proper permissions to bypass restrictions and add users to their team via API requests. Mattermost Advisory ID: MMSA-2025-00561
GitHub Security Advisory: GHSA-cgjg-p2m2-qm4p
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 11.1.0, < 11.1.3
Patched in: unpatched

Summary: Mattermost fails to enforce invite permissions when updating team settings

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to enforce invite permissions when updating team settings, which allows team administrators without proper permissions to bypass restrictions and add users to their team via API requests. Mattermost Advisory ID: MMSA-2025-00561
GitHub Security Advisory: GHSA-cgjg-p2m2-qm4p
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 8.0.0[PII_REDACTED]0648-6404ab29acc0
Patched in: 8.0.0[PII_REDACTED]0648-6404ab29acc0

Summary: Mattermost fails to enforce invite permissions when updating team settings

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to enforce invite permissions when updating team settings, which allows team administrators without proper permissions to bypass restrictions and add users to their team via API requests. Mattermost Advisory ID: MMSA-2025-00561
GitHub Security Advisory: GHSA-5r23-prx4-mqg3
Package: github.com/cilium/cilium (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.18.0, < 1.18.5
Patched in: 1.18.6

Summary: Cilium may not enforce host firewall policies when Native Routing, WireGuard and Node Encryption are enabled

Details:
### Impact

[Host Policies](https://docs.cilium.io/en/stable/security/policy/language/#host-policies) will incorrectly permit traffic from Pods on other nodes when all of the following configurations are enabled:
* [Native Routing](https://docs.cilium.io/en/stable/network/concepts/routing/#native-routing)
* [WireGuard](https://docs.cilium.io/en/stable/security/policy/language/#host-policies)
* [Node Encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/#node-to-node-encryption-beta) (beta)

These options are disabled by default in Cilium.

### Patches

This issue was fixed by #42892.

This issue affects:

* Cilium v1.18 between v1.18.0 and v1.18.5 inclusive

This issue is fixed in:

* Cilium v1.18.6

### Workarounds

There is currently no officially verified or comprehensive workaround for this issue. The following procedure has been validated strictly within a local 'Kind' environment and has not undergone exhaustive testing across diverse production architectures. Proceed with caution.

To mitigate the identified traffic bypass, ensure all ingress traffic from the `cilium_wg0` interface is explicitly routed to `cilium_host` for policy enforcement. This ensures that host-level security policies are applied to decrypted WireGuard traffic. Execute the following configuration on each CiliumNode:

```bash
# IPv4 Traffic
ip rule add iif cilium_wg0 table 300
ip route add default dev cilium_host table 300

# IPv6 Traffic
ip -6 rule add iif cilium_wg0 table 300
ip -6 route add default dev cilium_net table 300
```

### Acknowledgements

Special thanks to @julianwiedmann for reporting the issue and helping with the resolution.

### For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.