When pglogical attempts to replicate data, it does not verify it is using a replication connection, which means a user with CONNECT access t
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.7.26-ELS, 4.3.8-ELS, 5.8.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
When pglogical attempts to replicate data, it does not verify it is using a replication connection, which means a user with CONNECT access to a database configured for replication can execute the pglogical command to obtain read access to replicated tables. When pglogical runs it should verify it is running on a replication connection but does not perform this check. This vulnerability was introduced in the pglogical 3.x codebase, which is proprietary to EDB. The same code base has been integrated into BDR/PGD 4 and 5. To exploit the vulnerability the attacker needs at least CONNECT permissions to a database configured for replication and must understand a number of pglogical3/BDR specific commands and be able to decode the binary protocol.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- EnterpriseDB pglogical
From 3 · fixed in 3.7.26-ELS
- EnterpriseDB BDR/PGD
From 4 · fixed in 4.3.8-ELS
- EnterpriseDB BDR/PGD
From 5 · fixed in 5.8.0