pgEdge libraries leaked LLM API key fragments in error text

pgEdge published two security advisories on 12 November 2026 describing credential disclosure flaws in its Go LLM Library and its RAG Server. In both cases, according to the advisories, an unauthenticated remote caller could read part of the operator's configured large language model provider API key, because the software passed provider error text straight back to the client without redaction.

The first advisory, GHSA-8835-xmqj-354h, tracked as CVE-2026-125328, covers pgEdge Go LLM Library versions 0.1.0 and 0.1.1. The advisory says the library's 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 advisory adds that the health endpoint is unauthenticated by default: the library's authorize() function 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.

The second advisory, GHSA-68g8-gh8f-7rhg, tracked as CVE-2026-125326, covers pgEdge RAG Server version 1.0.0 and earlier, including all alpha and beta pre-releases. According to pgEdge, the query API relayed the text of a provider error directly to the caller, and the endpoint carries no authentication in the affected versions. A caller who can reach the endpoint can trigger such a failure and read the result. The advisory notes that one code path interpolates the entire unparsed provider response body, while another returns the provider's own message, which for OpenAI quotes the sk-proj- prefix and the final four characters of the submitted key.

pgEdge says both issues carry a Scope: Changed rating because the disclosed material authenticates to a third-party provider account rather than to pgEdge software.

Fixes are available. The Go LLM Library is fixed in version 0.2.0, which the advisory says redacts credentials from provider error messages unconditionally through a new llm/internal/redact package, with a follow-up change anchoring word boundaries and tests pinning the behaviour. pgEdge warns that there is no 0.1.2 release — it was never cut, and some earlier material named it in error, so 0.2.0 is the first fixed release. The RAG Server is fixed in version 2.0.0, which adds an internal/safeerr package and stops provider error text reaching API clients.

Upgrading alone is not enough. Both advisories state that upgrading does not undo a disclosure that has already happened, and urge operators to rotate any LLM provider credential configured on an affected version while the endpoint was reachable by an untrusted caller. That applies particularly, pgEdge says, if a provider was rejecting the key at the time, since rejections are what produced the leaking error messages. A fragment already disclosed stays disclosed.

For those unable to upgrade immediately, the library advisory suggests setting an Authorize hook on the proxy, which closes the unauthenticated route to the health endpoint, and restricting network access to the listening port. Neither removes the underlying disclosure for a caller who does reach the endpoint. For the RAG Server, pgEdge suggests placing the server behind a proxy that rewrites 5xx response bodies, or terminating provider errors before they reach the API surface. Keeping provider credentials valid, so that no authentication failure is produced, also avoids the disclosure in practice. The company says none of these workarounds removes the underlying defect, and none is a substitute for upgrading.