EUVD-2026-89659
GHSA-r4r8-cv9q-rjpm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-privilege Pgpool-II credentials
-
DeliveryConnect to network-exposed Pgpool-II frontend
-
ExploitSend crafted input triggering out-of-bounds write
-
ExecutionCorrupt memory / abnormal process termination
-
ImpactDenial of service for pooled PostgreSQL clients
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the attacker to authenticate to Pgpool-II with at least low privileges (PR:L) - i.e. valid credentials accepted by the Pgpool-II frontend - and network reachability to the Pgpool-II listening port. No user interaction and no high privileges are needed. Exploitation is limited to instances running affected versions (Pgpool-II 3.5.x-4.2.x, 4.3.0-4.3.20, 4.4.0-4.4.17, 4.5.0-4.5.12, 4.6.0-4.6.7, 4.7.0-4.7.2) and to environments where untrusted or semi-trusted parties can obtain authenticated access; the impact is restricted to crashing the process (availability), not code execution or data exposure. The exact request or feature that triggers the out-of-bounds write is not specified in the advisory data. |
| Impact | This is a genuine but bounded-severity issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows a network-reachable, low-complexity flaw requiring low-privilege authentication, with impact confined entirely to availability (VC:N/VI:N/VA:H) - an out-of-bounds write that crashes the Pgpool-II process rather than yielding code execution or data disclosure. No EPSS score, KEV listing, or POC was provided, so exploitation is unproven: no public exploit identified at time of analysis. The authentication requirement (PR:L) and availability-only impact temper the 7.1 rating - this is a denial-of-service against a database middleware tier, not an RCE. Because Pgpool-II sits in front of PostgreSQL, a crash can interrupt all pooled/load-balanced client connections, so operational impact can be significant even though the primitive is only a controlled abort. CWE-787 (OOB write) technically carries memory-corruption potential, but the description explicitly limits the observed outcome to 'abnormal process termination,' consistent with the VA:H / C:N / I:N vector; treat any RCE speculation as unconfirmed. Real priority: moderate - patch on a normal cadence, prioritize where Pgpool-II is exposed to semi-trusted authenticated clients. |
| Exploit ScenarioDerived | An attacker who already holds valid low-privilege credentials to reach the Pgpool-II frontend (e.g. a semi-trusted application account or a tenant on a shared cluster) sends a crafted request that triggers the out-of-bounds write, terminating the Pgpool-II process and severing pooled connections to the backing PostgreSQL servers. This produces a denial of service for all clients routed through that Pgpool-II instance. No public exploit code was identified at time of analysis, and no code execution or data access is indicated. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Sep 30, 2026
An out-of-bounds write in the Pgpool-II connection pooling and load-balancing middleware allows an authenticated remote attacker to trigger abnormal termination of the Pgpool-II process, denying service to PostgreSQL clients routed through it. Exploitation requires valid credentials accepted by the Pgpool-II frontend (PR:L) and network reachability to its listening port; no user interaction or high privileges are needed, and the assessed impact is availability only (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, vendor-scored 7.1 under CVSS 4.0). Affected releases are Pgpool-II 3.5.x through 4.2.x, 4.3.0-4.3.20, 4.4.0-4.4.17, 4.5.0-4.5.12, 4.6.0-4.6.7 and 4.7.0-4.7.2. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV, so this is a genuine but bounded-severity availability issue rather than an active exploitation campaign.
Earlier versions of this analysis (1)
Denial of service in Pgpool-II (3.5.x through 4.2.x, 4.3.0-4.3.20, 4.4.0-4.4.17, 4.5.0-4.5.12, 4.6.0-4.6.7, and 4.7.0-4.7.2) allows an authenticated attacker with a valid credential for the fronted PostgreSQL backend to trigger an out-of-bounds write and cause abnormal process termination. The vulnerability is remotely reachable (AV:N) but requires low privileges (PR:L) and no user interaction; the CVSS vector shows no impact to confidentiality or integrity, only high availability impact. No public exploit code or confirmed active exploitation was identified at time of analysis, and this is assessed as a genuine but bounded availability risk.
RemediationAI
No vendor-released patch version is identified in the available advisory data, so the immediate priority is to consult the vendor notification at https://pgpool.net/news/2026-09-29/ and the JVN advisory at https://jvn.jp/en/jp/JVN22475874/ for the corrected release corresponding to your branch (the 4.x and 3.5.x lines listed as affected are the ones to watch) and upgrade as soon as a fixed build is published. Because the assessed vector requires authentication (PR:L), the most effective compensating control is to reduce who can reach and log in to the pooler: bind Pgpool-II to internal interfaces only and restrict the listening port (9999 by default, plus any PCP port) with firewall or security-group rules to application subnets, accepting that legitimate remote administration must then go through a bastion or VPN. Tighten authentication in pool_hba.conf/authentication configuration so only specific application roles with strong credentials can connect, and rotate any widely shared credentials, since valid low-privilege credentials are the only prerequisite for exploitation; the trade-off is added onboarding effort for new clients and possible breakage of legacy connection strings. If untrusted or semi-trusted tenants share the pooler, split them onto separate Pgpool-II instances per trust boundary so a single authenticated user cannot crash the pooler for everyone. Operationally, enable process supervision and restart-on-failure for Pgpool-II via systemd or your orchestrator, and alert on abnormal worker termination or crash/backtrace logs, which both limits outage duration and gives early warning of probing; be aware that aggressive auto-restart can mask an ongoing attack and should be paired with alerting. Until a fixed release is confirmed by the vendor, these controls mitigate but do not eliminate the out-of-bounds write itself.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Pgpool-II is a PostgreSQL middleware layer that sits between database clients and backends, providing connection pooling, load balancing, replication and query routing; it therefore terminates client sessions itself and parses/rewrites protocol traffic, which is the surface where this defect lives. The root cause is classified as CWE-787 (out-of-bounds write): a buffer is written past its allocated bounds during handling of attacker-supplied input, corrupting adjacent memory. Memory corruption of this class typically manifests as a segmentation fault or abort of the Pgpool-II worker/child process, and the independent assessment confines the demonstrated impact to availability (no confidentiality or integrity impact asserted, scope unchanged). The CPE cpe:2.3:a:pgpool_global_development_group:pgpool-ii:*:*:*:*:*:*:*:* confirms the affected component across all tracked releases, regardless of edition or build. Intelligence sources tag the issue as Buffer Overflow / Memory Corruption, and the JPCERT/CC coordination (JVN#22475874) together with the vendor advisory indicate the defect was reported through the Japanese CERT coordination channel. The advisory data does not specify which request, protocol message or feature triggers the write, so the precise vulnerable code path remains unidentified in open sources; the practical consequence is that authenticated callers can remotely crash the pooler, and the theoretical escalation beyond availability (arbitrary code execution) is not supported by the assessed vector and should not be assumed.
Know when Pgpool Ii gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-reachable, low-complexity flaw needing low-privilege authentication (PR:L); impact is process termination only, so C:N/I:N/A:H and no scope change.
Primary rating from Vendor (jpcert).
CVSS VectorVendor: jpcert
Lifecycle Timeline
2DescriptionCVE.org
An out-of-bounds write vulnerability exists in Pgpool-II, which may allow an authenticated attacker to cause abnormal process termination.
Executive ViewAI
CVE-2026-92869 is an availability-only flaw in Pgpool-II, the connection-pooling layer many organizations place between their applications and PostgreSQL; an attacker who already holds credentials accepted by the Pgpool-II frontend can crash the pooler, severing database connectivity for every application routed through it. No vendor-released patch is available and no public exploit has been identified at time of analysis, so the immediate risk is operational disruption rather than data compromise. Leadership should care because Pgpool-II is typically a single, shared entry point to production databases, meaning one crashed process can translate into a broad, customer-visible application outage.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict the Pgpool-II listening port to trusted application subnets via firewall or security-group rules; enforce least privilege and rotate credentials accepted by the Pgpool-II frontend to shrink the authenticated attack surface; run redundant pooler instances with automatic process restart and validated failover so a terminated process does not become a service outage; and add availability monitoring and alerting on Pgpool-II process health.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
NULL pointer dereference in Pgpool-II allows an unauthenticated remote attacker to crash the watchdog process when the h
Stack-based buffer overflow in Pgpool-II (versions 3.5.x through 4.7.2) allows unauthenticated remote attackers to crash
An out-of-bounds write (CWE-787) in Pgpool-II, the PostgreSQL connection pooler, allows an authenticated attacker who al
Pgpool-II deployments that run in watchdog-based high-availability clustering mode can have an arbitrary watchdog node p
Client certificate authentication in Pgpool-II can be bypassed by a remote unauthenticated attacker because affected ver
Information disclosure vulnerability exists in Pgpool-II 4.4.0 to 4.4.1 (4.4 series), 4.3.0 to 4.3.4 (4.3 series), 4.2.0
Pgpool-II writes sensitive cluster configuration and topology information into its log files, allowing an authenticated
Exploit-DB