PostgreSQL and the OpenSSL Heartbleed vulnerability

Is your PostgreSQL installation vulnerable to the Heartbleed bug in OpenSSL? The TL;DR; version is "maybe, it depends, you should read this whole thing to find out". If you are vulnerable, it is a high risk vulnerability!

The slightly longer version is that it will be vulnerable if you are using SSL, and not vulnerable if you are not. But the situation is not quite that easy, as you may be using SSL even without planning to. PostgreSQL also not provide any extra protection against the bug - if you are using SSL, you are vulnerable to the bug just as with any other service.

As the bug is in OpenSSL, however, what you need to get patched is your OpenSSL installation and not PostgreSQL itself. And of course, remember to restart your services (this includes both PostgreSQL and any other services using SSL on your system). You will then have to consider in your scenario if you have to replace your SSL keys or not - the same rules apply as to any other service.

It depends on if SSL is enabled

PostgreSQL by default ships with SSL turned off on most platforms. The most notable exception is Debian and derivatives (such as Ubuntu), which enable SSL by default.

If SSL is disabled globally, your installation is not vulnerable.

The easiest way to check this is to just use a simple SQL query:

postgres=# show ssl;
(1 row)

If this parameter returns off, you are not vulnerable. If it returns on, you are.

If you do not need SSL, the easiest fix is to turn this off and restart PostgreSQL. This also brings additional benefits of not paying the overhead of encryption if you don't need it. If you actually use SSL, this is of course not an option.

It depends on your installation

If you have installed PostgreSQL using a package based system, such as yum (from redhat/fedora or from, apt (from debian/ubuntu/etc or from, FreeBSD ports etc, it is up to your operating system to provide a patch. Most major distributions have already done this - you just need to to install it (and restart your services!). If your distribution has not yet updated, you need to convince them to do so ASAP.

If you are using a PostgreSQL installation package that bundles OpenSSL, you need an updated version of this package. The most common example of this is the EnterpriseDB Graphical Installers primarily used on Windows and Mac. We expect a new version of these installers to be released within a day or a few. is also vulnerable and needs an update, but is normally not used for servers.

The OpenSCG separate download packages are also vulnerable.

For each of these you will have to wait for an updated package to show up in the next couple of days. All package maintainers have been notified, so it's only a matter of time.

Per the download pages we do recommend that you always use the "package manager" system for any platform where this is supported, which means most modern Linux or BSD distributions. If you are currently using one of the above installers on these platforms, a quick fix before the packages are out would be to switch to one of the "package manager" platforms that rely on the operating system update process. This may or may not be an option of course, depending on the complexity of the installation.

If you are using a platform where this is not available (such as Windows), your only option is to wait.

pg_hba does not protect you

In PostgreSQL, the SSL negotiation happens before pg_hba.conf is matched. And the vulnerability in OpenSSL is in the negotiation phase. For this reason, even if you have restricted access to your server using pg_hba.conf IP filter rules, or your pg_hba.conf specifies only hostnossl records, this does not protect you.

Obviously, if you have an IP level firewall, either at the host or on the network, that will protect you. But pg_hba does not.

Usage in pgcrypto

The pgcrypto module in PostgreSQL uses OpenSSL to provide encryption functions when available. Since the vulnerability is specifically in the protocol negotiation, use in pgcrypto is not vulnerable to this issue.


I think it's worth mentioning that even if you do not use SSL or you think you can turn it off, you should still upgrade the libraries on your system ASAP. Leaving this unpatched is a recipe for exploit if you find you do need it on some day.

Posted on Apr 8, 2014 at 12:02 by Robert Treat.

It is also worth noting that if you were vulnerable, it means that your private keys and usernames/passwords may have been compromised. See

Posted on Apr 8, 2014 at 13:58 by Joe Conway.

How does this work for Windows? Looking at my server I only see two programs installed, MSVC++ runtime and PostgreSQL 9.3. Is it using a separate install of OpenSSL?

Posted on Apr 9, 2014 at 20:51 by Caleb.

Mac Users: If you are using or PG Commander, please update to the newest versions as both of them include their own version of OpenSSL.

Posted on Apr 10, 2014 at 12:45 by Jakob Egger.

If you are using SSL on Windows, you need an updated openssl library. EDB has not yet shipped the updated installers, but we hope this will happen shortly.

Posted on Apr 10, 2014 at 13:55 by Magnus.

Here's a modified version of Jared Stafford's test script, to test if a server is vulnerable. The vanilla script doesn't recognize a vulnerable PostreSQL server, because it doesn't understand the PostgreSQL protocol.

Posted on Apr 11, 2014 at 10:57 by Heikki Linnakangas.

Here's a modified version of Jared Stafford's test script, to test if a server is vulnerable. The original script doesn't work with a PostgreSQL server, because it doesn't understand the PostgreSQL protocol, and hence will not report a server as vulnerable even if it is.

Posted on Apr 11, 2014 at 10:59 by Heikki Linnakangas.


I speak at and organize conferences around Open Source in general and PostgreSQL in particular.


PGConf.EU 2017
Oct 24-27, 2017
Warsaw, Poland
2Q PGconf
Nov 6-7, 2017
New York, USA
Dec 4-6, 2017
Tokyo, Japan
Feb 2-4, 2018
Brussels, Belgium


Inagural Oslo PUG meetup
Sep 12, 2017
Oslo, Norway
Postgres Open 2017
Sep 6-8, 2017
San Francisco, USA
Jul 5-7, 2017
St Petersburg, Russia
Jul 4, 2017
London, UK
Amsterdam PUG
Jun 29, 2017
Amsterdam, Netherlands
More past conferences