CVE‑2026‑31431

[lxrkz]

Describe the issue you are experiencing

Why is nobody writing about CVE‑2026‑31431?
What if someone downloads an "update" for any kind of plugin, with a dirty payload?
Or is it already patched without notice?

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

17.2

Did the problem occur after upgrading the Operating System?

No

Hardware details

.

Steps to reproduce the issue

...

Anything in the Supervisor logs that might be useful for us?

.

Anything in the Host logs that might be useful for us?

.

System information

No response

Additional information

No response

[gautamkrishnar]

@lxrkz the issue was fixed in 6.18.22, the kernel for OS was updated to 6.18.26 in #4674, they just have to create a new release.

[jpettitt]

It there any ETA on the next release? This the only unpatched VM on my network and the one with the biggest attack surface in terms of downloaded code ...

[NicolasHaas]

Would really appreciate a new release with #4674 included. I'm in the same boat as @jpettitt.

[kevincw01]

while you're waiting, login via developer ssh (port 22222) or use the ssh app and do:
echo "install algif_aead /bin/false" > /etc/modprobe.d/copyfail_mitigation.conf

then verify it worked:
modprobe algif_aead

you should get an error:
modprobe: ERROR: Error running install command '/bin/false' for module algif_aead: retcode 1 modprobe: ERROR: could not insert 'algif_aead': Invalid argument

[remcom]

i would also love to see this patched

[agners]

The threat model of the complete Home Assistant appliance is not much affected by this privilege escalation: We run many services (including Home Assistant Core) as root anyways. To a large degree, if you can run code on HAOS, your owning the machine anyways. It's not a multi tenant cloud machine, it's a single application appliance. The security relies on not gaining unauthorized access in first place.

Apps can opt in to run as user (and some of them do) so those potentially can expand their privilege via this CVE. But even those often have privileges configured in their config.yaml which allows them to own the system if they are acting in bad faith (e.g. via D-Bus, allows to run commands as root, or Supervisor API, allows to restore backups and hence inject custom apps or components etc.).

The fix will be included in our next release, but we are currently planning on OS 18, a new major release. We'd like to include more changes in that release.We'd have to make a hot fix patch release 17.3 (or a half finished 18) if fixing this CVE really becomes urgent. I'd prefer to continue our full release cycle, along with testing etc. before releasing the next version.

[remcom]

@agners thanks for your clarification. But isn't the issue that you don't need to have unauthorised access first. if somebody implement this in there app or with hacs then they can elevate there privileges and run whatever they please. It can happen if somebody (indeed in bad faith) implements this and a HA user updates to that version.

[AlexHunterCodes]

But isn't the issue that you don't need to have unauthorised access first.

I think Agners' point is that HA's security model means all access is essentially authorised regardless. If the code can run at all, it is likely already running as root, and the code got there because a user put it there themselves. Local Privilege Escalation is sorta built-in, you wouldn't need an exploit.

At the end of the day, apps and HACS are a risk no matter if this CVE is patched or not. Users are responsible for only downloading code/updates they trust, and if a bad actor wanted to cause trouble they could do catastrophic damage with or without this patch anyway.

If you're that concerned, hold off on updating any apps or HACS custom integrations until the next HAOS release patches the kernel, or inspect the code yourself.

[remcom]

Yeah I was actually kind of surprised that a lot of process already run as root. But indeed makes it a lower priority.

I get your point that people are responsible on what they install. But not every user that uses HA is able to understand code to keep themself safe. Especially. I raised the question mainly for that.

[jwilkicki]

I understand the argument why it doesn't really matter, per se. No point locking the door if all of the windows are broken. What really concerns me is that all of this stuff runs as root. That seems like exactly the kind of thing Internet of Things devices are criticized for all the time. I'd like to see everything much more locked down. After all, the programs in here can actually affect physical things in our homes and they often have keys to accounts in the cloud that matter.

[mortenmoulder]

@jwilkicki I think the context matters a lot here.

