deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mh4x-rmrx-3hp4
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 10.11.0-rc1, < 10.11.13
Patched in: 10.11.13

Summary: Mattermost has session spoofing due to lack of single-use consumption of guest magic link tokens enforcement

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to enforce atomic single-use consumption of guest magic link tokens, which allows an attacker with access to a valid magic link to establish multiple independent authenticated sessions via concurrent requests. Mattermost Advisory ID: MMSA-2026-00624.
GitHub Security Advisory: GHSA-mh4x-rmrx-3hp4
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 8.0.0[PII_REDACTED]2209-4952acea88ce, < 8.0.0[PII_REDACTED]2842-4cb8d8940332
Patched in: 8.0.0[PII_REDACTED]2842-4cb8d8940332

Summary: Mattermost has session spoofing due to lack of single-use consumption of guest magic link tokens enforcement

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to enforce atomic single-use consumption of guest magic link tokens, which allows an attacker with access to a valid magic link to establish multiple independent authenticated sessions via concurrent requests. Mattermost Advisory ID: MMSA-2026-00624.
GitHub Security Advisory: GHSA-qhmp-q7xh-99rh
Package: github.com/coredns/coredns (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-287: Improper Authentication, CWE-303: Incorrect Implementation of Authentication Algorithm
Vulnerable versions: < 1.14.3
Patched in: 1.14.3

Summary: CoreDNS has TSIG authentication bypass on DoT, DoH, DoH3, DoQ, and gRPC

Details:
### Summary
CoreDNS' tsig plugin can be bypassed on non-plain-DNS transports because it trusts the transport writer's TsigStatus() instead of performing verification itself. In the attached PoC, plain DNS/TCP correctly rejects an invalid TSIG (NOTAUTH), while the same invalid-TSIG request is accepted over DoT (tls://) and DoH (https://), allowing a client without the shared secret to satisfy require all. The same bug class affects DoH3, DoQ, and gRPC.

### Details
The tsig plugin decides whether an incoming TSIG was valid by consulting w.TsigStatus(): tsigStatus := w.TsigStatus(); if tsigStatus != nil { ... NOTAUTH ... } (plugin/tsig/tsig.go)

Two affected transports are shown directly in the PoC:
- DoH: DoHWriter.TsigStatus() always returns nil (core/dnsserver/https.go), and the HTTP server passes unpacked DNS messages directly into the plugin chain.
- DoT: the TLS server builds a dns.Server without setting TsigSecret (core/dnsserver/server_tls.go), unlike plain DNS/TCP/UDP which sets TsigSecret: s.tsigSecret (core/dnsserver/server.go).

The same transport-family bug pattern also appears on other transports:
- DoH3 reuses the DoH writer path (core/dnsserver/server_https3.go -> core/dnsserver/https.go), so it inherits the same TsigStatus() == nil behavior.
- DoQ uses DoQWriter.TsigStatus() error { return nil } (core/dnsserver/quic.go).
- gRPC uses gRPCresponse.TsigStatus() error { return nil } (core/dnsserver/server_grpc.go).

The attached PoC was kept deliberately small (baseline TCP+DoT+DoH only) for convenience.

### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
2. Run python3 ./tsig-repro.py
3. Expected output:
*** Start CoreDNS ***
Corefile: /tmp/vh-f001-tsig-doh-dot-bypass/Corefile
Log: /tmp/vh-f001-tsig-doh-dot-bypass/coredns.log

*** Baseline (plain TCP) ***
no_tsig rcode=5 (expected REFUSED=5)
invalid_tsig rcode=9 (expected NOTAUTH=9)

*** Candidate (DoT) ***
no_tsig rcode=5 (expected REFUSED=5)
invalid_tsig rcode=0 ancount=1 (expected NOERROR=0 and ancount>0)

*** Candidate (DoH) ***
no_tsig http=200 rcode=5 (expected REFUSED=5)
invalid_tsig http=200 rcode=0 ancount=1 (expected NOERROR=0 and ancount>0)

*** OK ***
TSIG bypass reproduced: plain TCP rejects invalid TSIG, while DoT and DoH accept it.
Results: /tmp/vh-f001-tsig-doh-dot-bypass/results.json


### Impact
Unauthenticated remote clients can bypass TSIG-based authentication/authorization on first-class encrypted transports, enabling access to whatever the deployment intended to restrict behind tsig { require all } (e.g., zone data/privileged queries, etc.).
GitHub Security Advisory: GHSA-h8mm-c463-wjq3
Package: github.com/coredns/coredns (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-862: Missing Authorization, CWE-863: Incorrect Authorization
Vulnerable versions: < 1.14.3
Patched in: 1.14.3

Summary: CoreDNS' transfer stanza selection uses lexicographic compare (subzone ACL bypass)

Details:
### Summary
CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.

### Details
In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison:
- zone := "" // longest zone match wins (plugin/transfer/transfer.go)
- if z > zone { zone = z; x = xfr } (plugin/transfer/transfer.go)

So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.

### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
2. Run python3 ./acl-repro.py
3. Expected output:
*** Baseline (only subzone transfer rule) ***
axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)

*** Candidate (add permissive parent transfer rule) ***
axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0)

*** OK ***
Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection.

### Impact
Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.
GitHub Security Advisory: GHSA-2wpx-qpw2-g5h5
Package: github.com/coredns/coredns (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.14.3
Patched in: 1.14.3

Summary: CoreDNS' DoQ worker pool does not bound stream backlog

Details:
### Summary
CoreDNS' DNS-over-QUIC (DoQ) server can be driven into large goroutine and memory growth by a remote client that opens many QUIC streams and stalls after sending only 1 byte. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill.

### Details
CoreDNS' DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool <- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go)

Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go)

This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token.

Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw).

