{"id":5726,"date":"2025-11-10T11:30:24","date_gmt":"2025-11-10T11:30:24","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=5726"},"modified":"2025-11-10T11:30:24","modified_gmt":"2025-11-10T11:30:24","slug":"runtime-bugs-break-container-walls-enabling-root-on-docker-hosts","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=5726","title":{"rendered":"Runtime bugs break container walls, enabling root on Docker hosts"},"content":{"rendered":"<div>\n<div class=\"grid grid--cols-10@md grid--cols-8@lg article-column\">\n<div class=\"col-12 col-10@md col-6@lg col-start-3@lg\">\n<div class=\"article-column__content\">\n<div class=\"container\"><\/div>\n<p>Three newly disclosed high-severity bugs in the \u201crunc\u201d container runtime let attackers break out of containers despite standard hardening and isolation controls.<\/p>\n<p>According to Aleksa Sarai, a senior software engineer at SUSE and an OCI board member, the bugs stem from logic flaws in how runc handles writes to certain procfs files, letting attackers inside containers hijack host privileges by abusing masked paths, console bind-mounts, and write gadgets.<\/p>\n<p>\u201cAll these vulnerabilities ultimately allow (through different methods) for full container breakouts by bypassing runc\u2019s restrictions for writing to arbitrary \/proc files,\u201d Sarai said in an advisory posted to the oss-sec list.<\/p>\n<p>Sarai emphasized that while these attacks require custom mount configurations or untrusted images, the threat is very real for containerized systems, especially in orchestrators like Docker or Kubernetes.<\/p>\n<p>The advisory urges users to update immediately to patched versions or apply the provided patches.<\/p>\n<h2 class=\"wp-block-heading\"><a><\/a>Masked-path issue: CVE-2025-31133<\/h2>\n<p>The first of the trio addresses a masked-path issue in runc where the container runtime replaces a file with a bind-mount to \u201c\/dev\/null\u201d, a data sink file on Unix-like systems. If an attacker can instead make \/dev\/null a symlink to a critical procfs file (e.g., \/proc\/sys\/kernel\/core_pattern or \/proc\/sysrq-trigger), runc inadvertently mounts that target read-write, granting the attacker host access.<\/p>\n<p>On one variant, runc simply ignores a missing \/dev\/null and proceeds, which leads to information disclosure via masked files like \u201c\/proc\/kcore\u201d or \u201c\/proc\/timer_list\u201d, both sensitive kernel-visible interfaces.<\/p>\n<p>Sarai <a href=\"https:\/\/seclists.org\/oss-sec\/2025\/q4\/138\" target=\"_blank\" rel=\"noopener\">warned<\/a> that while the attack cannot mount arbitrary host files directly, the methods are sufficient to trigger full container breakout or host crash.<\/p>\n<p>The flaw, tracked as <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2025-31133\">CVE-2025-31133<\/a>, affects all known runc versions and has received a severity rating of 7.3 out of 10. It has been fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.<\/p>\n<h2 class=\"wp-block-heading\"><a><\/a>Console and Write-Gadget Lurkers: CVE-2025-52565 &amp; CVE-2025-52881<\/h2>\n<p>The second vulnerability, tracked as <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2025-52565\">CVE-2025-52565<\/a>, targets \u201c\/dev\/console\u201d bind-mount handling. An attacker can replace the target path with a symlink, which will cause runc to bind-mount the wrong target, allowing the attacker to gain write access to procfs paths.<\/p>\n<p>\u201cAs with CVE-2025-31133, this happens after pivot_root(2) and so cannot be used to bind-mount host files directly, but an attacker can trick runc into creating a read-write bind-mount of \/proc\/sys\/kernel\/core_pattern or \/proc\/sysrq-trigger, leading to a complete container breakout,\u201d Sarai said, adding that versions 1.0.0-rc3 and later remain vulnerable.<\/p>\n<p>The third flaw (<a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2025-52881\" target=\"_blank\" rel=\"noopener\">CVE-2025-52881<\/a>) allows an attacker to bypass Linux Security Modules (LSM) such as SELinux or AppArmor by redirecting writes to procfs files. Once the LSM labels are effectively neutered, writes to host-level procfs become possible, enabling <a href=\"https:\/\/www.csoonline.com\/article\/4046353\/critical-docker-desktop-flaw-allows-container-escape.html\">full host compromise<\/a>.<\/p>\n<p>\u201cBased on our analysis, neither AppArmor nor SELinux can protect against the full version of the redirected write attack,\u201d Sarai said. \u201c The container runtime is generally privileged enough to write to arbitrary procfs files, which is more than sufficient to cause a container breakout.\u201d <\/p>\n<p>Using rootless containers can help, as doing so will block most of the inadvertent writes, Sarai added. Additional analysis from Sysdig confirmed that all three flaws require the ability to start containers with custom mount configurations, which can be easily achieved through untrusted container images and Dockerfiles. Exploitation of these flaws can be done by monitoring suspicious symlink behaviors, Sysdig <a href=\"https:\/\/www.sysdig.com\/blog\/runc-container-escape-vulnerabilities\" target=\"_blank\" rel=\"noopener\">said<\/a>. For this, it has added detection rules for its Secure and Falco users.\u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Three newly disclosed high-severity bugs in the \u201crunc\u201d container runtime let attackers break out of containers despite standard hardening and isolation controls. According to Aleksa Sarai, a senior software engineer at SUSE and an OCI board member, the bugs stem from logic flaws in how runc handles writes to certain procfs files, letting attackers inside [&hellip;]<\/p>\n","protected":false},"author":0,"featured_media":5727,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-5726","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5726"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5726"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5726\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/5727"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5726"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5726"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5726"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}