Home Assistant OS is not really a general purpose, multi-user/tenant Linux system where different users and workloads need to be protected from each other. It is closer to an "appliance OS" with one main purpose: running Home Assistant and its managed addons (Docker containers). You own the device, you control what is installed, and the code is open source.

So in that model, root is not automatically the same kind of red flag as it would be on a shared server with multi-tenants and users.

Imagine you buy a dedicated device where the entire purpose is to run one open source software stack. You own the hardware, you control the installed software, and the device is meant to be administered as a whole. If all of the meaningful services already have access to the same secrets, integrations, devices, automations, and configuration, then simply changing the Unix user does not magically make the system safe.

So I think the concern is valid, but I would frame it differently:

Running as root in HAOS is not ideal from a least-privilege point of view, but it is also not automatically irresponsible, given that HAOS is a single purpose system. The bigger concern is how much access each addon gets, whether it can break out of its container, what secrets it can read, and whether users understand the implication of just installing random addons from unknown sources. If an user just decides to install an addon from a (potential malicious) 3rd party source, and that addon mounts / from the host, then yes, that could be quite bad, if everything runs as root.

In other words: I would like to see things locked down more too, but "runs as root" by itself does not tell the whole story. Root with limited container access is one thing. Root with host level privileges is another. Spinning up a container (addon) with UID set to 0/root, does not automatically mean it's bad, as the container is the only thing vulnerable then.

I understand the reasoning, though. File and user privileges is a hard problem to tackle, and unfortunately there's a huge trade-off by limiting what the containers (addons) can do, if they cannot run as root, as they will not be able to investigate logs, read .storage directory for stuff, and so on, because of how HAOS is designed. Changing that up is not a one night thing, and it requires insane planning because of how widespread HA is. Basically every addon needs to be updated. The entire HAOS stack would basically need to be redesigned, as I'm guessing some addons and integrations would be greatly missed, if they cannot have access to everything (like Spook, which I know is not an addon, but essentially has the same issues as integrations by default will run with the same privilege as HA, as far as I know).

[Robbe-B]

Releasing the patch asap would be the right thing to do in my opinion, no matter the vulnerability.
It's value, just sitting there, waiting to be released.
Plus, I would really like to sleep again at night 😄 .
Thanks for the great work and staying on top of things !

[AlexHunterCodes]

The team has posted a release candidate for OS 17.3 which updates the Linux kernel to 6.12.85 which includes the fix for this CVE, and backports the fix to 6.12.75 for Raspberry Pi and Home Assistant Yellow.

https://github.com/home-assistant/operating-system/releases/tag/17.3.rc1

[jwilkicki]

@mortenmoulder I agree it is a hard problem. I work with containerized applications and have gone through the effort of migrating apps that worked in more open environments to run in more secure ones. There is definitely more to it than changing the root user. There's also thinking about things like what access each process has to secrets so it can't see or share other components' secrets, figuring out resource limits to avoid starving competing processes, etc. Giving each service within HA its own identity and thinking about what it needs to access (files, data, etc.) would probably be the process at a high level. Having only certain types of addons have monitoring privileges (like Kyverno or Wiz), etc.

I think it would be worth it; supply chain attacks and issues like this current scramble means that defense in depth would be useful. A compromise in one HA addon being mitigated by strong isolation would be a nice feature.

I also see that @AlexHunterCodes has got an RC out for the kernel patch. I feel better that the team is willing to take that step even when the impact for HA is less than with other systems. This discussion has been useful for me and I'm glad that our concerns are heard and there is a thoughtful response. Keep up the good work!

[AlexHunterCodes]

@jwilkicki I am not an HA developer. I just posted something relevant I saw in my inbox. 😆

Personally, I think the note on the RC is justified. This CVE only affects Home Assistant in one very specific way that is really not very high impact. I completely agree with the developers comments above, and If I was in HA's position I wouldn't have bothered rushing out an update for this CVE.

Too many vulnerabilities have catchy names, flashy websites and attract massive media fear-mongering these days, and that creates unnecessary work for open source projects flooded with non-experts freaking out and impatiently asking for patches against threats that don't really exist.