### PoC
1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
2. Run python3 ./doq-dos-repro.py
3. Expected sample output:
*** Start CoreDNS ***
Corefile: /tmp/vh-f003-doq-mem-regression/Corefile
Log: /tmp/vh-f003-doq-mem-regression/coredns.log

*** Baseline sample (idle) ***
rss_kib=49380 go_goroutines=17

*** Build + run partial-stream flooder ***
go: downloading golang.org/x/net v0.43.0
go: downloading golang.org/x/crypto v0.41.0
go: downloading go.uber.org/mock v0.5.2
go: downloading github.com/stretchr/testify v1.11.1
go: downloading golang.org/x/sys v0.35.0
go: downloading github.com/pmezard/go-difflib v1.0.0
go: downloading github.com/davecgh/go-spew v1.1.1
go: downloading gopkg.in/yaml.v3 v3.0.1

*** Candidate sample (during attack) ***
rss_kib=137968 go_goroutines=15557

*** Flooder output ***
opened conns=60 streams_per_conn=256 total_streams=15360

*** Wrote results ***
/tmp/vh-f003-doq-mem-regression/results.json

*** OK ***
DoQ flood caused goroutine/RSS growth despite worker_pool_size.


### Impact
Unauthenticated remote DoS on an encrypted DNS transport via goroutine/RSS growth leading to OOM-kill/crash and service outage.
GitHub Security Advisory: GHSA-35hp-hqmv-8qg8
Package: github.com/gofiber/fiber/v3 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-436: Interpretation Conflict, CWE-524: Use of Cache Containing Sensitive Information
Vulnerable versions: <= 3.1.0
Patched in: 3.2.0

Summary: Fiber's cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters

Details:
### Summary
Fiber cache middleware's default key generator uses only `c.Path()` and does not include the query string.
As a result, requests like `/?id=1` and `/?id=2` can map to the same cache key and share the same cached response.

This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.

### Details
Default configuration in cache middleware:

- `KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }`

References:
- https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92
- https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621

The existing test demonstrates that when handler output depends on query parameter `id`, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.

### PoC
Minimal PoC:

```go
package main

import (
    "log"

    "github.com/gofiber/fiber/v3"
    "github.com/gofiber/fiber/v3/middleware/cache"
)

func main() {
    app := fiber.New()
    app.Use(cache.New()) // default config

    app.Get("/", func(c fiber.Ctx) error {
        return c.SendString(c.Query("id", "1"))
    })

    log.Fatal(app.Listen(":3000"))
}
```

Reproduction:

1. `GET /?id=1`
   - Cache miss
   - Response body: `1`
2. `GET /?id=2`
   - Cache hit
   - Response body: `1` (expected `2`)

Local verification command used:

```bash
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1
```

Observed result: test passes, confirming this is current behavior.

### Impact
- Responses that should vary by query parameters can be mixed between requests.
- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.

