pgedge/pgedge-go-llm-lib · Security
pgEdge Go LLM Library discloses provider API key fragments in error messages
- GHSA ID
- GHSA-8835-xmqj-354h
- CVE ID
- CVE-2026-125328
- Severity
- medium
- Published
- Updated
- CVSS
- 5.8 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
- CVSS v3
- 5.8 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Description
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.
CWEs
- CWE-209 · Generation of Error Message Containing Sensitive Information
- CWE-522 · Insufficiently Protected Credentials
References
- https://github.com/pgEdge/pgedge-go-llm-lib/security/advisories/GHSA-8835-xmqj-354h ↗
- https://nvd.nist.gov/vuln/detail/CVE-2026-125328 ↗
- https://github.com/pgEdge/pgedge-go-llm-lib/pull/26 ↗
- https://github.com/pgEdge/pgedge-go-llm-lib/commit/7531a55d368b3a29cd173c792cc4609c4134b076 ↗
- https://github.com/pgEdge/pgedge-go-llm-lib/commit/8bb9a6380d5f8db0124b51605759897034ad4da1 ↗
- https://github.com/pgEdge/pgedge-go-llm-lib/releases/tag/v0.2.0 ↗
- https://github.com/advisories/GHSA-8835-xmqj-354h ↗