CVE-2026-16742 in systemd-homed allows a logged-in homed-managed user to add arbitrary group memberships to their identity record. The CVSS 6.7 score is misleading—this is a privilege escalation that warrants serious attention, not deferred review.
The core issue is that systemd-homed stores user identity records on LUKS2-encrypted volumes the user controls, then treats those self-controlled records as authoritative sources for authorization decisions. The vulnerability exploits this structural contradiction: the group-addition code path lacked proper authorization checks, allowing a homed user to inject group memberships that grant access to D-Bus activation paths, journald access, udev device nodes, and in some configurations, input devices or kernel interfaces that gate hardware passthrough.
The 'already logged in' precondition that keeps this at medium severity understates the real exposure. A homed user carrying an escalated authorization record can provision that identity on any system where their encrypted volume is mounted—this isn't a traditional local privilege escalation contained to one machine, it's a portable credential. The groups that matter most are those controlling systemd unit execution, polkit delegation, and journal access.
Compounding the risk: systemd-homed is deprecated. The patch will land in a project with no active maintenance relationship. Downstream deployments may never receive the fix, and sysadmins managing these systems in 2028 will likely have no institutional memory of the non-standard group-membership code path that needs auditing. The CVSS 6.7 pushes this into the 'review within 90 days' bucket, where deprecated code gets filed under 'will decommission anyway' and silently persists.
Practical steps: verify whether any systems still run systemd-homed; audit existing homed user records for unexpected group memberships (check /run/systemd/users/ and the JSON identity files on mounted homed volumes); if homed cannot be removed immediately, disable the group-modification code path at the PAM configuration layer or via polkit restrictions; treat any homed-managed user as having elevated blast radius given the portability of their identity record.
The deeper lesson is that systemd-homed's design philosophy—treating the user's own storage as the source of truth for authorization—produced a class of vulnerability likely to recur in other systems that conflate authentication storage with authorization authority.