CVE-2026-81192: Local Code Execution via Untrusted Search Path in OpenTelemetry.Resources.Host

The OpenTelemetry.Resources.Host package provides essential infrastructure for gathering environment-specific metadata in .NET applications. During execution on macOS platforms, the host detector attempts to resolve a unique hardware identifier to populate the host.id attribute. This identification process relies on invoking OS utilities to query system attributes.\n\nTo execute these queries, the library invokes external binaries via the standard system command interface. In versions prior to 1.16.0-beta.2, the process initialization parameters specified relative executable names rather than absolute directory paths. This design pattern delegates the resolution of the executable files to the host operating system's PATH search mechanisms.\n\nBy delegating resolution to the PATH variable, the component introduces a vulnerability classified under CWE-426 (Untrusted Search Path). A local adversary who can write to any location prioritized within the runtime's PATH variable can substitute a malicious executable. This vulnerability only affects macOS deployments, leaving Linux and Windows installations unaffected.

The underlying defect in HostDetector.cs stems from improper configuration of the ProcessStartInfo class during shell command initialization. The detector attempts to run the command ioreg -rd1 -c IOPlatformExpertDevice using an intermediary shell. To launch this process, the FileName property of ProcessStartInfo is set to "sh" while UseShellExecute is disabled.\n\nWith UseShellExecute set to false, the .NET execution runtime bypasses the system shell wrapper for the initial process launch but must locate the "sh" binary. Because only a relative name is provided, the runtime searches sequentially through the folders defined in the active process's PATH environment variable. This search sequence proceeds from the left-most directory to the right-most, executing the first matching binary found.\n\nFurthermore, the argument string passed to the process is -c \"ioreg -rd1 -c IOPlatformExpertDevice\". The newly spawned shell must resolve the ioreg binary name to execute the hardware query. Because the shell also relies on the active PATH variable to locate ioreg, it presents a secondary point of path resolution vulnerability. If an attacker controls any of these path targets, arbitrary binary execution is achieved.

Analysis of the vulnerable code segment in HostDetector.cs reveals how the process instantiation details are defined. The library utilizes a relative executable string "sh" as the primary execution target. The actual utility query ioreg is wrapped in arguments that are sequentially parsed by the resolved shell.\n\nThe remediated version modifies this behavior by executing the required diagnostic tool directly. The intermediate shell launch is eliminated, removing potential shell parsing risks. Additionally, the execution path is explicitly defined using the absolute path /usr/sbin/ioreg, bypassing the system path search entirely.\n\nOn macOS platforms, the /usr/sbin directory is protected by System Integrity Protection (SIP). This OS-level security boundary ensures that administrative users cannot write to or modify files within this directory. By relying on an absolute, protected path, the system guarantees that the execution flow cannot be hijacked by localized path manipulation.\n\nTo visualize this control flow difference, consider the following process resolution paths:\n\nmermaid\ngraph LR\n subgraph Vulnerable Flow\n A[\"Start Process\"] --> B[\"Query 'sh'\"]\n B --> C[\"Search PATH\"]\n C --> D[\"Execute 'sh' from PATH\"]\n D --> E[\"Launch 'ioreg'\"]\n E --> F[\"Search PATH for 'ioreg'\"]\n end\n subgraph Patched Flow\n G[\"Start Process\"] --> H[\"Direct Launch\"]\n H --> I[\"Execute '/usr/sbin/ioreg'\"]\n end\n

Exploitation of CVE-2026-81192 requires a local attacker to possess specific privileges or environment control on the target macOS system. The primary objective is to direct the .NET runtime or the spawned shell to execute a payload named either sh or ioreg. This is achieved by manipulating the PATH environment variable or writing to an existing PATH directory.\n\nIf the application runs within an environment where standard user-writable directories are included in the search path, exploitation is straightforward. The attacker creates an executable file named sh within the writable directory and populates it with arbitrary payload commands. Once the telemetry engine initializes, the operating system executes the attacker's script instead of the legitimate shell.\n\nAlternatively, if the attacker can modify environment variables, they can prepend an arbitrary writable folder to the application's PATH. For instance, exporting a modified PATH prefixing /tmp/attacker_bin ensures that the runtime resolves the malicious sh file first. The execution of this binary occurs within the security context of the parent application.

The security impact of this vulnerability is classified as High, with a CVSS v3.1 base score of 7.0. The CVSS vector is calculated as CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, reflecting local access, high complexity, and low required privileges. The primary consequence is the potential for local privilege escalation on macOS endpoints.\n\nIf the host application utilizing the OpenTelemetry SDK runs with administrative or root privileges, the hijacked execution inherits these elevated permissions. This allows a low-privileged local user to execute arbitrary commands as a high-privileged service or administrator. The confidentiality, integrity, and availability of the affected system are entirely compromised.\n\nAccording to the Exploit Prediction Scoring System (EPSS), the probability of active exploitation in the wild remains minimal. The vulnerability is currently not cataloged in CISA's Known Exploited Vulnerabilities (KEV) database, and there are no reports of its use in active ransomware campaigns. However, internal corporate environments executing macOS-based development or monitoring agents remain at risk.

Remediation requires upgrading the OpenTelemetry.Resources.Host dependency to version 1.16.0-beta.2 or later. This version replaces relative command executions with direct, absolute path calls, neutralizing the path traversal vector. For applications where immediate upgrades are impossible, strict environment isolation must be enforced.\n\nSystem administrators must verify that the process-level PATH variable does not contain directories writable by non-privileged accounts. Ensuring that protected system directories like /bin and /usr/sbin precede other paths in the sequence reduces the likelihood of hijacking. Furthermore, running applications under least-privilege identities minimizes the impact of potential execution bypasses.\n\nDetection strategies involve auditing process executions and monitoring system events. Security operations teams should establish rules to detect situations where a .NET application invokes shell processes with hardware information queries in their argument list. Any invocation where the resolved command path is outside standard system folders should be treated as a high-priority alert.