### Suggested remediation
- Change default cache key generation to include path + normalized query string (or canonicalized original URL).
- Keep ability for custom key generators.
- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
GitHub Security Advisory: GHSA-gj49-89wh-h4gj
Package: github.com/cilium/cilium (GO)
Severity: HIGH (CVSS 7.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: >= 1.19.0, < 1.19.3
Patched in: 1.19.3

Summary: Cillium exposes sensitive information included in the cilium-bugtool debug archive

Details:
### Impact
The output of `cilium-bugtool` can contain sensitive data when the tool is run against Cilium deployments with WireGuard encryption enabled.

Users of [WireGuard Transparent Encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/) are affected.
The sensitive data is  the WireGuard private key (`cilium_wg0.key`) used for node-to-node encrypted communication

`cilium-bugtool` is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster. It is also invoked when gathering sysdumps using the Cilium CLI's `cilium sysdump` command.

### Patches
This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.2 inclusive
- Cilium v1.18 between v1.18.0 and v1.18.8 inclusive
- All versions of Cilium prior to v1.17.15

This issue has been patched in:

- Cilium v1.19.3
- Cilium v1.18.9
- Cilium v1.17.15


### Workarounds
There is no workaround to this issue.

Users who have previously shared bugtool or sysdump archives from WireGuard-enabled nodes should rotate the WireGuard keys on the affected nodes. This can be done by deleting the key file and restarting the Cilium agent, which will generate a new key pair.

### Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Cillium extends special thanks to @kodareef5  for reporting the issue and  @tklauser for their work on triaging and remediating this issue.

### For more information

If there are any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/).

Cilium strongly encourages the reporting of suspected vulnerabilities to the security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and the report will be treated as top priority.
GitHub Security Advisory: GHSA-gj49-89wh-h4gj
Package: github.com/cilium/cilium (GO)
Severity: HIGH (CVSS 7.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: >= 1.18.0, < 1.18.9
Patched in: 1.18.9

Summary: Cillium exposes sensitive information included in the cilium-bugtool debug archive

Details:
### Impact
The output of `cilium-bugtool` can contain sensitive data when the tool is run against Cilium deployments with WireGuard encryption enabled.

Users of [WireGuard Transparent Encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/) are affected.
The sensitive data is  the WireGuard private key (`cilium_wg0.key`) used for node-to-node encrypted communication

`cilium-bugtool` is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster. It is also invoked when gathering sysdumps using the Cilium CLI's `cilium sysdump` command.

### Patches
This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.2 inclusive
- Cilium v1.18 between v1.18.0 and v1.18.8 inclusive
- All versions of Cilium prior to v1.17.15

This issue has been patched in:

- Cilium v1.19.3
- Cilium v1.18.9
- Cilium v1.17.15


### Workarounds
There is no workaround to this issue.

Users who have previously shared bugtool or sysdump archives from WireGuard-enabled nodes should rotate the WireGuard keys on the affected nodes. This can be done by deleting the key file and restarting the Cilium agent, which will generate a new key pair.

### Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Cillium extends special thanks to @kodareef5  for reporting the issue and  @tklauser for their work on triaging and remediating this issue.

### For more information

If there are any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/).

Cilium strongly encourages the reporting of suspected vulnerabilities to the security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and the report will be treated as top priority.
GitHub Security Advisory: GHSA-gj49-89wh-h4gj
Package: github.com/cilium/cilium (GO)
Severity: HIGH (CVSS 7.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: < 1.17.15
Patched in: 1.17.15

Summary: Cillium exposes sensitive information included in the cilium-bugtool debug archive

Details:
### Impact
The output of `cilium-bugtool` can contain sensitive data when the tool is run against Cilium deployments with WireGuard encryption enabled.

Users of [WireGuard Transparent Encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/) are affected.
The sensitive data is  the WireGuard private key (`cilium_wg0.key`) used for node-to-node encrypted communication

`cilium-bugtool` is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster. It is also invoked when gathering sysdumps using the Cilium CLI's `cilium sysdump` command.

### Patches
This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.2 inclusive
- Cilium v1.18 between v1.18.0 and v1.18.8 inclusive
- All versions of Cilium prior to v1.17.15

This issue has been patched in:

- Cilium v1.19.3
- Cilium v1.18.9
- Cilium v1.17.15


### Workarounds
There is no workaround to this issue.

Users who have previously shared bugtool or sysdump archives from WireGuard-enabled nodes should rotate the WireGuard keys on the affected nodes. This can be done by deleting the key file and restarting the Cilium agent, which will generate a new key pair.

### Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Cillium extends special thanks to @kodareef5  for reporting the issue and  @tklauser for their work on triaging and remediating this issue.

### For more information

If there are any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/).

