CVE-2026-40225

What it actually does

This vulnerability affects udev in systemd before version 260. udev processes device events and metadata supplied by the kernel when hardware is attached or changes state. If a malicious physical device can cause crafted or unsanitized kernel-provided output to be consumed by udev, the flaw may allow execution of code as root. Because udev runs with high privileges, successful exploitation can result in full local compromise of confidentiality, integrity, and availability. The CVSS vector indicates physical access is required, attack complexity is high, no prior privileges or user interaction are required, and the impact can be complete system compromise.

Why it matters to the business

An attacker with physical access to a vulnerable Linux system, or the ability to introduce malicious hardware through a docking station, USB, Thunderbolt, PCIe, or similar interface, may be able to take control of the device. This is most relevant for workstations, kiosks, shared systems, labs, manufacturing environments, field devices, and servers in locations where physical access is not tightly controlled. EPSS is currently very low and there is no known KEV listing, ransomware association, or public exploit maturity, so broad internet-scale exploitation is unlikely; however, the consequence of a successful local physical attack is severe because it can result in root-level compromise.

How an attack unfolds

An attacker first obtains physical access to a system or an exposed peripheral interface. They connect or emulate a malicious hardware device that causes the kernel to expose specially crafted device attributes or event data. udev receives and processes that kernel output while running with elevated privileges. Due to insufficient input validation or sanitization, crafted data can influence udev behavior in a way that leads to command execution or code execution as root. After gaining root execution, the attacker can install persistence, alter system configuration, access sensitive data, disable security controls, or use the host as a foothold for further activity. No mature public exploit is reported in the supplied data, so exploitation should be treated as plausible but not currently commoditized.

How to fix it

Upgrade systemd/udev to version 260 or later, or install the operating-system vendor’s security update that backports the fix. Because many Linux distributions backport security fixes without changing the upstream major version, validate remediation using vendor advisories and package changelogs rather than upstream version numbers alone. Where immediate patching is not possible, reduce exposure by restricting physical access, disabling or locking unused external ports, enforcing USB/Thunderbolt device authorization policies, using USBGuard or equivalent allowlisting, disabling Thunderbolt pre-boot access where applicable, and avoiding untrusted docks, adapters, and peripherals. For high-risk systems, consider tamper-evident controls, BIOS/UEFI port restrictions, kernel lockdown features, and endpoint monitoring for unusual udev-triggered activity.

How to confirm the fix worked

Confirm the installed systemd/udev package contains the vendor fix for this issue or is upstream version 260 or later. Use package inventory tools, distribution security advisories, and changelog entries to verify the patch state. On Linux systems, commands such as `systemd --version` and package-manager queries can help identify the installed version, but vendor backports should be checked separately. Validate that physical interface controls are in place by reviewing BIOS/UEFI settings, USB/Thunderbolt authorization policy, USBGuard or equivalent configuration, and endpoint hardening baselines. Confirm that no unexpected local udev rules, helper scripts, or recently added privileged startup artifacts appeared around device-connection times.

Typical attack path

1. Identify a vulnerable Linux system running systemd/udev before version 260 or a vendor package without the relevant backport.
2. Gain physical access to the system or to an exposed hardware interface such as USB, Thunderbolt, PCIe, a docking port, or a peripheral bus.
3. Attach or emulate a malicious device that generates crafted kernel device metadata or uevents.
4. Trigger udev processing of the malicious device event.
5. Exploit improper validation of kernel-provided data to execute code in the context of udev.
6. Obtain root privileges on the local system.
7. Establish persistence, collect data, modify system state, or pivot according to the attacker’s objectives.

How to detect it

There are no supplied public exploit indicators, known threat actors, KEV activity, or ransomware use for this vulnerability. Detection should focus on signs of suspicious hardware insertion followed by privileged process activity. Review system logs for udev activity around times of physical access, unexpected device add/remove events, kernel messages for newly attached USB, Thunderbolt, PCIe, storage, HID, serial, or network devices, and any errors or abnormal parsing behavior from systemd-udevd. Correlate those events with process telemetry showing systemd-udevd spawning unexpected shells, interpreters, network tools, package managers, file-transfer utilities, or newly created executables. Examine `/etc/udev/rules.d/`, `/usr/lib/udev/rules.d/`, and related helper locations for unauthorized changes. On endpoints with EDR, hunt for root-owned processes whose ancestry traces to systemd-udevd and for persistence created shortly after a hotplug event. If physical-access logging exists, correlate device insertion times with badge access, camera logs, maintenance windows, and helpdesk activity.

• systemd-udevd
• /etc/udev/rules.d/
• /usr/lib/udev/rules.d/
• /lib/udev/rules.d/
• /run/udev/
• add@/devices/
• remove@/devices/
• DEVTYPE=
• SUBSYSTEM=
• ID_VENDOR=
• ID_MODEL=

What your security team should do

• Prioritize patching laptops, workstations, kiosks, lab systems, field devices, and other assets where untrusted people may reach hardware ports.
• Deploy the vendor-provided systemd/udev security update or upgrade to systemd 260 or later where supported.
• Inventory systems running systemd and identify those with exposed USB, Thunderbolt, docking, PCIe, or other hotplug interfaces.
• Enforce physical security and peripheral control policies, including USB/Thunderbolt allowlisting for high-risk endpoints.
• Review udev rules and helper scripts for unexpected additions or modifications, especially on systems with suspicious physical access events.
• Monitor for unusual child processes spawned by systemd-udevd and unexpected root-level commands following hardware connection events.
• Because EPSS is low, KEV status is false, and exploit maturity is reported as none, treat this as a targeted physical-access risk rather than a mass exploitation emergency, while still remediating promptly due to full root-impact potential.