CVE-2022-3602 and CVE-2022-3786 in your homelab

The OpenSSL project pre-announced critical in October 2022, downgraded it to high at disclosure, and the security world called it "SPECTRE" for about forty-eight hours before realising the pun didn't work. Two years later, most fixed advisories later, these bugs are still shipping on every stock Ubuntu 22.04 installation.

What they are

CVE-2022-3602: A 4-byte stack buffer overflow in the punycode decoder used when OpenSSL validates X.509 certificates containing an emailAddress extension. Triggerable during TLS client-side certificate verification, which is the path taken by basically every server-to-server TLS connection that pins certs.
CVE-2022-3786: A related arbitrary-length stack overflow of the NUL byte in the same punycode path. Reported alongside CVE-2022-3602 because they share the function.

Both affect OpenSSL 3.0.0 through 3.0.6. Fixed in 3.0.7 upstream. Ubuntu 22.04 shipped the patch as openssl 3.0.2-0ubuntu1.7 and later in the jammy-security pocket.

Why you still have it

Three common reasons, all of them reasonable:

Unattended-upgrades is off. Your Proxmox guest or Raspberry Pi was provisioned once, and auto-updates were disabled because you got burned by a kernel update that broke networking. You meant to re-enable them. You haven't.
Package is held. apt-mark hold openssl because you've got a service that depends on a specific TLS behaviour, and you've been meaning to re-test.
The box is Ubuntu 22.04.5 with apt upgrade having never been run since imaging — the exact scenario we use as the Noxen test fixture, because it's the most common homelab baseline.

How to find them across your fleet

The hard way

for host in $(awk '/^Host / && !/*/ {print $2}' ~/.ssh/config); do
  echo "=== $host ==="
  ssh "$host" "dpkg-query -W -f='\${Package} \${Version}\n' openssl libssl3 2>/dev/null"
done

That works. It also doesn't generalise to the next CVE. Every new package-vs-CVE lookup is a new ad-hoc pipeline.

The Noxen way

Open Noxen. Hit "Scan now" on any host. In the findings list:

[HIGH]  CVE-2022-3602  — libssl3 3.0.2-0ubuntu1.20
[HIGH]  CVE-2022-3786  — libssl3 3.0.2-0ubuntu1.20
[HIGH]  CVE-2022-3602  — openssl  3.0.2-0ubuntu1.20
[HIGH]  CVE-2022-3786  — openssl  3.0.2-0ubuntu1.20

Remediation: update `openssl` to the patched version
from your distro security channel.

Under the hood: SSH inventory pulls dpkg -l, the CPE normaliser maps openssl 3.0.2-0ubuntu1.20 to cpe:2.3:a:openssl:openssl:3.0.2, the matcher queries the bundled NDJSON CVE feed by vendor|product, and every overlap where the installed upstream version is below the patched version becomes a finding.

What to do with the report

On Debian/Ubuntu, the fix is one line:

sudo apt-get update && sudo apt-get install --only-upgrade openssl libssl3

Reboot the box if it hosts a long-running TLS server (nginx, Apache, PostgreSQL with SSL) — libssl is loaded at process start and the running processes won't pick up the update until they restart.

On Red Hat family, dnf update openssl does the same job. Red Hat backports the patch into 3.0.x so you'll see openssl-3.0.7-6.el9 or similar after upgrade.

The broader pattern

CVE-2022-3602/3786 isn't special. Five years' worth of critical and high-severity OpenSSL CVEs behave the same way: disclosed in coordinated windows, fixed immediately in tracked distributions, and then sat on by machines that never got apt upgrade again. A weekly scan catches them. Noxen is how you do that weekly scan on a Mac, without writing a shell loop that'll rot in six months.