deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5hvv-m4w4-gf6v
Package: github.com/oauth2-proxy/oauth2-proxy (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: <= 3.2.0
Patched in: unpatched

Summary:  OAuth2 Proxy's Health Check User-Agent Matching Bypasses Authentication in auth_request Mode

Details:
### Impact
A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

- OAuth2 Proxy is used with an `auth_request`-style integration   (for example, nginx `auth_request`)
- `--ping-user-agent` is set or `--gcp-healthchecks` is enabled

In affected configurations, OAuth2 Proxy will treat a request with the configured health check `User-Agent` value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.

This issue does not affect deployments that do not use `auth_request`-style subrequests, or that do not enable  `--ping-user-agent`/`--gcp-healthchecks`.

### Patches
Users should upgrade to `v7.15.2` or later once available. Deployments running versions prior to `v7.15.2` should be considered affected if they use `auth_request`-style authentication together with `--ping-user-agent` or  `--gcp-healthchecks`.

### Workarounds
Users can mitigate this issue by:

- disabling `--gcp-healthchecks`
- removing any configured `--ping-user-agent`
- ensuring the reverse proxy does not forward client-controlled `User-Agent`  headers to the OAuth2 Proxy auth subrequest
- using path-based health checks only, on dedicated health check endpoints

Example nginx mitigation for the auth subrequest:

```nginx
location = /oauth2/auth {
    internal;
    proxy_pass http://127.0.0.1:4180;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header Host $host;
    # set to value that isn't the same as your configured PingUserAgent or GCPs "GoogleHC/1.0"
    proxy_set_header User-Agent "oauth2-proxy-auth-request";
}
```
GitHub Security Advisory: GHSA-5hvv-m4w4-gf6v
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: < 7.15.2
Patched in: 7.15.2

Summary:  OAuth2 Proxy's Health Check User-Agent Matching Bypasses Authentication in auth_request Mode

Details:
### Impact
A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

- OAuth2 Proxy is used with an `auth_request`-style integration   (for example, nginx `auth_request`)
- `--ping-user-agent` is set or `--gcp-healthchecks` is enabled

In affected configurations, OAuth2 Proxy will treat a request with the configured health check `User-Agent` value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.

This issue does not affect deployments that do not use `auth_request`-style subrequests, or that do not enable  `--ping-user-agent`/`--gcp-healthchecks`.

### Patches
Users should upgrade to `v7.15.2` or later once available. Deployments running versions prior to `v7.15.2` should be considered affected if they use `auth_request`-style authentication together with `--ping-user-agent` or  `--gcp-healthchecks`.

### Workarounds
Users can mitigate this issue by:

- disabling `--gcp-healthchecks`
- removing any configured `--ping-user-agent`
- ensuring the reverse proxy does not forward client-controlled `User-Agent`  headers to the OAuth2 Proxy auth subrequest
- using path-based health checks only, on dedicated health check endpoints

Example nginx mitigation for the auth subrequest:

```nginx
location = /oauth2/auth {
    internal;
    proxy_pass http://127.0.0.1:4180;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header Host $host;
    # set to value that isn't the same as your configured PingUserAgent or GCPs "GoogleHC/1.0"
    proxy_set_header User-Agent "oauth2-proxy-auth-request";
}
```
GitHub Security Advisory: GHSA-f24x-5g9q-753f
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: LOW (CVSS 3.5)
CWE: CWE-384: Session Fixation, CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 7.11.0, < 7.15.2
Patched in: 7.15.2

Summary: OAuth2 Proxy's session cookies are not cleared when rendering sign-in page

Details:
### Impact
A regression introduced in [v7.11.0](https://github.com/oauth2-proxy/oauth2-proxy/pull/2605) is preventing OAuth2 Proxy from clearing the session cookie when rendering the sign-in page.

This only impacts deployments that rely on the sign-in page as part of their logout flow. In those setups, a user may be shown the sign-in page while the existing session cookie remains valid, so the browser session is not actually logged out. On shared workstations be it browsers or devices, a subsequent  user could continue to use the previous user's authenticated session.

Deployments that use a dedicated logout/sign-out endpoint to terminate sessions are not affected.

### Patches
This issue is fixed in v7.15.2.

### Workarounds
Do not rely on the sign-in page to clear an existing session. Instead:

- Use the dedicated logout/sign-out endpoint of OAuth2 Proxy
- Ensure your application logout flow explicitly clears the OAuth2 Proxy   session cookie before redirecting users to the sign-in page
- If needed, clear the session cookie at the reverse proxy or application   layer as a temporary mitigation
GitHub Security Advisory: GHSA-hc8w-h2mf-hp59
Package: github.com/containers/podman/v5 (GO)
Severity: MODERATE (CVSS 7.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 5.8.1
Patched in: 5.8.2

Summary: PowerShell Command Injection in Podman HyperV Machine

Details:
## Summary

A command injection vulnerability exists in Podman's HyperV machine backend. The VM image path is inserted into a PowerShell double-quoted string without sanitization, allowing `$()` subexpression injection.

## Affected Code

**File**: `pkg/machine/hyperv/stubber.go:647`

```go
resize := exec.Command("powershell", []string{
    "-command",
    fmt.Sprintf("Resize-VHD \"%s\" %d", imagePath.GetPath(), newSize.ToBytes()),
}...)
```



## Root Cause

PowerShell evaluates `$()` subexpressions inside double-quoted strings before executing the outer command. The `fmt.Sprintf` call places the user-controlled image path directly into double quotes without escaping or sanitization.

## Impact

An attacker who can control the VM image path (through a crafted machine name or image directory) can execute arbitrary PowerShell commands with the privileges of the Podman process on the Windows host. On typical Windows installations, this means SYSTEM-level code execution.


## Patch

https://github.com/containers/podman/commit/571c842bd357ee626019ea97d030fb772fc654ed

The affected code is only used on Windows, all other operating systems are not affected by this and can thus ignore the CVE patch.

## Credit

We like to thank Sang-Hoon Choi (@KoreaSecurity) for reporting this issue to us.
GitHub Security Advisory: GHSA-hc8w-h2mf-hp59
Package: github.com/containers/podman/v4 (GO)
Severity: MODERATE (CVSS 7.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 4.8.0, <= 4.9.5
Patched in: unpatched

Summary: PowerShell Command Injection in Podman HyperV Machine

Details:
## Summary

A command injection vulnerability exists in Podman's HyperV machine backend. The VM image path is inserted into a PowerShell double-quoted string without sanitization, allowing `$()` subexpression injection.

## Affected Code

**File**: `pkg/machine/hyperv/stubber.go:647`

```go
resize := exec.Command("powershell", []string{
    "-command",
    fmt.Sprintf("Resize-VHD \"%s\" %d", imagePath.GetPath(), newSize.ToBytes()),
}...)
```



## Root Cause

PowerShell evaluates `$()` subexpressions inside double-quoted strings before executing the outer command. The `fmt.Sprintf` call places the user-controlled image path directly into double quotes without escaping or sanitization.

## Impact

An attacker who can control the VM image path (through a crafted machine name or image directory) can execute arbitrary PowerShell commands with the privileges of the Podman process on the Windows host. On typical Windows installations, this means SYSTEM-level code execution.


## Patch

https://github.com/containers/podman/commit/571c842bd357ee626019ea97d030fb772fc654ed

The affected code is only used on Windows, all other operating systems are not affected by this and can thus ignore the CVE patch.

## Credit

We like to thank Sang-Hoon Choi (@KoreaSecurity) for reporting this issue to us.
GitHub Security Advisory: GHSA-xm5m-wgh2-rrg3
Package: github.com/sigstore/timestamp-authority/v2 (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 2.0.5
Patched in: 2.0.6

Summary: Sigstore Timestamp Authority has Improper Certificate Validation in verifier

Details:
### Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier

An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): `VerifyTimestampResponse` function correctly verifies the certificate chain but when the TSA specific constraints are verified in `VerifyLeafCert`, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls. 

This vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.

This vulnerability does **not** apply to sigstore-go even though it is a user of `timestamp-authority/v2/pkg/verification`: Providing `TSACertificate` option to  `VerifyTimestampResponse` fully mitigates the issue.


### Patches

The issue will be fixed in timestamp-authority 2.0.6

### Workarounds

Users of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.

### References

This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)
GitHub Security Advisory: GHSA-p5w6-75f9-cc2p
Package: github.com/enchant97/note-mark/backend (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 0.0.0[PII_REDACTED]5[PII_REDACTED]855ad
Patched in: 0.0.0[PII_REDACTED]5[PII_REDACTED]855ad

Summary: Note Mark has Broken Access Control on Asset Download

Details:
### Summary
A broken access control vulnerability allows unauthenticated users to retrieve note assets directly from the asset download endpoint when they know both the note UUID and asset UUID. This exposes the full contents of private note assets without authentication, even when the associated book is not public.

### Details
The issue is caused by the asset download route being registered without authentication middleware.

Relevant route registration:
- `handlers/assets.go`, line 40

```go
huma.Get(api, "/api/notes/{noteID}/assets/{assetID}", h.GetNoteAssetContentByID)
```

By contrast, other asset operations correctly apply authentication middleware. For example:

```go
huma.Delete(api, "/api/notes/{noteID}/assets/{assetID}", h.DeleteNoteAsset,
    huma.WithMiddleware(h.authMiddleware.AuthRequiredMiddleware))
```

The backend service for asset retrieval also does not enforce ownership or visibility checks. According to the provided code references, the lookup only queries the asset table by asset ID and note ID:

```sql
SELECT * FROM note_assets WHERE id = ? AND note_id = ?
```

Because the retrieval path does not join against the related `notes` or `books` records, it does not verify:
- whether the requester owns the parent book
- whether the parent book is public or private
- whether the related note has been deleted

As a result, possession of a valid `noteID` and `assetID` is sufficient to retrieve the asset binary, regardless of whether the note belongs to a private book.

The exploitability is constrained by identifier knowledge. Both `noteID` and `assetID` are UUIDv4 values, so blind guessing is impractical. However, the endpoint remains vulnerable whenever those identifiers are disclosed through another channel, such as leaked links, browser history, proxy logs, shared URLs, or other application behaviors that expose internal asset references.

### PoC
The issue can be reproduced by creating a private note with an attached asset, then requesting the asset download endpoint without authentication using the valid `noteID` and `assetID`. The server returns the asset content even though the associated note is private.

### Impact
- **Type:** Broken access control / unauthenticated information disclosure
- **Who is impacted:** Any deployment exposing the affected asset download endpoint
- **Security impact:** Full binary contents of private note assets can be disclosed to unauthenticated users who know the required identifiers
- **Attack preconditions:** The attacker must know both the target `noteID` and `assetID`; no authentication is required
- **Attack complexity:** High, because successful exploitation depends on prior disclosure of both UUIDs rather than feasible online guessing
GitHub Security Advisory: GHSA-w6m9-39cv-2fwp
Package: github.com/enchant97/note-mark/backend (GO)
Severity: LOW (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 0.19.2-0[PII_REDACTED]5025-cf4c6f6acf70
Patched in: 0.19.2-0[PII_REDACTED]5025-cf4c6f6acf70

Summary: Note Mark: Username Enumeration via Login Endpoint Timing Side-Channel

Details:
### Summary
A timing side-channel in the login endpoint allows unauthenticated attackers to determine whether a username exists by measuring response time differences. Requests for valid usernames take noticeably longer because the server performs bcrypt password verification, while requests for nonexistent usernames return much faster. This enables reliable remote username enumeration and increases the risk of targeted credential attacks.

### Details
The issue affects the login endpoint:

- `POST /api/auth/token`

The root cause is that authentication processing takes different code paths depending on whether the supplied username exists. When the username is found, the server performs `bcrypt.CompareHashAndPassword`, which adds substantial latency. When the username does not exist, the server returns immediately without performing an equivalent bcrypt operation.

Vulnerable flow:

```go
user, err := db.Where("username = ?", username).First(&user)
if err != nil {
    return ErrUnauthorized
}
err = bcrypt.CompareHashAndPassword(user.PasswordHash, []byte(password))
```

This creates a measurable timing discrepancy between:
- **existing username + wrong password** requests, which incur bcrypt cost
- **nonexistent username + any password** requests, which avoid bcrypt entirely

Because no constant-time equalization is performed, the endpoint leaks account existence through timing behavior.

The measurements provided show a large and consistent gap between the two cases across repeated trials, making the difference distinguishable without requiring especially high request volume. In the supplied test results:
- existing user requests averaged about `0.0616s`
- nonexistent user requests averaged about `0.0027s`

That gap is large enough to support reliable username enumeration under typical testing conditions.

### PoC
The issue can be reproduced by sending repeated authentication attempts to the login endpoint using the same invalid password while alternating between a known valid username and a nonexistent username, then comparing average response times. Valid usernames consistently take longer because bcrypt verification is performed.

### Impact
- **Type:** Timing side-channel / username enumeration
- **Who is impacted:** Any deployment exposing the affected login endpoint
- **Security impact:** Unauthenticated attackers can confirm valid usernames one at a time, improving the effectiveness of credential stuffing, password spraying, phishing, and other targeted account attacks
- **Attack preconditions:** None beyond network access to the login endpoint
- **Confidentiality impact:** Low to moderate, depending on the sensitivity of account existence in the target environment
GitHub Security Advisory: GHSA-q98v-9f9w-f49q
Package: go.temporal.io/server (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 1.30.0-143.0, < 1.30.4
Patched in: 1.30.4

Summary: Temporal does not enforce authentication and authorization for the streaming AdminService/StreamWorkflowReplicationMessages endpoint

Details:
The frontend gRPC server's streaming interceptor chain did not include the authorization interceptor. When a ClaimMapper and Authorizer are configured, unary RPCs enforce authentication and authorization, but the streaming AdminService/StreamWorkflowReplicationMessages endpoint accepted requests without credentials. This endpoint is registered on the same port as WorkflowService and cannot be disabled independently. An attacker with network access to the frontend port could open the replication stream without authentication. Data exfiltration is possible, but  only when a configured replication target is correctly configured and the attacker has knowledge of the cluster configuration, as the history service validates cluster IDs and peer membership before returning replication data.




Temporal Cloud is not affected.
GitHub Security Advisory: GHSA-q98v-9f9w-f49q
Package: go.temporal.io/server (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: >= 1.29.0-135.0, < 1.29.6
Patched in: 1.29.6

Summary: Temporal does not enforce authentication and authorization for the streaming AdminService/StreamWorkflowReplicationMessages endpoint

Details:
The frontend gRPC server's streaming interceptor chain did not include the authorization interceptor. When a ClaimMapper and Authorizer are configured, unary RPCs enforce authentication and authorization, but the streaming AdminService/StreamWorkflowReplicationMessages endpoint accepted requests without credentials. This endpoint is registered on the same port as WorkflowService and cannot be disabled independently. An attacker with network access to the frontend port could open the replication stream without authentication. Data exfiltration is possible, but  only when a configured replication target is correctly configured and the attacker has knowledge of the cluster configuration, as the history service validates cluster IDs and peer membership before returning replication data.




Temporal Cloud is not affected.
GitHub Security Advisory: GHSA-q98v-9f9w-f49q
Package: go.temporal.io/server (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 1.28.4
Patched in: 1.28.4

Summary: Temporal does not enforce authentication and authorization for the streaming AdminService/StreamWorkflowReplicationMessages endpoint

Details:
The frontend gRPC server's streaming interceptor chain did not include the authorization interceptor. When a ClaimMapper and Authorizer are configured, unary RPCs enforce authentication and authorization, but the streaming AdminService/StreamWorkflowReplicationMessages endpoint accepted requests without credentials. This endpoint is registered on the same port as WorkflowService and cannot be disabled independently. An attacker with network access to the frontend port could open the replication stream without authentication. Data exfiltration is possible, but  only when a configured replication target is correctly configured and the attacker has knowledge of the cluster configuration, as the history service validates cluster IDs and peer membership before returning replication data.




Temporal Cloud is not affected.
GitHub Security Advisory: GHSA-ghc4-35x6-crw5
Package: github.com/envoyproxy/envoy (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-863: Incorrect Authorization
Vulnerable versions: <= 1.34.12
Patched in: 1.34.13

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

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

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

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

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

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

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

## 4. Reproduction Steps
To verify this vulnerability:

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

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

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

**Credit:** Dor Konis