PostgreSQL

PostgreSQL 13

PostgreSQL 13

The PostgreSQL 13 reached end of service life on Nov 13, 2025 — PostgreSQL no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.

End of Service LifeEOSL Date: Nov 13, 2025
Issue Management

24/7 engineers own your PostgreSQL 13 incidents end to end.

Vulnerability Remediation

Mitigation and patch-around guidance when the vendor no longer ships fixes.

Compliance Maintenance

Controls evidence and documentation that keep auditors satisfied.

Specifications

product
postgresql
release
13
product Label
PostgreSQL
release Label
13
codename
lts
latest Version
13.23
release Date
2020-09-24
maintained
source Url
https://endoflife.date/postgresql

Lifecycle Dates

End of Service Life
Nov 13, 2025
Last OEM Support
Nov 13, 2025

Get Third Party Support

Your quote will be sent to this address.

By submitting this form, you agree to our Privacy Policy.

OEM vs. 3rd Party Support

See how third-party support compares to the vendor contract for PostgreSQL 13 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.

FeatureOEM Support3rd Party Support
Post-EOSL Support
Break/Fix Support
Until EOSL
24/7 Monitoring
Vulnerability Scanning & Remediation
Managed Operations
Procedure & Configuration Review
Compliance & Audit Documentation
Limited
Discounted Migration to Other Platforms

Why Choose 3rd Party Support for PostgreSQL 13?

Vulnerability Remediation

Scanning, mitigation and patch-around guidance for PostgreSQL 13 when the vendor no longer ships fixes.

Compliance Maintenance

Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.

24/7 Expert Support

Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.

PostgreSQL 13 Support: Frequently Asked Questions

Is the PostgreSQL 13 still supported?

PostgreSQL ended support for the PostgreSQL 13 on Nov 13, 2025 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.

When is the PostgreSQL 13 end of service life (EOSL) date?

PostgreSQL lists the end of service life for the PostgreSQL 13 as Nov 13, 2025.

Can I keep using the PostgreSQL 13 after its EOSL date?

Yes. EOSL means PostgreSQL stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.

How much does third-party support for the PostgreSQL 13 cost?

Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.

Known Vulnerabilities Affecting PostgreSQL 13

36 published CVEs affect the PostgreSQL 13, including 18 rated critical or high severity. PostgreSQL no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.

