There's a highest severity security hole in openssl v3.0.x where x<7. The patched version (3.0.7) has officially dropped on November 1, 2022.

How to install/update openssl 3.0.7 on an Ubuntu 22.04 system?

Update: The vulnerability has been downgraded from Critical to High.

  • Rest assured that the Ubuntu team is working on this, no matter what. Nov 1, 2022 at 18:12
  • In the future, if you run apt policy <package-name>, you'll get info if there is an updated package. Nov 1, 2022 at 18:22
  • 1
    @ArturMeinild Yes I know, and I did: the absence of a 3.0.7 for one of the foundational components of server security prompted my question.
    – Lexible
    Nov 1, 2022 at 21:40
  • Every few months/weeks/days, some component gets a vulnerability, but it's not going to be get updated to whatever version number that vulnerability scanners look for. ^That is how you check for whether your system is vulnerable to a given CVE and whether an update exists from Canonical for patching it.
    – muru
    Nov 2, 2022 at 4:45

1 Answer 1


First, you need to know that there are TWO ways to fix a vulnerability: Upgrading and Patching.

  • Upstreams emphasize "upgrade" in their public announcements simply because most folks don't know how to patch. But both methods are long-accepted practices.
  • Ubuntu (and many other distros) prefer to patch because upgrading can introduce new bugs and regressions. Upstreams usually make patches available specifically for this purpose.

This means that a fully-secure openssl package in Ubuntu WON'T be version 3.0.7. That's why we need to know the specific CVE(s) for the vulnerabilities.

Second, lets find those CVE(s). A bit of search-engine-fu reveals that the OpenSSL 3.0.7 release targets two CVEs:

  • CVE-2022-3602
  • CVE-2022-3786

Third, let's look at CVE-2022-3602 in the Ubuntu CVE Tracker:

Ubuntu CVE Tracker for CVE 2022-3786

This tells us a couple of important things:

  1. The Ubuntu Security Team is already tracking the issue.
  2. The only package affected is openssl.
  3. A patched package has already been released.

Fourth, let's dig a little deeper by looking at package details the tracker:

enter image description here

Now we know the exact version numbers of openssl packages that are patched and secure.

  • Reminder: It's patched, so the version number is NOT 3.0.7. But it's still secure; that CVE has been mitigated.

Finally, let's see if our 22.04 system has that secure package version

$ apt list openssl
Listing... Done
openssl/jammy-updates,jammy-security,now 3.0.2-0ubuntu1.6 amd64 [installed,automatic]

It's not the secure version (recall that the secure version is 3.0.2-0ubuntu1.7). But it was released today, so a simple sudo apt update and sudo apt upgrade shows an openssl update, then:

$ apt list openssl
Listing... Done
openssl/jammy-security,now 3.0.2-0ubuntu1.7 amd64 [installed,automatic]

SECURE! This system is now running a package that has been patched by the Ubuntu Security Team to mitigate CVE-2022-3602.

Checking if CVE-2022-3786 is also mitigated is left as an exercise for the student.

One final note: If a lot of this information was new to you (patching, CVEs, tracker, confusing version numbers), then one easy way to pierce the veil and understand what's going on is a couple episodes of the Ubuntu Security Podcast, a short weekly discussion of security-related topics from the Ubuntu Security Team. They want you to understand it!

  • 3
    Great answer, but on my Ubuntu 22.04.1, when I do sudo apt update and sudo apt upgrade I don't see any openssl updates, and still see 3.0.2-0ubuntu1.6. Am I missing a step? Nov 1, 2022 at 19:07
  • 4
    Awesome in-depth writeup. Had no idea patches worked this way!
    – sheng
    Nov 1, 2022 at 21:02
  • 7
    The biggest issue with this approach is when trying to audit/verify that things like nginx or python are using the standard library and didn't do a static link. for instance in python you can do an import ssl; ssl.OPENSSL_VERSION which spits out 3.0.2 Mar 2022 and doesn't care about the ubuntu1.7 label. lsof -p xxxx on a python pid that has imported ssl should show the path to the .so which is usually /usr/lib/x86_64-linux-gnu/libssl.so.3 and has a Oct 27 12:06 timestamp. nginx can be done by a ldd $(which nginx) and you can see it is using the correct .so file. Nov 1, 2022 at 21:25
  • 3
    @EricTwilegar patching has been the primary method used by the Ubuntu Security Team for 15 years (and other distros long before), and they're not going to change anytime soon, so be judicious in your use of audit approaches likely to return false answers. For a more in-depth exploration, please open a new Question or offer an alternative Answer.
    – user535733
    Nov 1, 2022 at 22:04
  • 1
    @EricTwilegar even if they arent statically linked, they need to be restarted - your lsof / ldd method is rather useful for that. traversing /proc/pid/fd also can be a helpful addon. all of that is useful, or even neccessary for envs where things need to be tight and controlled and you want to be able to make reliable statements, at least. ubuntu makes for a tricky territory in secure operations (i.e. to less good quality of openscap input data) and can be better to rely on an independent toolset for monitoring security updates. Nov 3, 2022 at 22:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.