CVE-2026-125325

pgEdge RAG Server is an API server for retrieval-augmented generation over PostgreSQL content using pgvector. Prior to 2.0.0, the BM25 keyword index is a single per-pipeline object shared by the unauthenticated query endpoint, and concurrent requests lock its clear, refill, and search operations separately. This allows one request to search a corpus populated through another request's search filter, which can return documents belonging to a different tenant or customer without malformed input. The affected responses cannot be identified retrospectively from the server logs. This issue is fixed in version 2.0.0.

pgEdge RAG Server shared keyword index leaked results between concurrent unauthenticated requests

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 (internal/server/middleware.go:37 applies logging, panic recovery and optional CORS only), so both the party whose results leak and the party receiving them are anonymous remote callers.

Patches

Fixed in 2.0.0. Upgrade to 2.0.0 or later.

The index is now built per request rather than shared. The regression is pinned by TestSearch_ConcurrentRequestsDoNotShareKeywordIndex in internal/pipeline/orchestrator_test.go.

Upgrading does not tell a developer whether or not their application affected, and needs action beyond upgrading. If a consuminag application scopes results by tenant, treat responses served under concurrent load on any affected version as potentially having included another tenant's documents. Affected responses cannot be identified from the server's own logs, so there is no retrospective check available.

Workarounds

Set hybrid_enabled: false on the pipeline, which skips the keyword arm and with it the shared index. Callers can also pass disable_hybrid per request, which can only ever turn the arm off.

Neither is a substitute for upgrading.

pgEdge RAG Server is an API server for retrieval-augmented generation over PostgreSQL content using pgvector. Prior to 2.0.0, the BM25 keyword index is a single per-pipeline object shared by the unauthenticated query endpoint, and concurrent requests lock its clear, refill, and search operations separately. This allows one request to search a corpus populated through another request's search filter, which can return documents belonging to a different tenant or customer without malformed input. The affected responses cannot be identified retrospectively from the server logs. This issue is fixed in version 2.0.0.

pgEdge RAG Server is an API server for retrieval-augmented generation over PostgreSQL content using pgvector. Prior to 2.0.0, the BM25 keyword index is a single per-pipeline object shared by the unauthenticated query endpoint, and concurrent requests lock its clear, refill, and search operations separately. This allows one request to search a corpus populated through another request's search filter, which can return documents belonging to a different tenant or customer without malformed input. The affected responses cannot be identified retrospectively from the server logs. This issue is fixed in version 2.0.0.

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 (internal/server/middleware.go:37 applies logging, panic recovery and optional CORS only), so both the party whose results leak and the party receiving them are anonymous remote callers.

Patches

Fixed in 2.0.0. Upgrade to 2.0.0 or later.

The index is now built per request rather than shared. The regression is pinned by TestSearch_ConcurrentRequestsDoNotShareKeywordIndex in internal/pipeline/orchestrator_test.go.

Upgrading does not tell a developer whether or not their application affected, and needs action beyond upgrading. If a consuminag application scopes results by tenant, treat responses served under concurrent load on any affected version as potentially having included another tenant's documents. Affected responses cannot be identified from the server's own logs, so there is no retrospective check available.

Workarounds

Set hybrid_enabled: false on the pipeline, which skips the keyword arm and with it the shared index. Callers can also pass disable_hybrid per request, which can only ever turn the arm off.

Neither is a substitute for upgrading.