CVE-2026-125327

pgEdge RAG Server is an API server for retrieval-augmented generation over PostgreSQL content using pgvector. Prior to 2.0.0, the unauthenticated query endpoint uses FetchDocuments in internal/database/search.go to read the entire filtered corpus without a LIMIT and rebuild an in-memory BM25 index on every request. Because HybridEnabled is set by default in internal/config/loader.go and the endpoint has no rate limit, inexpensive remote queries can impose database and CPU work proportional to corpus size and exhaust service resources. 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 unauthenticated query endpoint uses FetchDocuments in internal/database/search.go to read the entire filtered corpus without a LIMIT and rebuild an in-memory BM25 index on every request. Because HybridEnabled is set by default in internal/config/loader.go and the endpoint has no rate limit, inexpensive remote queries can impose database and CPU work proportional to corpus size and exhaust service resources. This issue is fixed in version 2.0.0.

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 all alpha and beta pre-releases, whose query endpoint is reachable by an untrusted party. The endpoint required no authentication and applied no rate limiting.

In 1.0.0, internal/database/search.go:130 built the corpus query with no LIMIT:

query = fmt.Sprintf(`
    SELECT ...
    FROM %s%s`,
    tableIdent,
    filterClause)

FetchDocuments accepted no limit parameter at all, so neither a caller nor the orchestrator had any way to bound the read. internal/config/loader.go:197 defaulted HybridEnabled to true, and internal/server/middleware.go:37 applied only logging, panic recovery and optional CORS.

Patches

Fixed in 2.0.0. Upgrade to 2.0.0 or later.

Reads are capped by a new per-pipeline search.bm25_max_documents, defaulting to 10000, plumbed through SearchBackend.FetchDocuments and applied as a parameterised LIMIT. There is deliberately no unlimited value: a non-positive setting is rejected at configuration load time rather than silently treated as unbounded.

Requests that reach the cap are logged, because keyword recall is partial at that point and an operator should not have to infer it. A new disable_hybrid request field lets a caller skip the expensive arm per query, and can only ever turn it off.

After upgrading, review the default search.bm25_max_documents value of 10000 against the size of your corpus. A cap far below corpus size silently reduces keyword recall.

Workarounds

Place the server behind an authenticating, rate-limiting reverse proxy.

Setting hybrid_enabled: false on each pipeline removes the keyword arm and with it the unbounded read, at the cost of keyword recall. This is the only mitigation available without a proxy.

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 unauthenticated query endpoint uses FetchDocuments in internal/database/search.go to read the entire filtered corpus without a LIMIT and rebuild an in-memory BM25 index on every request. Because HybridEnabled is set by default in internal/config/loader.go and the endpoint has no rate limit, inexpensive remote queries can impose database and CPU work proportional to corpus size and exhaust service resources. 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 unauthenticated query endpoint uses FetchDocuments in internal/database/search.go to read the entire filtered corpus without a LIMIT and rebuild an in-memory BM25 index on every request. Because HybridEnabled is set by default in internal/config/loader.go and the endpoint has no rate limit, inexpensive remote queries can impose database and CPU work proportional to corpus size and exhaust service resources. This issue is fixed in version 2.0.0.

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 all alpha and beta pre-releases, whose query endpoint is reachable by an untrusted party. The endpoint required no authentication and applied no rate limiting.

In 1.0.0, internal/database/search.go:130 built the corpus query with no LIMIT:

query = fmt.Sprintf(`
    SELECT ...
    FROM %s%s`,
    tableIdent,
    filterClause)

FetchDocuments accepted no limit parameter at all, so neither a caller nor the orchestrator had any way to bound the read. internal/config/loader.go:197 defaulted HybridEnabled to true, and internal/server/middleware.go:37 applied only logging, panic recovery and optional CORS.

Patches

Fixed in 2.0.0. Upgrade to 2.0.0 or later.

Reads are capped by a new per-pipeline search.bm25_max_documents, defaulting to 10000, plumbed through SearchBackend.FetchDocuments and applied as a parameterised LIMIT. There is deliberately no unlimited value: a non-positive setting is rejected at configuration load time rather than silently treated as unbounded.

Requests that reach the cap are logged, because keyword recall is partial at that point and an operator should not have to infer it. A new disable_hybrid request field lets a caller skip the expensive arm per query, and can only ever turn it off.

After upgrading, review the default search.bm25_max_documents value of 10000 against the size of your corpus. A cap far below corpus size silently reduces keyword recall.

Workarounds

Place the server behind an authenticating, rate-limiting reverse proxy.

Setting hybrid_enabled: false on each pipeline removes the keyword arm and with it the unbounded read, at the cost of keyword recall. This is the only mitigation available without a proxy.

Neither is a substitute for upgrading.