deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-r65v-xgwc-g56j
Package: github.com/openbao/openbao (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-674: Uncontrolled Recursion, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.0.0[PII_REDACTED]0337-2b2a901aa9f7
Patched in: 0.0.0[PII_REDACTED]0337-2b2a901aa9f7

Summary: OpenBao: Decompression Bomb via Unbounded Copy in OCI Plugin Extraction (DoS)

Details:
### Summary

`ExtractPluginFromImage()` in OpenBao's OCI plugin downloader extracts a plugin binary from a container image by streaming decompressed tar data via `io.Copy` with no upper bound on the number of bytes written.
An attacker who controls or compromises the OCI registry referenced in the victim's configuration can serve a crafted image containing a decompression bomb that decompresses to an arbitrarily large file.

The SHA256 integrity check occurs after the full file is written to disk, meaning the hash mismatch is detected only after the damage (disk exhaustion) has already occurred. This allow the attacker to replace **legit plugin image** with no need to change its signature.

### Details

#### Root cause

`helper/pluginutil/oci/downloader.go:301`:

```go
if _, copyErr := io.Copy(outFile, tarReader); copyErr != nil {
```

`io.Copy()` reads until EOF with no size limit.  
The tar `header.Size` field is never validated before the copy, and `mutate.Extract` decompresses all gzip layers in memory/streaming, resulting in unbounded decompression-to-disk.

### PoC

1. Set up a malicious OCI registry
2. Create a decompression bomb binary:
   ```bash
   dd if=/dev/zero bs=1G count=100 > /tmp/bomb-binary
   ```
3. Package it in a minimal OCI image
4. Push to the malicious registry
5. Configure victim OpenBao to use this registry:
   ```hcl
   plugin "secrets" "bomb" {
     image       = "evil.example.com/plugin"
     version     = "v1.0.0"
     binary_name = "openbao-plugin-secrets-bomb"
     sha256sum   = "[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]0000"
   }
   plugin_auto_download = true
   ```
6. Start OpenBao (or trigger SIGHUP), load OCI image, disk fill -> cause DoS

### Impact

- Denial of Service: Disk exhaustion on the OpenBao server
- Cascading failure: Co-located services (databases, other apps) also fail when the disk is full
- Difficult recovery: If the process is killed mid-extraction, the partial file remains on disk and is not cleaned up
- Repeated exploitation: On SIGHUP or restart with plugin_auto_download = true, the bomb is re-downloaded

### Remediation

1. Validate `header.Size` against a configurable maximum before opening the output file
2. Wrap `tarReader` in `io.LimitReader(tarReader, maxSize+1)` and check bytes written after copy
3. Add a max_size configuration field to PluginConfig for operator control (default: 1 GiB)
GitHub Security Advisory: GHSA-7ccv-rp6m-rffr
Package: github.com/openbao/openbao (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-295: Improper Certificate Validation, CWE-863: Incorrect Authorization
Vulnerable versions: < 0.0.0[PII_REDACTED]0924-abe84e1af4c3
Patched in: 0.0.0[PII_REDACTED]0924-abe84e1af4c3

Summary: OpenBao's Certificate Authentication Allows Token Renewal With Different Certificate

Details:
### Background

OpenBao's Certificate authentication method, when a token renewal is requested and `disable_binding=true` is set, attempts to verify the current request's presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information.

### Impact

Due to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor. 

This vulnerability is originally from HashiCorp Vault.

### Patches

This has been addressed in v2.5.3.

### Workarounds

Ensure privileged roles are tightly scoped to single certificates.
GitHub Security Advisory: GHSA-2gw9-c2r2-f5qf
Package: github.com/m1k1o/neko/server (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-269: Improper Privilege Management, CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 0.0.0[PII_REDACTED]5643-212bf8a60756, < 0.0.0[PII_REDACTED]4107-c54bcf1ee211
Patched in: 0.0.0[PII_REDACTED]4107-c54bcf1ee211

Summary: Neko has a Self-service Privilege Escalation for Authenticated Users

Details:
### Impact

Any authenticated user can immediately obtain full administrative control of the entire Neko instance (member management, room settings, broadcast control, session termination, etc.). This results in a complete compromise of the instance.

### Patches

The vulnerability has been patched in the following releases:

- [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) (backport release)
- [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) (latest stable release)

Users should upgrade to [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) or later (for the 3.0 branch) or [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) or later.

### Workarounds

If upgrading is not immediately possible, the following mitigations can reduce risk:

- Restrict access to trusted users only (avoid granting accounts to untrusted parties)
- Run the instance only when needed; avoid leaving it continuously exposed
- Disable or restrict access to the `/api/profile` endpoint if feasible
- Monitor for suspicious privilege changes or unexpected administrative actions

Note: These are temporary mitigations and do not fully eliminate the vulnerability. Upgrading is strongly recommended.

### Credits
Neko thanks @blitzkrieg-patch for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.
GitHub Security Advisory: GHSA-2gw9-c2r2-f5qf
Package: github.com/m1k1o/neko/server (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-20: Improper Input Validation, CWE-269: Improper Privilege Management, CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 3.0.0, < 3.0.11
Patched in: 3.0.11

Summary: Neko has a Self-service Privilege Escalation for Authenticated Users

Details:
### Impact

Any authenticated user can immediately obtain full administrative control of the entire Neko instance (member management, room settings, broadcast control, session termination, etc.). This results in a complete compromise of the instance.

### Patches

The vulnerability has been patched in the following releases:

- [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) (backport release)
- [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) (latest stable release)

Users should upgrade to [v3.0.11](https://github.com/m1k1o/neko/releases/tag/v3.0.11) or later (for the 3.0 branch) or [v3.1.2](https://github.com/m1k1o/neko/releases/tag/v3.1.2) or later.

### Workarounds

If upgrading is not immediately possible, the following mitigations can reduce risk:

- Restrict access to trusted users only (avoid granting accounts to untrusted parties)
- Run the instance only when needed; avoid leaving it continuously exposed
- Disable or restrict access to the `/api/profile` endpoint if feasible
- Monitor for suspicious privilege changes or unexpected administrative actions

Note: These are temporary mitigations and do not fully eliminate the vulnerability. Upgrading is strongly recommended.

### Credits
Neko thanks @blitzkrieg-patch for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.
GitHub Security Advisory: GHSA-x234-x5vq-cc2v
Package: github.com/0xJacky/Nginx-UI (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 1.9.10-0[PII_REDACTED]2518-7b66578adb47
Patched in: 1.9.10-0[PII_REDACTED]2518-7b66578adb47

Summary: Nginx-UI: Disabled users retain full API access through previously issued bearer tokens

Details:
### Summary

A user who was disabled by an administrator can use previously issued API tokens for up to the token lifetime. In practice, disabling a compromised account does not actually terminate that user’s access, so an attacker who already stole a JWT can continue reading and modifying protected resources after the account is marked disabled.

Since tokens can be used to create new accounts, it is possible the disabled user to maintain the privilege.

### Details

The application exposes an account-level disable control through the users management API. Login process correctly enforces that control:
https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/internal/user/login.go#L29-L31

However, token-based authentication does not enforce the same check (This code validates token structure and expiry, but returns that user object without checking `user.Status`.):
https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/internal/user/user.go#L44-L139

There’s also no token revocation feature, unlike when a password is changed:
https://github.com/0xJacky/nginx-ui/blob/6ec542fd97abf2c5950f374f78a32938ad0030e6/api/user/user.go#L38-L51

As a result, a disabled user can continue to have full API access. In particular, since that includes account creation, they can create a new account and keep operating even after the JWT expires.

### PoC

The issue was validated with version 2.3.3 using the `uozi/nginx-ui:sha-c92ec0a` docker image.

View the PoC video:


https://github.com/user-attachments/assets/7a5175cb-2f79-4c1b-adad-e7d0bf2ea2bd



### Impact

Administrators who rely on "disable user" as an authentication or authorization control can be bypassed.

The disabled user can keep reading sensitive configuration and executing authenticated state-changing actions allowed to that account.
GitHub Security Advisory: GHSA-mph4-q2vm-w2pw
Package: github.com/kubernetes-sigs/aws-efs-csi-driver (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Vulnerable versions: < 1.7.8-0[PII_REDACTED]2831-51806c22c575
Patched in: 1.7.8-0[PII_REDACTED]2831-51806c22c575

Summary: Amazon EFS CSI Driver has mount option injection via unsanitized volumeHandle and mounttargetip fields

Details:
### Summary
The Amazon EFS CSI Driver is a Container Storage Interface driver that allows Kubernetes clusters to use Amazon Elastic File System. An issue exists where, under certain circumstances, unsanitized values in the volumeHandle and mounttargetip fields are passed directly to the mount command, allowing injection of arbitrary mount options.

### Impact
An actor with PersistentVolume creation privileges can inject arbitrary mount options by appending comma-separated values to the Access Point ID in volumeHandle or to the mounttargetip volumeAttribute. The mount utility parses comma-separated values as separate options, causing the injected options to be applied to the filesystem mount without authorization.

Impacted versions: <= v3.0.0

### Patches
This issue has been addressed in Amazon EFS CSI Driver version v3.0.1. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

### Workarounds
Restrict PersistentVolume and StorageClass creation to cluster administrators using Kubernetes RBAC, preventing untrusted users from supplying arbitrary field values.

### References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com).  Please do not create a public GitHub issue.

### Acknowledgement
We would like to thank Shaul Ben-Hai from Sentinel One for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-c97m-vxhj-p7j6
Package: github.com/yuin/goldmark/renderer/html (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.7.17
Patched in: 1.7.17

Summary: goldmark vulnerable to Cross-site Scripting (XSS)

Details:
Versions of the package github.com/yuin/goldmark/renderer/html before 1.7.17 are vulnerable to Cross-site Scripting (XSS) due to improper ordering of URL validation and normalization. The renderer validates link destinations using a prefix-based check (IsDangerousURL) before resolving HTML entities. This allows an attacker to bypass protocol filtering by encoding dangerous schemes using HTML5 named character references. For example, a payload such as javascript&colon;alert(1) is not recognized as dangerous during validation, leading to arbitrary script execution in the context of applications that render the URL.
GitHub Security Advisory: GHSA-88v5-9hxc-f85r
Package: github.com/hashicorp/vault (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.21.4
Patched in: unpatched

Summary: HashiCorp Vault Vulnerable to Denial-of-Service via Unauthenticated Root Token Generation/Rekey Operations

Details:
Vault is vulnerable to a denial-of-service condition where an unauthenticated attacker can repeatedly initiate or cancel root token generation or rekey operations, occupying the single in-progress operation slot. This prevents legitimate operators from completing these workflows. This vulnerability, CVE-2026-5807, is fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0.
GitHub Security Advisory: GHSA-8r5m-3f66-qpr3
Package: github.com/hashicorp/vault (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 1.14.0, <= 1.21.4
Patched in: unpatched

Summary: HashiCorp Vault has Server-Side Request Forgery in ACME Challenge Validation via Attacker-Controlled DNS

Details:
Vault’s PKI engine’s ACME validation did not reject local targets when issuing http-01 and tls-alpn-01 challenges. This may lead to these requests being sent to local network targets, potentially leading to information disclosure. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16.
GitHub Security Advisory: GHSA-72gw-fmmr-c4r4
Package: github.com/hashicorp/vault (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: >= 0.11.2, <= 1.21.4
Patched in: unpatched

Summary: HashiCorp Vault May Expose Tokens to Auth Plugins Due to Incorrect Header Sanitization

Details:
If a Vault auth mount is configured to pass through the "Authorization" header, and the "Authorization" header is used to authenticate to Vault, Vault forwarded the Vault token to the auth plugin backend. Fixed in 2.0.0, 1.21.5, 1.20.10, and 1.19.16.
GitHub Security Advisory: GHSA-m2w4-8ggf-rj47
Package: github.com/hashicorp/vault (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 0.10.0, <= 1.21.4
Patched in: unpatched

Summary: HashiCorp Vault has a KVv2 Metadata and Secret Deletion Policy Bypass that leads to Denial-of-Service

Details:
An authenticated user with access to a kvv2 path through a policy containing a glob may be able to delete secrets they were not authorized to read or write, resulting in denial-of-service. This vulnerability did not allow a malicious user to delete secrets across namespaces, nor read any secret data. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16.
GitHub Security Advisory: GHSA-xgrm-4fwx-7qm8
Package: github.com/jackc/pgx/v5/pgproto3 (GO)
Severity: CRITICAL (CVSS 9.8)
Vulnerable versions: < 5.9.0
Patched in: 5.9.0

Summary: pgx contains memory-safety vulnerability

Details:
[pgx](github.com/jackc/pgx/v5) is a pure Go driver and toolkit for PostgreSQL. pgx prior to v5.9.0 contains a memory-safety vulnerability.
GitHub Security Advisory: GHSA-3xc5-wrhm-f963
Package: github.com/go-git/go-git/v6 (GO)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: <= 6.0.0-alpha.1
Patched in: 6.0.0-alpha.2

Summary: go-git: Credential leak via cross-host redirect in smart HTTP transport

Details:
### Impact
`go-git` may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations.

If a remote repository responds to the initial `/info/refs` request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host.

An attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim’s repositories or other resources, depending on the scope of the credential.

**Clients using `go-git` exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue.** The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data.

### Patches
Users should upgrade to `v5.18.0`, or `v6.0.0-alpha.2`, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported `go-git` version.

The patched versions add support for configuring [followRedirects](https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpfollowRedirects). In line with upstream behaviour, the default is now `initial`, while users can opt into `FollowRedirects` or `NoFollowRedirects` programmatically.

### Credit
Thanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the `go-git` project. :bow:
GitHub Security Advisory: GHSA-3xc5-wrhm-f963
Package: github.com/go-git/go-git/v5 (GO)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: <= 5.17.2
Patched in: 5.18.0

Summary: go-git: Credential leak via cross-host redirect in smart HTTP transport

Details:
### Impact
`go-git` may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations.

If a remote repository responds to the initial `/info/refs` request with a redirect to a different host, go-git updates the session endpoint to the redirected location and reuses the original authentication for subsequent requests. This can result in the credentials (e.g. Authorization headers) being sent to an unintended host.

An attacker controlling or influencing the redirect target can capture these credentials and potentially reuse them to access the victim’s repositories or other resources, depending on the scope of the credential.

**Clients using `go-git` exclusively with trusted remotes (for example, GitHub or GitLab), and over a secure HTTPS connection, are not affected by this issue.** The risk arises when interacting with untrusted or misconfigured Git servers, or when using unsecured HTTP connections, which is not recommended. Such configurations also expose clients to a broader class of security risks beyond this issue, including credential interception and tampering of repository data.

### Patches
Users should upgrade to `v5.18.0`, or `v6.0.0-alpha.2`, in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported `go-git` version.

The patched versions add support for configuring [followRedirects](https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpfollowRedirects). In line with upstream behaviour, the default is now `initial`, while users can opt into `FollowRedirects` or `NoFollowRedirects` programmatically.

### Credit
Thanks to the 3 separate reports from @celinke97, @N0zoM1z0 and @AyushParkara. Thanks for finding and reporting this issue privately to the `go-git` project. :bow:
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.3.0, < 1.15.14
Patched in: 1.15.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.