GHSA-JF24-8G2H-2WG7: Remote Code Execution in LibreNMS AboutController via Binary Path Substitution

LibreNMS is an open-source, PHP-based autodiscovering network monitoring tool that relies extensively on external system binaries to query network devices. The application exposes an administrative interface that allows authorized users to manage system configurations, including the file paths for utilities such as Net-SNMP. One of these utilities is the snmpget binary, which LibreNMS executes to retrieve SNMP data and verify version information.

Historically, configuration systems that execute system commands face substantial risks if input fields are not strictly restricted to pre-defined safe paths. In LibreNMS, the configuration settings are stored in a database and can be modified by users holding administrative privileges. The /about endpoint of the application triggers a configuration check that invokes the binary path defined in this database.

This architecture creates an attack surface where an administrative user can influence the execution path of system commands. If an attacker can manipulate the binary path configuration to point to an arbitrary executable, they can abuse the application logic to execute arbitrary code on the underlying operating system. The vulnerability is classified under command injection and path traversal weaknesses.

The root cause of this vulnerability lies in the insufficient validation of the snmpget configuration value within the AboutController.php file. When the /about endpoint is accessed, the application retrieves the path to the snmpget executable and runs it using the PHP shell_exec() function. This function passes the command string directly to the host shell for execution, which inherently exposes the system to command execution vulnerabilities if the binary path itself is untrusted.

To prevent malicious inputs, LibreNMS employs a sanitization filter named sanitizePath() located in LibreNMS/Util/DynamicConfigItem.php. This helper function utilizes a regular expression pattern to detect and reject typical shell metacharacters such as semicolons, pipes, backticks, and redirection operators. It also verifies that the configured target is a valid, executable file on the local disk using PHP's native is_file() and is_executable() functions.

While this sanitization effectively blocks direct inline command injection (such as appending a command separator followed by malicious code), it fails to validate the identity and integrity of the executable itself. An attacker who can write a file to the filesystem can specify their malicious script as the target executable. Because the malicious script exists as a valid file and has the executable bit set, it satisfies both is_file() and is_executable(), allowing the path to be saved and subsequently executed by the application.

The vulnerable version of the application processes the execution of the version check inside app/Http/Controllers/AboutController.php as follows:

// Vulnerable code in AboutController.php
'version_netsnmp' => str_replace('version: ', '', 
    rtrim(shell_exec(LibrenmsConfig::get('snmpget', 'snmpget') . ' -V 2>&1'))),

In this implementation, shell_exec() is used to execute the binary string directly. This passes the command to the default shell (typically /bin/sh), which interprets the string and runs the target process.

To remediate this issue, the patch replaces shell_exec() with the Symfony Process component, which executes the binary directly without spawning a shell interpreter. The updated code inside the controller is structured as follows:

// Patched code in AboutController.php
use Symfony\Component\Process\Process;
 
// The process is initialized with arguments as an array
$process = new Process([LibrenmsConfig::get('snmpget', 'snmpget'), '-V']);
$process->run();
 
'version_netsnmp' => str_replace('version: ', '', rtrim($process->getOutput())),

By passing the binary path and arguments as an array, the Symfony Process component bypasses shell parsing. Even if the path points to a customized script, it prevents any argument injection or command-chaining. This restricts the execution to the targeted file and safely processes the output.

Exploitation of this vulnerability requires administrative credentials to access the LibreNMS web interface and modify system settings. In addition, the attacker must have a mechanism to write or upload an executable script onto the local filesystem of the target server. Common avenues for dropping the script include using temporary directories like /tmp, leveraging existing file upload functionalities, or exploiting secondary vulnerabilities.

Once a malicious executable is written to the filesystem, the attacker modifies the snmpget binary path configuration. This can be accomplished by navigating to the 'Settings' panel under 'External Binaries' or by sending a direct PUT request to /settings/snmpget. The value is set to the absolute path of the newly written executable file, which passes the validation checks because it exists and is executable.

PUT /settings/snmpget HTTP/1.1
Host: librenms.target.local
Authorization: Bearer <ADMIN_API_TOKEN>
Content-Type: application/json
 
{
  "value": "/tmp/malicious_script.sh"
}

After saving the configuration, the attacker triggers the execution by requesting the /about endpoint. The server executes the malicious script via the web daemon's account. This allows the attacker to establish a reverse shell connection or execute arbitrary system commands, resulting in host compromise.

The security impact of successful exploitation is high, leading to arbitrary code execution within the context of the web server daemon (such as www-data or apache). An attacker can leverage this execution access to read sensitive configuration files, modify application data, or access the database credentials stored within the LibreNMS environment.

Because LibreNMS acts as a centralized network monitoring platform, it typically holds sensitive operational data. This data includes SNMP community strings, API keys, network topology maps, and credentials for monitored network infrastructure. Access to the LibreNMS host allows an attacker to pivot and conduct lateral movement across the entire monitored corporate network.

From a CVSS perspective, the vulnerability is scored at 6.4 (CVSS v4.0) under the assumption that the immediate impact to the application itself is managed, but subsequent impact to the host OS and connected systems is high. Under CVSS v3, this scenario represents a high-severity vulnerability with a score of 7.2 due to the administrative privilege requirement.

The primary remediation for this vulnerability is upgrading LibreNMS to version 26.5.0 or higher. This version implements safe process execution via the Symfony Process component, neutralizing the command injection vector. System administrators should verify that all binary paths point to standard system directories after the upgrade.

If immediate upgrading is not feasible, several defensive workarounds should be applied to reduce the attack surface. Administrators should mount temporary write directories, such as /tmp and /var/tmp, with the noexec mount option to prevent the execution of arbitrary scripts dropped by attackers.

# Example of setting noexec on /tmp dynamically
mount -o remount,noexec /tmp

Additionally, access to the administration interface must be restricted to trusted networks using firewall rules, reverse proxies, or Web Application Firewalls (WAFs). WAF rules can be deployed to block PUT requests to the /settings/snmpget endpoint from unauthorized source IPs, ensuring that only authenticated maintenance channels can modify critical configurations.