CVE-2026-40227
Assertion Failure in systemd IPC API Allows Local Privilege Escalation
Publication date: 2026-04-10
Last updated on: 2026-04-14
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| systemd_project | systemd | 260 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1025 | The code performs a comparison between two entities, but the comparison examines the wrong factors or characteristics of the entities, which can lead to incorrect results and resultant weaknesses. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes a denial of service by freezing systemd when triggered by a local unprivileged user. It does not result in any loss of confidentiality or integrity of data.
Since there is no impact on confidentiality or integrity, the vulnerability itself does not directly compromise compliance with standards such as GDPR or HIPAA, which primarily focus on protecting personal data confidentiality and integrity.
However, the denial of service could affect system availability, which may indirectly impact compliance if availability is a requirement under certain regulations or organizational policies.
Can you explain this vulnerability to me?
CVE-2026-40227 is a vulnerability in systemd version 260 where a local unprivileged user can cause systemd (running as PID 1) to hit an assertion failure and freeze execution.
This happens when an unprivileged user makes an IPC API call with malformed or spurious data, specifically by sending a JSON payload containing a null element in an array or map via the varlink socket `/run/systemd/io.systemd.Manager`.
The issue was introduced in systemd v260 and was fixed in versions 260.1 and 261.
How can this vulnerability impact me? :
The vulnerability allows a local unprivileged user to cause systemd to freeze by triggering an assertion failure.
This results in a denial of service (DoS) condition affecting system availability.
There is no impact on confidentiality or integrity.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to reproduce the assertion failure in systemd using an IPC API call with a malformed payload. Specifically, sending the JSON payload {"method": "io.systemd.UserDatabase.GetUserRecord", "parameters": {"fuzzyNames": [null,[]]}} to the varlink socket /run/systemd/io.systemd.Manager can trigger the issue.
A suggested command to test this is using socat to send the payload to the varlink socket as follows:
- echo '{"method": "io.systemd.UserDatabase.GetUserRecord", "parameters": {"fuzzyNames": [null,[]]}}' | socat - UNIX-CONNECT:/run/systemd/io.systemd.Manager
If systemd freezes or hits an assertion failure after this command, the system is vulnerable.
What immediate steps should I take to mitigate this vulnerability?
An immediate mitigation step is to restrict access to the varlink socket /run/systemd/io.systemd.Manager so that only the root user can access it. This prevents unprivileged local users from sending malicious IPC API calls that trigger the vulnerability.
Additionally, updating systemd to version 260.1 or later (including version 261) where the vulnerability is patched will fully resolve the issue.