fix(security/UNKNOWN/): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY]

[renovate-sh-app]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/opencontainers/runc	v1.3.3 → v1.3.6

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

runc: Malicious image with /dev symlink can trigger limited host filesystem integrity violations

CVE-2026-41579 / GHSA-xjvp-4fhw-gc47 / GO-2026-5761

More information

Details

Impact

When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.

Please note that this issue is not exploitable under Docker because it creates a top-level ro layer that masks any malicious /dev symlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious /dev symlink to trick it into resolving to some other path). Unfortunately, Podman and containerd^† do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.

This issue mirrors a somewhat similar issue in crun, which was also published recently.

† Actually, at the time the issue was analysed, containerd had dead code that implemented this feature but the implementation contained several security issues that would arguably have made it more exploitable than in runc. Luckily, the code appears to have never been used (at least since 2017) and the code has since been removed.

Mitigating Factors

There are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.

While the deletion of ptmx seems like a significant issue, in practice it is quite limited. Notably, devpts does not permit you to unlink /dev/pts/ptmx regardless of privileges and so it is not a usable target for this attack. Additionally, while /dev/ptmx can be unlinked^‡, trying to use an image with a symlink from /dev to /dev will cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files called ptmx that are guaranteed to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.

As for the issue of symlinks, again the impact is likely quite limited. While the creation of arbitrary symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:

• core → /proc/kcore
• fd → /proc/self/fd/
• ptmx → pts/ptmx
• stdin → /proc/self/fd/0
• stdout → /proc/self/fd/1
• stderr → /proc/self/fd/2

Note that none of these symlinks are likely to point to user-controlled data -- the /proc/self/fd/$n symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the pts/ptmx symlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as .conf) so it's not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.

‡ This would actually be quite problematic if it could occur because glibc seemingly only attempts to use /dev/ptmx when creating new terminals and thus most terminal managers (including tmux) and shell tools (including sudo -- but not su) would fail to start and thus bring the system to a halt. setupPtmx does add a symlink to /dev/pts/ptmx afterwards but on some systems the mode of the host /dev/pts/ptmx is set to 0o000 which would still cause the same DoS issue.

Patches

This issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.

Workarounds

Using user namespaces restricts this attack fairly significantly such that the attacker can only create/delete inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use /etc/sub[ug]id), this in practice means that an attacker would only be able to create or delete inodes in world-writable directories.

LSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default container_runtime_t SELinux label rules (or custom AppArmor rules for the host runc context) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.

Resources

• commit opencontainers/runc@864db8042dbb ("rootfs: make /dev initialisation code fd-based")
• GHSA-7vwr-4279-7gq5

Credits

runc thanks "Davias" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@​arthurscchan from Ada Logics), Junyi Liu (@​mosskappa), and Derek Manzella (@​Dmanzella).

Severity

• CVSS Score: 4.8 / 10 (Medium)
• Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N

References

• https://github.com/opencontainers/runc/security/advisories/GHSA-xjvp-4fhw-gc47
• https://github.com/opencontainers/runc

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Malicious image with /dev symlink can trigger limited host filesystem integrity violations in github.com/opencontainers/runc

CVE-2026-41579 / GHSA-xjvp-4fhw-gc47 / GO-2026-5761

More information

Details

Malicious image with /dev symlink can trigger limited host filesystem integrity violations in github.com/opencontainers/runc

Severity

Unknown

References

• https://github.com/opencontainers/runc/security/advisories/GHSA-xjvp-4fhw-gc47

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Release Notes

opencontainers/runc (github.com/opencontainers/runc)

v1.3.6: runc 1.3.6 -- "On no account should you allow a Vogon to read poetry at you."

Compare Source

This is the sixth patch release of the 1.3.z series of runc. Among some
performance improvements and bugfixes, it includes a fix for a
low-severity vulnerability (CVE-2026-41579) and users are encouraged to
update. As it was a low-severity vulnerability and it was reported by
multiple people, we decided to release it publicly with NO EMBARGO.

Security

This release includes a fix for the following low-severity security issue:

• CVE-2026-41579 allowed a malicious image with a /dev symlink to have
  limited write access to the host filesystem in ways that our analysis
  indicates was too limited to be problematic in practice. This bug was very
  similar to those fixed in CVE-2025-31133, CVE-2025-52565,
  CVE-2025-31133 and was simply missed at the time when we hardened the
  rootfs preparation code. We have conducted a deeper audit and not found any
  other problematic cases.

  This patchset required backports for #​5190 and #​5285, which were primarily
  code reorganisations that were already backported to runc 1.4 and 1.5.

Fixed

