deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mqcj-8c2g-h97q
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.5.0, < 10.5.12
Patched in: 10.5.12

Summary: Mattermost Incorrect Authorization vulnerability

Details:
Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11 fail to properly validate team membership permissions in the Add Channel Member API, which allows users from one team to access user metadata and channel membership information from other teams via the API endpoint.
GitHub Security Advisory: GHSA-mqcj-8c2g-h97q
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.11.0, < 10.11.4
Patched in: 10.11.4

Summary: Mattermost Incorrect Authorization vulnerability

Details:
Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11 fail to properly validate team membership permissions in the Add Channel Member API, which allows users from one team to access user metadata and channel membership information from other teams via the API endpoint.
GitHub Security Advisory: GHSA-pm3x-jrhh-qcr7
Package: github.com/authzed/spicedb (GO)
Severity: LOW (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.45.2
Patched in: 1.45.2

Summary: SpiceDB WriteRelationships fails silently if payload is too big

Details:
### Impact

Users who:
1. Use the exclusion operator somewhere in their authorization schema.
1. Have configured their SpiceDB server such that `--write-relationships-max-updates-per-call` is bigger than 6500.
1. Issue calls to WriteRelationships with a large enough number of updates that cause the payload to be bigger than what their datastore allows.

Users will:

1. Receive a successful response from their `WriteRelationships` call, when in reality that call failed.
2. Receive incorrect permission check results, if those relationships had to be read to resolve the relation involving the exclusion.

### Patches

Upgrade to v.145.2.

### Workarounds

Set `--write-relationships-max-updates-per-call` to `1000`.
GitHub Security Advisory: GHSA-6jqf-mv7m-3q7p
Package: github.com/filebrowser/filebrowser/v2 (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 2.45.1
Patched in: 2.45.2

Summary: File Browser has risk of HTTP Request/Response smuggling through vulnerable dependency

Details:
The standard library `net/http` package dependency used by File Browser improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. I can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext.

See https://nvd.nist.gov/vuln/detail/CVE-2025-22871 for more details.
GitHub Security Advisory: GHSA-6cqf-cfhv-659g
Package: github.com/filebrowser/filebrowser/v2 (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-285: Improper Authorization, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2.45.1
Patched in: 2.45.1

Summary: File Browser is Vulnerable to Insecure Direct Object Reference (IDOR) in Share Deletion Function

Details:
### Summary
It has been found an Insecure Direct Object Reference (IDOR) vulnerability in the FileBrowser application's share deletion functionality. This vulnerability allows any authenticated user with share permissions to delete other users' shared links without authorization checks.

The impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.

### Details
**Technical Analysis**

The vulnerability exists in` /http/share.go` at lines 72-82. The shareDeleteHandler function processes deletion requests using only the share hash without comparing the link.UserID with the current authenticated user's ID (d.user.ID). This missing authorization check enables the vulnerability.

```
var shareDeleteHandler = withPermShare(func(_ http.ResponseWriter, r *http.Request, d *data) (int, error) {
    hash := strings.TrimSuffix(r.URL.Path, "/")
    hash = strings.TrimPrefix(hash, "/")

    if hash == "" {
        return http.StatusBadRequest, nil
    }

    err := d.store.Share.Delete(hash)  // Missing ownership validation
    return errToStatus(err), err
})
```

### PoC
**Reproduce Steps:**

Prerequisites: Two authenticated user accounts (User A and User B) with share permissions

Step 1: User A creates a share link and obtains the share hash (e.g., MEEuZK-v)

Step 2: User B authenticates and obtains a valid JWT token

Step 3: User B sends DELETE request to /api/share/MEEuZK-v with their own JWT token

Step 4: Observe that User A's share is deleted without authorization

DELETE /api/share/MEEuZK-v HTTP/1.1
Host: filebrowser.local
Content-Type: application/json

### Impact

The impact is significant as malicious actors can disrupt business operations by systematically removing shared files and links. This leads to denial of service for legitimate users, potential data loss in collaborative environments, and breach of data confidentiality agreements. In organizational settings, this could affect critical file sharing for projects, presentations, or document collaboration.
GitHub Security Advisory: GHSA-7wq2-32h4-9hc9
Package: github.com/aws/aws-advanced-go-wrapper/awssql (GO)
Severity: HIGH (CVSS 8.0)
CWE: CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: AWS Advanced Go Wrapper: Privilege Escalation in Aurora PostgreSQL Instance

Details:
### Description of Vulnerability: 
An issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rds_superuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.

We recommend customers upgrade to the following versions:  AWS Go Wrapper to 2025-10-17


### Source of Vulnerability Report: 
Allistair Ishmael Hakim [allistair.hakim@gmail.com](mailto:allistair.hakim@gmail.com)


### Affected products & versions: 
AWS Go Wrapper < 2025-10-17


### Platforms:
 MacOS/Windows/Linux
GitHub Security Advisory: GHSA-mhjq-8c7m-3f7p
Package: github.com/milvus-io/milvus (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 0.10.3-0[PII_REDACTED]1934-6102f001a971
Patched in: 0.10.3-0[PII_REDACTED]1934-6102f001a971

Summary: Milvus Proxy has a Critical Authentication Bypass Vulnerability

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_
An unauthenticated attacker can exploit this vulnerability to bypass all authentication mechanisms in the Milvus Proxy component, gaining full administrative access to the Milvus cluster.
This grants the attacker the ability to read, modify, or delete data, and to perform privileged administrative operations such as database or collection management.
All users running affected Milvus versions are strongly advised to upgrade immediately.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
This issue has been fixed in the following versions:
	•	Milvus 2.4.24
	•	Milvus 2.5.21
	•	Milvus 2.6.5

Users should upgrade to these patched versions or later to mitigate the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
If immediate upgrade is not possible, a temporary mitigation can be applied by removing the sourceID header from all incoming requests at the gateway, API gateway, or load balancer level before they reach the Milvus Proxy.
This prevents attackers from exploiting the authentication bypass behavior.

### References
_Are there any links users can visit to find out more?_

The following pull requests contain the fixes for the affected Milvus branches:
	•	[Fix for 2.4 branch](https://github.com/milvus-io/milvus/pull/45391)￼
	•	[Fix for 2.5 branch](https://github.com/milvus-io/milvus/pull/45383)￼
	•	[Fix for 2.6 branch](https://github.com/milvus-io/milvus/pull/45379)￼

Special thanks to the Volcengine Milvus team at ByteDance(liumingzhe.5689@bytedance.com) for responsibly discovering, reporting, and coordinating the disclosure of this critical authentication bypass vulnerability with the Milvus maintainers.
GitHub Security Advisory: GHSA-mhjq-8c7m-3f7p
Package: github.com/milvus-io/milvus (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 2.6.0, < 2.6.5
Patched in: 2.6.5

Summary: Milvus Proxy has a Critical Authentication Bypass Vulnerability

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_
An unauthenticated attacker can exploit this vulnerability to bypass all authentication mechanisms in the Milvus Proxy component, gaining full administrative access to the Milvus cluster.
This grants the attacker the ability to read, modify, or delete data, and to perform privileged administrative operations such as database or collection management.
All users running affected Milvus versions are strongly advised to upgrade immediately.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
This issue has been fixed in the following versions:
	•	Milvus 2.4.24
	•	Milvus 2.5.21
	•	Milvus 2.6.5

Users should upgrade to these patched versions or later to mitigate the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
If immediate upgrade is not possible, a temporary mitigation can be applied by removing the sourceID header from all incoming requests at the gateway, API gateway, or load balancer level before they reach the Milvus Proxy.
This prevents attackers from exploiting the authentication bypass behavior.

### References
_Are there any links users can visit to find out more?_

The following pull requests contain the fixes for the affected Milvus branches:
	•	[Fix for 2.4 branch](https://github.com/milvus-io/milvus/pull/45391)￼
	•	[Fix for 2.5 branch](https://github.com/milvus-io/milvus/pull/45383)￼
	•	[Fix for 2.6 branch](https://github.com/milvus-io/milvus/pull/45379)￼

Special thanks to the Volcengine Milvus team at ByteDance(liumingzhe.5689@bytedance.com) for responsibly discovering, reporting, and coordinating the disclosure of this critical authentication bypass vulnerability with the Milvus maintainers.
GitHub Security Advisory: GHSA-mhjq-8c7m-3f7p
Package: github.com/milvus-io/milvus (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 2.5.0, < 2.5.21
Patched in: 2.5.21

Summary: Milvus Proxy has a Critical Authentication Bypass Vulnerability

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_
An unauthenticated attacker can exploit this vulnerability to bypass all authentication mechanisms in the Milvus Proxy component, gaining full administrative access to the Milvus cluster.
This grants the attacker the ability to read, modify, or delete data, and to perform privileged administrative operations such as database or collection management.
All users running affected Milvus versions are strongly advised to upgrade immediately.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
This issue has been fixed in the following versions:
	•	Milvus 2.4.24
	•	Milvus 2.5.21
	•	Milvus 2.6.5

Users should upgrade to these patched versions or later to mitigate the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
If immediate upgrade is not possible, a temporary mitigation can be applied by removing the sourceID header from all incoming requests at the gateway, API gateway, or load balancer level before they reach the Milvus Proxy.
This prevents attackers from exploiting the authentication bypass behavior.

### References
_Are there any links users can visit to find out more?_

The following pull requests contain the fixes for the affected Milvus branches:
	•	[Fix for 2.4 branch](https://github.com/milvus-io/milvus/pull/45391)￼
	•	[Fix for 2.5 branch](https://github.com/milvus-io/milvus/pull/45383)￼
	•	[Fix for 2.6 branch](https://github.com/milvus-io/milvus/pull/45379)￼

Special thanks to the Volcengine Milvus team at ByteDance(liumingzhe.5689@bytedance.com) for responsibly discovering, reporting, and coordinating the disclosure of this critical authentication bypass vulnerability with the Milvus maintainers.
GitHub Security Advisory: GHSA-mhjq-8c7m-3f7p
Package: github.com/milvus-io/milvus (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 0.10.4, < 2.4.24
Patched in: 2.4.24

Summary: Milvus Proxy has a Critical Authentication Bypass Vulnerability

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_
An unauthenticated attacker can exploit this vulnerability to bypass all authentication mechanisms in the Milvus Proxy component, gaining full administrative access to the Milvus cluster.
This grants the attacker the ability to read, modify, or delete data, and to perform privileged administrative operations such as database or collection management.
All users running affected Milvus versions are strongly advised to upgrade immediately.

### Patches
_Has the problem been patched? What versions should users upgrade to?_
This issue has been fixed in the following versions:
	•	Milvus 2.4.24
	•	Milvus 2.5.21
	•	Milvus 2.6.5

Users should upgrade to these patched versions or later to mitigate the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
If immediate upgrade is not possible, a temporary mitigation can be applied by removing the sourceID header from all incoming requests at the gateway, API gateway, or load balancer level before they reach the Milvus Proxy.
This prevents attackers from exploiting the authentication bypass behavior.

### References
_Are there any links users can visit to find out more?_

The following pull requests contain the fixes for the affected Milvus branches:
	•	[Fix for 2.4 branch](https://github.com/milvus-io/milvus/pull/45391)￼
	•	[Fix for 2.5 branch](https://github.com/milvus-io/milvus/pull/45383)￼
	•	[Fix for 2.6 branch](https://github.com/milvus-io/milvus/pull/45379)￼

Special thanks to the Volcengine Milvus team at ByteDance(liumingzhe.5689@bytedance.com) for responsibly discovering, reporting, and coordinating the disclosure of this critical authentication bypass vulnerability with the Milvus maintainers.
GitHub Security Advisory: GHSA-88h9-77c7-p6w4
Package: github.com/evervault/evervault-go (GO)
Severity: HIGH (CVSS 8.7)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.3.2
Patched in: 1.3.2

Summary: Evervault Go SDK: Incomplete PCR Validation in Enclave Attestation for non-Evervault hosted Enclaves

Details:
### Summary

A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees.

The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. 

The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2.
 

### Patches
The identified issue has been addressed in version [1.3.2](https://github.com/evervault/evervault-go/pull/48) by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check.

### Workarounds
If you are using evervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade:

1) Modify your application logic to fail verification if PCR8 is not explicitly present and non-empty
2) Add custom pre-validation to reject documents that omit any required PCRs.

### POC
```
package evervault
import (
        "testing"

        "github.com/evervault/evervault-go/attestation"
        "github.com/stretchr/testify/assert"
        "github.com/hf/nitrite"
)


func TestVulnerableCompare(t *testing.T) {
          assert := assert.New(t)
          // arrange
          expectedPCRs := []attestation.PCRs{
                attestation.PCRs{
                      PCR0:
"[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000001",
                      PCR1:
"[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000002",
                      PCR2:
"[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000003",
                      PCR8:
"[PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED][PII_REDACTED]000004",
                     },
           }
            actualDocument := nitrite.Document {}
            actualDocument.PCRs = map[uint][]byte{
                    10: make([]byte, 32),
            }
            // act
            v := verifyPCRs(expectedPCRs, actualDocument)
            
            // assert
            // Verify should not pass but it does
            
            assert.Equal(true, v)
}
```
GitHub Security Advisory: GHSA-vjrc-mh2v-45x6
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax
Vulnerable versions: < 7.13.0
Patched in: 7.13.0

Summary: OAuth2-Proxy is vulnerable to header smuggling via underscore leading to potential privilege escalation

Details:
### Impact
All deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications).

Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised.

### Patches

This change mitigates a request header smuggling vulnerability where an attacker could bypass header stripping by using different capitalization or replacing dashes with underscores. The problem has been patched with v7.13.0.

By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away.

However, if users have a rationale for keeping a similar-looking header and don't want to strip it, a new configuration field for headers managed through AlphaConfig called InsecureSkipHeaderNormalization has been introduced :

```golang
// Header represents an individual header that will be added to a request or
// response header.
type Header struct {
	// Name is the header name to be used for this set of values.
	// Names should be unique within a list of Headers.
	Name string `json:"name,omitempty"`

	// PreserveRequestValue determines whether any values for this header
	// should be preserved for the request to the upstream server.
	// This option only applies to injected request headers.
	// Defaults to false (headers that match this header will be stripped).
	PreserveRequestValue bool `json:"preserveRequestValue,omitempty"`

	// InsecureSkipHeaderNormalization disables normalizing the header name
	// According to RFC 7230 Section 3.2 there aren't any rules about
	// capitalization of header names, but the standard practice is to use
	// Title-Case (e.g. X-Forwarded-For). By default, header names will be
	// normalized to Title-Case and any incoming headers that match will be
	// treated as the same header. Additionally underscores (_) in header names
	// will be converted to dashes (-) when normalizing.
	// Defaults to false (header names will be normalized).
	InsecureSkipHeaderNormalization bool `json:"InsecureSkipHeaderNormalization,omitempty"`

	// Values contains the desired values for this header
	Values []HeaderValue `json:"values,omitempty"`
}
```

### Workarounds
Ensure filtering and processing logic in upstream services don't treat underscores and hyphens in Headers the same way.
GitHub Security Advisory: GHSA-vwq2-jx9q-9h9f
Package: github.com/charmbracelet/soft-serve (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.11.1
Patched in: 0.11.1

Summary: Soft Serve is vulnerable to SSRF through its Webhooks

Details:
SUMMARY

We have identified and verified an SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints.


AFFECTED COMPONENTS (VERIFIED)

1. Webhook Creation (pkg/ssh/cmd/webhooks.go:125)
2. Backend CreateWebhook (pkg/backend/webhooks.go:17)
3. Backend UpdateWebhook (pkg/backend/webhooks.go:122)
4. Webhook Delivery (pkg/webhook/webhook.go:97)

IMPACT

This vulnerability allows repository administrators to perform SSRF attacks, potentially enabling:

a) Cloud Metadata Theft - Access AWS/Azure/GCP credentials via 169.254.169.254
b) Internal Network Access - Target localhost and private networks (10.x, 192.168.x, 172.16.x)
c) Port Scanning - Enumerate internal services via response codes and timing
d) Data Exfiltration - Full HTTP responses stored in webhook delivery logs
e) Internal API Access - Call internal admin panels and Kubernetes endpoints

PROOF OF CONCEPT

Simple example demonstrating localhost access:

```sh
ssh localhost webhook create my-repo http://127.0.0.1:8080/internal \
    --events push --active
```

then push to trigger.
GitHub Security Advisory: GHSA-fv2r-r8mp-pg48
Package: github.com/charmbracelet/soft-serve (GO)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: <= 0.10.0
Patched in: 0.11.0

Summary: Soft Serve does not sanitize ANSI escape sequences in user input

Details:
### Impact
In several places where the user can insert data (e.g. names), ANSI escape sequences are not being removed, which can then be used, for example, to show fake alerts.

In the same token, git messages, when printed, are also not being sanitized.

Places in which this was found:

1. Repository Description (pkg/backend/repo.go - SetDescription)
2. Repository Project Name (pkg/backend/repo.go - SetProjectName)
3. Git Commit Author Names (pkg/ssh/cmd/commit.go:69)
4. Git Commit Messages (pkg/ssh/cmd/commit.go:71)
5. Access Token Names (pkg/ssh/cmd/token.go:107)
6. Webhook URLs (pkg/ssh/cmd/webhooks.go:72)

### Patches
v0.11.0

### Workarounds
No.

### References
n/a