LinuxCNC path traversal shows how privileged dlopen() turns local code into root

At a glance

What this is: This is a Linux privilege-escalation issue in linuxcnc-uspace where an attacker-controlled module name can escape a trusted directory and load arbitrary code through dlopen() with root privileges.

Why it matters: It matters because privileged module loading turns a local code execution foothold into full host compromise, which changes how teams should harden LinuxCNC hosts that also hold secrets, build tools, or remote access paths.

Context

CVE-2026-58302 shows what happens when a privileged helper treats a path component like a harmless module identifier instead of an untrusted input. The security gap is boundary enforcement: once a basename is interpolated into a filesystem path, the trusted directory stops being a boundary unless slashes and traversal tokens are rejected.

For IAM and PAM teams, the identity lesson is that privilege is part of the attack surface even when the issue looks like application code. A SUID-root helper or equivalent elevated runtime collapses the difference between a local user and root if the code path loads attacker-controlled content before privilege dropping.

This pattern is common in mixed-purpose Linux systems where CNC control, development, package management, and remote administration share the same host. That combination makes local exploitation materially more valuable than the label suggests, because the system often contains credentials, automation, or operational control.

Key questions

Q: What breaks when a privileged helper accepts module names from untrusted local input?

A: The trust boundary breaks because the module name stops being a label and becomes a filesystem path chosen by the attacker. If the process is still privileged when it calls dlopen(), that path can load attacker-controlled code as root. The right response is to validate the name before path construction and remove standing privilege from the loader.

Q: Why do privileged plugin loaders turn local access into full system compromise?

A: Because the loader runs with more power than the caller. A local user may only control input, but if that input determines which shared object a privileged process loads, the resulting code executes with the process's elevated identity. That is why module-loading helpers must be treated as privilege boundaries, not convenience wrappers.

Q: How can security teams tell whether a module-loading path is still safe?

A: Check whether the program accepts only known basenames, rejects traversal tokens, and drops privileges before any dynamic load occurs. If user input can reach path construction first, the path is not safe even if the final directory looks trusted. A safe design keeps selection, resolution, and execution tightly bounded.

Q: Should organisations prioritize privilege reduction or path sanitisation first?

A: Path sanitisation and privilege reduction should be implemented together, but privilege reduction has the larger blast-radius benefit if the process can no longer load code as root. Sanitisation prevents the bad path, while privilege reduction limits the damage if a validation gap appears elsewhere. Both are needed for a defensible control plane.

Technical breakdown

Why privileged dlopen() becomes a root boundary problem

dlopen() loads a shared object into a running process, and if that process still has elevated privileges, any code in the library runs with those privileges. The risk is not the loader itself but the trust decision upstream: the caller must ensure the path points only to intended content. If a program accepts a user-controlled module name and maps it directly to a file path, then filesystem traversal becomes code execution. In this case, the attack works because the path is constructed from input rather than resolved from a fixed allowlist of basenames.

Practical implication: Treat any privileged plugin-loading path as a code-execution boundary, not a convenience feature.

How path traversal turns a module name into arbitrary code execution

Path traversal occurs when input like ../ or embedded slashes lets a caller escape the intended directory. In a helper such as rtapi_app, a name such as ../../tmp/evil becomes a path that resolves outside the trusted library directory and can point to an attacker-supplied .so file. If the binary has not dropped privileges, the library constructor or entrypoint executes as root. The key failure is that the program trusted the module name to remain a basename, but never enforced that assumption before calling dlopen().

Practical implication: Reject traversal tokens before path construction and verify the final resolved target still sits inside the allowed directory.

Why sanitisation and privilege dropping must be coupled

Sanitising input alone is not enough if the process continues to run with elevated privileges, and privilege dropping alone is not enough if untrusted paths are still accepted before the drop. Secure design requires both: constrain the input to a known-safe module set, then ensure the process sheds unnecessary privilege before any dynamic loading occurs. That separation matters because the vulnerable code path loads the attacker-controlled library before the trust boundary is reduced. In other words, the sequence of operations is the security control.

Practical implication: Drop privilege before any dynamic load and prove that no privileged code path can consume user-controlled module names first.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution with root privileges on the LinuxCNC host.

