deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-4fxq-2x3x-6xqx
Package: github.com/openziti/zrok/v2 (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: < 2.0.1
Patched in: 2.0.1

Summary: zrok: Reflected XSS in GitHub OAuth callback via unsanitized refreshInterval error rendering

Details:
**Summary**
The proxyUi template engine uses Go's text/template (which performs no HTML escaping) instead of html/template. The GitHub OAuth callback handlers in both publicProxy and dynamicProxy embed the attacker-controlled refreshInterval query parameter verbatim into an error message when time.ParseDuration fails, and render that error unescaped into HTML. An attacker can deliver a crafted login URL to a victim; after the victim completes the GitHub OAuth flow, the callback page executes arbitrary JavaScript in the OAuth server's origin.

- Attack Vector: Network — the attack is delivered as a crafted URL over the internet.
- Attack Complexity: Low — no race conditions or special environment prerequisites.
- Privileges Required: None — the attacker needs no account on the zrok instance.
- User Interaction: Required — the victim must click the crafted link and complete the GitHub OAuth flow.
- Scope: Changed — the injected script executes in the OAuth server's origin, not the victim's share origin.
- Confidentiality Impact: Low — the script runs in the OAuth server origin after a failed flow; no session cookie is set at this point, limiting what can be exfiltrated to what is visible in the DOM and what can be requested from the OAuth server.
- Integrity Impact: Low — the script can initiate new OAuth flows or submit forms on behalf of the victim in the OAuth server origin.
- Availability Impact: None.

**Affected Components**

- endpoints/proxyUi/template.go — init() / WriteTemplate (lines 8, 18, 99) — text/template used for HTML rendering
- endpoints/proxyUi/template.html — line 119 — {{ .Error }} in HTML without escaping
- endpoints/publicProxy/providerGithub.go — login callback closure (lines 93, 128, 130)
- endpoints/dynamicProxy/providerGithub.go — loginHandler() (lines 110, 146, 148)
GitHub Security Advisory: GHSA-4fxq-2x3x-6xqx
Package: github.com/openziti/zrok (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: <= 1.1.11
Patched in: unpatched

Summary: zrok: Reflected XSS in GitHub OAuth callback via unsanitized refreshInterval error rendering

Details:
**Summary**
The proxyUi template engine uses Go's text/template (which performs no HTML escaping) instead of html/template. The GitHub OAuth callback handlers in both publicProxy and dynamicProxy embed the attacker-controlled refreshInterval query parameter verbatim into an error message when time.ParseDuration fails, and render that error unescaped into HTML. An attacker can deliver a crafted login URL to a victim; after the victim completes the GitHub OAuth flow, the callback page executes arbitrary JavaScript in the OAuth server's origin.

- Attack Vector: Network — the attack is delivered as a crafted URL over the internet.
- Attack Complexity: Low — no race conditions or special environment prerequisites.
- Privileges Required: None — the attacker needs no account on the zrok instance.
- User Interaction: Required — the victim must click the crafted link and complete the GitHub OAuth flow.
- Scope: Changed — the injected script executes in the OAuth server's origin, not the victim's share origin.
- Confidentiality Impact: Low — the script runs in the OAuth server origin after a failed flow; no session cookie is set at this point, limiting what can be exfiltrated to what is visible in the DOM and what can be requested from the OAuth server.
- Integrity Impact: Low — the script can initiate new OAuth flows or submit forms on behalf of the victim in the OAuth server origin.
- Availability Impact: None.

**Affected Components**

- endpoints/proxyUi/template.go — init() / WriteTemplate (lines 8, 18, 99) — text/template used for HTML rendering
- endpoints/proxyUi/template.html — line 119 — {{ .Error }} in HTML without escaping
- endpoints/publicProxy/providerGithub.go — login callback closure (lines 93, 128, 130)
- endpoints/dynamicProxy/providerGithub.go — loginHandler() (lines 110, 146, 148)
GitHub Security Advisory: GHSA-9gcg-w975-3rjh
Package: istio.io/istio (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-185: Incorrect Regular Expression
Vulnerable versions: >= 0.0.0[PII_REDACTED]0207-0bf27d49ba4b, < 0.0.0[PII_REDACTED]4500-692e460c342d
Patched in: 0.0.0[PII_REDACTED]4500-692e460c342d

Summary: Istio: AuthorizationPolicy serviceAccounts regex injection via unescaped dots

Details:
### Impact
The `serviceAccounts` and `notServiceAccounts` fields in AuthorizationPolicy incorrectly interpret dots (`.`) as a regular expression matcher. Because `.` is a valid character in a service account name, an `AuthorizationPolicy` ALLOW rule targeting SA e.g. `cert-manager.io` also matches `cert-manager-io`, `cert-managerXio`, etc. A DENY rule targeting the same name fails to block those variants.

### Patches
Fixes are available in 1.29.2, 1.28.6, and 1.27.9

### Workarounds
None
GitHub Security Advisory: GHSA-pc3f-x583-g7j2
Package: github.com/moby/spdystream (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.5.0
Patched in: 0.5.1

Summary: SpdyStream: DOS on CRI

Details:
The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:
1. **SETTINGS entry count** -- The SETTINGS frame reader reads a 32-bit
`numSettings` from the payload and allocates a slice of that size
without checking it against the declared frame length. An attacker
can set `numSettings` to a value far exceeding the actual payload,
triggering a large allocation before any setting data is read.
 
2. **Header count** -- `parseHeaderValueBlock` reads a 32-bit
`numHeaders` from the decompressed header block and allocates an
`http.Header` map of that size with no upper bound.
 
3. **Header field size** -- Individual header name and value lengths are
read as 32-bit integers and used directly as allocation sizes with
no validation.
 
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.
## Impact
 Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the process with a single
crafted SPDY control frame, causing denial of service.
## Affected versions
 `github.com/moby/spdystream` <= v0.5.0
## Fix
 v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
 
**Core fixes:**
 
- **SETTINGS entry-count validation** -- The SETTINGS frame reader now
checks that `numSettings` is consistent with the declared frame
length (`numSettings <= (length-4)/8`) before allocating.
 
- **Header count limit** -- `parseHeaderValueBlock` enforces a maximum
number of headers per frame (default: 1000).
 
- **Header field size limit** -- Individual header name and value
lengths are checked against a per-field size limit (default: 1 MiB)
before allocation.
 
- **Connection closure on protocol error** -- The connection read loop
now closes the underlying `net.Conn` when it encounters an
`InvalidControlFrame` error, preventing further exploitation on the
same connection.
 
**Additional hardening:**
 
- **Write-side bounds checks** -- All frame write methods now verify
that payloads fit within the 24-bit length field, preventing the
library from producing invalid frames.
 
**Configurable limits:**
 
- Callers can adjust the defaults using `NewConnectionWithOptions` or
the lower-level `spdy.NewFramerWithOptions` with functional options:
`WithMaxControlFramePayloadSize`, `WithMaxHeaderFieldSize`, and
`WithMaxHeaderCount`.
GitHub Security Advisory: GHSA-pxq7-h93f-9jrg
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: >= 7.5.0, < 7.15.2
Patched in: 7.15.2

Summary: OAuth2 Proxy has an Authentication Bypass via Fragment Confusion in skip_auth_routes and skip_auth_regex

Details:
### Impact

A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

* Use of `skip_auth_routes` or the legacy `skip_auth_regex` * Use of patterns that can be widened by attacker-controlled suffixes,    such as `^/foo/.*/bar$` causing potential exposure of `/foo/secret` * Protected upstream applications that interpret `#` as a fragment delimiter    or otherwise route the request to the protected base path

In deployments that rely on these settings, an unauthenticated attacker can send a crafted request containing a number sign in the path, including the browser-safe encoded form `%23`, so that OAuth2 Proxy matches a public allowlist rule while the backend serves a protected resource.

Deployments that do not use these skip-auth options, or that only allow exact public paths with tightly scoped method and path rules, **ARE NOT** affected.

### Patches

A fix has been implemented to normalize request paths more conservatively before skip-auth matching so fragment content does not influence allowlist decisions.

Released as part of `v7.15.2`

### Workarounds

Users who cannot upgrade immediately can reduce exposure by tightening or removing `skip_auth_routes` and `skip_auth_regex` rules, especially patterns that use broad wildcards across path segments.

Recommended mitigations:

* Replace broad rules with exact, anchored public paths and explicit HTTP methods
* Reject requests whose path contains `%23` or `#` at the ingress, load balancer, or WAF level
* Avoid placing sensitive application paths behind broad `skip_auth_routes` rules
GitHub Security Advisory: GHSA-c5c4-8r6x-56w3
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 7.15.2
Patched in: 7.15.2

Summary: OAuth2 Proxy has an Authorization Bypass in Email Domain Validation via Malformed Multi-@ Email Claims

Details:
### Impact

An authorization bypass exists in OAuth2 Proxy as part of the `email_domain` enforcement option. An attacker may be able to authenticate with an email claim such as `attacker@evil.com@company.com` and satisfy an allowed domain check for `company.com`, even though the claim is not a valid email address.

The issue **ONLY** affects deployments that rely on `email_domain` restrictions and accept email claim values from identity providers or claim mappings that do not strictly enforce normal email syntax. The practical risk ONLY exists in self-hosted or custom OIDC environments and federated setups where unexpected claim values can reach oauth2-proxy. Standard hosted providers that enforce valid email formatting ARE NOT effected.

### Patches
Users should upgrade to `v7.15.2` or later once available.

### Workarounds
The most effective workaround is to ensure the configured identity provider cannot emit malformed or attacker-controlled email claim values.
GitHub Security Advisory: GHSA-7x63-xv5r-3p2x
Package: github.com/oauth2-proxy/oauth2-proxy/v7 (GO)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: >= 7.5.0, < 7.15.2
Patched in: 7.15.2

Summary: OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing

Details:
### Impact

A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

* OAuth2 Proxy is configured with `--reverse-proxy`
* and at least one rule is defined with `--skip_auth_routes` or the legacy `--skip-auth-regex`

OAuth2 Proxy may trust a client-supplied `X-Forwarded-Uri` header when `--reverse-proxy` is enabled and `--skip-auth-route` or `--skip-auth-regex` is configured. An attacker can spoof this header so OAuth2 Proxy evaluates authentication and skip-auth rules against a different path than the one actually sent to the upstream application.

This can result in an unauthenticated remote attacker bypassing authentication and accessing protected routes without a valid session.


### Patches
This issue is addressed as part of the newly introduced `--trusted-proxy-ip` flag in `v7.15.2`. If you leave it unset, OAuth2 Proxy will **continue to trust ALL** source IPs (0.0.0.0/0) for backwards compatibility, which means a client may still be able to spoof forwarded headers. Therefore after upgrading we urge you to use the new `--trusted-proxy-ip` flag to set the IPs or CIDR ranges of the reverse proxies that are allowed to send `X-Forwarded-*` headers and furthermore implement the mitigation steps outlined below to properly configure your load balancer infrastructure.

### Mitigation

- Strip any client-provided `X-Forwarded-Uri` header at the reverse proxy or load balancer level
- Explicitly overwrite `X-Forwarded-Uri` with the actual request URI before forwarding requests to OAuth2 Proxy

  Example nginx mitigation for the auth subrequest:
  ```
    location /internal-auth/ {
      internal; # Ensure external users can't access this path
  
      # Make sure the OAuth2 Proxy knows where the original request came from.
      proxy_set_header Host       $host;
      proxy_set_header X-Real-IP  $remote_addr;
      # set the value to the actual $request_uri and therefore strip any user provided X-Forwarded-Uri
      proxy_set_header X-Forwarded-Uri $request_uri;
  
      proxy_pass http://oauth2-proxy:4180/;
    }
  ```
- Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy
- Remove or narrow `--skip-auth-route` / `--skip-auth-regex` rules where possible
GitHub Security Advisory: GHSA-c4hg-6933-x62x
Package: github.com/apache/skywalking-mcp (GO)
Severity: HIGH (CVSS 7.1)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Apache SkyWalking MCP: Server-Side Request Forgery via SW-URL Header in MCP Server

Details:
Server-Side Request Forgery via SW-URL Header vulnerability in Apache SkyWalking MCP.

This issue affects Apache SkyWalking MCP: 0.1.0.

Users are recommended to upgrade to version 0.2.0, which fixes this issue.
GitHub Security Advisory: GHSA-7jrq-q4pq-rhm6
Package: github.com/oxia-db/oxia (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 0.16.1
Patched in: 0.16.2

Summary: Oxia's TLS CA certificate chain validation fails with multi-certificate PEM bundles

Details:
### Summary
The `trustedCertPool()` function in the TLS configuration only parses the first PEM block from CA certificate files. When a CA bundle contains multiple certificates (e.g., intermediate + root CA), only the first certificate is loaded. This silently breaks certificate chain validation for mTLS.

### Impact
In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with `x509: certificate signed by unknown authority`. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification.

All versions using TLS with `trustedCaFile` configuration are affected.

### Details
In `common/security/tls.go`, the `trustedCertPool()` method calls `pem.Decode()` only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from `pem.Decode` is ignored, so a corrupted CA file results in an empty certificate pool without any error.

### Patches
Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.

### Workarounds
Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).
GitHub Security Advisory: GHSA-5gqc-qhrj-9xw8
Package: github.com/oxia-db/oxia (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: <= 0.16.1
Patched in: 0.16.2

Summary: Oxia affected by server crash via race condition in session heartbeat handling

Details:
### Summary
A race condition between session heartbeat processing and session closure can cause the server to panic with `send on closed channel`. The `heartbeat()` method uses a blocking channel send while holding a mutex, and under specific timing with concurrent `close()` calls, this can lead to either a deadlock (channel buffer full) or a panic (send on closed channel after TOCTOU gap in `KeepAlive`).

### Impact
A remote client can trigger a server crash by sending rapid `KeepAlive` requests while a session is expiring or being closed. This is a denial-of-service vulnerability that crashes the entire data server process.

All versions are affected.

### Details
In `oxiad/dataserver/controller/lead/session.go`, the `heartbeat()` method performs a blocking `s.heartbeatCh <- true` send. If the channel buffer is full (size 1), this blocks while holding the session mutex, preventing `close()` from acquiring the lock to close the channel — a deadlock.

Additionally, in `session_manager.go`, `KeepAlive()` releases the session manager's read lock before calling `heartbeat()`, creating a TOCTOU window where the session can be removed and closed between the lookup and the heartbeat call.

### Patches
Fixed by changing `heartbeat()` to use a non-blocking `select` with a `default` case, and by holding the session manager read lock through the entire `KeepAlive()` operation.

### Workarounds
No workaround available.
GitHub Security Advisory: GHSA-fhvp-9hcj-6m33
Package: github.com/oxia-db/oxia (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 0.16.1
Patched in: 0.16.2

Summary: Oxia has an OIDC token audience validation bypass via SkipClientIDCheck

Details:
### Summary
The OIDC authentication provider unconditionally sets `SkipClientIDCheck: true` in the `go-oidc` verifier configuration, disabling the standard audience (`aud`) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia.

### Impact
In deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different `client_id`/`aud`) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC.

All versions using OIDC authentication are affected.

### Details
In `oxiad/common/rpc/auth/oidc.go`, both `createStaticKeyVerifier()` and `createRemoteVerifier()` set `SkipClientIDCheck: true`. While a custom audience check exists in `Authenticate()`, the library-level check — which validates the `aud` claim against the expected `client_id` — is completely bypassed.

### Patches
Fixed by removing `SkipClientIDCheck: true` and setting the `ClientID` field from the configured `AllowedAudiences`.

### Workarounds
Ensure network-level isolation so that only trusted services can reach the Oxia gRPC endpoints.
GitHub Security Advisory: GHSA-pm7q-rjjx-979p
Package: github.com/oxia-db/oxia (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: <= 0.16.1
Patched in: 0.16.2

Summary: Oxia exposes bearer token in debug log messages on authentication failure

Details:
### Summary
When OIDC authentication fails, the full bearer token is logged at DEBUG level in plaintext. If debug logging is enabled in production, JWT tokens are exposed in application logs and any connected log aggregation system.

### Impact
An attacker with access to application logs (e.g., via a compromised log aggregation pipeline, shared logging infrastructure, or misconfigured log access controls) can extract valid JWT tokens and replay them to authenticate as legitimate users.

All versions using OIDC authentication are affected.

### Details
In `oxiad/common/rpc/auth/interceptor.go`, the `validateTokenWithContext()` function logs the complete token value via `slog.String("token", token)` when authentication fails. This includes the full JWT header, payload, and signature.

### Patches
Fixed by redacting the token in log output — only the last 8 characters are preserved for correlation purposes.

### Workarounds
Ensure DEBUG-level logging is never enabled in production environments.
GitHub Security Advisory: GHSA-77fj-vx54-gvh7
Package: github.com/gomarkdown/markdown (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.0.0[PII_REDACTED]3819-759bbc3e3207
Patched in: 0.0.0[PII_REDACTED]3819-759bbc3e3207

Summary: Go Markdown has an Out-of-bounds Read in SmartypantsRenderer

Details:
### Summary

Processing a malformed input containing a `<` character that is not followed by a `>` character anywhere in the remaining text with a SmartypantsRenderer will lead to Out of Bounds read or a panic.

### Details

The `smartLeftAngle()` function in `html/smartypants.go:367-376` performs an out-of-bounds slice operation when processing a `<` character that is not followed by a `>` character anywhere in the remaining text.
https://github.com/gomarkdown/markdown/blob/37c66b85d6ab025ba67a73ba03b7f3ef55859cca/html/smartypants.go#L367-L376
If the length of the slice is lower than its capacity, this leads to an extra byte of data read. If the length equals the capacity, this leads to a panic.

### PoC
```golang
package main

import (
	"bytes"
	"fmt"

	"github.com/gomarkdown/markdown/html"
)

func main() {
	src := []byte("<a")

	fmt.Printf("Input: %q  (len=%d, cap=%d)\n", src, len(src), cap(src))

	var buf bytes.Buffer
	sp := html.NewSmartypantsRenderer(html.Smartypants)
	sp.Process(&buf, src) // panics: slice bounds out of range

	fmt.Printf("Output: %q\n", buf.String())
}
```

### Impact
This vulnerability will lead to a Denial of Service / panic on the processing service.


-- The Datadog Security Team
GitHub Security Advisory: GHSA-jf4f-rr2c-9m58
Package: github.com/authzed/spicedb (GO)
Severity: MODERATE (CVSS 6.0)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 1.49.0, <= 1.51.0
Patched in: 1.51.1

Summary: SpiceDB's SPICEDB_DATASTORE_CONN_URI is leaked on startup logs

Details:
### Impact
When SpiceDB starts with log level `info`, the startup `"configuration"` log will include the full datastore DSN, including the plaintext password, inside `DatastoreConfig.URI`.

### Patches
v1.51.1

### Workarounds
Change the log level to `warn` or `error`.