CVE-2026-58302: LinuxCNC rtapi_app Local Privilege Escalation
| Field | Value |
|---|---|
| CVE ID | CVE-2026-58302 |
| CVSS score | 8.4 |
| Attack vector | Local |
| Auth required | Yes. Local access as an unprivileged user is required. |
| Patch status | Fixed upstream in LinuxCNC 2.9.9 and in Debian package 1:2.9.9-1 |
TL;DR - LinuxCNC
rtapi_appbefore 2.9.9 can let a local user become root. - Systems usinglinuxcnc-uspacewith SUIDrtapi_appare affected. - Upgrade quickly if untrusted local users can access the host.
Vulnerability at a Glance
CVE-2026-58302 is a high-severity local privilege escalation flaw in LinuxCNC, specifically in the rtapi_app component shipped with the linuxcnc-uspace package. According to the NVD description, the issue exists in LinuxCNC versions before 2.9.9. The vulnerable binary is installed SUID root and loads shared library modules with dlopen() using a user-supplied module name.
The core problem is insufficient validation of that module name. Because the process still has elevated privileges at load time, a local attacker can abuse path traversal to point rtapi_app at an attacker-controlled shared object. If the binary loads it successfully, the code runs with root privileges. This turns what might otherwise be a limited local foothold into full system compromise.
What the Bug Is and Why It Matters
This is not a remote code execution issue. An attacker must already have local access to the LinuxCNC host. That said, local privilege escalation vulnerabilities matter a great deal in real environments because they are often the step that converts a low-privileged account, kiosk escape, weak SSH credential, or another application bug into complete root access.
The affected component, rtapi_app, is particularly sensitive because it is SUID root. SUID programs must treat all user-controlled input as hostile. In this case, the dangerous combination is clear from the published description: privileged execution, user-controlled module names, dlopen()-based loading, and insufficient sanitization. That pattern is well understood in Linux hardening circles as high risk because shared library loading under elevated privileges is difficult to secure unless paths and names are strictly constrained.
Technical Notes
The NVD states the vulnerable logic allows path traversal in a user-supplied module name. That means defenders should think in terms of malicious inputs such as relative paths, unexpected directory separators, or attempts to reference shared objects from user-writable locations.
A simplified conceptual example of the risk looks like this:
rtapi_app <user-controlled module name>
|
+--> insufficient validation
|
+--> dlopen(attacker-controlled path)
|
+--> code executes as root
On exposed systems, confirm whether the binary is SUID root:
find / -perm -4000 -type f 2>/dev/null | grep rtapi_app
ls -l /usr/bin/rtapi_app /usr/sbin/rtapi_app /usr/lib/linuxcnc/bin/rtapi_app 2>/dev/null
Affected Versions and Fixed Versions
The safest supported statement from the available sources is that LinuxCNC versions before 2.9.9 are affected. The upstream fix is included in LinuxCNC 2.9.9. If you maintain LinuxCNC directly from upstream packages or source builds, that is the version threshold to use in your asset review and patch planning.
There is also useful packaging evidence from Debian bug #1140943. That record reports the issue as found in linuxcnc/1:2.9.4-2 and linuxcnc/2.9.0~pre1+git20230208.f1270d6ed7-1, and fixed in linuxcnc/1:2.9.9-1. That does not necessarily define the full vulnerable range for every distro, but it gives defenders a concrete package-level checkpoint for Debian-based environments.
| Scope | Affected versions | Fixed version |
|---|---|---|
| Upstream LinuxCNC | Before 2.9.9 | 2.9.9 |
| Debian packaging evidence | At least 1:2.9.4-2 and 2.9.0~pre1+git20230208.f1270d6ed7-1 |
1:2.9.9-1 |
The LinuxCNC 2.9.9 release notes also explicitly reference the relevant remediation work with entries including “Fix rtapi_app: Sanitize name for module addresses” and “rtapi: Refuse to load uspace components missing rtapi_app_exit”. The first line aligns directly with the published CVE description and confirms the fix theme: input sanitization around module loading.
Exploitation Status, PoC Status, and Defender Assumptions
At the time of writing, exploitation in the wild is not confirmed from the sources provided. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, which means there is no CISA-required remediation date or federal directive attached to it right now.
Also, no confirmed public proof-of-concept is known from the supplied research set. The available references include the NVD entry, Debian bug, LinuxCNC release notes, and associated GitHub commits, but they do not provide a published exploit repository or exploit script. That is important to say clearly: no confirmed public PoC was identified here.
However, defenders should not take the absence of KEV listing or PoC publication as a sign that the issue is low risk. The underlying exploit path appears technically straightforward for a local attacker because the vulnerable program is SUID root and the flaw involves unsafe module loading. In practical terms, if a host is shared by multiple users or reachable by semi-trusted operators, treat this as a serious privilege-boundary failure and patch accordingly.
Operational Guidance for Defenders
This CVE is most important in environments where local privilege boundaries still matter. If your LinuxCNC host is single-purpose and only root-level administrators log in, the immediate exploitability may be narrower. But many real deployments do not look like that. Shared engineering stations, teaching labs, integrator-maintained systems, and mixed-use industrial endpoints often have multiple accounts or periodic third-party access. In those cases, a local LPE bug is a material risk.
The defensive priority is straightforward: identify LinuxCNC installations, verify whether the vulnerable rtapi_app is present and SUID, and patch to 2.9.9 or 1:2.9.9-1 as appropriate. If patching is delayed, monitor execution of rtapi_app, restrict local access, and consider temporarily removing SUID privileges after testing. Because no in-the-wild exploitation or PoC is confirmed here, defenders should avoid panic, but they should also avoid complacency. The published bug mechanics are credible, high impact, and actionable.
For further reading on related security topics, check out our articles on what is a kill switch in a VPN and smishing defense best practices.
How to Identify Exposure
First, determine whether LinuxCNC is installed and whether the linuxcnc-uspace package is present. Then verify the actual package version and locate rtapi_app. On a Debian-derived system, package queries are the fastest starting point. On manually built or appliance-like systems, you may need to inspect LinuxCNC binaries and release metadata directly.
Second, verify whether rtapi_app retains the SUID bit on deployed hosts. The CVE description specifically depends on that privileged execution context. If a system has LinuxCNC installed but does not expose a SUID rtapi_app, the risk profile may differ. In the absence of vendor guidance beyond the published description, defenders should assume hosts running vulnerable versions with SUID rtapi_app are exposed.
Technical Notes
Use these commands to inventory package versions and SUID exposure:
dpkg -l | grep -E 'linuxcnc|linuxcnc-uspace'
apt-cache policy linuxcnc-uspace
find / -perm -4000 -type f 2>/dev/null | grep rtapi_app
stat /usr/bin/rtapi_app 2>/dev/null
stat /usr/lib/linuxcnc/bin/rtapi_app 2>/dev/null
If auditd is available, a targeted rule can help catch suspicious execution of the binary:
auditctl -w /usr/bin/rtapi_app -p x -k rtapi_app_exec
auditctl -w /usr/lib/linuxcnc/bin/rtapi_app -p x -k rtapi_app_exec
Useful log review patterns include process execution events where rtapi_app is launched by a non-root user, especially with unusual path characters in arguments:
type=EXECVE msg=audit(...): argc=2 a0="rtapi_app" a1="../tmp/malicious.so"
type=EXECVE msg=audit(...): argc=2 a0="rtapi_app" a1="/home/user/libpayload.so"
Example Splunk query for Linux audit logs:
index=linux_audit (process_name=rtapi_app OR exe="*rtapi_app*")
| search cmdline="*../*" OR cmdline="*/tmp/*" OR cmdline="*/home/*" OR cmdline="*.so*"
| stats count values(user) values(host) values(cmdline) by exe
Example Sigma-like detection logic concept:
title: Suspicious rtapi_app execution with path-like module input
logsource:
product: linux
service: auditd
detection:
selection:
exe|endswith: '/rtapi_app'
suspicious_args:
cmdline|contains:
- '../'
- '/tmp/'
- '/home/'
- '.so'
condition: selection and suspicious_args
level: high
Mitigation and Patching
The primary mitigation is to upgrade to LinuxCNC 2.9.9 or later. For Debian-based packaging, upgrade to linuxcnc-uspace 1:2.9.9-1 or later. Because this is a privilege escalation flaw in a SUID binary, patching should be prioritized on shared systems, lab workstations, training environments, and any CNC host where operators do not already have administrative rights.
If you cannot patch immediately, the most practical interim control is to review whether rtapi_app truly needs to remain SUID root in your environment. Removing the SUID bit may reduce or eliminate the privilege-escalation path, but it can also break expected LinuxCNC functionality. Because that tradeoff is deployment-specific, test carefully before making the change in production. Also reduce access to the host: restrict shell access, tighten SSH access, and avoid allowing untrusted local users on affected machines.
Technical Notes
Debian-based upgrade example:
sudo apt update
sudo apt install --only-upgrade linuxcnc-uspace
dpkg -l | grep linuxcnc-uspace
If the fixed package is available and you want to pin the minimum known fixed version explicitly:
sudo apt install linuxcnc-uspace=1:2.9.9-1
Temporary workaround to remove SUID, if operational testing shows LinuxCNC can tolerate it:
sudo chmod u-s /usr/bin/rtapi_app 2>/dev/null
sudo chmod u-s /usr/lib/linuxcnc/bin/rtapi_app 2>/dev/null
find / -perm -4000 -type f 2>/dev/null | grep rtapi_app
To restore the original behavior later, if required and approved:
sudo chmod u+s /usr/bin/rtapi_app 2>/dev/null
sudo chmod u+s /usr/lib/linuxcnc/bin/rtapi_app 2>/dev/null
For source-based or manually managed LinuxCNC installations, confirm the installed upstream release is 2.9.9 or newer before returning the system to normal service. If version provenance is unclear, assume the host remains vulnerable until you validate the exact build level.
References
- NVD:
https://nvd.nist.gov/vuln/detail/CVE-2026-58302 - Debian bug
#1140943:https://bugs.debian.org/1140943 - LinuxCNC 2.9.9 release announcement:
http://linuxcnc.org/2026/06/28/LinuxCNC-2.9.9/ - GitHub commit reference:
https://github.com/LinuxCNC/linuxcnc/commit/00d534c87464a3ed446656998aa02b8abc74b391 - GitHub commit reference:
https://github.com/LinuxCNC/linuxcnc/commit/ea7cd579d39b586952a42e3da9a26d3e36e7a272 - LinuxCNC compare view:
https://github.com/LinuxCNC/linuxcnc/compare/v2.9.8...v2.9.9
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.