pglogical vulnerabilities

A use-after-free condition exists in pglogical's worker signaling code, where a worker structure can be dereferenced after the underlying slot has been freed or recycled during normal worker lifecycle events. The condition is reachable during normal replication operation, including by a low-privileged user able to influence worker start, stop, and restart timing through permitted pglogical operations. In the typical case the condition crashes replication workers, causing an availability impact. In the worst case a use-after-free in a PostgreSQL backend can be leveraged as a remote code execution primitive at the privilege of that backend.

In pglogical, when applying replicated changes for a row with missing columns, the table's default expressions are evaluated on the subscriber. The apply worker runs with PostgreSQL superuser privileges, so functions invoked by default expressions also run with those privileges. A publisher can use this path to escalate to superuser on the subscriber.

The pglogical queue mechanism executes message payloads on the subscriber with PostgreSQL superuser privileges. A publisher can send crafted messages to execute arbitrary SQL as superuser, escalating privileges and breaking tenant isolation.

The apply worker in pglogical does not sufficiently validate field lengths in incoming replication protocol messages before copying them, leading to an out-of-bounds read. An attacker controlling a publishing endpoint can send crafted messages, causing disclosure of process memory or crashing the apply worker.