deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3q34-rx83-r6mq
Package: github.com/dadrus/heimdall (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-35: Path Traversal: '.../...//', CWE-436: Interpretation Conflict
Vulnerable versions: < 0.17.14
Patched in: 0.17.14

Summary: Heimdall has an authorization bypass via path normalization mismatch

Details:
### Summary

Heimdall performs rule matching on the raw (non-normalized) request path, while downstream components may normalize dot-segments according to [RFC 3986, Section 6.2.2.3](https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.3). This discrepancy can result in heimdall authorizing a request for one path (e.g., `/user/../admin`, or URL-encoded variants such as `/user/%2e%2e/admin` or `/user/%2e%2e%2fadmin`. The latter would require the `allow_encoded_slashes` option to be set to `on` or `no_decode`.) while the downstream ultimately processes a different, normalized path (`/admin`).

### Details

This vulnerability can be exploited by an adversary if rule matching is performed using free (named or unnamed) wildcards without further constraints, as shown in the example snippets below.

```yaml
id: rule-1
match:
  routes:
    - path: /user/**
execute: # configured to require authentication and authorization
  # ...
```

```yaml
id: rule-2
match:
  routes:
    - path: /public/**
execute: # configured to allow anonymous access
  # ...
```

If an adversary sends a request to `/public/../user/whatever`, rule-2 will be matched and executed. The downstream service may, however, normalize the request path and interpret it as `/user/whatever`.

### Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

* Access to or modification of data that should be restricted
* Invocation of functionality that is expected to require authentication or authorization
* In certain configurations, escalation of privileges depending on the exposed functionality

### Workarounds

* Normalize HTTP paths or reject HTTP paths containing relative path expressions in the layers in front of Heimdall - this is good practice anyway. Some proxies do that by default, such as Traefik; others, such as Envoy, require additional configuration (for Envoy see [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)).
* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.
GitHub Security Advisory: GHSA-72h4-mxfc-jx37
Package: github.com/dadrus/heimdall (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-178: Improper Handling of Case Sensitivity, CWE-436: Interpretation Conflict
Vulnerable versions: < 0.17.14
Patched in: 0.17.14

Summary: Heimdall: Case-sensitive host matching may lead to policy bypass

Details:
### Summary

Heimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.

**Note:** The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via `--insecure-skip-secure-default-rule-enforcement` or the broader `--insecure` flag.

### Details

This vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.

For example, consider the following rule:

```yaml
id: rule-1
match:
  hosts:
    - type: exact
      value: admin.example.com
execute: # configured to require authentication and authorization
  # ...
```

If an adversary now sends a request with the `Host` header set to `Admin.Example.Com`, rule-1 will not be matched, and the following will happen instead:

* If no default rule is configured, the request will result in an error (`404 Not Found`)
* If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.

### Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

* Access to or modification of data that should be restricted
* Invocation of functionality that is expected to require authentication or authorization
* In certain configurations, escalation of privileges depending on the exposed functionality

### Workarounds

* Normalize request hosts to lowercase in the layers in front of heimdall.
* Do not configure a permissive default rule. Respectively, do not make use of the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags.
* When using `regex` type for host matching, expressions shall be defined in a case-insensitive manner (e.g. `(?i)^admin\.example\.com$`)
* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.
GitHub Security Advisory: GHSA-43jv-5j4x-qv67
Package: github.com/dadrus/heimdall (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-178: Improper Handling of Case Sensitivity, CWE-436: Interpretation Conflict
Vulnerable versions: < 0.17.14
Patched in: 0.17.14

Summary: Heimdall: Case-sensitive handling of URL-encoded slashes may lead to inconsistent path interpretation

Details:
### Summary

Heimdall handles URL-encoded slashes (`%2F`) in a case-sensitive manner, while percent-encoding is defined to be case-insensitive. As a result, the lowercase equivalent (`%2f`) is not recognized and therefore not processed as expected when `allow_encoded_slashes` is set to `off` (the default setting).

This discrepancy can lead to differences in how request paths are interpreted by heimdall and upstream components, which may result in authorization bypass.

**Note:** The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled (e.g. via `--insecure-skip-secure-default-rule-enforcement` or the broader `--insecure` flag).

### Details

Consider the following rule configuration:

```yaml
id: rule-1
match:
  routes:
    - path: /admin/**
execute: # configured to require authentication and authorization
  # ...
```

If an adversary sends a request such as `/admin%2fsecret`, neither is the above rule matched, nor is the request rejected (as would be expected when `allow_encoded_slashes` is set to `off`). Instead, the default rule (if configured) will be executed.

If the configured default rule is overly permissive (e.g. allowing anonymous access), and the upstream service interprets `%2f` as a path separator, the request may ultimately be processed as `/admin/secret`.

This results in the request being authorized based on a different path than the one processed by the upstream service, leading to authorization bypass.

### Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

* Access to or modification of data that should be restricted
* Invocation of functionality that is expected to require authentication or authorization
* In certain configurations, escalation of privileges depending on the exposed functionality


### Workarounds

* Developers should not use the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags and configure their default rule to implement "deny by default".
* Reject HTTP paths containing encoded slashes in the layers in front of heimdall. Some proxies, like e.g., Traefik, do that by default.
* Include the ID of the rule expected to be executed in the JWT issued by heimdall and verify that value in the project's service.
GitHub Security Advisory: GHSA-h829-5cg7-6hff
Package: github.com/supply-chain-tools/gitverify (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.0.0[PII_REDACTED]4901-c2c60da05d5c
Patched in: 0.0.0[PII_REDACTED]4901-c2c60da05d5c

Summary: gitverify has improper tag signature verification

Details:
gitverify is still a prototype.

### Impact
The bug is related to `requireSignedTags` which is on by default: an unsigned annotated tag would pass the verification. The commit pointed to by the tag would still have to be signed by a maintainer or a contributor.

### Patches
Since the initial commit, fixed in c2c60da05d5c73621d0ce7ea02770bacd79ec8b1 (no semantic versions yet).

### Workarounds
No
GitHub Security Advisory: GHSA-6x2q-h3cr-8j2h
Package: github.com/traefik/traefik (GO)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: <= 1.7.34
Patched in: unpatched

Summary: Traefik: A timing side-channel vulnerability allows for valid username enumeration via BasicAuth middleware

Details:
## Summary

There is a timing side-channel vulnerability in Traefik's BasicAuth middleware that allows an attacker to enumerate valid usernames through response-time differences.

The variable intended to hold a constant-time fallback secret always resolves to an empty string, causing the constant-time comparison to short-circuit in microseconds rather than performing a full bcrypt evaluation. This restores the original timing oracle and makes it possible to distinguish existing users from non-existing ones by measuring authentication response times.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

## 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>

# BasicAuth Timing Regression: CVE-2026-32595 Fix Is a No-Op Due to Map Key/Value Confusion

## TL;DR

The patch for CVE-2026-32595 is a no-op. Line 49 of `basic_auth.go` has a
map key/value confusion that makes `notFoundSecret` always `""`. The
"constant time" fallback calls `goauth.CheckSecret(password, "")`, which
fast-fails in ~1us instead of running bcrypt (~60ms).

## Evidence (HEAD `786f7192e`, 2026-04-09)

Black-box PoC against live traefik binary on port 28080:

| bucket                       | n   | median   | min      |
|------------------------------|-----|----------|----------|
| existing user (wrong pw)     | 240 | 62.85 ms | 57.54 ms |
| nonexistent user (wrong pw)  | 400 |  0.48 ms |  0.35 ms |

Median ratio: **130.4x**. Classification: **8/8 correct**.

Go in-tree test: `goauth.CheckSecret` direct ratio **12,746x**.

## Root cause (4-step trace)

1. `basic_auth.go:49`: `users[slices.Collect(maps.Values(users))[0]]` -- looks
   up a hash as a username key, returns `""`.
2. `basic_auth.go:119-120`: calls `goauth.CheckSecret(password, "")`.
3. `go-http-auth/basic.go:87`: empty string matches no prefix, falls to default
   `compareMD5HashAndPassword`.
4. `basic.go:107-109`: `bytes.SplitN("", "$", 4)` returns length 1, function
   returns instantly.

## Files

- `poc/exploit.py` -- black-box Python timing oracle
- `poc/basic_auth_timing_regression_test.go` -- Go in-tree test
- `poc/traefik.yml` + `poc/dynamic.yml` -- traefik config
- `poc/live_http_poc_output_head.txt` -- verbatim PoC output on HEAD


Koda Reef

</details>

---
GitHub Security Advisory: GHSA-6x2q-h3cr-8j2h
Package: github.com/traefik/traefik/v2 (GO)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 2.11.43
Patched in: 2.11.43

Summary: Traefik: A timing side-channel vulnerability allows for valid username enumeration via BasicAuth middleware

Details:
## Summary

There is a timing side-channel vulnerability in Traefik's BasicAuth middleware that allows an attacker to enumerate valid usernames through response-time differences.

The variable intended to hold a constant-time fallback secret always resolves to an empty string, causing the constant-time comparison to short-circuit in microseconds rather than performing a full bcrypt evaluation. This restores the original timing oracle and makes it possible to distinguish existing users from non-existing ones by measuring authentication response times.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

## 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>

# BasicAuth Timing Regression: CVE-2026-32595 Fix Is a No-Op Due to Map Key/Value Confusion

## TL;DR

The patch for CVE-2026-32595 is a no-op. Line 49 of `basic_auth.go` has a
map key/value confusion that makes `notFoundSecret` always `""`. The
"constant time" fallback calls `goauth.CheckSecret(password, "")`, which
fast-fails in ~1us instead of running bcrypt (~60ms).

## Evidence (HEAD `786f7192e`, 2026-04-09)

Black-box PoC against live traefik binary on port 28080:

| bucket                       | n   | median   | min      |
|------------------------------|-----|----------|----------|
| existing user (wrong pw)     | 240 | 62.85 ms | 57.54 ms |
| nonexistent user (wrong pw)  | 400 |  0.48 ms |  0.35 ms |

Median ratio: **130.4x**. Classification: **8/8 correct**.

Go in-tree test: `goauth.CheckSecret` direct ratio **12,746x**.

## Root cause (4-step trace)

1. `basic_auth.go:49`: `users[slices.Collect(maps.Values(users))[0]]` -- looks
   up a hash as a username key, returns `""`.
2. `basic_auth.go:119-120`: calls `goauth.CheckSecret(password, "")`.
3. `go-http-auth/basic.go:87`: empty string matches no prefix, falls to default
   `compareMD5HashAndPassword`.
4. `basic.go:107-109`: `bytes.SplitN("", "$", 4)` returns length 1, function
   returns instantly.

## Files

- `poc/exploit.py` -- black-box Python timing oracle
- `poc/basic_auth_timing_regression_test.go` -- Go in-tree test
- `poc/traefik.yml` + `poc/dynamic.yml` -- traefik config
- `poc/live_http_poc_output_head.txt` -- verbatim PoC output on HEAD


Koda Reef

</details>

---
GitHub Security Advisory: GHSA-6x2q-h3cr-8j2h
Package: github.com/traefik/traefik/v3 (GO)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: >= 3.0.0-beta1, < 3.6.14
Patched in: 3.6.14

Summary: Traefik: A timing side-channel vulnerability allows for valid username enumeration via BasicAuth middleware

Details:
## Summary

There is a timing side-channel vulnerability in Traefik's BasicAuth middleware that allows an attacker to enumerate valid usernames through response-time differences.

The variable intended to hold a constant-time fallback secret always resolves to an empty string, causing the constant-time comparison to short-circuit in microseconds rather than performing a full bcrypt evaluation. This restores the original timing oracle and makes it possible to distinguish existing users from non-existing ones by measuring authentication response times.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

## 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>

# BasicAuth Timing Regression: CVE-2026-32595 Fix Is a No-Op Due to Map Key/Value Confusion

## TL;DR

The patch for CVE-2026-32595 is a no-op. Line 49 of `basic_auth.go` has a
map key/value confusion that makes `notFoundSecret` always `""`. The
"constant time" fallback calls `goauth.CheckSecret(password, "")`, which
fast-fails in ~1us instead of running bcrypt (~60ms).

## Evidence (HEAD `786f7192e`, 2026-04-09)

Black-box PoC against live traefik binary on port 28080:

| bucket                       | n   | median   | min      |
|------------------------------|-----|----------|----------|
| existing user (wrong pw)     | 240 | 62.85 ms | 57.54 ms |
| nonexistent user (wrong pw)  | 400 |  0.48 ms |  0.35 ms |

Median ratio: **130.4x**. Classification: **8/8 correct**.

Go in-tree test: `goauth.CheckSecret` direct ratio **12,746x**.

## Root cause (4-step trace)

1. `basic_auth.go:49`: `users[slices.Collect(maps.Values(users))[0]]` -- looks
   up a hash as a username key, returns `""`.
2. `basic_auth.go:119-120`: calls `goauth.CheckSecret(password, "")`.
3. `go-http-auth/basic.go:87`: empty string matches no prefix, falls to default
   `compareMD5HashAndPassword`.
4. `basic.go:107-109`: `bytes.SplitN("", "$", 4)` returns length 1, function
   returns instantly.

## Files

- `poc/exploit.py` -- black-box Python timing oracle
- `poc/basic_auth_timing_regression_test.go` -- Go in-tree test
- `poc/traefik.yml` + `poc/dynamic.yml` -- traefik config
- `poc/live_http_poc_output_head.txt` -- verbatim PoC output on HEAD


Koda Reef

</details>

---
GitHub Security Advisory: GHSA-6x2q-h3cr-8j2h
Package: github.com/traefik/traefik/v3 (GO)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: >= 3.7.0-ea.1, < 3.7.0-rc.2
Patched in: 3.7.0-rc.2

Summary: Traefik: A timing side-channel vulnerability allows for valid username enumeration via BasicAuth middleware

Details:
## Summary

There is a timing side-channel vulnerability in Traefik's BasicAuth middleware that allows an attacker to enumerate valid usernames through response-time differences.

The variable intended to hold a constant-time fallback secret always resolves to an empty string, causing the constant-time comparison to short-circuit in microseconds rather than performing a full bcrypt evaluation. This restores the original timing oracle and makes it possible to distinguish existing users from non-existing ones by measuring authentication response times.

## Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

## 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>

# BasicAuth Timing Regression: CVE-2026-32595 Fix Is a No-Op Due to Map Key/Value Confusion

## TL;DR

The patch for CVE-2026-32595 is a no-op. Line 49 of `basic_auth.go` has a
map key/value confusion that makes `notFoundSecret` always `""`. The
"constant time" fallback calls `goauth.CheckSecret(password, "")`, which
fast-fails in ~1us instead of running bcrypt (~60ms).

## Evidence (HEAD `786f7192e`, 2026-04-09)

Black-box PoC against live traefik binary on port 28080:

| bucket                       | n   | median   | min      |
|------------------------------|-----|----------|----------|
| existing user (wrong pw)     | 240 | 62.85 ms | 57.54 ms |
| nonexistent user (wrong pw)  | 400 |  0.48 ms |  0.35 ms |

Median ratio: **130.4x**. Classification: **8/8 correct**.

Go in-tree test: `goauth.CheckSecret` direct ratio **12,746x**.

## Root cause (4-step trace)

1. `basic_auth.go:49`: `users[slices.Collect(maps.Values(users))[0]]` -- looks
   up a hash as a username key, returns `""`.
2. `basic_auth.go:119-120`: calls `goauth.CheckSecret(password, "")`.
3. `go-http-auth/basic.go:87`: empty string matches no prefix, falls to default
   `compareMD5HashAndPassword`.
4. `basic.go:107-109`: `bytes.SplitN("", "$", 4)` returns length 1, function
   returns instantly.

## Files

- `poc/exploit.py` -- black-box Python timing oracle
- `poc/basic_auth_timing_regression_test.go` -- Go in-tree test
- `poc/traefik.yml` + `poc/dynamic.yml` -- traefik config
- `poc/live_http_poc_output_head.txt` -- verbatim PoC output on HEAD


Koda Reef

</details>

---
GitHub Security Advisory: GHSA-rp7v-4384-hfrp
Package: github.com/k8sgpt-ai/k8sgpt (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-502: Deserialization of Untrusted Data, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: < 0.4.32
Patched in: 0.4.32

Summary: k8sGPT has Prompt Injection through its k8sGPT-Operator

Details:
### Summary
In the auto-remediation pipeline, `object_to_execution.go` was deserializing the AI-generated YAML directly into a Deployment object, but there was lack of validation from the original Deployment object.

### Details
This issue was fixed after coordination with Alex Jones.

### PoC
To minimize the impact, the PoC of this vulnerability wasn't released, but was shared with the maintainers.
GitHub Security Advisory: GHSA-xhj4-g6w8-2xjw
Package: github.com/woven-planet/go-zserio (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 0.9.1
Patched in: 0.9.1

Summary: go-zserio has Unbounded Memory Allocation for All Platforms

Details:
### Impact

When deserializing arrays, strings or bytes (blob) types zserio first reads the size of the variable, and then allocates sufficient memory to load data. Since the size is always trusted this can be abused by creating a data file with a large size value, causing the zserio runtime to allocate large amounts of memory.

### Patches

Please apply [this commit](https://github.com/woven-by-toyota/go-zserio/commit/39ef1decde7e[PII_REDACTED]d396018776b33c6e45).

### Workarounds

- Do not accept zserio data from non-trusted sources.
- Use secure transportation protocols (like TLS).