Why your Raspberry Pi's OpenSSL is out of date (and how to fix it)

If you've ever imaged a Raspberry Pi, plugged it in, and walked away happy — the odds are that right now, months or years later, it's running an OpenSSL version with a handful of unpatched CVEs. This isn't a Pi problem specifically. It's a "I imaged once and never touched it again" problem, and the Pi happens to be where it shows up most visibly. Here's how to find the damage and fix it.

Why it happens

The default Raspberry Pi OS image ships with packages from the Debian pool at the time the image was cut. Debian security updates flow in continuously, but they only land on your Pi if apt upgrade runs — and by default, it doesn't. The unattended-upgrades package is available but not enabled on first boot.

Add to that:

• Pis often run "set it and forget it" services (Pi-hole, Home Assistant, Plex, a Mastodon instance) — nobody SSHes in for months.
• Kernel updates are pinned behind rpi-update, which most users don't run.
• Some older Pi models don't get current Raspberry Pi OS — stuck on Buster or older Debian.

The result: your Pi is running OpenSSL 3.0.2 from 2022, with CVE-2022-3602, CVE-2022-3786, CVE-2023-0286, CVE-2023-0215, and a handful more sitting there.

How to check in one command

ssh pi@raspberrypi 'dpkg-query -W -f="\${Package}\t\${Version}\n" openssl libssl3 libcurl4 libcurl3-gnutls'

Output looks like:

openssl  3.0.2-0ubuntu1.20
libssl3  3.0.2-0ubuntu1.20
libcurl4 7.81.0-1ubuntu1.16

Cross-reference each against the NVD or Ubuntu Security pages. Expect to find at least a dozen HIGH-severity CVEs on a stock 2022-era image.

How to fix in one command

ssh pi@raspberrypi 'sudo apt-get update && sudo apt-get upgrade -y'

Reboot if the upgrade included a kernel update:

ssh pi@raspberrypi 'sudo reboot'

Wait thirty seconds, re-check the package versions. Every HIGH-severity CVE on the Debian tracker should be closed.

How to make it stay fixed

ssh pi@raspberrypi 'sudo apt-get install -y unattended-upgrades && sudo dpkg-reconfigure --priority=low unattended-upgrades'

This enables the unattended-upgrades service. It pulls security updates overnight, applies them, and leaves a log at /var/log/unattended-upgrades/. No reboots unless you explicitly opt in via Unattended-Upgrade::Automatic-Reboot "true";.

Scale this across the fleet

If you've got one Pi, the above is fifteen seconds of work. If you've got five Pis, plus three VMs, plus a NAS, plus a VPS, plus a Proxmox host — running apt upgrade manually stops being reasonable. This is what Noxen automates.

Noxen scans every enrolled host nightly, matches packages to CVEs, and shows you a diff from yesterday:

pi.home.example.com
[HIGH]  CVE-2023-0286   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: run `sudo apt-get upgrade openssl libssl3`

You're not tracking CVE trackers by hand. You're not SSHing into every box. You see the exposure in one place and fix it in one place. Which, frankly, is what "homelab" was supposed to mean before the maintenance burden got out of hand.