deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8mc6-xjpr-h98x
Package: github.com/lin-snow/ech0 (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.4.8-0[PII_REDACTED]0602-091d26d2d942
Patched in: 1.4.8-0[PII_REDACTED]0602-091d26d2d942

Summary: Ech0 has Server-Side Request Forgery (SSRF) via Connect Handler fetchPeerConnectInfo

Details:
## Summary
The `fetchPeerConnectInfo` function in `internal/service/connect/connect.go:214-239` uses `httpUtil.SendRequest` (no SSRF protection) instead of `SendSafeRequest` (which has `ValidatePublicHTTPURL` with private IP blocking). This allows authenticated users to make the server request arbitrary URLs including internal/cloud metadata endpoints.

## Details
In `internal/service/connect/connect.go`, the `fetchPeerConnectInfo` function:
```go
func fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {
    url := httpUtil.TrimURL(peerConnectURL) + "/api/connect"
    resp, err := httpUtil.SendRequest(url, "GET", struct {...}{...}, requestTimeout)
```

This uses `SendRequest` which has NO URL validation. The codebase HAS `SendSafeRequest` at `internal/util/http/http.go:228-281` with proper SSRF protection, but `fetchPeerConnectInfo` does not use it.

Called from:
- Line 307: `data, err := fetchPeerConnectInfo(conn.ConnectURL, requestTimeout)`
- - Line 498: `data, err := fetchPeerConnectInfo(conn.ConnectURL, healthProbeTimeout)`
## PoC
```bash
# 1. Add a connection pointing to AWS metadata service
curl -X POST "https://ech0.example.com/api/connects" \
  -H "Authorization: Bearer <token>" \
  -d '{"connect_url": "http://169.254.169.254/latest/meta-data/instance-id"}'

# 2. Trigger SSRF via health check
curl -H "Authorization: Bearer <token>" \
  "https://ech0.example.com/api/connects/health"
# Returns AWS EC2 instance ID
```

Or for Kubernetes:
```bash
curl -X POST "https://ech0.example.com/api/connects" \
  -H "Authorization: Bearer <token>" \
  -d '{"connect_url": "http://kubernetes.default.svc.cluster.local:443/api"}'
```

## Impact
- **Confidentiality**: SSRF can access internal services, cloud metadata (AWS IMDSv1, GCE metadata), Kubernetes API
- - **CWE-918**: Server-Side Request Forgery
GitHub Security Advisory: GHSA-q6mh-rqwh-g786
Package: github.com/enchant97/note-mark/backend (GO)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-326: Inadequate Encryption Strength, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 0.0.0[PII_REDACTED]2247-18b587758667
Patched in: 0.0.0[PII_REDACTED]2247-18b587758667

Summary: Note Mark has a JWT Secret Weakness that allows Full Account Takeover via Token Forgery

Details:
#### Summary

No minimum length or entropy is enforced on the `JWT_SECRET` configuration value. The application accepts any base64-decodable secret regardless of size, including secrets as short as 1 byte.

HS256 secrets below 32 bytes are brute-forceable offline, allowing attackers to recover the signing key and forge valid JWTs for arbitrary users.

---

#### Impact

An attacker who captures a single valid JWT (e.g, from cookies, logs, or network traffic) can:

\> Crack the signing secret offline using brute-force or wordlist attacks
\> Forge valid JWTs for any user ID (including administrators)
\> Authenticate without knowing any credentials

This results in **full account takeover across the entire application** with no server-side detection or rate limiting possible.

---

#### Details

In `backend/config/utils.go`, the `Base64Decoded.UnmarshalText` function decodes the JWT secret but does not validate its length or entropy.

In `backend/core/auth.go`, JWT tokens are signed using HS256 without enforcing minimum key size requirements.

According to **RFC 7518 Section 3.2**, HS256 keys must be at least 256 bits (32 bytes). Libraries such as PyJWT explicitly warn against shorter keys, but note-mark performs no such validation.

---

### PoC

1- Deploy note-mark with a weak secret:

   ```
   JWT_SECRET = base64("testsecret[PII_REDACTED]2345")
   ```

2- Register an account and capture the `Auth-Session-Token` cookie

3- Crack the secret offline (example using Python):

   ```python
   import jwt, base64
   jwt.decode(TOKEN, base64.b64decode(SECRET), algorithms=["HS256"])
   ```

4- Forge a new token for any user UUID with extended expiry

5- Send the forged token in requests → server returns **200 Ok** and authenticates as that user

---

### Reproduction Steps

1- Deploy the application with a JWT secret shorter than 32 bytes (after base64 decoding)
2- Authenticate and capture a valid JWT
3- Perform offline brute-force or dictionary attack against the token signature
4- Recover the secret
5- Generate a forged JWT for another user
6- Use the forged token to access protected endpoints

---

### Fix Recommendation

* Enforce a **minimum of 32 bytes (256 bits)** for JWT secrets after base64 decoding
* Reject weak secrets during configuration parsing (e.g., in `Base64Decoded.UnmarshalText` or config validation)
* Optionally log warnings or fail startup if the secret is insecure

---

### Resources

* RFC 7518 Section 3.2 (JSON Web Algorithms - HMAC key size requirements)
* CWE-326: Inadequate Encryption Strength
* CWE-345: Insufficient Verification of Data Authenticity

---
GitHub Security Advisory: GHSA-6r3x-h84w-fhxx
Package: github.com/sipeed/picoclaw (GO)
Severity: MODERATE (CVSS 7.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 0.2.4
Patched in: unpatched

Summary: PicoClaw has an Injection issue in its Web Launcher Management Plane component

Details:
A vulnerability was detected in PicoClaw up to 0.2.4. Impacted is an unknown function of the file /api/gateway/restart of the component Web Launcher Management Plane. Performing a manipulation results in command injection. It is possible to initiate the attack remotely. The project was informed of the problem early through an issue report but has not responded yet.
GitHub Security Advisory: GHSA-ffqx-q65f-36jf
Package: github.com/grafana/tempo (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-326: Inadequate Encryption Strength
Vulnerable versions: < 2.10.3
Patched in: 2.10.3

Summary: Grafana Tempo has Inadequate Encryption Strength

Details:
A vulnerability in Grafana Tempo exposes the S3 SSE-C encryption key in plaintext through the /status/config endpoint, potentially allowing unauthorized users to obtain the key used to encrypt trace data stored in S3.

Grafana thanks william_goodfellow for reporting this vulnerability.
GitHub Security Advisory: GHSA-mmpx-jh39-wrv6
Package: github.com/gtsteffaniak/filebrowser (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.0.0[PII_REDACTED]4955-6bfc3974192e
Patched in: 0.0.0[PII_REDACTED]4955-6bfc3974192e

Summary: FileBrowser Vulnerable to Stored XSS via SVG File in Public Share (Missing CSP Header)

Details:
## Summary

FileBrowser Quantum serves inline SVG files without a `Content-Security-Policy` header, allowing embedded JavaScript in SVG files to execute when accessed via public share links.

Verified on v1.3.0-stable.

## Affected product

- **Product:** FileBrowser Quantum (`gtsteffaniak/filebrowser`)
- **Verified version:** v1.3.0-stable
- **Docker image:** gtstef/filebrowser:latest
- **Affected endpoint:** `GET /public/api/resources/download?hash=HASH&inline=true`
- **CWE:** CWE-79 — Cross-site Scripting (Stored)

## Impact

- **Stored XSS** — Malicious SVG persists and executes for every visitor to the share link
- **No authentication required to trigger** — Public share links are accessible to anyone
- **Session hijacking** — If authenticated users click the link, their session can be stolen
- **Phishing** — Attacker can redirect or overlay fake login forms

## Reproduction

1. Login as any user with upload permission
2. Upload SVG file:
   ```xml
   <svg xmlns="http://www.w3.org/2000/svg">
     <script>alert(document.domain)</script>
   </svg>
   ```
3. Create public share for the file
4. Access the share link with `?inline=true`
5. JavaScript executes in browser

## Root cause

The inline download endpoint returns SVG files with:
```
Content-Type: image/svg+xml
Content-Disposition: inline; filename="xss.svg"
X-Content-Type-Options: nosniff
```

But no CSP header to block script execution. The upstream project (filebrowser/filebrowser) mitigates this with:
```
Content-Security-Policy: script-src 'none'
```

## Suggested fix

Add CSP header on inline file downloads:

```go
w.Header().Set("Content-Security-Policy", "script-src 'none'")
```

This matches the upstream filebrowser/filebrowser implementation.
GitHub Security Advisory: GHSA-fwj3-42wh-8673
Package: github.com/gtsteffaniak/filebrowser (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.0.0[PII_REDACTED]3844-112740bdd41d
Patched in: 0.0.0[PII_REDACTED]3844-112740bdd41d

Summary: FileBrowser Public Share DELETE API Path Traversal Allows Unauthenticated Arbitrary File Deletion

Details:
### **Summary**

Attacker-controlled path input is joined with a trusted base path prior to sanitization, allowing traversal sequences (e.g., ../) to escape the intended shared directory. As a result, an unauthenticated attacker possessing a valid public share hash with delete permissions enabled can delete arbitrary files outside the shared directory within the share owner’s configured storage scope.

### **Affected Components**

**Two distinct vulnerable code paths:**

1. Stable versions (e.g., gtstef/filebrowser:stable)
`DELETE /public/api/resources?hash=<hash>&path=../victim`
Root cause: middleware.go:111
Issue: path query parameter is joined before SanitizeUserPath()
2. Development / HEAD (e.g., commit eabdfd9)
`DELETE /public/api/resources/bulk?hash=<hash>`
Body: [{"path":"../victim"}]
Root cause: resource.go:274
Issue: item.Path is joined before SanitizeUserPath()

### **Steps to reproduce (Stable Version)**

**1. Create a directory structure:**

```
/folder/shared_subdir/   (shared)
/folder/protected.txt    (outside shared directory)
```

**2. Create a public share:**
```
Path: /shared_subdir
AllowDelete=true
```

**3. Send request:**

```
curl -X DELETE "http://localhost/public/api/resources?hash=<HASH>&path=../protected.txt"

#Observe:
#protected.txt is deleted despite being outside the shared directory
```

### **Proof of Concept (HEAD / bulk endpoint)**

```
curl -X DELETE "http://localhost/public/api/resources/bulk?hash=<HASH>" \
  -H "Content-Type: application/json" \
  -d '[{"path":"../protected.txt"}]'
```

### **Alternative PoC Scripts:**
[poc_v3.sh](https://github.com/user-attachments/files/26159404/poc_v3.sh) (**If the script fails due to environment differences, the manual PoC above reliably reproduces the issue.**)


### **Impact**
An unauthenticated attacker with access to a public share link configured with delete permissions enabled can delete attacker-chosen files outside the shared directory, anywhere within the share owner’s storage scope. This results in unauthorized data loss and potential service disruption.
GitHub Security Advisory: GHSA-x35m-3gp4-4fh5
Package: go.etcd.io/etcd (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 3.4.43
Patched in: 3.4.44

Summary: etcd RBAC bypass allows unauthorized data access via PrevKv/lease attachment in nested transaction Put requests

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

A vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled.

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:
- etcd 3.6.11
- etcd 3.5.30
- etcd 3.4.44

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters

Samy Ghannad (@SamyGhannad on Github) reported that read access via PrevKv in a Put request within etcd transactions bypassed RBAC authorization checks. Benjamin Wang (@ahrtr ) further analyzed that lease attachment in a Put request within etcd transactions also bypassed RBAC authorization checks
GitHub Security Advisory: GHSA-x35m-3gp4-4fh5
Package: go.etcd.io/etcd/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.5.0, <= 3.5.29
Patched in: 3.5.30

Summary: etcd RBAC bypass allows unauthorized data access via PrevKv/lease attachment in nested transaction Put requests

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

A vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled.

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:
- etcd 3.6.11
- etcd 3.5.30
- etcd 3.4.44

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters

Samy Ghannad (@SamyGhannad on Github) reported that read access via PrevKv in a Put request within etcd transactions bypassed RBAC authorization checks. Benjamin Wang (@ahrtr ) further analyzed that lease attachment in a Put request within etcd transactions also bypassed RBAC authorization checks
GitHub Security Advisory: GHSA-x35m-3gp4-4fh5
Package: go.etcd.io/etcd/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.6.0, <= 3.6.10
Patched in: 3.6.11

Summary: etcd RBAC bypass allows unauthorized data access via PrevKv/lease attachment in nested transaction Put requests

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

A vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled.

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

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

This vulnerability is patched in the following versions:
- etcd 3.6.11
- etcd 3.5.30
- etcd 3.4.44

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

If upgrading is not immediately possible, reduce exposure by treating the affected
RPCs as unauthenticated in practice.

- restrict network access to etcd server ports so only trusted components can connect
- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate
distribution

### Reporters

Samy Ghannad (@SamyGhannad on Github) reported that read access via PrevKv in a Put request within etcd transactions bypassed RBAC authorization checks. Benjamin Wang (@ahrtr ) further analyzed that lease attachment in a Put request within etcd transactions also bypassed RBAC authorization checks
GitHub Security Advisory: GHSA-w239-58x2-q8p5
Package: github.com/ipld/go-ipld-prime (GO)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: go-ipld-prime's DAG-CBOR and DAG-JSON decoders have unbounded recursion depth

Details:
The DAG-CBOR and DAG-JSON decoders recurse on each nested map or list without a depth limit. A payload containing deeply nested collections causes the decoder to recurse once per level, growing the goroutine stack until the Go runtime terminates the process with a fatal stack overflow (distinct from a recoverable panic).

For DAG-CBOR, a payload of approximately 2 MB, consisting of repeated `0x81` (array-of-1) bytes followed by a terminator, produces around 2 million recursion frames and reliably exhausts Go's default 1 GB goroutine stack. The existing allocation budget does not prevent this: each nested collection header costs only a handful of budget units, so the stack is exhausted before the budget is. DAG-JSON has equivalent exposure via `[[[...]]]`-style payloads; it has no budget system and is therefore unprotected against recursion depth as well.

Schema-free decoding (using `basicnode.Prototype.Any`) allows arbitrary nesting depth. Schema-bound decoding bounds nesting only when the schema itself is non-recursive and contains no fields typed as `Any`; schemas with recursive type references or any `Any`-typed fields permit unconstrained nesting at those points.

The fix adds a configurable `MaxDepth` option to both decoders, defaulting to 1024 nested levels. The decoder returns `ErrDecodeDepthExceeded` when a payload nests beyond the limit. Well-formed IPLD data rarely approaches this depth in practice; the default is generous for legitimate use while preventing stack exhaustion.
GitHub Security Advisory: GHSA-6rgm-gr97-x3j5
Package: github.com/free5gc/pcf (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1.4.3
Patched in: 1.4.3

Summary: Free5GC PCF: Missing authentication middleware in Npcf_SMPolicyControl allows access to SM policy handlers and disclosure of subscriber SUPI

Details:
### Summary
PCF Npcf_SMPolicyControl missing authentication middleware allows unauthenticated access to SM policy handlers and disclosure of subscriber SUPI
### Details
In `NewServer()`, the `smPolicyGroup` route group is created and routes are applied without attaching the router authorization middleware. In contrast, other PCF service groups such as `Npcf_PolicyAuthorization` do attach `RouterAuthorizationCheck` before route registration.

Because the middleware is missing, requests to the following endpoints can reach business logic even when no valid OAuth token is provided:

- `POST /npcf-smpolicycontrol/v1/sm-policies`
- `GET /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}`
- `POST /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/update`
- `POST /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete`

This is visible at runtime because unauthenticated requests return business-level responses such as `400` or `404` instead of being rejected with `401` before handler execution. Under valid lab preconditions (existing UE/session context and related policy data), unauthenticated `POST /sm-policies` can succeed with `201`, and unauthenticated `GET /sm-policies/{id}` can succeed with `200` and return policy context containing subscriber identifiers including `supi`.

The root cause is missing router auth enforcement for `Npcf_SMPolicyControl`. 
Upstream also fixed this by adding `RouterAuthorizationCheck` to `smPolicyGroup` (and `uePolicyGroup`) in free5gc/pcf PR #63.

### PoC
1. Deploy free5GC with PCF reachable on the SBI network.
2. Use the PoC against the PCF service **without** an `Authorization` header:
   ```bash
   go run /home/ubuntu/free5gc/tools/npcf-smpolicy-noauth-poc/main.go \
     --pcf-root /home/ubuntu/free5gc/NFs/pcf \
     --pcf-url http://10.100.200.9:8000 \
     --timeout 4s
Observe that unauthenticated requests to Npcf_SMPolicyControl return business responses instead of 401.
### Impact

This is an authentication/authorization bypass on a network-accessible SBI service. Any unauthenticated actor able to reach the PCF SBI interface can invoke Npcf_SMPolicyControl handlers directly.
GitHub Security Advisory: GHSA-5v3h-x4wf-5c35
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.4)
CWE: CWE-35: Path Traversal: '.../...//'
Vulnerable versions: >= 2.10.11, < 2.11.13
Patched in: 2.11.13

Summary: Rancher Extensions have arbitrary file access via path traversal

Details:
### Impact

A vulnerability has been identified in [Rancher's Extensions](https://ranchermanager.docs.rancher.com/integrations-in-rancher/rancher-extensions) where malicious code can be injected in Rancher through a path traversal in the `compressedEndpoint` field inside a `UIPlugin` deployment. A malicious UI extension could abuse that to:

- Overwrite Rancher binaries or configuration to inject code.
- Write to `/var/lib/rancher/` to tamper with cluster state.
- If `hostPath` volumes are mounted, write to the host node filesystem.
- Use this issue to chain with other attack vectors.

By default only the administrator can deploy UI extensions, unless permissions are granted to other users. It's always recommended to only install extensions that come from sources trusted by the user.

Please consult the associated  [MITRE CAPEC-126 - Technique - Path Traversal](https://capec.mitre.org/data/definitions/126.html) for further information about this category of attack.

### Patches

This vulnerability is addressed by ensuring that:

- The file defined by the UI Plugin CR's `compressedEndpoint` has to be created inside the cache directory and cannot contain `../`. If that is not possible, the installation will fail and the file won't be created. 
- The icons referenced by Cluster Repos' `index.yaml` file always resolves to a file inside the repository directory.

Patched versions of Rancher include releases v2.14.1, v2.13.5, v2.12.9, v2.11.13.

### Workarounds

There is no workaround. The user must be careful about which UI Plugins they install.

### Resources

If there are any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).