GHSA-8835-XMQJ-354H

Vulnerability from github – Published: 2026-11-12 19:32 – Updated: 2026-11-12 19:32
VLAI
Summary
pgEdge Go LLM Library discloses provider API key fragments in error messages
Details

Impact

An unauthenticated caller could read part of the operator's configured LLM provider API key.

The library's own health handler pings every configured provider using the operator's real credential and returns the resulting error text verbatim. Providers characteristically quote a partially masked form of the credential they rejected, so a failing ping published a fragment of the key.

The endpoint is unauthenticated by default. authorize() returns true immediately when the consuming application sets no Authorize hook, so GET /v1/health is reachable by anyone who can reach the listening port unless the consumer opted in to authentication.

Who is affected: any application embedding pgedge-go-llm-lib at 0.1.0 or 0.1.1 that exposes the bundled HTTP proxy without setting an Authorize hook. Both affected versions are released tags and resolve through the public Go module proxy.

The disclosed material authenticates to a third-party provider account rather than to pgEdge software, which is why the severity carries Scope: Changed.

Evidence at v0.1.1: llm/proxy/handlers.go:296 (handleHealth returning err.Error() in ProviderHealth.Error), llm/proxy/proxy.go:247 (authorize() defaulting to permit), and llm/proxy/proxy.go:350 (writeError writing the error with no redaction).

Patches

Fixed in 0.2.0. Upgrade to 0.2.0 or later, which redacts credentials from provider error messages unconditionally. The fix adds llm/internal/redact, with a follow-up anchoring word boundaries, and is pinned by tests in that package.

Note the version. There is no 0.1.2 — it was never cut, and some earlier material named it in error. 0.2.0 is the first fixed release.

Upgrading does not undo a disclosure that already happened. Rotate any LLM provider credential configured on an affected version where the proxy was reachable without an Authorize hook, particularly if a provider was rejecting that key at the time.

Workarounds

Set an Authorize hook on the proxy, which closes the unauthenticated route to the health endpoint. Restricting network access to the listening port limits who can reach it. Neither removes the underlying disclosure for a caller who does reach the endpoint.

Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pgEdge/pgedge-go-llm-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.2-0.20260729024727-7531a55d368b"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-125328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-12T19:32:36Z",
    "nvd_published_at": "2026-11-10T19:21:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn unauthenticated caller could read part of the operator\u0027s configured LLM provider API key.\n\nThe library\u0027s own health handler pings every configured provider using the operator\u0027s real credential and returns the resulting error text verbatim. Providers characteristically quote a partially masked form of the credential they rejected, so a failing ping published a fragment of\nthe key.\n\n**The endpoint is unauthenticated by default.** `authorize()` returns\ntrue immediately when the consuming application sets no `Authorize` hook,\nso `GET /v1/health` is reachable by anyone who can reach the listening\nport unless the consumer opted in to authentication.\n\n**Who is affected:** any application embedding pgedge-go-llm-lib at\n`0.1.0` or `0.1.1` that exposes the bundled HTTP proxy without setting an\n`Authorize` hook. Both affected versions are released tags and resolve\nthrough the public Go module proxy.\n\nThe disclosed material authenticates to a **third-party provider\naccount** rather than to pgEdge software, which is why the severity\ncarries Scope: Changed.\n\nEvidence at `v0.1.1`: `llm/proxy/handlers.go:296` (`handleHealth`\nreturning `err.Error()` in `ProviderHealth.Error`), `llm/proxy/proxy.go:247`\n(`authorize()` defaulting to permit), and `llm/proxy/proxy.go:350`\n(`writeError` writing the error with no redaction).\n\n### Patches\n\n**Fixed in `0.2.0`. Upgrade to `0.2.0` or later**, which redacts\ncredentials from provider error messages unconditionally. The fix adds\n`llm/internal/redact`, with a follow-up anchoring word boundaries, and is\npinned by tests in that package.\n\n**Note the version.** There is no `0.1.2` \u2014 it was never cut, and some\nearlier material named it in error. `0.2.0` is the first fixed release.\n\n**Upgrading does not undo a disclosure that already happened. Rotate any\nLLM provider credential configured on an affected version** where the\nproxy was reachable without an `Authorize` hook, particularly if a\nprovider was rejecting that key at the time.\n\n### Workarounds\n\nSet an `Authorize` hook on the proxy, which closes the unauthenticated\nroute to the health endpoint. Restricting network access to the listening\nport limits who can reach it. Neither removes the underlying disclosure\nfor a caller who does reach the endpoint.",
  "id": "GHSA-8835-xmqj-354h",
  "modified": "2026-11-12T19:32:36Z",
  "published": "2026-11-12T19:32:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib/security/advisories/GHSA-8835-xmqj-354h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-125328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib/pull/26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib/commit/7531a55d368b3a29cd173c792cc4609c4134b076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib/commit/8bb9a6380d5f8db0124b51605759897034ad4da1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgEdge/pgedge-go-llm-lib/releases/tag/v0.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pgEdge Go LLM Library discloses provider API key fragments in error messages"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.