CVE-2026-6473

What it actually does

The vulnerability is an integer wraparound in multiple PostgreSQL server features. A low-privileged authenticated database user can cause PostgreSQL to calculate an allocation size incorrectly, allocate too small a memory buffer, and then write beyond the end of that buffer. Depending on memory layout and exploit reliability, this can crash the PostgreSQL backend process or potentially execute attacker-controlled code with the privileges of the operating-system account running PostgreSQL, commonly the database service account. The flaw affects PostgreSQL versions before 18.4, 17.10, 16.14, 15.18, and 14.23.

Why it matters to the business

A successful exploit can compromise the confidentiality, integrity, and availability of data managed by PostgreSQL. In the worst case, an attacker with only database-level access could gain code execution as the database service account, enabling data theft, data tampering, lateral movement from the database server, persistence through database-adjacent tooling, or service disruption. The vulnerability is not currently listed in CISA KEV, is not reported as ransomware-used, and has low EPSS at the time of assessment, but the CVSS severity is high and PostgreSQL is widely deployed in critical business applications, so exposed and multi-tenant database environments should prioritize patching.

How an attack unfolds

An attacker first obtains the ability to execute SQL or otherwise invoke affected PostgreSQL server functionality as an unprivileged database user. This may occur through valid low-privilege credentials, a compromised application account, or an application path that passes very large user-controlled input into the relevant database functions. The attacker then supplies gigabyte-scale or otherwise boundary-triggering input that causes an integer size calculation inside PostgreSQL to wrap. PostgreSQL allocates a buffer that is smaller than required and then writes past the end of that allocation. A simple attempt may terminate a backend process with a segmentation fault, causing connection loss and possible service instability. A more advanced exploit may shape memory contents and repeated attempts to achieve arbitrary code execution as the PostgreSQL operating-system user. From there, the attacker may access database files, read credentials available to the service account, modify stored data, install persistence where filesystem permissions allow, or pivot to other systems reachable from the database host.

How to fix it

Upgrade PostgreSQL to a fixed release for the deployed major version: PostgreSQL 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later. If using vendor-packaged PostgreSQL, install the vendor security update that backports this fix and verify the resulting package maps to one of the fixed upstream releases or includes the relevant patch. Restart PostgreSQL after updating so all backend processes run the patched binaries. As interim risk reduction, restrict direct database access to trusted application servers and administrative networks, remove unnecessary database accounts, enforce least privilege for application database users, monitor and limit application paths that can submit unusually large values to PostgreSQL functions, and consider connection- or statement-level controls that reduce the ability to process gigabyte-scale attacker-controlled input. Mitigations should not be treated as a substitute for patching because the flaw is memory corruption with potential code execution.

How to confirm the fix worked

Confirm the running PostgreSQL version with SELECT version(); or postgres --version and verify it is PostgreSQL 18.4+, 17.10+, 16.14+, 15.18+, or 14.23+ depending on the major branch in use. Validate that the database service has been restarted after package installation by checking process start times and package installation timestamps. For vendor distributions, confirm the package changelog or advisory explicitly includes the fix for this vulnerability. Review application dependency containers, database appliances, managed images, and standby/replica hosts because PostgreSQL binaries may be present outside the primary server. Exposure exists where untrusted or low-privileged users can execute SQL against affected PostgreSQL servers, or where applications pass very large user-controlled inputs into affected PostgreSQL server features.

Typical attack path

1. Obtain authenticated access to PostgreSQL as a low-privileged database user or reach an application path that submits attacker-controlled large input to PostgreSQL.
2. Identify database functions or server features that process large attacker-controlled values and are reachable by the current privileges.
3. Submit crafted oversized input that triggers the integer wraparound during allocation-size calculation.
4. Cause PostgreSQL to allocate an undersized memory buffer and perform an out-of-bounds write.
5. Observe backend crashes, connection resets, or PostgreSQL recovery events while refining the payload.
6. If exploit development is successful, gain code execution as the operating-system user running the PostgreSQL service.
7. Use database service-account access to read or alter data, access local files permitted to the service account, collect secrets, or disrupt database availability.

How to detect it

Look for signs of attempted exploitation in PostgreSQL server logs, operating-system logs, crash dumps, core files, and application logs that submit unusually large values to the database. PostgreSQL exploitation attempts are likely to appear as backend process crashes, segmentation faults, abrupt connection termination, postmaster recovery activity, or repeated failures involving very large SQL statements or parameters. Review logs around any PostgreSQL crash for the authenticated database user, source IP, application name, database name, and the last statement logged if statement logging or error verbosity was enabled. On Linux, inspect syslog, journald, auditd, kernel logs, and systemd service logs for postgres processes receiving SIGSEGV or producing core dumps. Check filesystem locations configured by core_pattern, systemd-coredump, apport, ABRT, or equivalent crash handlers for postgres core artifacts. Investigate any unexpected child processes, shell execution, outbound network connections, or file modifications made by the PostgreSQL operating-system user after a crash, as those may indicate progression from denial of service to code execution. Detection is inherently behavioral because no universal exploit string is provided and crash indicators are not specific to this vulnerability.

• server process .* was terminated by signal 11: Segmentation fault
• terminating any other active server processes
• all server processes terminated; reinitializing
• database system is in recovery mode
• database system was interrupted; last known up at
• postmaster: .* was terminated by signal 11
• postgres: .* was terminated by signal 11
• kernel: postgres.*segfault
• kernel: postmaster.*segfault
• systemd-coredump.*postgres
• systemd-coredump.*postmaster
• core.postgres
• core.postmaster
• /var/lib/systemd/coredump/
• /var/crash/
• /var/spool/abrt/
• connection to server was lost
• server closed the connection unexpectedly

What your security team should do

• Patch PostgreSQL to 18.4, 17.10, 16.14, 15.18, or 14.23 or later, prioritizing internet-reachable, partner-accessible, multi-tenant, and high-value database servers.
• Inventory all PostgreSQL instances, including replicas, containers, developer images, embedded deployments, and vendor-packaged distributions.
• Restrict direct PostgreSQL network access to trusted hosts and remove unnecessary low-privilege database accounts.
• Review application paths that allow large user-controlled values to be passed into database functions, and apply size limits where operationally feasible.
• Increase monitoring for PostgreSQL backend crashes, segmentation faults, repeated connection resets, and unexpected postmaster recovery messages until all instances are patched.
• Audit database roles and service-account operating-system permissions to reduce the impact of possible code execution as the PostgreSQL user.
• After patching, verify the active server version and restart status rather than relying only on package installation records.
• Because there is no current KEV listing, no known ransomware association, and no public exploit maturity reported, balance emergency response with standard high-severity patch SLAs, but do not defer remediation on critical database systems.