The CVSS 6.1 score for CVE-2026-50735 obscures a more serious concern: this vulnerability exploits a trust assumption baked into pglogical's architecture where the subscriber validates nothing from the publisher. The out-of-bounds read is a symptom of that missing validation layer, not an isolated bug.

pglogical's apply worker was designed assuming a benign publisher within a trusted PostgreSQL cluster—not adversarial input from an endpoint you control. When you can direct a subscription at an attacker-controlled publisher, you've established a channel where that publisher can send arbitrary protocol messages the subscriber will process without validation. This is the core architectural problem: the trust model assumes cooperation, not confrontation.

The CVSS feels calibrated for the default deployment where only superusers can create subscriptions. But this CVE is explicitly most relevant to managed PostgreSQL services—PaaS, cloud instances, or any setup where subscription creation has been delegated to lesser-privileged roles. In those environments, the exploit barrier drops to whatever role has subscription privileges. That's a significant expansion of the actual attack surface compared to what the CVSS suggests.

The disclosure mentions pglogical's replication protocol was extended beyond PostgreSQL's own replication protocol validation to support non-PostgreSQL endpoints. That extension may have removed safeguards PostgreSQL itself would provide. The question is whether other pglogical protocol messages have similar validation gaps—this may not be an isolated instance.

What to check in your environment: Identify who can create subscriptions and whether those subscriptions can point to untrusted or external publishers. If subscription privileges extend to roles that aren't fully trusted, or if publishers can be external endpoints, your risk profile differs significantly from what the CVSS implies. Audit the apply worker's message parsing paths for other fields that feed into memory operations without bounds validation. The historical precedent across MySQL, PostgreSQL streaming replication, and MongoDB suggests this class of vulnerability—apply workers assuming well-formed input—tends to reproduce when replication protocols cross trust boundaries.