Public PoC Drops for 20-Year PostgreSQL pgcrypto RCE Flaw

A working proof-of-concept exploit for CVE-2026-2005 is now public, and the flaw it targets is a heap-based buffer overflow in PostgreSQL’s pgcrypto extension built on code that shipped with the database unmodified since 2005. Every PostgreSQL instance running a version older than the February 12, 2026 patch release, with pgcrypto present and any authenticated user on the other side of a connection, is now reachable through a published attack chain.

Security researcher Varik Matevosyan, known publicly as var77, published the full exploitation code on the CVE-2026-2005 proof-of-concept repository on GitHub, demonstrating a complete path from a single crafted PGP message to operating system command execution under the PostgreSQL service account. The gap between the patch and the public exploit code was roughly three months. That window is now closed.

Two Decades in the Code

The vulnerable function is pgp_parse_pubenc_sesskey(), housed in contrib/pgcrypto/pgp-pubdec.c. When PostgreSQL’s pgcrypto extension decrypts a PGP public-key encrypted session key packet, it reads the RSA or ElGamal payload, calculates a session key length as msglen - 3, and copies that many bytes into ctx->sess_key. That destination buffer is capped at PGP_MAX_KEY, which evaluates to 32 bytes, with no bounds check between the calculated copy length and the buffer limit. An attacker who controls the incoming PGP message through the RSA or ElGamal modulus size can push the session key length into the hundreds of bytes, far past the 32-byte destination, overwriting adjacent heap memory structures in the process.

Team Xint Code, using an AI-powered security analysis tool developed at Wiz, discovered the flaw during the ZeroDay.Cloud 2025 hacking event in London on December 10 and 11, 2025. The official CVE-2026-2005 advisory from the PostgreSQL Global Development Group credited the team and confirmed that all supported major versions were affected.

From Hacking Event to Patch Day

Three months separated discovery from public patch. The upstream fix was committed to the PostgreSQL source tree on February 8, 2026, and shipped across every supported major release four days later. Team Xint Code then published a detailed technical advisory through the ZeroDay.Cloud blog on May 4, 2026, describing the root cause and a reliable exploitation method. A working PoC followed roughly ten days after that, posted to GitHub by Matevosyan. The same February 12 update also addressed a companion flaw uncovered at the same event by a second competing team.

CVE-2026-2006, uncovered by Team Bugz Bunnies, carries a higher CVSS of 9.0 and targets a separate missing-validation path inside the same extension. Both were patched in the same February 12 release. No working public PoC for CVE-2026-2006 has been confirmed; the ZeroDay.Cloud technical advisory for CVE-2026-2005 published by Team Xint Code covers the root-cause analysis for the flaw now carrying live exploit code.

What shifted this week is the category the vulnerability sits in. A coordinated disclosure that stayed within the security research community for three months is now a patched flaw with a published recipe, accessible to anyone who can compile PostgreSQL from the vulnerable commit and run Python against a target host.

The timing also matters. PostgreSQL released a further maintenance update across all branches on May 14, 2026, bringing current users to 18.4, 17.10, 16.14, 15.18, and 14.23. Any instance that has not applied either the February or May update remains exposed.

The Exploit Chain var77 Built

Matevosyan’s PoC relies on two Python libraries: psycopg2, a PostgreSQL client adapter for Python, and pwntools, an exploit development and CTF library widely used in security research. The target PostgreSQL binary must be compiled from a specific vulnerable commit, because the attack resolves the address space layout randomization (ASLR) base by matching leaked memory pointers against ELF symbol offsets unique to that build. Variations in compilation settings or PostgreSQL version change those offsets and cause the chain to fail. That constraint limits automated mass scanning, but it does not protect a specific deployment once an attacker has fingerprinted the binary in use.

Stage One: Controlled Heap Leak

A crafted PGP message partially overwrites the dst->data pointer with two null bytes, redirecting it to a lower heap address. When decrypt_internal() returns and calls mbuf_steal_data(dst), PostgreSQL returns a window of heap contents spanning from the corrupted pointer to the original buffer end. That window contains position-independent executable (PIE) text pointers and heap addresses. A single call leaks both the PIE base address and a reference heap pointer, giving the attacker a working map of the process address space without triggering a crash that would alert defenders.

Stage Two: Arbitrary Write and ASLR Defeat

A second database connection, opened against the same PostgreSQL postmaster process, inherits an identical ASLR layout through PostgreSQL’s fork() model. Addresses recovered in stage one remain valid on the new connection. That second session triggers the overflow again, this time with a payload that forges all four MBuf header fields: data, data_end, read_pos, and buf_end. With those headers under attacker control, writes to any known memory address become achievable.

