Cyera reported this to the PostgreSQL Security Team in February and the fixes landed in August [14], so coordinated handling ran about six months [2]. The longer interval is the one that matters for planning: the identifier is CVE-2026-6471 [3] and the affected code reaches back to 9.4 in 2014 [4], roughly twelve years in which the replication path loaded plugins without the check applied to everyone else [1]. The disclosure asserts no exploitation for this CVE [16]; the interval alone does not establish it. What the interval does measure is how long a class of account carried a capability nobody had priced.
The shape of the defect explains the longevity. PostgreSQL already had the guard: check_restricted_library_name() limits where non-superusers may load plugins from and blocks traversal and absolute paths [7]. The replication code path never called it [7], so a plugin name supplied when creating a logical replication slot passed to the operating system's library-loading functions as given, and the library's initialization code ran inside the PostgreSQL server process [8]. The guard existed in the codebase; the replication path simply never called it.
The score itself argues for a lower priority: 7.2 falls short of critical [15], and nothing begins without an account carrying the REPLICATION attribute [1]. That score is fair to the precondition. The precondition is also a credential held as ordinary plumbing by backups, replicas, change data capture pipelines, migrations, and monitoring [9]. Cyera's Vladimir Tokarev describes the outcome as a foothold that "escalates to full PostgreSQL superuser with persistent backdoor access" [2], and because an output plugin runs inside the server process, malicious code operates outside the normal SQL permission model [11].
Patching is the cheap half of the work, and Cyera pairs it with auditing accounts that hold the REPLICATION attribute, restricting replication access, and blocking unnecessary outbound SMB and NFS from database servers [17]. On Windows that egress item is load-bearing rather than tidy: Cyera says an attacker can host the malicious DLL on a remote SMB server and point PostgreSQL at it, with no prior placement of the file on the target [10]. Cutting that traffic changes what the database server can reach, which amounts to a compatibility test against whatever the backup path actually uses.
The 114 malicious PostgreSQL plugins Cyera found on VirusTotal, among them trojans, miners, and reverse shells, support a narrower claim than the count suggests: the plugin surface is worked, and the disclosure ties none of those samples to this CVE [16]. Persistence is the part that outlives the fix, since Cyera demonstrated authentication-configuration changes and preloaded libraries that survive database restarts [13]. A patched instance therefore addresses the future only, leaving the months before it a separate and unresolved question, which is why the account inventory and the auth-config review are separate line items from the version bump. This quarter the decision is a restart window across five release branches [5]; next quarter the consequence is whether anyone can still name who holds the attribute.
