Docker containers now ship the majority of production workloads, and attackers have followed the workload. In January 2024 alone, researchers disclosed CVE-2024-21626, a runc container breakout rated CVSS 8.6 that let a malicious image or Dockerfile hand an attacker a file descriptor to the host filesystem — no privileged flag required. It followed a pattern stretching back to CVE-2019-5736, the runc binary-overwrite bug that first showed container escapes were not theoretical. Between those two headline CVEs sit thousands of lower-profile issues: exposed Docker daemons scanned continuously by botnets like Kinsing, cgroups escape bugs like CVE-2022-0492, and a steady stream of malicious images uploaded to public registries. Most teams still triage these by CVSS score alone, which is exactly why exploitation keeps outpacing patching. This post walks through the vulnerability classes actually driving incidents in Docker environments today, with the specific CVEs, campaigns, and misconfigurations behind them — and what actually reduces exposure versus what just adds noise to a backlog.
What is CVE-2024-21626 and why does it matter?
CVE-2024-21626 is a runc container escape disclosed on January 31, 2024, and it matters because it broke the assumption that non-privileged containers can't touch the host filesystem. The bug lived in runc's handling of an internal file descriptor tied to process.cwd(): when a container was built or started with a manipulated working directory, runc could leak a file descriptor referencing the host filesystem into the new container's namespace. An attacker who controlled a Dockerfile, a base image, or a docker exec workflow — including through CI pipelines that build images from untrusted sources — could escape to the host with no additional privileges. It carried a CVSS of 8.6 and affected runc versions up to 1.1.11, meaning any container platform built on it (Docker Engine, containerd, Kubernetes via containerd/CRI-O) inherited the exposure until patched to 1.1.12. The practical lesson: base-image and build-pipeline provenance matters as much as runtime hardening, because this class of bug turns "build a container" into "run arbitrary code on the host."
How are exposed Docker APIs actually being exploited?
Exposed Docker APIs are being exploited primarily by cryptomining botnets that scan the public internet for unauthenticated daemons on TCP port 2375 and immediately deploy malicious containers. Docker's remote API is unencrypted and unauthenticated by default when exposed without TLS, and campaigns like Kinsing — tracked by Aqua Nautilus since 2020 and still active — automate the entire kill chain: scan for open 2375/2376 ports, pull a malicious image, mount the host filesystem into a new container, and drop a cryptominer plus a rootkit for persistence. TeamTNT ran a parallel campaign targeting the same misconfiguration, adding credential-harvesting for AWS and Docker Hub tokens found inside compromised containers. Shodan-based scans by multiple security teams have repeatedly turned up thousands of internet-facing Docker daemons at any given time, most belonging to organizations that exposed the port for CI convenience and never closed it. Binding the daemon socket to localhost, requiring mutual TLS for any remote API access, and alerting on outbound connections from container hosts closes this specific door — but only if someone is actually watching for the daemon being reachable in the first place, not just scanning image contents.
What container escape bugs affect the Linux kernel and runc specifically?
The two most consequential kernel/runtime escape bugs are CVE-2022-0492, a cgroups release_agent flaw, and CVE-2019-5736, the original runc binary-overwrite vulnerability. CVE-2022-0492, disclosed in February 2022 with a CVSS of 7.8, existed because the kernel's cgroup v1 release_agent file could be written by a container process that had the right capabilities (or ran unconfined), letting it register a host-side program to execute outside the container's namespace. Kubernetes clusters and Docker hosts running containers with CAP_SYS_ADMIN or without user namespace isolation were directly exposed. CVE-2019-5736, three years earlier, worked differently but landed at a similarly severe CVSS 8.6: a malicious container could trick runc exec into overwriting the host's runc binary itself, meaning the next container start or exec on that host executed attacker code. Both bugs share a root cause worth internalizing: container isolation depends on kernel namespace and capability boundaries holding, and any workload running with excess capabilities (--privileged, CAP_SYS_ADMIN, host PID/network namespace sharing) turns a contained bug into a host compromise. Capability minimization isn't a compliance checkbox here — it's the actual blast-radius control.
How much risk do malicious images on public registries add?
Malicious images on Docker Hub and other public registries add substantial risk because attackers routinely typosquat popular image names and hide cryptominers or backdoors inside images that otherwise function normally. Sysdig's threat research team has documented recurring waves of malicious Docker Hub uploads — images named to look like official python, node, or nginx builds, or disguised as popular open-source tools, that embed XMRig miners or reverse shells triggered on container start. Because Docker Hub's anonymous pull model doesn't require verification to publish, and automated scanning at upload time historically lagged behind upload volume, malicious images have stayed live and pullable for extended periods before takedown — long enough to accumulate thousands of pulls in some documented cases. The fix isn't "don't use public registries," which is impractical; it's pinning images by digest rather than mutable tags, restricting pulls to a vetted internal registry or an allowlist of verified publishers, and scanning every image at pull time and on a recurring basis, since an image clean at pull can have a vulnerability disclosed in a dependency the next day.
Why do most Docker CVEs never actually get exploited in your environment?
Most Docker CVEs never get exploited in a given environment because the vulnerable code path inside the container image is never reachable from running application code, even though the vulnerable package is technically present. A base image can ship a vulnerable version of libxml2 or openssl that a scanner flags as critical, but if the application never calls the vulnerable function — or the package is a transitive dependency of a dependency that's never invoked — there is no exploitable path, no matter what the CVSS score says. This is the core reason severity-only triage produces backlogs measured in thousands of "critical" findings that security teams can't realistically work through: traditional SCA and image scanners report on presence, not exploitability. Studies across the industry have consistently found that only a small fraction of flagged vulnerabilities in container images correspond to code that's actually loaded and callable at runtime. Teams that keep scanning without adding reachability context end up patching the easy, irrelevant CVEs first and leaving the genuinely exploitable ones — like a container escape reachable through an exposed API — sitting in the same undifferentiated queue.
How Safeguard Helps
Safeguard cuts through exactly this noise by running reachability analysis on every image and dependency, so a CVE in an unused code path gets deprioritized while a flaw sitting on an actual execution route — including toward container escape primitives like the runc and cgroups bugs above — gets flagged as urgent. Griffin AI, Safeguard's analysis engine, correlates that reachability signal with real-world exploitation data (including active campaigns like Kinsing-style API scanning) to rank findings by what's actually being attacked, not just CVSS. Safeguard generates and ingests SBOMs across your build pipeline so every base image, layer, and transitive dependency is accounted for and diffable release to release, closing the provenance gap that lets typosquatted or tampered images slip through. When a fix is available, Safeguard opens an auto-fix PR with the minimal version bump or config change needed — pinned by digest where relevant — so remediation ships in the same workflow developers already use, instead of sitting in a spreadsheet.