systemd-homed CVE-2026-16742

Exploitation requires that the target system has systemd-homed installed and actively managing at least one user account - this is a non-default configuration on most Linux distributions, where traditional /etc/passwd and shadow-based account management remains the norm. The attacker must already hold a local, authenticated session as a low-privileged user whose account is specifically managed by systemd-homed (PR:L). The CVSS AC:H metric indicates a high-complexity prerequisite, likely a race condition, a specific timing window, or a crafted user record state that must be induced. The UI:R metric further requires that some user interaction occur during exploitation, adding a dependency on an active session or user activity. Systems using only traditional PAM/shadow user management with no homed-managed accounts are not affected, regardless of whether the systemd-homed binary is installed.

The CVSS 6.7 score reflects a meaningful but constrained local escalation: AV:L limits reach to authenticated local sessions, AC:H signals a non-trivial exploitation path (timing, race condition, or specific configuration state), PR:L requires a pre-existing low-privilege account, and UI:R adds a further dependency on some user action. Scope is unaffected (S:U), meaning the flaw does not inherently escape the system boundary, though gaining membership in a privileged group (e.g., sudo or docker) is functionally equivalent to root on most Linux deployments. No EPSS score was provided in the intelligence feed, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV, and no public proof-of-concept is known - these signals together suggest opportunistic mass exploitation is unlikely at present. A hardened multi-user Linux system where homed is actively used - the kind managed by even a mid-sized municipal IT team in opole running shared infrastructure - should prioritize patching over emergency response, as the AC:H and UI:R constraints meaningfully reduce realistic exploitation risk compared to the high CIA impact scores alone might imply.

An attacker with a low-privileged local account managed by systemd-homed satisfies a high-complexity condition - likely a race condition or a crafted user record manipulation - while some form of user interaction occurs, causing systemd-homed to add the account to a privileged system group such as 'sudo' or 'docker'. With group membership established, the attacker invokes standard system utilities (e.g., 'sudo su' or 'docker run --privileged') to achieve full root-level access. No public proof-of-concept exploit code is known at time of analysis.