CVE-2026-15059
Linux Debian vulnerability analysis and mitigation

Overview

CVE-2026-15059 is a path traversal vulnerability in systemd-oomd that allows local unprivileged users to terminate arbitrary processes — including root-owned and privileged service processes — via a confused-deputy attack on the io.systemd.oom.ReportManagedOOMCGroups IPC API. It affects systemd-oomd versions 250 through pre-patch releases, with fixed versions at 261, 260.3, 259.7, and 258.9. The vulnerability was published on August 10, 2026, and carries a CVSS v3.1 base score of 5.5 (Medium) (GitHub Advisory).

Technical details

The root cause is a missing path traversal validation (CWE-22) combined with improper link resolution (CWE-59) in systemd-oomd's varlink request handler. The io.systemd.oom.ReportManagedOOMCGroups method is exposed on a world-accessible socket (/run/systemd/oom/io.systemd.ManagedOOM, mode 0666) and accepts a caller-supplied cgroup path field. Authorization is performed by parsing the textual user-<UID>.slice component from the submitted path string via cg_path_get_owner_uid(), but this check does not verify that the path actually resolves to a real cgroupfs directory. Subsequent calls to cg_get_path() join /sys/fs/cgroup with the untrusted path and apply path_simplify(), which collapses ../ traversal sequences, allowing the resolved path to escape /sys/fs/cgroup into attacker-controlled locations such as /dev/shm. A secondary issue exists where cg_set_xattr() uses setxattr() (follows symlinks) while cg_get_xattr() uses lgetxattr() (does not follow symlinks), enabling a constrained fixed-name xattr write to symlink targets (GitHub Advisory).

Impact

Successful exploitation allows a local unprivileged attacker to cause systemd-oomd — a privileged system service — to send SIGKILL to any attacker-selected PID, including processes owned by root or other privileged users. The primary confirmed impact is arbitrary local denial-of-service: targeted processes such as security monitoring agents, privileged daemons, SUID helpers during authenticated operations, and availability-critical services can be killed without the attacker holding any special privileges. A secondary constrained xattr write side-effect was confirmed but no arbitrary file write or local privilege escalation chain was demonstrated. Confidentiality is not directly impacted (GitHub Advisory).

Exploitability

A proof-of-concept reproducer script was included in the GitHub Security Advisory at the time of disclosure, demonstrating reliable end-to-end exploitation on Debian and Fedora systems. The NVD SSVC assessment classifies exploitation status as poc and the attack is not automatable. The EPSS score is approximately 0.119%, indicating low but non-zero probability of widespread exploitation in the near term. No in-the-wild exploitation or threat actor attribution has been reported. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

Exploitation steps

  1. Confirm prerequisites: Verify that systemd-oomd is running (systemctl status systemd-oomd) and that the varlink socket /run/systemd/oom/io.systemd.ManagedOOM exists and is world-accessible.
  2. Identify user slice: Read /proc/self/cgroup to obtain the caller's real cgroup path and extract the user-<UID>.slice component needed to pass the textual ownership check.
  3. Create fake cgroup directory: Create an attacker-controlled directory in a location visible to systemd-oomd, such as /dev/shm/fakecg-kill (note: /tmp is blocked by PrivateTmp=disconnected and home directories by ProtectHome=yes, but /dev/shm remains accessible despite PrivateDevices=yes).
  4. Populate fake cgroup files: Write syntactically valid but extreme values to memory.pressure, memory.current, memory.min, memory.low, memory.swap.current, and memory.stat to make the fake cgroup appear to exceed OOM thresholds. Write the target PID to cgroup.procs.
  5. Craft traversal path: Construct a payload path of the form <real_user_cgroup_prefix>/../../../../../../../../../../dev/shm/fakecg-kill. The prefix (e.g., /user.slice/user-1000.slice/session-5.scope) satisfies the user-<UID>.slice ownership check; the ../ traversal causes path_simplify() to resolve the final path to the fake directory.
  6. Submit varlink request: Send a ReportManagedOOMCGroups request to the socket using varlinkctl: {"cgroups":[{"mode":"kill","path":"<payload_path>","property":"ManagedOOMMemoryPressure","limit":1,"duration":0}]}.
  7. Wait for kill: systemd-oomd reads the fake pressure/accounting files, selects the fake cgroup for OOM action, reads the target PID from the attacker-controlled cgroup.procs, and sends SIGKILL to that PID. systemd-oomd itself remains running (GitHub Advisory).

Indicators of compromise

  • Logs: systemd-oomd journal entries showing a candidate cgroup path containing ../ traversal components; log lines referencing paths outside /sys/fs/cgroup (e.g., /dev/shm/) during OOM candidate evaluation.
  • Process: Unexpected process terminations with exit status SIGKILL (status=9) for processes that are not under genuine memory pressure; systemd-oomd remaining active and healthy immediately after such kills.
  • Network/IPC: Connections from unprivileged user processes to /run/systemd/oom/io.systemd.ManagedOOM varlink socket, particularly with ReportManagedOOMCGroups calls containing path fields with .. components.
  • File System: Presence of directories in /dev/shm/ containing files named memory.pressure, memory.current, memory.min, memory.low, memory.swap.current, memory.stat, and cgroup.procs — indicative of a fake cgroup staging area.
  • File System: Unexpected user.oomd_ooms or user.oomd_kill extended attributes set on files or symlink targets outside /sys/fs/cgroup (GitHub Advisory).

Mitigation and workarounds

Upgrade to one of the patched systemd releases: 261, 260.3, 259.7, or 258.9, which include commits cde88c4, 1b2a891, 967850c, and a8feb2f respectively. Ubuntu has released a security notice (USN-8626-1) with updated packages. If immediate upgrade is not possible, restrict access to the vulnerable socket by adding a drop-in for systemd-oomd.socket with [Socket]\nSocketMode=0600, which prevents unprivileged users from connecting to the varlink interface. Alternatively, disable systemd-oomd.service entirely if managed OOM functionality is not required (GitHub Advisory, Ubuntu Advisory).

Community reactions

The vulnerability was reported by researcher cyberlanc3r and published by bluca (a systemd maintainer) via the GitHub Security Advisory program on August 10, 2026. Ubuntu issued security notice USN-8626-1 promptly on the same day, and AUSCERT published bulletin ESB-2026.9311 shortly after. Linux security news aggregators including linuxsecurity.com and linuxcompatible.org covered the advisory. No significant broader media controversy or social media debate has been observed, consistent with the moderate severity rating and local-only attack vector (GitHub Advisory, Ubuntu Advisory).

Additional resources


SourceThis report was generated using AI

Related Linux Debian vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-63343CRITICAL9.9
  • Linux Debian logoLinux Debian
  • incus
NoYesAug 21, 2026
CVE-2026-63125CRITICAL9.9
  • Linux Debian logoLinux Debian
  • incus
NoYesAug 21, 2026
CVE-2026-62941CRITICAL9.9
  • Linux Debian logoLinux Debian
  • incus
NoYesAug 21, 2026
CVE-2026-62940CRITICAL9.9
  • Linux Debian logoLinux Debian
  • incus
NoYesAug 21, 2026
CVE-2026-62867CRITICAL9.9
  • Linux Debian logoLinux Debian
  • incus
NoYesAug 21, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management