CVESeverityCVSSPublishedSummary
CVE-2026-6637HIGH8.8May 14, 2026Stack buffer overflow in PostgreSQL module "refint" allows an unprivileged database user to execute arbitrary code as the operating system user running the database. A distinct attack is possible if the application declares a user-controlled column as a "refint" cascade primary key and facilitates user-controlled updates to that column. In that case, a SQL injection allows a primary key update value provider to execute arbitrary SQL as the database user performing the primary key update. Vers
CVE-2026-6477HIGH8.8May 14, 2026Use of inherently dangerous function PQfn(..., result_is_int=0, ...) in PostgreSQL libpq lo_export(), lo_read(), lo_lseek64(), and lo_tell64() functions allows the server superuser to overwrite a client stack buffer with an arbitrarily-large response. Like gets(), PQfn(..., result_is_int=0, ...) stores arbitrary-length, server-determined data into a buffer of unspecified size. Because both the \lo_export command in psql and pg_dump call lo_read(), the server superuser can overwrite pg_dump or
CVE-2026-6475HIGH8.8May 14, 2026Symlink following in PostgreSQL pg_basebackup plain format and in pg_rewind allows an origin superuser to overwrite local files, e.g. /var/lib/postgres/.bashrc, that hijack the operating system account. It will remain the case that starting the server after these commands implicitly trusts the origin superuser, due to features like shared_preload_libraries. Hence, the attack has practical implications only if one takes relevant action between these commands and server start, like moving the fi
CVE-2026-6473HIGH8.8May 14, 2026Integer wraparound in multiple PostgreSQL server features allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds. This may execute arbitrary code as the operating system user running the database. In applications that pass gigabyte-scale user inputs to the relevant database functions, the application input provider may achieve a segmentation fault. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
CVE-2024-10979HIGH8.8Nov 14, 2024Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
CVE-2024-7348HIGH8.8Aug 8, 2024Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.
CVE-2023-5869HIGH8.8Dec 10, 2023A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server's memory.
CVE-2022-1552HIGH8.8Aug 31, 2022A flaw was found in PostgreSQL. There is an issue with incomplete efforts to operate safely when a privileged user is maintaining another user's objects. The Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER, and pg_amcheck commands activated relevant protections too late or not at all during the process. This flaw allows an attacker with permission to create non-temporary objects in at least one schema to execute arbitrary SQL functions under a superuser identity.
CVE-2021-32027HIGH8.8Jun 1, 2021A flaw was found in postgresql in versions before 13.3, before 12.7, before 11.12, before 10.17 and before 9.6.22. While modifying certain SQL array values, missing bounds checks let authenticated database users write arbitrary bytes to a wide area of server memory. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CVE-2020-25695HIGH8.8Nov 16, 2020A flaw was found in PostgreSQL versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. An attacker having permission to create non-temporary objects in at least one schema can execute arbitrary SQL functions under the identity of a superuser. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CVE-2021-23214HIGH8.1Mar 4, 2022When the server is configured to use trust authentication with a clientcert requirement or to use cert authentication, a man-in-the-middle attacker can inject arbitrary SQL queries when a connection is first established, despite the use of SSL certificate verification and encryption.
CVE-2020-25694HIGH8.1Nov 16, 2020A flaw was found in PostgreSQL versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. If a client application that creates additional database connections only reuses the basic connection parameters while dropping security-relevant parameters, an opportunity for a man-in-the-middle attack, or the ability to observe clear-text transmissions, could exist. The highest threat from this vulnerability is to data confidentiality and integrity as well as system a
CVE-2024-0985HIGH8.0Feb 8, 2024Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. Versions be
CVE-2022-2625HIGH8.0Aug 18, 2022A vulnerability was found in PostgreSQL. This attack requires permission to create non-temporary objects in at least one schema, the ability to lure or wait for an administrator to create or update an affected extension in that schema, and the ability to lure or wait for a victim to use the object targeted in CREATE OR REPLACE or CREATE IF NOT EXISTS. Given all three prerequisites, this flaw allows an attacker to run arbitrary code as the victim role, which may be a superuser.
CVE-2026-6479HIGH7.5May 14, 2026Uncontrolled recursion in PostgreSQL SSL and GSS negotiation allows an attacker able to connect to a PostgreSQL AF_UNIX socket to achieve sustained denial of service. If SSL and GSS are both disabled, an attacker can do the same via access to a PostgreSQL TCP socket. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
CVE-2023-39417HIGH7.5Aug 11, 2023IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.
CVE-2020-25696HIGH7.5Nov 23, 2020A flaw was found in the psql interactive terminal of PostgreSQL in versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an interactive psql session uses \gset when querying a compromised server, the attacker can execute arbitrary code as the operating system account running psql. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CVE-2023-2454HIGH7.2Jun 9, 2023schema_element defeats protective search_path changes; It was found that certain database calls in PostgreSQL could permit an authed attacker with elevated database-level privileges to execute arbitrary code.
CVE-2026-6478MEDIUM6.5May 14, 2026Covert timing channel in comparison of MD5-hashed password in PostgreSQL authentication allows an attacker to recover user credentials sufficient to authenticate. This does not affect scram-sha-256 passwords, the default in all supported releases. However, current databases may have MD5-hashed passwords originating in upgrades from PostgreSQL 13 or earlier. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
CVE-2021-3677MEDIUM6.5Mar 2, 2022A flaw was found in postgresql. A purpose-crafted query can read arbitrary bytes of server memory. In the default configuration, any authenticated database user can complete this attack at will. The attack does not require the ability to create objects. If server settings include max_worker_processes=0, the known versions of this attack are infeasible. However, undiscovered variants of the attack may be independent of that setting.

Showing the 20 most severe of 36 known CVEs.

Get Third Party Support

Related PostgreSQL Products

All PostgreSQL products →
PostgreSQL 13
Save 40-70% vs OEM
Get Third Party Support