Upgrading Pgpool-II for the September 2026 CVEs: a practical order of work
Five maintained Pgpool-II branches received security releases on 29 September 2026 in response to JVN#22475874. The notice groups seven CVEs, and the patched versions are 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21. Deciding which node to patch first is a scheduling problem rather than a technical one, and it helps to work from the failure modes.
What the patch set fixes
The advisory lists two out-of-bounds writes, CVE-2026-92867 and CVE-2026-92869, a stack-based buffer overflow, CVE-2026-92870, an improper certificate validation flaw, CVE-2026-92868, a sensitive information logging issue, CVE-2026-92872, and an incorrect authentication algorithm implementation, CVE-2026-92873. Three of them have CVSS v4 base scores of 8.7 or higher.
The single highest-risk item is CVE-2026-92867, which the advisory ties to arbitrary code execution and carries a v3 score of 8.8. CVE-2026-92873 promotes an arbitrary watchdog node to leader. The rest produce process termination, a cluster information leak, or the certificate bypass.
Sequencing the upgrade
Exposure narrows the field. A pooler that accepts client certificates is the one that needs CVE-2026-92868 fixed; a cluster with a single node has no watchdog peer and cannot trigger CVE-2026-92873. The remaining memory safety defects apply to every installation of the affected versions, so no deployment can skip them entirely.
Within a multi-node cluster the usual pattern applies: patch the nodes that are not currently serving traffic first, verify the running version, then move the active leader and confirm that watchdog leadership settles on a patched node. A partial rollout leaves the cluster running mixed versions, which is workable but should not persist.
Version checks that catch real gaps
Reading the version from the running binary is more reliable than reading it from the package manager. Container images and distribution packages sometimes carry a different minor release than the one an administrator expects, and a pooler deployed as a sidecar often sits outside the asset inventory that the rest of the stack lives in.
For clusters on 3.5.x through 4.2.x the situation is different. Those branches appear in the advisory, but support has ended and no fixes will be issued. The path forward is a branch upgrade, and that work needs a maintenance window of its own.
Exposure during the upgrade window
A ZoomEye query for app="Pgpool-II" returned 101 internet-visible instances on 29 September 2026. The corresponding vul.cve="CVE-2026-92868" query returned zero, which is expected while fingerprint data catches up with the advisory. The 101 figure is a reminder that poolers are reachable from outside in some environments, and that an exposed listener during a staged upgrade is still an exposed listener.
Impact while patching is in progress
Between the first and last patched node, a cluster runs mixed versions and the unpatched nodes keep the original behaviour. CVE-2026-92867 remains reachable on those nodes with a low privileged starting point, and CVE-2026-92873 remains reachable in watchdog-enabled clusters until every node is updated. Shortening that window is the practical goal of the sequencing above.
Remediation summary
Update each branch to its fixed release: 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21. Confirm the running version on every node after the rollout. Where the update has to wait, restrict access to the pooler listener and the watchdog peer ports, and keep an eye on process restarts that the logs would otherwise explain. The advisory recommends the update and does not offer workarounds, so anything beyond that is an operational decision.
Top comments (1)
The sequencing logic is sound — two additions from the exposure side. For CVE-2026-92868 (cert validation), the real filter isn’t “does the pooler do TLS” but “is client certificate authentication actually required on the frontend”; plenty of poolers terminate TLS without ever demanding a client cert, and those aren’t exposed to that one even though a scanner will happily mark them as affected. For CVE-2026-92872 (sensitive logging), the blast radius is your log pipeline rather than the database — if those logs ship to a shared sink or a SaaS index, treat it as a data-exposure item, not just a patch item. And on the mixed-version rollout: the watchdog CVE is arguably most dangerous during a partial rollout, because the eligible-but-unpatched nodes are still peers. If watchdog is enabled, it’s worth writing down which nodes can currently be promoted before you touch anything, so you don’t leave an unpatched node electable for the whole window. Reading the version from the running binary rather than the package is exactly right — sidecars drift from the inventory more than anyone expects.