The Critical Patch Triad: Four Root-Level Vulns Across Your Entire Stack
What Happened
Four critical CVEs landed on overlapping infrastructure tiers in the same window: Linux hosts, FreeBSD appliances, AI proxy layers, and hosting control planes. Coordination failed in two directions. Dirty Frag's embargo broke before distro patches shipped. The cPanel zero-day is already weaponized in the wild. The common factor is overlapping infrastructure tiers.
| CVE | Target | Severity | Exploitation | Patch Status |
|---|---|---|---|---|
| CVE-2026-43284 (Dirty Frag) | All Linux since 2017 | Critical (LPE → root) | Public PoC, broken embargo | Distros rolling |
| CVE-2026-42511 | FreeBSD DHCP (since 2005) | Critical (LAN → root, no interaction) | No wild exploitation confirmed yet | Patched |
| CVE-2026-42208 | LiteLLM AI proxy | Critical (unauth DB r/w) | Active exploitation confirmed | Patched April 2026 |
| CVE-2026-41940 | cPanel/WHM | High (zero-day) | Dropping Mirai + Sorry ransomware | Patch available |
| CVE-2026-29201/2/3 | cPanel/WHM 11.x | High (two at CVSS 8.8) | No wild exploitation yet — window is short | Patched |
Why This Cluster Is Worse Than Individual CVEs
The operational problem is sequencing. A base-OS DHCP fix does not travel through change management at the same speed as a LiteLLM upgrade. Most teams will patch LiteLLM first because it is easiest. Ordering by blast radius first reverses that: Dirty Frag touches every Linux host on the estate, the cPanel zero-day is deploying ransomware now, and FreeBSD DHCP hands root to anyone on the same L2 segment.
The disclosure process itself is failing. Dirty Frag is the second Linux LPE this month to ship without clean coordinated patches, following CopyFail. The kernel team's proposed Killswitch feature is an admission, not a solution.
The LiteLLM Dimension
LiteLLM sits in the AI proxy layer, a category that was not on most patch calendars a year ago. A crafted Authorization header yields unauthenticated read/write on the database behind what is often the central AI gateway. Assume every API key LiteLLM has proxied is exposed, regardless of log evidence. Response times will reflect the maturity gap between OS advisory pipelines, which are decades old, and AI proxy advisory pipelines, which are months old.
Ollama Adds a Fifth Exposure
Separately, an out-of-bounds read in Ollama lets any unauthenticated remote caller read process memory from exposed instances. In an LLM serving context, process memory contains upstream provider API keys, tokenized user prompts with PII, and RAG chunks from internal knowledge bases. Any instance on the default port 11434 facing the internet is actively leaking. Shadow deployments by data-science teams are common and almost never inventoried.
Cross-Source Pattern
Three independent sources converge on the same read: patch windows are compressing faster than change management can absorb. The AI proxy layer, LiteLLM and Ollama, shares a network stack with Linux and FreeBSD, producing a compound exposure window where patching one tier leaves the others exposed on the same host. Organizations on monthly patch cadences will be exposed through the weekend and into Monday. That is the window attackers target.
What to do
Patch Dirty Frag (CVE-2026-43284) on all Linux hosts, prioritizing internet-facing and crown-jewel systems
Patch FreeBSD DHCP (CVE-2026-42511) on all pfSense, OPNsense, NAS, and network appliances
Upgrade LiteLLM and rotate every API key it has ever proxied, regardless of log evidence
Patch cPanel/WHM across all 11.x branches and hunt for CVE-2026-41940 IoCs (Mirai C2, Sorry ransomware)
Run external ASM scan for Ollama port 11434 and any exposed instance; deploy auth proxy in front of all internal deployments
Establish emergency patch runbook that bypasses CAB for critical CVEs, targeting <24-hour deployment