1. Entry occurs when a local user or code execution foothold can invoke rtapi_app on an affected LinuxCNC host.
2. Credential or privilege abuse happens when the attacker supplies a traversal-based module name that escapes the trusted directory and resolves to an attacker-controlled shared object.
3. Impact occurs when dlopen() loads the malicious library while the process still has elevated privileges, executing attacker code as root.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Malwarebytes breach 2021: SolarWinds attackers added a certificate to a dormant email security app's service principal at Malwarebytes and read internal email via Microsoft Graph.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Privileged plugin loading is a control-plane issue, not a narrow application bug. This case shows that dynamic loading inside an elevated helper creates an identity boundary as much as a filesystem boundary. If the process identity is still privileged when untrusted input reaches dlopen(), the trust decision has already failed. Practitioners should treat module-loading paths as part of privileged access governance, not just secure coding.

Path sanitisation only works when the allowed name space is explicit. A basename check is meaningful because it preserves the intended trust model, while path normalization after interpolation does not. That distinction matters across NHI, PAM, and host-hardening programmes: the control is not merely avoiding bad characters, it is preventing untrusted actors from selecting the executable object that a privileged process loads.

LinuxCNC illustrates the standing-privilege problem in a form operations teams often miss. The vulnerable helper did not need network reachability to become dangerous; it only needed a local execution path and elevated runtime. That is why local-user assumptions fail on shared engineering workstations, lab hosts, and controller systems. The practical conclusion is to eliminate standing privilege where possible and constrain any privileged helper to a fixed, auditable input set.

Root compromise from a local helper should be modelled as host-wide exposure until proven otherwise. Once attacker code runs in a privileged process, the blast radius extends beyond the CNC application into credentials, scripts, service accounts, and administrative tooling on the same machine. That is an access-governance failure mode, not just a patching issue. Teams should respond by shrinking the privilege window and isolating control hosts from general-purpose workloads.

Module-name traversal is a named concept worth watching in privileged Linux tooling. This is the pattern where a trusted loader assumes a user-supplied module name is only an identifier, but the program later converts it into a filesystem path and executes the result. The governance lesson is simple: if the subject of control can become a pathname, it must be treated as attacker-controlled until validated end to end.

What this signals

Standing privilege remains the real vulnerability multiplier. The issue here is not simply that a path can be traversed, but that a privileged helper can be induced to execute attacker-controlled code before its authority is reduced. For practitioners, that means the security outcome depends on where privilege is shed in the execution chain, not just on whether input validation exists.

Host hardening must account for local execution paths that look operational, not remote. CNC controllers, engineering workstations, and shared lab systems often have legitimate local modules and automation, which makes privilege misuse easy to overlook. The governance response is to remove unnecessary elevation, segment these systems, and treat any local code execution route as a candidate root path until proven otherwise.

Path traversal in a privileged loader is a good example of module-name traversal: a user-supplied identifier that should name a component instead becomes a pathname that escapes its trust boundary. Teams should watch for the same pattern anywhere a privileged process translates names into executable objects, especially on Linux hosts that also handle secrets or admin tooling.

For practitioners

• Audit privileged module loaders for traversal exposure Review any SUID-root or otherwise elevated helper that turns user input into a filesystem path for dlopen(), plugin loading, or module resolution. Look specifically for slash, dot-dot, and path-join logic that occurs before privilege dropping.
• Remove standing privilege from rtapi_app where possible If the workflow permits it, drop the SUID bit or equivalent elevated execution from rtapi_app and verify that LinuxCNC functions still operate under the least-privilege model your environment supports.
• Constrain module names to an explicit allowlist Permit only fixed basenames that are known in advance and reject any input containing path separators or traversal markers before path construction. Confirm the resolved path stays inside the trusted library directory.
• Treat local code execution on control hosts as root-equivalent Assume any untrusted local shell, package, or automation foothold can become full host compromise if a privileged loader exists. Segment CNC controllers away from developer tools, shared users, and remote administration paths.

Key takeaways

• This issue shows that a local-only vulnerability can still be a full host compromise when a privileged helper loads attacker-controlled code.
• The exploit works because the process turns a user-supplied module name into a path before the privilege boundary is reduced.
• Preventing the class requires both strict input validation and removal of standing privilege from the loading path.

Key terms

• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• dlopen(): dlopen() is a dynamic loading call that maps a shared object into a running process. On ELF systems, the loader may execute constructors immediately, so the call does more than open a file. It can create an execution event before the application has confirmed the object is trustworthy.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• SUID: SUID, or Set User ID, is a Linux permission bit that makes a program run with the file owner’s privileges instead of the launching user’s privileges. It is necessary for tightly controlled administrative actions, but it becomes dangerous when applied to binaries that can access shells, protected files, or system-level resources.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is useful for practitioners who need to connect identity control decisions to privilege, trust, and operational risk.