deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vvf7-6rmr-m29q
Package: github.com/dgraph-io/dgraph (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 1.2.8
Patched in: unpatched

Summary: Dgraph: Unauthenticated Admin Token Disclosure Leading to Authentication Bypass via /debug/vars

Details:
### Summary
Dgraph `v25.3.2` still exposes the process command line through the unauthenticated `/debug/vars` endpoint on Alpha. Because the admin token is commonly supplied via the `--security "token=..."` startup flag, an unauthenticated attacker can retrieve that token and replay it in the `X-Dgraph-AuthToken` header to access admin-only endpoints.

This is a variant of the previously fixed `/debug/pprof/cmdline` issue, but the current fix is incomplete because it blocks only `/debug/pprof/cmdline` and still serves `http.DefaultServeMux`, which includes `expvar`'s `/debug/vars` handler.

### Details
Alpha still exposes Go's default HTTP mux:

- `x/metrics.go`
  - imports `expvar`
  - initializes `Conf = expvar.NewMap("dgraph_config")`
- Go's `expvar` package automatically registers `/debug/vars`
- `expvar` publishes:
  - `cmdline = os.Args`
  - `memstats = runtime.Memstats`

Alpha's HTTP handler explicitly blocks only the old CVE path:

- `dgraph/cmd/alpha/run.go`
  - checks `if r.URL.Path == "/debug/pprof/cmdline"` and returns `404`
  - otherwise falls through to `http.DefaultServeMux.ServeHTTP(w, r)`

Admin endpoints still trust the leaked token:

- `dgraph/cmd/alpha/admin.go`
  - reads `X-Dgraph-AuthToken`
  - compares it to `worker.Config.AuthToken`
### PoC
1. Send an unauthenticated request to Alpha:

```http
GET /debug/vars HTTP/1.1
Host: target:8080
```

2. Parse the JSON response and read the `cmdline` field.

3. Extract the admin token from the startup arguments, for example:

```text
--security token=debug-vars-secret;
```

4. Replay the token to an admin-only endpoint:

```http
GET /admin/config/cache_mb HTTP/1.1
Host: target:8080
X-Dgraph-AuthToken: debug-vars-secret
```

5. The request is accepted as an authorized admin request.

This was reproduced against `dgraph/dgraph:v25.3.2` in Docker.

Observed behavior:

- unauthenticated `/debug/vars` leaked the configured token
- replaying the leaked token in `X-Dgraph-AuthToken` successfully accessed `/admin/config/cache_mb`
- response body was:

```text
4096
```

It was verified that the old CVE path appears specifically patched in the same version:

- `/debug/pprof/cmdline` returned `404 Not Found`
- `/debug/pprof/` remained reachable

### Impact
Unauthenticated attackers can obtain the Alpha admin token and gain unauthorized administrative access.

This enables privileged admin operations such as:

- reading privileged admin configuration
- mutating admin configuration
- performing operational control actions gated by `X-Dgraph-AuthToken`

In deployments where the Alpha HTTP port is reachable by untrusted parties, this is a practical authentication bypass to admin functionality.
GitHub Security Advisory: GHSA-vvf7-6rmr-m29q
Package: github.com/dgraph-io/dgraph/v24 (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 24.1.8
Patched in: unpatched

Summary: Dgraph: Unauthenticated Admin Token Disclosure Leading to Authentication Bypass via /debug/vars

Details:
### Summary
Dgraph `v25.3.2` still exposes the process command line through the unauthenticated `/debug/vars` endpoint on Alpha. Because the admin token is commonly supplied via the `--security "token=..."` startup flag, an unauthenticated attacker can retrieve that token and replay it in the `X-Dgraph-AuthToken` header to access admin-only endpoints.

This is a variant of the previously fixed `/debug/pprof/cmdline` issue, but the current fix is incomplete because it blocks only `/debug/pprof/cmdline` and still serves `http.DefaultServeMux`, which includes `expvar`'s `/debug/vars` handler.

### Details
Alpha still exposes Go's default HTTP mux:

- `x/metrics.go`
  - imports `expvar`
  - initializes `Conf = expvar.NewMap("dgraph_config")`
- Go's `expvar` package automatically registers `/debug/vars`
- `expvar` publishes:
  - `cmdline = os.Args`
  - `memstats = runtime.Memstats`

Alpha's HTTP handler explicitly blocks only the old CVE path:

- `dgraph/cmd/alpha/run.go`
  - checks `if r.URL.Path == "/debug/pprof/cmdline"` and returns `404`
  - otherwise falls through to `http.DefaultServeMux.ServeHTTP(w, r)`

Admin endpoints still trust the leaked token:

- `dgraph/cmd/alpha/admin.go`
  - reads `X-Dgraph-AuthToken`
  - compares it to `worker.Config.AuthToken`
### PoC
1. Send an unauthenticated request to Alpha:

```http
GET /debug/vars HTTP/1.1
Host: target:8080
```

2. Parse the JSON response and read the `cmdline` field.

3. Extract the admin token from the startup arguments, for example:

```text
--security token=debug-vars-secret;
```

4. Replay the token to an admin-only endpoint:

```http
GET /admin/config/cache_mb HTTP/1.1
Host: target:8080
X-Dgraph-AuthToken: debug-vars-secret
```

5. The request is accepted as an authorized admin request.

This was reproduced against `dgraph/dgraph:v25.3.2` in Docker.

Observed behavior:

- unauthenticated `/debug/vars` leaked the configured token
- replaying the leaked token in `X-Dgraph-AuthToken` successfully accessed `/admin/config/cache_mb`
- response body was:

```text
4096
```

It was verified that the old CVE path appears specifically patched in the same version:

- `/debug/pprof/cmdline` returned `404 Not Found`
- `/debug/pprof/` remained reachable

### Impact
Unauthenticated attackers can obtain the Alpha admin token and gain unauthorized administrative access.

This enables privileged admin operations such as:

- reading privileged admin configuration
- mutating admin configuration
- performing operational control actions gated by `X-Dgraph-AuthToken`

In deployments where the Alpha HTTP port is reachable by untrusted parties, this is a practical authentication bypass to admin functionality.
GitHub Security Advisory: GHSA-vvf7-6rmr-m29q
Package: github.com/dgraph-io/dgraph/v25 (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 25.3.3
Patched in: 25.3.3

Summary: Dgraph: Unauthenticated Admin Token Disclosure Leading to Authentication Bypass via /debug/vars

Details:
### Summary
Dgraph `v25.3.2` still exposes the process command line through the unauthenticated `/debug/vars` endpoint on Alpha. Because the admin token is commonly supplied via the `--security "token=..."` startup flag, an unauthenticated attacker can retrieve that token and replay it in the `X-Dgraph-AuthToken` header to access admin-only endpoints.

This is a variant of the previously fixed `/debug/pprof/cmdline` issue, but the current fix is incomplete because it blocks only `/debug/pprof/cmdline` and still serves `http.DefaultServeMux`, which includes `expvar`'s `/debug/vars` handler.

### Details
Alpha still exposes Go's default HTTP mux:

- `x/metrics.go`
  - imports `expvar`
  - initializes `Conf = expvar.NewMap("dgraph_config")`
- Go's `expvar` package automatically registers `/debug/vars`
- `expvar` publishes:
  - `cmdline = os.Args`
  - `memstats = runtime.Memstats`

Alpha's HTTP handler explicitly blocks only the old CVE path:

- `dgraph/cmd/alpha/run.go`
  - checks `if r.URL.Path == "/debug/pprof/cmdline"` and returns `404`
  - otherwise falls through to `http.DefaultServeMux.ServeHTTP(w, r)`

Admin endpoints still trust the leaked token:

- `dgraph/cmd/alpha/admin.go`
  - reads `X-Dgraph-AuthToken`
  - compares it to `worker.Config.AuthToken`
### PoC
1. Send an unauthenticated request to Alpha:

```http
GET /debug/vars HTTP/1.1
Host: target:8080
```

2. Parse the JSON response and read the `cmdline` field.

3. Extract the admin token from the startup arguments, for example:

```text
--security token=debug-vars-secret;
```

4. Replay the token to an admin-only endpoint:

```http
GET /admin/config/cache_mb HTTP/1.1
Host: target:8080
X-Dgraph-AuthToken: debug-vars-secret
```

5. The request is accepted as an authorized admin request.

This was reproduced against `dgraph/dgraph:v25.3.2` in Docker.

Observed behavior:

- unauthenticated `/debug/vars` leaked the configured token
- replaying the leaked token in `X-Dgraph-AuthToken` successfully accessed `/admin/config/cache_mb`
- response body was:

```text
4096
```

It was verified that the old CVE path appears specifically patched in the same version:

- `/debug/pprof/cmdline` returned `404 Not Found`
- `/debug/pprof/` remained reachable

### Impact
Unauthenticated attackers can obtain the Alpha admin token and gain unauthorized administrative access.

This enables privileged admin operations such as:

- reading privileged admin configuration
- mutating admin configuration
- performing operational control actions gated by `X-Dgraph-AuthToken`

In deployments where the Alpha HTTP port is reachable by untrusted parties, this is a practical authentication bypass to admin functionality.
GitHub Security Advisory: GHSA-x4mj-7f9g-29h4
Package: github.com/projectcontour/contour (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 1.33.0, < 1.33.4
Patched in: 1.33.4

Summary: Contour has Lua code injection via Cookie Path Rewrite Policy

Details:
### Impact

Contour's [Cookie Rewriting](https://projectcontour.io/docs/1.33/config/cookie-rewriting/) feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify `HTTPProxy` resources can craft a malicious value in the following fields that results in arbitrary code execution in the Envoy proxy:

- `spec.routes[].cookieRewritePolicies[].pathRewrite.value`
- `spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value`

The cookie rewriting feature is internally implemented using Envoy's [HTTP Lua filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter). User-controlled values are interpolated into Lua source code using Go `text/template` without sufficient sanitization.

The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also:

- Read Envoy's xDS client credentials from the filesystem, which could be used to read all Contour xDS configuration, including TLS certificates and private keys of other tenants.
- Cause denial of service for other tenants sharing the Envoy instance.

Other use cases of Lua filter are not vulnerable.

### Patches

The fix is available in Contour [v1.33.4](https://github.com/projectcontour/contour/releases/tag/v1.33.4), [v1.32.5](https://github.com/projectcontour/contour/releases/tag/v1.32.5), and [v1.31.6](https://github.com/projectcontour/contour/releases/tag/v1.31.6).

- v1.33.4: User-provided values are no longer interpolated into Lua code. Use of `text/template` is removed. Requires Envoy 1.35.0 or later.
- v1.32.5, v1.31.6: User-provided values are escaped before interpolation into Lua code.

### Workarounds

There are no workarounds. Users should upgrade to a patched version.
GitHub Security Advisory: GHSA-x4mj-7f9g-29h4
Package: github.com/projectcontour/contour (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 1.32.0, < 1.32.5
Patched in: 1.32.5

Summary: Contour has Lua code injection via Cookie Path Rewrite Policy

Details:
### Impact

Contour's [Cookie Rewriting](https://projectcontour.io/docs/1.33/config/cookie-rewriting/) feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify `HTTPProxy` resources can craft a malicious value in the following fields that results in arbitrary code execution in the Envoy proxy:

- `spec.routes[].cookieRewritePolicies[].pathRewrite.value`
- `spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value`

The cookie rewriting feature is internally implemented using Envoy's [HTTP Lua filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter). User-controlled values are interpolated into Lua source code using Go `text/template` without sufficient sanitization.

The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also:

- Read Envoy's xDS client credentials from the filesystem, which could be used to read all Contour xDS configuration, including TLS certificates and private keys of other tenants.
- Cause denial of service for other tenants sharing the Envoy instance.

Other use cases of Lua filter are not vulnerable.

### Patches

The fix is available in Contour [v1.33.4](https://github.com/projectcontour/contour/releases/tag/v1.33.4), [v1.32.5](https://github.com/projectcontour/contour/releases/tag/v1.32.5), and [v1.31.6](https://github.com/projectcontour/contour/releases/tag/v1.31.6).

- v1.33.4: User-provided values are no longer interpolated into Lua code. Use of `text/template` is removed. Requires Envoy 1.35.0 or later.
- v1.32.5, v1.31.6: User-provided values are escaped before interpolation into Lua code.

### Workarounds

There are no workarounds. Users should upgrade to a patched version.
GitHub Security Advisory: GHSA-x4mj-7f9g-29h4
Package: github.com/projectcontour/contour (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 1.19.0, < 1.31.6
Patched in: 1.31.6

Summary: Contour has Lua code injection via Cookie Path Rewrite Policy

Details:
### Impact

Contour's [Cookie Rewriting](https://projectcontour.io/docs/1.33/config/cookie-rewriting/) feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify `HTTPProxy` resources can craft a malicious value in the following fields that results in arbitrary code execution in the Envoy proxy:

- `spec.routes[].cookieRewritePolicies[].pathRewrite.value`
- `spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value`

The cookie rewriting feature is internally implemented using Envoy's [HTTP Lua filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/lua_filter). User-controlled values are interpolated into Lua source code using Go `text/template` without sufficient sanitization.

The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also:

- Read Envoy's xDS client credentials from the filesystem, which could be used to read all Contour xDS configuration, including TLS certificates and private keys of other tenants.
- Cause denial of service for other tenants sharing the Envoy instance.

Other use cases of Lua filter are not vulnerable.

### Patches

The fix is available in Contour [v1.33.4](https://github.com/projectcontour/contour/releases/tag/v1.33.4), [v1.32.5](https://github.com/projectcontour/contour/releases/tag/v1.32.5), and [v1.31.6](https://github.com/projectcontour/contour/releases/tag/v1.31.6).

- v1.33.4: User-provided values are no longer interpolated into Lua code. Use of `text/template` is removed. Requires Envoy 1.35.0 or later.
- v1.32.5, v1.31.6: User-provided values are escaped before interpolation into Lua code.

### Workarounds

There are no workarounds. Users should upgrade to a patched version.
GitHub Security Advisory: GHSA-q2pw-xx38-p64j
Package: chainguard.dev/melange (GO)
Severity: LOW (CVSS 3.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.32.0, < 0.43.4
Patched in: 0.43.4

Summary: melange has Path Traversal via .PKGINFO in --persist-lint-results

Details:
### Impact

`melange lint --persist-lint-results` (opt-in flag, also usable via `melange build --persist-lint-results`) constructs output file paths by joining `--out-dir` with the `arch` and `pkgname` values read from the `.PKGINFO` control file of the APK being linted. In affected versions these values were not validated for path separators or `..` sequences, so an attacker who can supply an APK to a melange-based lint/build pipeline (e.g. CI that lints third-party APKs, or build-as-a-service) could cause melange to write `lint-<pkgname>-<pkgver>-r<epoch>.json` to an arbitrary `.json` path reachable by the melange process. The written file is a JSON lint report whose content is partially attacker-influenced. There is no direct code-execution path, but the write can clobber other JSON artifacts on the filesystem. The issue only affects deployments that explicitly pass `--persist-lint-results`; the flag is off by default.

### Patches

Fixed in melange **v0.43.4** by validating `arch` and `pkgname` for `..`, `/`, and `filepath.Separator` before path construction in `pkg/linter/results.go` (commit [84f3b45](https://github.com/chainguard-dev/melange/commit/84f3b450ce6e472c4abb8dc4c26d0ce8ac1259ac)).

### Workarounds

Do not pass `--persist-lint-results` when linting or building APKs whose `.PKGINFO` contents are not fully trusted. Running melange as a low-privileged user and confining writes to an isolated directory also limits impact.

### Credits

melange thanks Oleh Konko ([@1seal](https://github.com/1seal) from [1seal.org](https://1seal.org/)) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-98f2-w9h9-7fp9
Package: chainguard.dev/melange (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 0.32.0, < 0.43.4
Patched in: 0.43.4

Summary: melange has Path Traversal When Resolving External Pipelines via Unvalidated pipeline[].uses

Details:
### Impact

An attacker who can influence a melange configuration file — for example through pull-request-driven CI or build-as-a-service scenarios — could set `pipeline[].uses` to a value containing `../` sequences or an absolute path. The `(*Compiled).compilePipeline` function in `pkg/build/compile.go` passed `uses` directly to `filepath.Join(pipelineDir, uses + ".yaml")` without validating the value, so the resolved path could escape each `--pipeline-dir` and read an arbitrary YAML-parseable file visible to the melange process. Because the loaded file is subsequently interpreted as a melange pipeline and its `runs:` block is executed via `/bin/sh -c` in the build sandbox, this additionally allowed shell commands sourced from an out-of-tree file to run during the build, bypassing the review boundary that normally covers the in-tree pipeline definition.

### Patches

Fixed in melange **v0.43.4** via commit [5829ca4](https://github.com/chainguard-dev/melange/commit/5829ca45cfe14dfeb73ffb716992db3b1b7892ac). The fix rejects `uses` values that are absolute paths or contain `..`, and verifies (via `filepath.Rel` after `filepath.Clean`) that the resolved target remains within the pipeline directory.

### Workarounds

Only run `melange build` against configuration files from trusted sources. In CI systems that build user-supplied melange configs, gate builds behind manual review of `pipeline[].uses` values and reject any containing `..` or leading `/`.

### Credits

melange thanks Oleh Konko ([@1seal](https://github.com/1seal) from [1seal.org](https://1seal.org/)) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-7g92-g4vh-hp84
Package: github.com/grafana/grafana (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 1.9.2-0[PII_REDACTED]0334-daffe750de85
Patched in: 1.9.2-0[PII_REDACTED]0334-daffe750de85

Summary: Grafana OSS: Authorization bypass allows users with Editor role to modify protected webhook URLs without permissions

Details:
A vulnerability has been discovered in Grafana OSS where an authorization bypass in the provisioning contact points API allows users with Editor role to modify protected webhook URLs without the required alert.notifications.receivers.protected:write permission.

A patched version is available at https://github.com/grafana/grafana/releases/tag/v12.3.6.
GitHub Security Advisory: GHSA-pjcq-xvwq-hhpj
Package: github.com/Azure/go-ntlmssp (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.1.1
Patched in: 0.1.1

Summary: go-ntlmssp NTLM challenges can panic on malformed payloads

Details:
go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.
GitHub Security Advisory: GHSA-rhf7-wvw3-vjvm
Package: github.com/patrickhener/goshs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 1.1.4
Patched in: unpatched

Summary: goshs has Cross-Origin Arbitrary File Write via Missing CSRF on PUT and Wildcard CORS

Details:
### Summary
The PUT upload handler (`httpserver/updown.go`) lacks the CSRF token validation that was added to the POST upload handler during the GHSA-jrq5-hg6x-j6g3 fix. Combined with the unconditional `Access-Control-Allow-Origin: *` on the OPTIONS preflight handler (`httpserver/server.go`), any website can write arbitrary files to a goshs instance through the victim's browser — bypassing network isolation (e.g. localhost, internal network).

### Details
**Root Cause 1 — Missing CSRF on PUT** (`httpserver/updown.go:19`)

When GHSA-jrq5-hg6x-j6g3 was fixed (commit `e3c3d37`), `checkCSRF()` was added to the POST `upload()` function (line 78) but not to the PUT `put()` function directly above it in the same file. This means PUT requests are accepted without any CSRF token.

```go
// POST — protected 
func (fs *FileServer) upload(w http.ResponseWriter, req *http.Request) {
    if !fs.checkCSRF(w, req) { return }
    // ...
}

// PUT — unprotected 
func (fs *FileServer) put(w http.ResponseWriter, req *http.Request) {
    // No checkCSRF call
    // ...
}
```

**Root Cause 2 — Wildcard CORS** (`httpserver/server.go:126`)

The OPTIONS handler unconditionally returns permissive CORS headers:

```go
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Methods", "POST, PUT, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
```

This allows any website's JavaScript to pass the browser's CORS preflight check and send PUT requests to the goshs server.

### PoC
[poc.zip](https://github.com/user-attachments/files/26828829/poc.zip)

Please extract the uploaded compressed file before proceeding

1. bash poc.sh
<img width="543" height="376" alt="스크린샷 2026-04-17 오후 11 08 13" src="https://github.com/user-attachments/assets/a695cbc8-133e-4e80-a2f5-9fe9fd36b569" />




### Impact
- Arbitrary file write to the goshs webroot from any website the victim visits
- File overwrite — existing files can be silently replaced