• A regression in runc v1.3.0 which can result in a stuck runc exec or
  runc run when the container process runs for a short time. (#​5208,
  #​5210, #​5215)
• Various integration test improvements. (#​5159, #​5188, #​5226, #​5228, #​5239,
  #​5253, #​5269, #​5288)

Changed

• When masking directories with maskPaths, runc will now re-use a single
  tmpfs instance (which is not writable) to reduce the number tmpfs
  superblocks that need to be reaped when containers die (in particular,
  Kubernetes applies masks to per-CPU sysfs directories which get expensive
  quickly). (#​5275, #​5281)

Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

• libseccomp

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

---

Thanks to the following contributors for making this release possible:

• Aleksa Sarai cyphar@cyphar.com
• Ayato Tokubi atokubi@redhat.com
• Davanum Srinivas davanum@gmail.com
• Kevin Berry <kpberry11@​gmail.com>
• Kir Kolyshkin kolyshkin@gmail.com
• Ricardo Branco rbranco@suse.de
• Rodrigo Campos Catelin rodrigo@amutable.com
• Li Fubang lifubang@acmcoder.com

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.3.5: runc v1.3.5 -- "Lo viejo funciona!"

Compare Source

This is the fifth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for issues found in 1.3.4.

Fixed

• Recursive atime-related mount flags (rrelatime et al.) are now applied
  properly. (#​5115, #​5098)
• PR #​4757 caused a regression that resulted in spurious
  cannot start a container that has stopped errors when
  running runc create and has thus been reverted. (#​5158,
  #​5153, #​5151, #​4645, #​4757)

Changed

• Updated builds to Go 1.25, libseccomp v2.6.0. (#​5111, #​5053)
• Minor signing keyring updates. (#​5146, #​5139, #​5144, #​5148)

Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

• libseccomp

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

---

Thanks to the following contributors for making this release possible:

• Aleksa Sarai cyphar@cyphar.com
• Kir Kolyshkin kolyshkin@gmail.com
• Li Fu Bang lifubang@acmcoder.com
• Ricardo Branco rbranco@suse.de

v1.3.4: runc v1.3.4 -- "Take me to your heart, take me to your soul."

Compare Source

This is the fourth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for some regressions introduced in
1.3.3.

Fixed

• libct: fix mips compilation. (#​4962, #​4966)
• When configuring a tmpfs mount, only set the mode= argument if the
  target path already existed. This fixes a regression introduced in our
  CVE-2025-52881 mitigation patches. (#​4971, #​4976)
• Fix various file descriptor leaks and add additional tests to detect them as
  comprehensively as possible. (#​5007, #​5021, #​5034)

Changed

• Downgrade github.com/cyphar/filepath-securejoin dependency to v0.5.2,
  which should make it easier for some downstreams to import runc without
  pulling in too many extra packages. (#​5028)

Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

• libseccomp

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

---

Thanks to the following contributors for making this release possible:

• Akihiro Suda akihiro.suda.cz@hco.ntt.co.jp
• Aleksa Sarai cyphar@cyphar.com
• Kir Kolyshkin kolyshkin@gmail.com
• Li Fu Bang lifubang@acmcoder.com
• Tianon Gravi admwiggin@gmail.com

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

[github-actions]

🔍 Dependency Review

github.com/opencontainers/runc v1.3.3 → v1.3.6 — ✅ Safe

Summary:

• Scope: Patch-level upgrade within the same minor (v1.3.x).
• Finding: No breaking Go API changes were introduced in the reviewed releases. Changes are bug fixes, hardening, and minor behavior corrections. As this dependency is indirect, no code changes are required in this repository.

Why:

• Reviewed the release notes/changelog for all versions between 1.3.3 and 1.3.6:
  • v1.3.4: Bug fixes and stability improvements.
  • v1.3.5: Further fixes and small backports.
  • v1.3.6: Additional fixes and hardening.
• No entries indicating removals, renamed symbols, or signature changes in exported packages (e.g., github.com/opencontainers/runc/libcontainer, libcontainer/cgroups, libcontainer/specconv).

References:

• Releases:
  • https://github.com/opencontainers/runc/releases/tag/v1.3.4
  • https://github.com/opencontainers/runc/releases/tag/v1.3.5
  • https://github.com/opencontainers/runc/releases/tag/v1.3.6
• Changelog:
  • https://github.com/opencontainers/runc/blob/main/CHANGELOG.md

Action for maintainers:

• No code changes required.

Code changes needed:

• None.

Notes

• The updated dependency is indirect. If your project does not import github.com/opencontainers/runc/... packages directly (most projects don’t), this upgrade is operationally safe and should not require any code changes. If you do vendor or import libcontainer directly, standard CI/compile will surface any issues, though none are indicated by the upstream patch releases above.