CVE-2026-125328: pgEdge Go LLM Library discloses provider API key fragments in error messages
pgEdge Go LLM Library provides a unified Go interface for multiple LLM providers with streaming, tool calling, retries, and an HTTP and server-sent events proxy. From 0.1.0 until 0.2.0, GET /v1/health in llm/proxy/handlers.go uses handleHealth to ping providers with the operator's real credentials and returns their error text, while the Authorize hook in llm/proxy/proxy.go permits access by default when the consuming application does not configure it. When a provider rejects the configured credential, a remote caller who can reach the proxy can obtain part of the operator's third-party provider API key from the resulting error. This issue is fixed in version 0.2.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pgEdge Go LLM Libraryto a version that resolves this vulnerability.Fixed in 0.2.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using pgEdge Go LLM Library versions from 0.1.0 up to, but not including, 0.2.0 are exposed if a remote caller can reach the proxy. Exposure is especially likely when the consuming application has not configured the Authorize hook, because access is permitted by default.
What does an attacker need to retrieve key material?
An attacker only needs network access to the proxy's GET /v1/health endpoint. If a provider rejects the operator's configured credential, the endpoint can return provider error text containing a fragment of that third-party provider API key.
How can I tell whether my deployment may already be affected?
Check whether you use a vulnerable library version and expose the proxy health endpoint to remote callers. Also check whether the application leaves the Authorize hook unconfigured and whether configured provider credentials have generated rejected-credential errors.
What should be done if upgrading is not immediately possible?
Restrict remote access to the proxy, particularly GET /v1/health, and configure the Authorize hook rather than relying on its default behavior. Upgrade to version 0.2.0 when possible.