PostgreSQL 8.4
PostgreSQL 8.4
The PostgreSQL 8.4 reached end of service life on Jul 24, 2014 — 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 8.4 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
- 8.4
- product Label
- PostgreSQL
- release Label
- 8.4
- codename
- lts
- latest Version
- 8.4.22
- release Date
- 2009-07-01
- maintained
- source Url
- https://endoflife.date/postgresql
Lifecycle Dates
- End of Service Life
- Jul 24, 2014
- Last OEM Support
- Jul 24, 2014
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for PostgreSQL 8.4 — 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 8.4?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for PostgreSQL 8.4 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 8.4 Support: Frequently Asked Questions
Is the PostgreSQL 8.4 still supported?
PostgreSQL ended support for the PostgreSQL 8.4 on Jul 24, 2014 — 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 8.4 end of service life (EOSL) date?
PostgreSQL lists the end of service life for the PostgreSQL 8.4 as Jul 24, 2014.
Can I keep using the PostgreSQL 8.4 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 8.4 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 8.4
67 published CVEs affect the PostgreSQL 8.4, including 32 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-2015-0244 | CRITICAL | 9.8 | Jan 27, 2020 | PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 does not properly handle errors while reading a protocol message, which allows remote attackers to conduct SQL injection attacks via crafted binary data in a parameter and causing an error, which triggers the loss of synchronization and part of the protocol message to be treated as a new message, as demonstrated by causing a timeout or query cancellation. |
| CVE-2015-3166 | CRITICAL | 9.8 | Nov 20, 2019 | The snprintf implementation in PostgreSQL before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2 does not properly handle system-call errors, which allows attackers to obtain sensitive information or have other unspecified impact via unknown vectors, as demonstrated by an out-of-memory error. |
| 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-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-2013-1903 | HIGH | 10.0 | Apr 4, 2013 | PostgreSQL, possibly 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 incorrectly provides the superuser password to scripts related to "graphical installers for Linux and Mac OS X," which has unspecified impact and attack vectors. |
| CVE-2013-1902 | HIGH | 10.0 | Apr 4, 2013 | PostgreSQL, 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 generates insecure temporary files with predictable filenames, which has unspecified impact and attack vectors related to "graphical installers for Linux and Mac OS X." |
| 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-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-2015-0243 | HIGH | 8.8 | Jan 27, 2020 | Multiple buffer overflows in contrib/pgcrypto in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allow remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via unspecified vectors. |
| CVE-2015-0242 | HIGH | 8.8 | Jan 27, 2020 | Stack-based buffer overflow in the *printf function implementations in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1, when running on a Windows system, allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a floating point number with a large precision, as demonstrated by using the to_char function. |
| CVE-2015-0241 | HIGH | 8.8 | Jan 27, 2020 | The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric formatting template, which triggers a buffer over-read, or (2) crafted timestamp formatting template, which triggers a buffer overflow. |
| CVE-2013-1900 | HIGH | 8.5 | Apr 4, 2013 | PostgreSQL 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, and 8.4.x before 8.4.17, when using OpenSSL, generates insufficiently random numbers, which might allow remote authenticated users to have an unspecified impact via vectors related to the "contrib/pgcrypto functions." |
| CVE-2010-1447 | HIGH | 8.5 | May 19, 2010 | The Safe (aka Safe.pm) module 2.26, and certain earlier versions, for Perl, as used in PostgreSQL 7.4 before 7.4.29, 8.0 before 8.0.25, 8.1 before 8.1.21, 8.2 before 8.2.17, 8.3 before 8.3.11, 8.4 before 8.4.4, and 9.0 Beta before 9.0 Beta 2, allows context-dependent attackers to bypass intended (1) Safe::reval and (2) Safe::rdo access restrictions, and inject and execute arbitrary code, via vectors involving subroutine references and delayed execution. |
| CVE-2010-1169 | HIGH | 8.5 | May 19, 2010 | PostgreSQL 7.4 before 7.4.29, 8.0 before 8.0.25, 8.1 before 8.1.21, 8.2 before 8.2.17, 8.3 before 8.3.11, 8.4 before 8.4.4, and 9.0 Beta before 9.0 Beta 2 does not properly restrict PL/perl procedures, which allows remote authenticated users, with database-creation privileges, to execute arbitrary Perl code via a crafted script, related to the Safe module (aka Safe.pm) for Perl. NOTE: some sources report that this issue is the same as CVE-2010-1447. |
| CVE-2016-5423 | HIGH | 8.3 | Dec 9, 2016 | PostgreSQL before 9.1.23, 9.2.x before 9.2.18, 9.3.x before 9.3.14, 9.4.x before 9.4.9, and 9.5.x before 9.5.4 allow remote authenticated users to cause a denial of service (NULL pointer dereference and server crash), obtain sensitive memory information, or possibly execute arbitrary code via (1) a CASE expression within the test value subexpression of another CASE or (2) inlining of an SQL function that implements the equality operator used for a CASE expression involving values of different ty |
| 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. |
Showing the 20 most severe of 67 known CVEs.
Get Third Party Support