Cilium strongly encourages the reporting of suspected vulnerabilities to the security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and the report will be treated as top priority.
GitHub Security Advisory: GHSA-74m3-9qvm-rp9h
Package: github.com/openziti/zrok/v2 (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: < 2.0.2
Patched in: 2.0.2

Summary: zrok: WebDAV drive backend follows symlinks outside DriveRoot, enabling host filesystem read/write

Details:
**Summary**
The zrok WebDAV drive backend (davServer.Dir) restricts path traversal through lexical normalization but does not prevent symlink following. When a symbolic link inside the shared DriveRoot points to a location outside that root, remote WebDAV consumers can read files and—on shares without OS-level permission restrictions—write or overwrite files anywhere on the host filesystem accessible to the zrok process.

- Attack Vector: Network — exploitation is performed entirely over the WebDAV endpoint; the attacker issues HTTP requests to the public zrok share URL.
- Attack Complexity: High — a precondition outside the attacker's direct control must hold: a symlink pointing outside DriveRoot must already exist within it (created locally, not via WebDAV).
- Privileges Required: None — zrok share public --backend-mode drive exposes the WebDAV endpoint with no authentication by default.
- User Interaction: None — once the symlink precondition is met, exploitation requires no user interaction.
- Scope: Changed — the vulnerability allows an attacker to escape the WebDAV root (the security boundary) and access the broader host filesystem.
- Confidentiality Impact: High — arbitrary files readable by the zrok process can be retrieved.
- Integrity Impact: High — the WebDAV PUT handler opens files with O_RDWR|O_CREATE|O_TRUNC, meaning symlink targets outside DriveRoot can be overwritten (e.g. ~/.ssh/authorized_keys).
- Availability Impact: None — no direct availability impact.

Affected Components

- drives/davServer/file.go — Dir.OpenFile (line 140), Dir.Stat (line 176), Dir.Mkdir (line 133), Dir.RemoveAll (line 151)
- endpoints/drive/backend.go — NewBackend (line 51–52)
GitHub Security Advisory: GHSA-74m3-9qvm-rp9h
Package: github.com/openziti/zrok (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 1.1.11
Patched in: unpatched

Summary: zrok: WebDAV drive backend follows symlinks outside DriveRoot, enabling host filesystem read/write

Details:
**Summary**
The zrok WebDAV drive backend (davServer.Dir) restricts path traversal through lexical normalization but does not prevent symlink following. When a symbolic link inside the shared DriveRoot points to a location outside that root, remote WebDAV consumers can read files and—on shares without OS-level permission restrictions—write or overwrite files anywhere on the host filesystem accessible to the zrok process.

- Attack Vector: Network — exploitation is performed entirely over the WebDAV endpoint; the attacker issues HTTP requests to the public zrok share URL.
- Attack Complexity: High — a precondition outside the attacker's direct control must hold: a symlink pointing outside DriveRoot must already exist within it (created locally, not via WebDAV).
- Privileges Required: None — zrok share public --backend-mode drive exposes the WebDAV endpoint with no authentication by default.
- User Interaction: None — once the symlink precondition is met, exploitation requires no user interaction.
- Scope: Changed — the vulnerability allows an attacker to escape the WebDAV root (the security boundary) and access the broader host filesystem.
- Confidentiality Impact: High — arbitrary files readable by the zrok process can be retrieved.
- Integrity Impact: High — the WebDAV PUT handler opens files with O_RDWR|O_CREATE|O_TRUNC, meaning symlink targets outside DriveRoot can be overwritten (e.g. ~/.ssh/authorized_keys).
- Availability Impact: None — no direct availability impact.

Affected Components

- drives/davServer/file.go — Dir.OpenFile (line 140), Dir.Stat (line 176), Dir.Mkdir (line 133), Dir.RemoveAll (line 151)
- endpoints/drive/backend.go — NewBackend (line 51–52)