Hi all,

I’m on Unraid 7.2.3 and checking the container runtime shows this:

root@f:~# runc --version
runc version 1.2.4
commit: v1.2.4-0-g6c52b3f
spec: 1.2.0
go: go1.22.11
libseccomp: 2.5.4

There were several SEVERE runC container escape vulnerabilities that could let containers gain root access to whole system in November 2025 ( CVE-2025-31133, CVE-2025-52565 , CVE-2025-52881) and upstream mentions fixes in later runC releases (1.2.8+).

Questions:

1. Is Unraid 7.2.3 actually vulnerable because it ships runc 1.2.4, or are these fixes backported in some way?

2. If backported, is there a way to verify this to in patch notes,etc?

3. If not backported, is there an ETA or recommended mitigation on Unraid (beyond “avoid untrusted containers”)?
   

just trying to confirm whether this is a real exposure on Unraid.

Thanks

When are we going to see this dealt with? It's been months since they first published these vulnerabilities.

This is an unacceptable allowed security hole with no statement from staff

This is yet another reason why Unraid should transition away from Slackware and adopt a distribution like Ubuntu. By doing so, Unraid can ensure that updates are handled by the distribution itself and remain in a Long-Term Support (LTS) track. This approach would eliminate the need for Unraid users to wait for all updates from Unraid. Instead, Unraid should focus on its core functionalities, such as scripts and the user interface, while leaving the responsibility of distro updates to the distribution. As has been widely discussed here and on social media, this entire situation poses a significant security risk and demands immediate attention from Unraid leadership to address this critical security lapse and explain how course correction will occur immediately.

I would like to know if this is somehow fixed(mitigated)

6 hours ago, KhayrDev said:

This is yet another reason why Unraid should transition away from Slackware and adopt a distribution like Ubuntu. By doing so, Unraid can ensure that updates are handled by the distribution itself and remain in a Long-Term Support (LTS) track. This approach would eliminate the need for Unraid users to wait for all updates from Unraid. Instead, Unraid should focus on its core functionalities, such as scripts and the user interface, while leaving the responsibility of distro updates to the distribution. As has been widely discussed here and on social media, this entire situation poses a significant security risk and demands immediate attention from Unraid leadership to address this critical security lapse and explain how course correction will occur immediately.

this has nothing to do with it being slackware, its easy to update, you can do it at any point in time yourself.
The issue comes with it being immutable and nobody caring enough to just update the shipped version at any point, while having ample opportunities.

Edit: Since i did talk about it before in November, i want to put it here as well

Unraid 7.1 beta started with Docker 27.5.1 around March 18 2025 or so, at that point, Docker version 28 was already out, it released mid February 2025. Beta2 also didnt bump it. Then comes 7.2 and nobody updated Docker to v28 either. And then came November, where i did state the cve fixes and got told, nah 7.3. Which could have been a quick update, if, at any point, we moved to 28 instead of sticking to 27 for what is over a year now.

Edited April 12Apr 12 by Mainfrezzer

5 hours ago, unrateable said:

I would like to know if this is somehow fixed(mitigated)

There is a plugin that was developed by the maintainer of the unRAID Tailscale plugin. Its posted on the unRAID Reddit.

On Unraid 7.3.0 beta 2 this is the output of runc --version

root@Firefly:~# runc --version

runc version 1.3.4

commit: v1.3.4-0-gd6d73eb

spec: 1.2.1

go: go1.25.8

libseccomp: 2.5.4

On 4/10/2026 at 4:31 PM, JPetovello said:

When are we going to see this dealt with? It's been months since they first published these vulnerabilities.

just found out about this, competitors need to hammer on this as a downside of a container system that takes months to fix what seems to be a pretty major issue.

In the grand scheme, it isnt horrible. So there is that. But i absolutely agree that 6 months is a bit eh, to keep shipping something that has known issues, how trivial they might be. At this point, theres also the go tls issue which pilled untop of issues with that docker version, which is remedied in the 7.3 beta. That one is also hard to exploit, as a sidenote. But as time goes on, im sure more stuff will pop up and pile unto it and we all know that people set up their system like today and dont touch it and after a while, there will be more/easy ways that can be exploited.

Edit: forgot to note, the versions prior to 28 are all nat unprotected. You can do funny things with docker on unraid while just being on a system within the same network.

Edited April 12Apr 12 by Mainfrezzer

Hi All! Thank you for posting about this issue.

You’re right, 5 months is too long for a vulnerability like this to go unpatched in the product, and we are actively working on ways to make this faster in the future.

We track CVEs across the stack and evaluate each one using an internal set of criteria that looks at real-world risk, exploitability, relevance to how Unraid is typically used, and the potential impact of the fix itself. There are always tradeoffs.

In this case, addressing the vulnerability required a Docker engine upgrade. Historically, those upgrades have introduced breaking changes, so we made a deliberate call to validate it first in the 7.3 beta series before pushing it into a stable release. We began that work shortly after these CVEs were made public, with 7.3 entering internal beta on December 18, 2025. This approach was intended to reduce the risk of widespread breakage, rather than introducing a potentially disruptive change into a stable release.

That said, we hear the feedback on timing. This situation highlights a gap in how we handle fixes that depend on larger upstream changes, and we’re actively working to improve that so we can move faster in the future.

The fix is already included in the 7.3 beta, which is publicly available now. Additionally, alongside a few other bug fixes, these CVEs are addressed in a 7.2.5-rc.1 release, which went out today (April 15).

We also agree with the broader point raised… “just don’t run untrusted containers” isn’t a complete security model. There should be multiple layers of protection, and we will continue to improve there.

As Unraid continues to evolve and reach more users, including SMBs and less technical customers, our evaluation criteria, response timelines, and overall security posture will continue to evolve as well.

Security is a priority for us, and conversations like this help us raise the bar. Thanks for being part of the community and holding us accountable.

Hello everyone.

We've shipped a 7.2.5 release as of last week with a resolution for this problem, and 7.3.0 is coming soon and will also include this.

See our public security post here: https://product.unraid.net/p/runc-container-escape-vulnerabilities-cve-2025-31133-cve-2025-52565-cve-2025-52881?b=cve-reports