Exploitation ongoing with high activity in latest observed window (1 mentions)
Immediate actions
Patch linuxfoundation runc systems immediately
Assume compromise if assets are exposed
Hunt for exploitation attempts and persistence artifacts
Increase monitoring for publicly documented tradecraft
Recommended action window: Immediate (within 24h)
NVD description
runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
Security first. 🛡️
Unraid 7.3.0-rc.1 brings a major security-forward reason to upgrade your test servers.
Patched:
🔒 Docker 29.3.1 runc fixes (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881)
🔒 bind updated for outstanding CVEs
Plus: AMD XDNA support & QEMU 10.2.2! https://t.co/v6PqQN8CdT
Post summary
Unraid 7.3.0-rc.1 patch update includes fixes for three Docker runc CVEs and updates bind for other outstanding CVEs, with no mention of PoC, exploit, or active exploitation.
If you're running critical or multi-tenant workloads on containers, you're playing with fire. The CVE record keeps proving it:
- CVE-2024-21626 — Leaky Vessels: runc container escape, host filesystem access
- CVE-2025-23266 — NVIDIAScape: CVSS 9.0, triggered by a 3-line Dockerfile
- CVE-2025-52881 — runc procfs write-redirect: full breakout, actively exploited in the wild by mid-2026
- CVE-2025-38617 — Linux kernel packet-socket: full container escape via user namespaces
This is not a 2024 phenomenon that someone will eventually fix. The November-2025 runc trio (CVE-2025-31133 / -52565 / -52881) moved from disclosure to confirmed in-the-wild exploitation, affecting Docker, containerd and every major managed Kubernetes service. Escapes never stopped — 2024-2025 brought a fresh surge, and by 2026 the worst of them are being exploited for real.
Containers don't contain. ⚠️
📄 Full blog post: https://unikraft.com/blog/the-mighty-microvm
Post summary
Multiple container escape CVEs, including CVE‑2025‑52881, are reported as actively exploited in the wild, affecting Docker, containerd, and major managed Kubernetes services, underscoring ongoing container security risks.
Proof, not theory.
Jan 2024, CVE-2024-21626: runc leaked a file descriptor. The container reached the host filesystem. Mount namespace was intact. Escape was an fd runc forgot to close.
2025: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881. Mount races. Write to protected host paths from inside the container.
Post summary
The text announces CVE-2024-21626 and several 2025 CVEs, detailing container escape via file descriptor leaks and mount race conditions, but provides no exploit code, patch, or evidence of active exploitation.
runc TRIPLE-CVE (Nov 2025)
CVE-2025-31133: Replace /dev/null with symlink during container init → mount arbitrary host path → write /proc/sys/kernel/core_pattern → host code exec
All 3 exploit the gap between mount setup and security policy. A finality violation.
Post summary
The snippet announces three CVEs that enable host code execution via symlink abuse during container initialization, providing technical exploitation details but no PoC, exploit code, or patch information.
Three runc flaws (CVE-2025-31133, -52565, -52881) turn a crafted mount config into a container escape that writes host procfs, past AppArmor and SELinux.
Once host access is possible, credentials and neighboring workloads become targets. Userspace runtime checks fail after the mount is trusted, and in-kernel enforcement holds. KubeArmor v3.6 runs DNS and file policy through BPF LSM at that boundary.
Post summary
Three newly disclosed runc vulnerabilities enable container escape by exploiting crafted mount configurations, allowing attackers to write to host procfs and bypass AppArmor and SELinux, but no PoC, exploit tool, or reported active exploitation is referenced.
▌ The Bug in the Gap
Last Friday ended on a question: when one of these surfaces gives, who patches it, and how fast can you trust the patch? Pick a morning everyone remembers.
1 July 2024. Qualys publishes regreSSHion (CVE-2024-6387): a signal-handler race in OpenSSH's server, unauth root on glibc Linux. This is the OpenSSH on every server you own. The bug is not the interesting part; bugs arrive like weather. The answer is.
On FreeBSD it was one advisory, six branches corrected between 08:22:13 and 08:27:53 UTC: five minutes and forty seconds. On Linux it arrived as a week of distro advisories, each on its own calendar. Same patch, very different times before you could call it handled.
■ THE BREACH
The November 2025 runc break-outs (CVE-2025-31133, -52565, -52881) show where the bug lived. An attacker swaps a device file for a symlink into procfs; runc bind-mounts it read-write, and a write meant for /dev/null lands in /proc/sysrq-trigger. Put each part in the witness box: procfs behaved as documented, namespaces as promised, runc as asked. Each has an alibi; the prisoner escaped anyway, in the one place no one watched: the seam.
■ THE PATTERN
Individually correct, collectively wrong. In 2020 the kernel added faccessat2; glibc 2.33 preferred it; the container seccomp list did not. Three correct choices, and a program asking to read a file is refused. Four parties, each in the right, had fitted a locked door nobody ordered: what happens when everyone minds their component and no one minds the gaps. The repair scatters too: CIQ, who ship their own enterprise Linux, counted 4,594 upstream-fixed bugs never back-ported into RHEL 8.8. Not a backlog a fortnight clears: a standing condition.
■ THE LIMIT
Containers earned their place: portability, density, legible deployment. And FreeBSD does not get to look serene: weeks after regreSSHion it shipped CVE-2024-7589, another root hole in its own sshd, from its own blocklistd integration. Lower defect density. Not zero. Anyone selling zero has something else to sell.
■ THE BSD ANGLE
A jail (FreeBSD 4.0, 2000) is one kernel object: the boundary sits in the syscall layer, not assembled from four subsystems that read one surface three ways. No four parties, no seam to slip between: a bug cannot hide in a gap that was never opened. And one tree, kernel and libc from the same commit, so a faccessat2 gap cannot open. The scattered week and the five-minute window are not two work ethics. They are two architectures.
■ THE POINT
You do not choose your bugs. You choose your defect density, decided the day the system was designed. When regreSSHion lands on the integrated system, the hard morning is over before it began, and nobody writes up the incident, because there is none. Boring is not the absence of engineering. It is engineering, banked early, paying out on your worst morning.
The third and last of Boring on Purpose.
#freebsd#security#linux#containers#openssh
***
Read the primary sources and weigh the tree yourself:
→ Full essay: https://vivianvoss.net/blog/the-bug-in-the-gap
→ regreSSHion (CVE-2024-6387), Qualys: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
→ FreeBSD-SA-24:04, six branches in five minutes: https://lists.freebsd.org/archives/freebsd-security-notifications/2024-July/000038.html
→ runc break-outs via procfs writes (Nov 2025): https://seclists.org/oss-sec/2025/q4/138
→ CIQ, 4,594 un-backported fixes in RHEL 8.8: https://ciq.com/blog/new-research-the-red-hat-linux-kernel-model-is-broken-and-cant-be-fixed/
→ FreeBSD's own OpenSSH RCE (CVE-2024-7589): https://thehackernews.com/2024/08/freebsd-releases-urgent-patch-for-high.html
Post summary
The post announces CVE-2024-6387 (regreSSHion), highlights patch timelines across platforms, and provides technical details, but offers no evidence of active exploits or proof of concept sharing beyond linked references.