To validate the PIE base recovered in stage one before committing the destructive write, the exploit reads the CurrentUserId field at the computed offset and compares it against the session’s known database object identifier (OID, the internal numeric handle PostgreSQL assigns to each user). A match confirms the base address and allows the write stage to proceed without prematurely crashing the target process.

Stage Three: Superuser Takeover and Shell Access

With a confirmed base address and arbitrary write capability, the exploit overwrites CurrentUserId in PostgreSQL’s .data section, setting it to 10, the value of BOOTSTRAP_SUPERUSERID, PostgreSQL’s internal identifier for the bootstrap superuser. From that elevated position, the attacker calls COPY FROM PROGRAM, a standard PostgreSQL feature that passes a shell command directly to the operating system. The command executes under the PostgreSQL service account, completing the path from a crafted database query to arbitrary host command execution with database-daemon privileges over every database on the instance.

The Trusted Extension Problem

Most PostgreSQL extensions require superuser access to install. pgcrypto is marked as “trusted,” meaning any authenticated database user with CREATE privilege on a database can enable it with a single statement, no elevated role required. That designation extends the reachable attack surface well beyond what a superuser-restricted extension would allow, and it is why the vulnerability’s CVSS 3.0 vector reads AV:N/AC:L/PR:L: Network access, Low complexity, Low privilege requirements. For a bug that terminates in full OS command execution, that combination places this in a different risk tier than most database vulnerabilities.

The initial foothold does not require a privileged account. Stolen application credentials pulled from an environment variable file or CI/CD pipeline secrets store, a SQL injection flaw in a web application’s query layer, and lateral movement from an already-compromised internal host each provide sufficient authenticated SQL access to load the extension and begin the chain. Wiz Research data cited in the ZeroDay.Cloud advisory found that 80% of cloud environments run PostgreSQL, and that 45% of those cloud environments directly expose port 5432 to the internet, placing a substantial share of the deployed base within network reach of attackers who hold valid database credentials.

Cloud-managed PostgreSQL services carry an additional wrinkle. The patched engine version must be running in production, not simply listed as available in the provider’s console. Managed services apply minor version upgrades on their own maintenance schedules, and customers relying on automatic updates need to confirm the patched version landed before treating their exposure as resolved.

Organizations running pgcrypto because a framework installed it years ago and it was never audited face the same risk as those actively using it in application logic. The extension does not need to appear in current queries to be callable through an authenticated session by an attacker who knows to look for it in pg_extension.

Mitigation and Patch Coverage

Patching is the definitive action. The PostgreSQL Global Development Group shipped fixes across all supported branches on February 12, 2026, and a further maintenance update on May 14, 2026 carries the fix through to current minor versions. Any instance running an older minor release on any of the following branches, with the extension present, remains vulnerable regardless of other controls:

• Branch 18: upgrade to 18.2 or later
• Branch 17: upgrade to 17.8 or later
• Branch 16: upgrade to 16.12 or later
• Branch 15: upgrade to 15.16 or later
• Branch 14: upgrade to 14.21 or later

PostgreSQL 13 and earlier are past the project’s end-of-life support window and received no patch. Running an unsupported branch with the extension present is an unmitigated exposure with no vendor-supplied fix path. While patching is arranged, remove pgcrypto using DROP EXTENSION pgcrypto; on any instance where the extension is not actively required. Restrict the CREATE privilege on databases so untrusted roles cannot reinstall it. Block direct network access to port 5432 and limit PostgreSQL connectivity to trusted application subnets. Revoke COPY FROM PROGRAM permissions from any role that has no operational need for that feature. Rotate database credentials stored in configuration files, environment variables, and CI/CD pipeline secrets, since those credentials form the most common authenticated path to the vulnerable function. Anomalous PGP decryption calls in database logs and extensions appearing in pg_extension without a matching deployment record are both worth configuring alerts against.

The PoC’s binary-specific constraint limits automated scanning against random targets right now. Targeted intrusions against a known PostgreSQL deployment, where the build can be fingerprinted through prior reconnaissance, do not share that limitation. If the chain matures to handle a broader range of compiled builds, the current window of limited opportunistic exploitation narrows further still. Operators who apply the patch before that question becomes relevant do not need to answer it.

Disclaimer: This article is intended for informational and security awareness purposes only. Details of the CVE-2026-2005 exploitation chain are described for defensive and educational value. Figures are accurate as of the date of publication and reflect data from primary sources including the PostgreSQL Global Development Group, ZeroDay.Cloud, and the public GitHub repository. Organizations should consult qualified security professionals before making changes to production database configurations.