Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/pgEdge/pgedge-rag-server < 1.0.1-0.20260729020411-a09d4872356b
Fixed in
1.0.1-0.20260729020411-a09d4872356b· Vendor fix available
Issue
Impact An unauthenticated caller able to reach the query endpoint could exhaust database and server resources with ordinary, inexpensive requests. The keyword-search arm read the entire corpus on every request and rebuilt an in-memory BM25 index from it, so the cost of serving a query scaled with the size of the source table rather than with the size of the result set. Each request cost the server and the tenant's database far more than it cost the caller to make, which makes this a materially more effective denial-of-service lever than flooding the endpoint with ordinary requests. The amplification factor grows with corpus size, so the largest deployments are the most exposed. Hybrid search was enabled by default and configured per pipeline rather than per request, so a caller could not opt out of the keyword arm and an operator could not leave it available to some requests but not others. Who is affected: any deployment of pgEdge RAG Server at `1.0.0` or earlier, including…
Recommended action: Upgrade to 1.0.1-0.20260729020411-a09d4872356b (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pgEdge/pgedge-rag-server < 1.0.1-0.20260729022402-72e0785a6d7c
Fixed in
1.0.1-0.20260729022402-72e0785a6d7c· Vendor fix available
Issue
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…
Recommended action: Upgrade to 1.0.1-0.20260729022402-72e0785a6d7c (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/pgEdge/pgedge-rag-server < 1.0.1-0.20260729020411-a09d4872356b
Fixed in
1.0.1-0.20260729020411-a09d4872356b· Vendor fix available
Issue
Impact Documents belonging to one caller could be returned to another. Where an application passes a customer or tenant identifier as a search filter, that scoping could be defeated by ordinary concurrent traffic. No injection and no malformed input are required — normal load is enough. The BM25 keyword index was a single per-pipeline object shared by every request. A request cleared it, refilled it from its own filtered corpus and then searched it, taking a separate lock for each step rather than holding the sequence as a unit. Concurrent requests therefore interleaved, and a search could run against a corpus that a different request's filter had populated. Who is affected: any deployment of pgEdge RAG Server at `1.0.0` or earlier, including all alpha and beta pre-releases, that serves concurrent queries — most acutely those relying on a search filter to separate tenants or customers. The query endpoint is unauthenticated in the affected versions…
Recommended action: Upgrade to 1.0.1-0.20260729020411-a09d4872356b (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.