CVE-2026-40225
Local Root Execution via Malicious Devices in systemd udev
Publication date: 2026-04-10
Last updated on: 2026-04-27
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| systemd_project | systemd | to 257.13 (exc) |
| systemd_project | systemd | From 258 (inc) to 258.7 (exc) |
| systemd_project | systemd | From 259 (inc) to 259.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-669 | The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-40225 is a vulnerability in the udev package of systemd versions before 260 that allows local root execution via malicious hardware devices. The issue arises because certain udev helper binaries, specifically scsi_id and v4l_id, do not sanitize kernel output derived from connected devices. An attacker can craft a malicious device that sets device properties containing specially formatted strings that cause udev to execute arbitrary commands as root.
- For the v4l_id helper, the vulnerability involves the ID_V4L_PRODUCT property derived from the USB descriptor, which can be manipulated to execute commands.
- For the scsi_id helper, the vulnerability involves the ID_SCSI_SERIAL property derived from the hardware's SCSI serial number, which can be crafted to activate arbitrary systemd units, including spawning a root shell.
How can this vulnerability impact me? :
This vulnerability can have a significant impact because it allows an attacker with physical access to the system to gain root privileges without any user interaction or prior privileges. By plugging in a maliciously crafted hardware device, the attacker can execute arbitrary commands as root, potentially compromising the entire system.
- Complete system compromise due to root-level command execution.
- Activation of arbitrary systemd services, including those that spawn root shells.
- Potential loss of confidentiality, integrity, and availability of the affected system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves malicious hardware devices exploiting unsanitized kernel output properties processed by udev helper binaries scsi_id and v4l_id.
Detection involves checking for suspicious or unexpected systemd units activated via crafted device properties or unusual values in kernel device properties such as ID_V4L_PRODUCT or ID_SCSI_SERIAL.
You can inspect the current systemd units that may have been triggered by such properties using commands like:
- systemctl list-units --state=active
- journalctl -xe | grep -E 'v4l_id|scsi_id|SYSTEMD_WANTS|REMOVE_CMD'
Additionally, examining udev logs and kernel device properties for suspicious newline characters or commands embedded in ID_V4L_PRODUCT or ID_SCSI_SERIAL can help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the udev package to version 260 or later, or applying backported fixes available in versions 259.5, 258.7, and 257.13.
As a workaround, you can disable the v4l and iscsi kernel drivers to prevent the vulnerable helpers from processing malicious device properties.
- Upgrade udev to version 260 or later.
- Disable v4l kernel driver: blacklist the v4l modules or prevent them from loading.
- Disable iscsi kernel driver similarly by blacklisting or unloading.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows local root execution via malicious hardware devices exploiting unsanitized kernel output, which can lead to unauthorized system control and potential data breaches.
Such unauthorized root access and potential compromise of system integrity and confidentiality could negatively impact compliance with standards and regulations like GDPR and HIPAA, which require protection of sensitive data and system security.
However, the provided information does not explicitly discuss compliance implications or specific impacts on these regulations.