CVE-2026-6479

What it actually does

The flaw is an uncontrolled recursion condition in PostgreSQL connection negotiation, specifically around SSL and GSS encryption negotiation. An unauthenticated attacker who can connect to a PostgreSQL Unix-domain socket can repeatedly trigger the recursion path and consume server resources, resulting in sustained denial of service. If both SSL and GSS are disabled, the same denial-of-service condition can be triggered over a PostgreSQL TCP socket. The impact is availability-only: it does not provide data access, privilege escalation, or code execution, but it can make affected PostgreSQL instances unavailable or unstable.

Why it matters to the business

Successful exploitation can disrupt applications that depend on PostgreSQL by exhausting database server resources or making the database unable to accept legitimate connections. This can cause application outages, failed transactions, degraded customer-facing services, delayed batch jobs, and operational incidents. Because the issue may be reachable over TCP only in configurations where both SSL and GSS are disabled, exposure depends heavily on how PostgreSQL is configured and whether untrusted users can reach the database socket or port. The CVSS score is high, but EPSS is currently low and the issue is not in CISA KEV, so remediation should be prioritized based on exposure and business criticality rather than assumed active exploitation.

How an attack unfolds

An attacker first needs network or local socket reachability to PostgreSQL. In the common case, this means the attacker can connect to the PostgreSQL AF_UNIX socket on a local system or through some workload/container boundary where the socket is exposed. In deployments where both SSL and GSS are disabled, the attacker may be able to use the PostgreSQL TCP listener instead. The attacker then initiates malformed or repeated negotiation flows that exercise the vulnerable SSL/GSS negotiation logic. Because the vulnerable server recurses without proper control, repeated attempts can consume CPU, stack, memory, backend process capacity, or connection-handling resources. By sustaining the traffic, the attacker can prevent legitimate clients from connecting or cause service instability until the PostgreSQL process is patched, restarted, rate-limited, or otherwise protected.

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 immediate upgrade is not possible, reduce exposure by restricting access to PostgreSQL Unix-domain sockets and TCP listeners to trusted users and hosts only, enforcing firewall/security-group controls, limiting local users and containers that can access the socket directory, and reviewing socket permissions. For TCP-accessible deployments, avoid running with both SSL and GSS disabled where possible; enabling appropriate encrypted negotiation reduces the described TCP exposure condition. Use PostgreSQL connection limits, OS-level resource controls, and service supervision as temporary resilience measures, but do not treat them as complete fixes.

How to confirm the fix worked

Confirm the running PostgreSQL major and minor version with `SELECT version();`, package manager metadata, or the PostgreSQL server binary version, and verify it is at or above the fixed release for that major branch. Review PostgreSQL configuration to determine exposure: identify `unix_socket_directories`, socket filesystem permissions, `listen_addresses`, firewall rules, `ssl`, and GSS-related settings. Validate that untrusted users, containers, and remote hosts cannot connect to PostgreSQL sockets or ports. After patching, restart or reload PostgreSQL as required by the packaging method, confirm the active server process is the upgraded version, and monitor for reduced abnormal connection churn or availability symptoms.

Typical attack path

1. Identify a PostgreSQL instance or Unix-domain socket that is reachable by the attacker.
2. Determine whether the attack path is local socket based, or TCP based in environments where both SSL and GSS are disabled.
3. Open repeated PostgreSQL connection attempts that trigger SSL/GSS negotiation handling.
4. Sustain the connection pattern to repeatedly exercise the uncontrolled recursion condition.
5. Consume database server resources or connection handling capacity until legitimate clients experience failures, latency, or outage.

How to detect it

Look for evidence of abnormal PostgreSQL connection negotiation activity followed by availability degradation. Useful log sources include PostgreSQL server logs, systemd journal entries for the PostgreSQL service, database proxy logs, firewall or load balancer logs, host audit logs for Unix-domain socket access, and operating system metrics. Investigate sudden spikes in short-lived PostgreSQL connections, repeated connection attempts from the same local user, container, host, or IP address, rapid backend process creation and termination, unusually high CPU usage in PostgreSQL processes, stack/resource exhaustion symptoms, and application errors indicating inability to connect to the database. For TCP exposure, correlate connection spikes with deployments where SSL and GSS are both disabled. For Unix socket exposure, review local process accounting, auditd, container runtime logs, and shell history where available to identify processes repeatedly opening the PostgreSQL socket. There are no public threat actors, KEV listing, or ransomware usage indicated in the provided data, so detection should focus on behavioral denial-of-service patterns rather than known campaign-specific signatures.

What your security team should do

• Patch exposed and business-critical PostgreSQL servers first, especially systems reachable by untrusted users, shared hosts, containers, or network segments.
• Upgrade to PostgreSQL 18.4, 17.10, 16.14, 15.18, or 14.23 or later, matching the deployed major version.
• Inventory PostgreSQL instances that expose AF_UNIX sockets to local multi-user environments or containerized workloads.
• Identify TCP-exposed PostgreSQL deployments where both SSL and GSS are disabled and prioritize those for configuration hardening or patching.
• Restrict PostgreSQL TCP access with firewall rules, security groups, host-based ACLs, and `pg_hba.conf` so only trusted application sources can connect.
• Review Unix socket directory ownership and permissions so untrusted local users cannot initiate arbitrary PostgreSQL connections.
• Add monitoring for spikes in connection attempts, backend process churn, authentication failures, client negotiation errors, and database availability alerts.
• Prepare an operational runbook for rapid PostgreSQL restart/failover if active denial-of-service symptoms appear before patching is complete.