pgEdge RAG Server discloses part of the configured provider credential through API error messagespgEdge RAG Server discloses part of the configured provider credential through API error messages

Impact

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

The query API relayed the text of a provider error straight to the caller. That text carried the upstream provider's own message, and providers characteristically quote a partially masked form of the credential they rejected when authentication fails — so a failing provider call published a fragment of the operator's key. A caller who can reach the endpoint can cause such a failure and read the result.

Who is affected: any deployment of pgEdge RAG Server at 1.0.0 or earlier, including all alpha and beta pre-releases, whose query endpoint was reachable by an untrusted party. The endpoint carries no authentication in the affected versions.

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

v1.0.0:internal/server/handlers.go:121 relayed err.Error() to the client when pipeline execution failed. parseError in v1.0.0:internal/llm/openai/client.go produced that error by two routes, and both disclose:

var errResp ErrorResponse
if err := json.Unmarshal(body, &errResp); err != nil {
    return fmt.Errorf("API error (status %d): %s", resp.StatusCode, string(body))
}
return fmt.Errorf("API error (status %d): %s", resp.StatusCode, errResp.Error.Message)

The first branch interpolates the entire unparsed response body. The second returns the provider's own message, which for OpenAI quotes the sk-proj- prefix and the final four characters of the submitted key.

Patches

Fixed in 2.0.0. Upgrade to 2.0.0 or later.

The fix adds internal/safeerr and stops provider error text reaching API clients.

Upgrading does not undo the disclosure, and this needs action beyond upgrading. Rotate any LLM provider credential that was configured on an affected version while the endpoint was reachable by an untrusted caller, particularly if that provider was rejecting the key at the time. A fragment already disclosed stays disclosed.

Workarounds

Place the server behind a proxy that rewrites 5xx response bodies, or terminate 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.

None of these removes the underlying defect, and none is a substitute for upgrading.