When "Critical" Isn't: the Summer 2026 OpenSSL and curl Wave

Every few months the OpenSSL project ships a security advisory. Most teams skim it, bump a version, and move on. On June 9, 2026 the project shipped seven CVEs at once, and this time the version bump did not stay quiet.

Within four days those seven CVEs were sitting in most of the environments we watch, flagged High or Critical over and over by the scanners feeding the dashboard. Two weeks later curl did the same thing. Then SQLite and Perl added their own. None of it was a novel exploit. All of it was ordinary bugs in the two or three C libraries that ship inside nearly every container image on earth.

We track vulnerability findings across the tools our customers already run and normalize them against one asset model, across 100 connected environments. That gives us a clear view of a specific kind of event: the moment a shared library gets a CVE and lights up everywhere at once. This summer we watched it happen four times in five weeks. This is what the wave looked like from the inside, and why the number on the dashboard was the least useful thing about it.

One advisory, every image

These CVEs are everywhere for a boring reason. OpenSSL, curl, SQLite and Perl are transitive dependencies of almost every base image, and images get copied, not referenced. Build FROM python:3.12-slim and you inherit that image's OpenSSL. Build something on top of your image and it inherits it again. When the CVE lands, it is already baked into every layer and every container spawned from those layers, plus every registry artifact waiting to spawn more.

Our data shows the shape clearly. About three-quarters of the exposure sits in container and registry images, not in running workloads. The running instances are downstream copies. Patch a host and the next deploy off the same base image brings the bug right back. Rebuild the base image and the copies clear on their own. That asymmetry is the whole game, and it is why host-by-host ticketing loses to base-image hygiene.

It also explains the speed. Once the code is already everywhere, disclosure just gives it a name, and the scanners light up on the next pass.

The part nobody puts in the dashboard

Here is the thing the finding count hides. We pulled the vendors' own advisories for every CVE in the wave. OpenSSL rates five of its seven Low, one Moderate, and one High. curl rates its two credential-leak bugs Medium. The automated feeds that most scanners inherit from, NVD and the CISA ADP, scored several of those same CVEs 9.1 Critical and 8.8 High.

That gap is not a rounding error. It is the difference between a Moderate integrity bug in a rarely-called code path and a 9.1 that pages someone at 2 a.m. Multiply it by every image in every environment and you get a queue full of "criticals" carrying a label their own authors would not sign.

curl maintainer Daniel Stenberg has written about this exact gap for years, and it is not curl's problem alone. It is what automated scoring does to a widely-deployed library: it never under-calls, so on ubiquitous code it over-calls, and deployment breadth amplifies the mistake. In our fleet that dynamic turned a batch of mostly Low and Moderate bugs into the single largest source of vulnerability noise we saw all summer.

The bugs, briefly

Two are worth your time. The rest belong in the next base-image refresh, not in an incident channel.

CVE-2026-45447: use-after-free in PKCS7_verify (OpenSSL rates this High)

Verify a PKCS#7 or S/MIME message whose digestAlgorithms field is an empty ASN.1 SET, and OpenSSL frees a BIO the caller still owns. When the application uses that BIO afterward, usually by freeing it, you get a use-after-free. OpenSSL's own note says the result is a crash, possible heap corruption, and in some contexts possibly remote code execution. The realistic default is a crash. The precondition is that your code verifies attacker-influenced PKCS#7, which mail gateways, package verifiers and some TLS tooling do. It was the most widespread CVE in the wave, though only a minority of hosts actually run that verify path.

CVE-2026-34182: CMS integrity bypass (OpenSSL rates this Moderate, the feed says 9.1)

OpenSSL fails to check the cipher and tag length on a CMS AuthEnvelopedData container. An on-path attacker captures a real AES-GCM message to the victim, keeps the recipient info byte-for-byte so the victim's key still unwraps the content key, and swaps in a non-AEAD cipher. OpenSSL accepts it, and the integrity guarantee quietly fails. It is a genuine bug worth fixing. It is also an on-path integrity bypass on a rarely-used path, which is why the people who wrote it call it Moderate and not a 9.1 emergency.

