CVE-2026-125328

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.

pgEdge Go LLM Library discloses provider API key fragments in error messages

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.

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.

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.

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.