
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 1.0.1-0.20260729022402-72e0785a6d7c
Patched in 1.0.1-0.20260729022402-72e0785a6d7c
Details
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.
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.
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.
EPSS, exploit probability
Low0.41%
estimated chance of real-world exploitation in the next 30 days, higher than 35.8% of every CVE FIRST.org scores
Refreshed 11/13/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More go advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.