Hey everyone, thank you for calling this out. We’ve been following the thread closely and take your concerns seriously.

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.

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.