PostgreSQL Security After EOL: What Changes When the Community Stops Patching

PostgreSQL's Security Track Record

PostgreSQL has one of the better security track records in the open source database world. The PostgreSQL Global Development Group maintains a dedicated security team, coordinates embargoed CVE disclosures responsibly, and releases patch updates for all supported major versions simultaneously. For supported versions, the patching experience is fast, reliable, and well-communicated.

The operative word is "supported." When a PostgreSQL major version reaches EOL, the security team stops issuing patches for it. Vulnerabilities discovered after the EOL date are disclosed publicly — and fixed in supported versions — but the EOL version receives no fix.

The PostgreSQL EOL Timeline

PostgreSQL follows a strict 5-year major version support policy:

• PostgreSQL 11: EOL November 2023
• PostgreSQL 12: EOL November 2024
• PostgreSQL 13: EOL November 2025
• PostgreSQL 14: EOL November 2026
• PostgreSQL 15: EOL November 2027 (current LTS for migration targets)

For organisations running PostgreSQL 11 or 12 as of 2025, CVEs disclosed after the EOL date have no official fix available. OSSeva maintains backported patches for these versions; without extended lifecycle support, there is no remediation path short of an emergency upgrade.

High-Impact PostgreSQL Vulnerability Classes

SQL Injection via Extension Functions

Several CVEs across the PostgreSQL 12–14 range have addressed SQL injection risks in bundled extensions, particularly pg_catalog functions and contrib modules like pgcrypto and xml2. These vulnerabilities typically require an authenticated database user to exploit, reducing practical impact in well-configured deployments — but they remain compliance findings regardless of exploitability arguments.

Privilege Escalation via Type Casting

A category of PostgreSQL vulnerabilities involves privilege escalation through implicit type casting in security definer functions. When a function runs with elevated privileges (SECURITY DEFINER), certain type coercions can invoke attacker-controlled functions in a privileged context. These issues are subtle, require application-specific conditions to exploit, and are the type of vulnerability where the difference between "I understand the risk" and "I have a documented risk acceptance" matters enormously for auditors.

Row Security Policy Bypass

Row Level Security (RLS) is increasingly used in enterprise PostgreSQL deployments for multi-tenant data isolation. Several advisories across the PostgreSQL 12–14 range have addressed conditions under which RLS policies were not correctly enforced — particularly with COPY commands and certain query planner optimizations. In a multi-tenant deployment, an RLS bypass is a data isolation failure, not just a security advisory to evaluate in the abstract.

The Compliance Dimension

For regulated-industry PostgreSQL deployments, the compliance implications of EOL versions are direct:

• PCI DSS v4.0 Requirement 6.3.3: Requires that all software components are protected from known vulnerabilities via installation of applicable security patches. An EOL PostgreSQL version with known unpatched CVEs is a direct finding.
• HIPAA §164.312(a)(2)(iv): Encryption/decryption of ePHI, combined with audit controls — both of which have been the subject of PostgreSQL advisories — must be demonstrably addressed.
• SOC 2 CC7.1: Vulnerability detection and remediation controls require documented evidence that known vulnerabilities are being addressed. An unpatched EOL database is difficult to document as "addressed."

OSSeva PostgreSQL Extended Support

OSSeva provides backported CVE patches for PostgreSQL 11, 12, and 13, delivered as signed binary packages compatible with standard PostgreSQL packaging (RPM/DEB) and as container images. Each patch release is accompanied by a compliance evidence package that maps the fix to the relevant CVE, CVSS score, and affected version range — providing auditors with the documentation they require.

Conclusion

PostgreSQL's excellent security reputation is earned by its active maintenance model. EOL versions exit that model, and the security gap grows with every advisory cycle. For enterprise teams with PostgreSQL 11 or 12 in production, extended lifecycle support is the only way to maintain both security and compliance without an emergency upgrade.