April 2026 monthly report: open-source critical infrastructure - regreSSHion at year two
Two years after regreSSHion (CVE-2024-6387), the OpenSSH CVE that didn't quite weaponise globally - plus what CUPS, OpenSSL, and the rest of the critical OSS stack look like in April 2026.
The OSS layer is the substrate
Every commercial software stack we audit - regardless of vendor, regardless of cloud - depends on a small set of foundational open-source components. OpenSSH, OpenSSL, the Linux kernel, CUPS, glibc, libpcap, libxml2. When one of these has a critical CVE, the blast radius is measured in fractions of the public internet.
This month's digest revisits the foundational OSS CVEs of the past 24 months - what mattered, what proved less impactful than feared, and what defenders should still be tracking.
regreSSHion (CVE-2024-6387): the one that didn't quite weaponise
In July 2024, Qualys disclosed CVE-2024-6387 - a signal-handler race condition in OpenSSH's sshd that allows pre-authentication remote code execution as root on glibc-based Linux systems. Qualys's research note estimated the exploitation difficulty as "10,000 attempts over multiple hours" against a default-configured server.
Two years later, the CVE has not produced the kind of mass-exploitation many predicted. The reasons matter:
- High exploitation difficulty. Reliable exploit required architecture-specific tuning and per-target reconnaissance.
- Fast patch uptake. OpenSSH 9.8 shipped within days; major distros backported within a week.
- Mitigation availability. Setting
LoginGraceTime 0insshd_configblocked the race entirely.
The lesson: a high CVSS does not guarantee mass exploitation, and a fast vendor patch combined with a clear mitigation is the best counter-narrative to a high-profile CVE.
Exploitation difficulty is a feature of CVSS that gets under-weighted. CVSS scoring is for prioritisation, not prediction. regreSSHion was correctly scored 8.1 - but the qualitative difficulty kept mass exploitation from materialising. Don't assume "9.x" always means "patch immediately or die."
CUPS (CVE-2024-47076 + chain): the chain that did matter
In September 2024 researcher Simone Margaritelli disclosed a four-CVE chain in CUPS (the Unix printing system) - CVE-2024-47076, CVE-2024-47175, CVE-2024-47176, and CVE-2024-47177 - culminating in unauthenticated remote code execution on any Linux/macOS host running cups-browsed. The chain was demonstrated against default configurations on Ubuntu, Debian, Fedora, openSUSE, and other distros.
Unlike regreSSHion, the CUPS chain is technically straightforward to exploit. The mitigating factor is exposure: most production servers don't run cups-browsed at all, and few have UDP/631 reachable from the public internet.
| CVE | Component | Role in chain |
|---|---|---|
| CVE-2024-47076 | libcupsfilters | Input validation bypass |
| CVE-2024-47175 | libppd | PPD attribute injection |
| CVE-2024-47176 | cups-browsed | UDP 631 trust |
| CVE-2024-47177 | cups-filters | Command injection |
XZ Utils (CVE-2024-3094): the social-engineering anniversary
Covered in detail in our March 2026 monthly digest. The two-year retrospective: the XZ backdoor was caught before reaching stable distributions thanks to a single careful engineer (Andres Freund) noticing a 500ms regression in sshd login latency. The attack model - sustained social engineering of an unpaid maintainer - remains demonstrated and viable.
The April audit checklist
OpenSSH version sweep
Confirm every internet-reachable SSH service is on OpenSSH 9.8 or later (or has the LoginGraceTime 0 mitigation). Two years after regreSSHion, we still find unpatched 8.x instances on perimeter scans.
CUPS exposure check
For every Linux server in your estate, confirm cups-browsed is not running and UDP/631 is not reachable from the network boundary. Most prod servers don't need either; the default-on packaging on some distros is the risk.
OpenSSL inventory
Inventory every TLS-terminating service for OpenSSL version. The major 3.x CVE wave is behind us, but the long tail of 1.0.2 / 1.1.1 instances continues to surface on engagement scans.
SBOM coverage
For every production service, confirm the SBOM lists OpenSSH, OpenSSL, glibc, libxml2, and CUPS components with current versions. This is the data that lets you respond in hours to the next foundational-OSS CVE.
Where we are on coverage
Foundational OSS is the substrate the entire industry runs on. Defending it well means having an SBOM you can query, a patch cadence you can hold to, and a network posture where critical OSS daemons aren't on the public internet by default.
- Staatse monthly digest, Apr 2026
Key takeaways
- regreSSHion (CVE-2024-6387) is the case study for "high CVSS, low real-world impact" - exploitation difficulty matters and is under-weighted in standard scoring.
- The CUPS chain (CVE-2024-47076 et al.) is the opposite case - easy to exploit, mitigated mostly by limited exposure of the daemon.
- OpenSSL ≥ 3.0 adoption is at 64% in our scan data - the long tail is a long tail. Inventory remains the highest-leverage control.
- SBOM coverage at 41% means most teams cannot respond in hours to a foundational-OSS CVE. Fix the SBOM gap before the next one ships.
Closing
For a focused review of your foundational-OSS exposure across the production estate, our network penetration testing service and cloud penetration testing service together cover this scope. Get in touch.
References & further reading
- Qualys Threat ResearchregreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
- NVDCVE-2024-6387 - OpenSSH server signal handler race condition
- OpenSSHOpenSSH 9.8 release notes - regreSSHion fix
- NVDCVE-2024-47076 - libcupsfilter cfGetPrinterAttributes5 IPP attributes validation
- Simone MargaritelliPublic disclosure of CUPS RCE chain
- NVDCVE-2024-3094 - XZ Utils backdoor (referenced for OSS context)
- OpenSSFOpenSSF Best Practices Badge Program
- TideliftState of the open source maintainer report 2024