PostgreSQL 10
PostgreSQL 10
The PostgreSQL 10 reached end of service life on Nov 10, 2022 — 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.
24/7 engineers own your PostgreSQL 10 incidents end to end.
Mitigation and patch-around guidance when the vendor no longer ships fixes.
Controls evidence and documentation that keep auditors satisfied.
Specifications
- product
- postgresql
- release
- 10
- product Label
- PostgreSQL
- release Label
- 10
- codename
- lts
- latest Version
- 10.23
- release Date
- 2017-10-05
- maintained
- source Url
- https://endoflife.date/postgresql
Lifecycle Dates
- End of Service Life
- Nov 10, 2022
- Last OEM Support
- Nov 10, 2022
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for PostgreSQL 10 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.
| Feature | OEM Support | 3rd 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 10?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for PostgreSQL 10 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 10 Support: Frequently Asked Questions
Is the PostgreSQL 10 still supported?
PostgreSQL ended support for the PostgreSQL 10 on Nov 10, 2022 — 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 10 end of service life (EOSL) date?
PostgreSQL lists the end of service life for the PostgreSQL 10 as Nov 10, 2022.
Can I keep using the PostgreSQL 10 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 10 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 10
42 published CVEs affect the PostgreSQL 10, including 29 rated critical or high severity. PostgreSQL no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.
| CVE | Severity | CVSS | Published | Summary |
|---|---|---|---|---|
| CVE-2019-10211 | CRITICAL | 9.8 | Oct 29, 2019 | Postgresql Windows installer before versions 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24 is vulnerable via bundled OpenSSL executing code from unprotected directory. |
| CVE-2018-16850 | CRITICAL | 9.8 | Nov 13, 2018 | postgresql before versions 11.1, 10.6 is vulnerable to a to SQL injection in pg_upgrade and pg_dump via CREATE TRIGGER ... REFERENCING. Using a purpose-crafted trigger definition, an attacker can cause arbitrary SQL statements to run, with superuser privileges. |
| CVE-2018-1115 | CRITICAL | 9.1 | May 10, 2018 | postgresql before versions 10.4, 9.6.9 is vulnerable in the adminpack extension, the pg_catalog.pg_logfile_rotate() function doesn't follow the same ACLs than pg_rorate_logfile. If the adminpack is added to a database, an attacker able to connect to it could exploit this to force log rotation. |
| CVE-2026-6637 | HIGH | 8.8 | May 14, 2026 | Stack 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-6477 | HIGH | 8.8 | May 14, 2026 | Use 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-6475 | HIGH | 8.8 | May 14, 2026 | Symlink 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-6473 | HIGH | 8.8 | May 14, 2026 | Integer 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-2022-1552 | HIGH | 8.8 | Aug 31, 2022 | A 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-32027 | HIGH | 8.8 | Jun 1, 2021 | A 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-2019-10127 | HIGH | 8.8 | Mar 19, 2021 | A vulnerability was found in postgresql versions 11.x prior to 11.3. The Windows installer for BigSQL-supplied PostgreSQL does not lock down the ACL of the binary installation directory or the ACL of the data directory; it keeps the inherited ACL. In the default configuration, an attacker having both an unprivileged Windows account and an unprivileged PostgreSQL account can cause the PostgreSQL service account to execute arbitrary code. An attacker having only the unprivileged Windows account ca |
| CVE-2020-25695 | HIGH | 8.8 | Nov 16, 2020 | A 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-2019-10208 | HIGH | 8.8 | Oct 29, 2019 | A flaw was discovered in postgresql versions 9.4.x before 9.4.24, 9.5.x before 9.5.19, 9.6.x before 9.6.15, 10.x before 10.10 and 11.x before 11.5 where arbitrary SQL statements can be executed given a suitable SECURITY DEFINER function. An attacker, with EXECUTE permission on the function, can execute arbitrary SQL as the owner of the function. |
| CVE-2019-10164 | HIGH | 8.8 | Jun 26, 2019 | PostgreSQL versions 10.x before 10.9 and versions 11.x before 11.4 are vulnerable to a stack-based buffer overflow. Any authenticated user can overflow a stack-based buffer by changing the user's own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL operating system account. |
| CVE-2018-1058 | HIGH | 8.8 | Mar 2, 2018 | A flaw was found in the way Postgresql allowed a user to modify the behavior of a query for other users. An attacker with a user account could use this flaw to execute code with the permissions of superuser in the database. Versions 9.3 through 10 are affected. |
| CVE-2018-10915 | HIGH | 8.5 | Aug 9, 2018 | A vulnerability was found in libpq, the default PostgreSQL client library where libpq failed to properly reset its internal state between connections. If an affected version of libpq was used with "host" or "hostaddr" connection parameters from untrusted input, attackers could bypass client-side connection security features, obtain access to higher privileged connections or potentially cause other impact through SQL injection, by causing the PQescape() functions to malfunction. Postgresql versio |
| CVE-2021-23214 | HIGH | 8.1 | Mar 4, 2022 | When 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-25694 | HIGH | 8.1 | Nov 16, 2020 | A 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-2018-10925 | HIGH | 8.1 | Aug 9, 2018 | It was discovered that PostgreSQL versions before 10.5, 9.6.10, 9.5.14, 9.4.19, and 9.3.24 failed to properly check authorization on certain statements involved with "INSERT ... ON CONFLICT DO UPDATE". An attacker with "CREATE TABLE" privileges could exploit this to read arbitrary bytes server memory. If the attacker also had certain "INSERT" and limited "UPDATE" privileges to a particular table, they could exploit this to update other columns in the same table. |
| CVE-2017-15098 | HIGH | 8.1 | Nov 22, 2017 | Invalid json_populate_recordset or jsonb_populate_recordset function calls in PostgreSQL 10.x before 10.1, 9.6.x before 9.6.6, 9.5.x before 9.5.10, 9.4.x before 9.4.15, and 9.3.x before 9.3.20 can crash the server or disclose a few bytes of server memory. |
| CVE-2022-2625 | HIGH | 8.0 | Aug 18, 2022 | A 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. |
Showing the 20 most severe of 42 known CVEs.
Get Third Party Support