The wave at a glance. Maintainer rating vs. the automated feed score, with prevalence as the share of monitored environments where the CVE is present:

• CVE-2026-45447 OpenSSL, PKCS#7 use-after-free. Maintainer: High. Feed: 8.8. Prevalence 63%.
• CVE-2026-34182 OpenSSL, CMS forgery. Maintainer: Moderate. Feed: 9.1. Prevalence 63%.
• CVE-2026-45445 OpenSSL, AES-OCB IV reuse. Maintainer: Moderate. Feed: 7.5. Prevalence 63%.
• CVE-2026-34180 OpenSSL, ASN.1 over-read. Maintainer: Low. Feed: 7.5. Prevalence 63%.
• CVE-2026-7383 OpenSSL, ASN1 overflow. Maintainer: Low. Feed: 8.1. Prevalence 63%.
• CVE-2026-9076 OpenSSL, CMS over-read. Maintainer: Low. Feed: 7.5. Prevalence 63%.
• CVE-2026-34181 OpenSSL, PKCS#12 forgery. Maintainer: Low. Feed: 7.4. Prevalence 63%.
• CVE-2026-11856 curl, Digest capture-replay. Maintainer: Medium. Feed: 9.8. Prevalence 59%.
• CVE-2026-8927 curl, proxy capture-replay. Maintainer: Medium. Feed: 9.1. Prevalence 59%.
• CVE-2026-11822 SQLite, FTS5 overflow. Maintainer: conditional on a pre-existing SQL-injection hole. Feed: 7.8. Prevalence 63%.

Fixes: OpenSSL 3.0.21 / 3.5.7 / 4.0.1, curl 8.21.0, SQLite 3.53.2, Perl Socket 2.041.

Where the real fire was

The vulnerabilities that were actually being exploited in the same window looked nothing like the base-image wave. They were not broad shared-library bugs. They were application flaws on specific software, and several were already on CISA's Known Exploited list.

Each of those touched a handful of environments, a fraction of the wave's reach, and every one outranks a wall of dormant OpenSSL findings. A queue sorted by CVSS buries them under image noise. That inversion is the problem worth solving.

Are you affected, and what to do this week

If you run containers, you have these libraries, so the answer is yes. The useful work is narrowing "yes" down to the handful that matter.

• Inventory by artifact, not by host. Use your SBOM or image scanner, then map each finding back to the base image it came from. You are building a list of images to rebuild, not hosts to patch. A few dozen base images usually explain most of the count.
• Prioritize by reachability, not by score. Top of the list: KEV-listed and actively exploited, however few hosts. Then reachable and internet-facing where the vulnerable function actually runs. Then live compute over dormant images. Set aside what is present but unreachable, inactive, or below its own maintainer's bar.
• Fix at the source. Rebuild the base images off patched upstreams and redeploy. The downstream copies clear on their own. Match your distro's backported version, which already carries the patch, rather than the raw upstream number.
• Stop the next one. Pin and continuously re-scan base images, block deploys off images with reachable above-threshold CVEs, and reconcile scanner severity against the vendor advisory before it reaches a human.

How Zest approaches this

We collapse the same CVE reported by Upwind, Wiz, Trivy, Tenable and the rest into one finding with one base-image root cause. We set aside the provably-not-exploitable findings automatically, each with a written reason: library present but the path unreachable, code not loaded, resource inactive, or already mitigated. We group what is left by the image it came from, so a wall of findings reads as "rebuild these four images." And we rank by reachability, internet exposure, KEV status and dwell time, so the exploited ActiveMQ RCE sits above the dormant OpenSSL pile that a CVSS sort would put on top.

When your scanner queue jumps in a week, the question is not how to patch all of it. It is which few are reachable and exploited. That is the question we answer.

Sources

- OpenSSL advisory, June 9 2026: openssl-library.org/news/secadv/20260609.txt.

- curl: CVE-2026-11856 and CVE-2026-8927.

- SQLite: sqlite.org/cves.html. Severity, EPSS and exploitation status from NVD, the CISA KEV catalog and EPSS.

Fleet figures are aggregated and anonymized across connected environments