CVE-2026-125327: pgEdge RAG Server: unauthenticated query DoS via BM25
HIGHpgEdge RAG Server, which provides retrieval-augmented generation over PostgreSQL/pgvector content, has an unauthenticated query endpoint that loads the entire filtered corpus with no LIMIT and rebuilds an in-memory BM25 index on every request. Hybrid search is enabled by default and there is no rate limiting, so a few cheap remote requests can exhaust database and CPU resources in proportion to corpus size (CVSS 7.5, availability impact only). No EPSS score is available, the CVE is not in CISA KEV, and no public exploit or Nuclei template exists, but the attack needs no authentication or special skill, so likelihood rises quickly for any internet-exposed instance. Upgrade to pgEdge RAG Server 2.0.0, and until then restrict the endpoint behind an authenticated gateway or reverse proxy with rate limits and monitor database CPU and query load.
What is the risk?
High for availability, none for confidentiality and integrity. Exploitation is network-reachable, low complexity, and needs no privileges or user interaction. Cost per attacker request is tiny while the cost to the server scales with corpus size, so larger knowledge bases are hit hardest. Exposure matters most: instances reachable from the internet or untrusted networks are at real risk, while internal-only deployments are mainly exposed to abuse from compromised internal hosts. Because the shared PostgreSQL backend does the heavy reads, collateral impact on other applications using the same database is possible. No active exploitation, KEV listing, EPSS data or public exploit has been reported, so urgency is driven by ease of exploitation rather than observed attacks.
How does the attack unfold?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade pgEdge RAG Server to 2.0.0 or later (fix in PR #44 and commit a09d487; see GHSA-5qg5-rgp6-j5m5). 2) Until patched, do not expose the query endpoint publicly; place it behind an authenticating reverse proxy or API gateway with per-client rate limits and request concurrency caps. 3) If configurable, disable hybrid search (HybridEnabled) as a temporary workaround, accepting reduced retrieval quality. 4) Apply database statement timeouts and connection limits for the RAG service role, and run the RAG server with CPU and memory limits. 5) Detect abuse by alerting on spikes in query rate, long-running full-table SELECTs against the document tables, and sustained high CPU or memory on the RAG server from a single source.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-125327?
pgEdge RAG Server, which provides retrieval-augmented generation over PostgreSQL/pgvector content, has an unauthenticated query endpoint that loads the entire filtered corpus with no LIMIT and rebuilds an in-memory BM25 index on every request. Hybrid search is enabled by default and there is no rate limiting, so a few cheap remote requests can exhaust database and CPU resources in proportion to corpus size (CVSS 7.5, availability impact only). No EPSS score is available, the CVE is not in CISA KEV, and no public exploit or Nuclei template exists, but the attack needs no authentication or special skill, so likelihood rises quickly for any internet-exposed instance. Upgrade to pgEdge RAG Server 2.0.0, and until then restrict the endpoint behind an authenticated gateway or reverse proxy with rate limits and monitor database CPU and query load.
Is CVE-2026-125327 actively exploited?
No confirmed active exploitation of CVE-2026-125327 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-125327?
1) Upgrade pgEdge RAG Server to 2.0.0 or later (fix in PR #44 and commit a09d487; see GHSA-5qg5-rgp6-j5m5). 2) Until patched, do not expose the query endpoint publicly; place it behind an authenticating reverse proxy or API gateway with per-client rate limits and request concurrency caps. 3) If configurable, disable hybrid search (HybridEnabled) as a temporary workaround, accepting reduced retrieval quality. 4) Apply database statement timeouts and connection limits for the RAG service role, and run the RAG server with CPU and memory limits. 5) Detect abuse by alerting on spikes in query rate, long-running full-table SELECTs against the document tables, and sustained high CPU or memory on the RAG server from a single source.
What systems are affected by CVE-2026-125327?
This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, hybrid search retrieval services, LLM applications backed by PostgreSQL/pgvector.
What is the CVSS score for CVE-2026-125327?
CVE-2026-125327 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.45%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker finds an internet-exposed pgEdge RAG Server through scanning or documentation of its default API path. They send a modest stream of concurrent unauthenticated queries. Each request makes the server fetch the whole filtered document corpus from PostgreSQL and rebuild a BM25 index in memory, so database and CPU load climb sharply with only a handful of requests. The RAG service and the database slow to a crawl or crash, and every chatbot or agent depending on retrieval stops working until the attack ends or the service is restarted.
Weaknesses (CWE)
CWE-405Asymmetric Resource Consumption (Amplification)PrimaryCWE-770Allocation of Resources Without Limits or ThrottlingPrimaryCWE-405Asymmetric Resource Consumption (Amplification)CWE-770Allocation of Resources Without Limits or ThrottlingCWE-405 — Asymmetric Resource Consumption (Amplification): The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
- [Architecture and Design] An application must make resources available to a client commensurate with the client's access level.
- [Architecture and Design] An application must, at all times, keep track of allocated resources and meter their usage appropriately.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same attack type: DoSCVE-2023-256689.8TensorFlow: unauthenticated RCE via heap buffer overflow
Same attack type: DoSCVE-2022-235879.8TensorFlow: integer overflow in Grappler enables RCE
Same attack type: DoSCVE-2022-359399.8TensorFlow: ScatterNd OOB write enables RCE/crash
Same attack type: DoSCVE-2022-419009.8TensorFlow: heap OOB RCE in FractionalMaxPool op
Same attack type: DoS