GHSA-X645-6PF9-XWXW
Vulnerability from github – Published: 2024-11-15 15:54 – Updated: 2026-05-12 13:29Summary
An authenticated attacker can create dangerous directory names on the system and alter sensitive configuration parameters through the web portal. Those two defects combined then allows to inject arbitrary OS commands inside shell_exec() calls, thus achieving arbitrary code execution.
Details
OS Command Injection
We start by inspecting the file app/Http/Controllers/AboutController.php, more particularly the index() method which is executed upon simply visiting the /about page:
public function index(Request $request)
{
$version = Version::get();
return view('about.index', [
<TRUNCATED>
'version_webserver' => $request->server('SERVER_SOFTWARE'),
'version_rrdtool' => Rrd::version(),
'version_netsnmp' => str_replace('version: ', '', rtrim(shell_exec(Config::get('snmpget', 'snmpget') . ' -V 2>&1'))),
<TRUNCATED>
]);
}
We can see that the version_netsnmp key receives a value direclty dependent of a shell_exec() call. The argument to this call reflects a configuration parameter with no sanitization. Should an attacker identify a way to alter this parameter, the server is at risk of being compromised.
Configuration parameters poisoning
We now focus on the update() method of the SettingsController.php script. This method is called when the user visits the route /settings/{key} via HTTP PUT. The key parameter here is simply the name of the configuration key the user wishes to modify.
public function update(DynamicConfig $config, Request $request, $id)
{
$value = $request->get('value');
if (! $config->isValidSetting($id)) {
return $this->jsonResponse($id, ':id is not a valid setting', null, 400);
}
$current = \LibreNMS\Config::get($id);
$config_item = $config->get($id);
if (! $config_item->checkValue($value)) {
return $this->jsonResponse($id, $config_item->getValidationMessage($value), $current, 400);
}
if (\LibreNMS\Config::persist($id, $value)) {
return $this->jsonResponse($id, "Successfully set $id", $value);
}
return $this->jsonResponse($id, 'Failed to update :id', $current, 400);
}
We can see that some protections are implemented around the configuration parameters by $config_item->checkValue($value), with a format of data being expected depending on the data type of the variable the user wants to modify.
Specifically, the snmpget configuration variable expects a valid path to an existing binary on the system.
To summarize : if an attacker finds a valid full-path to a system binary, while that full-path also holds shell metacharacters, then those characters would be interpreted by the shell_exec() call defined above and allow for arbitrary command execution.
Arbitrary directory creation
When creating a new Device through the "Add Device" page, the server allows the user to send malformed or impossible hostnames and force the data to be stored, with no sanitization being performed on this field.
In the file app/Jobs/PollDevice.php, the initRrdDirectory() method is responsible for creating a directory named after the Device's hostname. We can see the mkdir() call inside the try block:
private function initRrdDirectory(): void
{
$host_rrd = \Rrd::name($this->device->hostname, '', '');
if (Config::get('rrd.enable', true) && ! is_dir($host_rrd)) {
try {
mkdir($host_rrd);
Log::info("Created directory : $host_rrd");
} catch (\ErrorException $e) {
Eventlog::log("Failed to create rrd directory: $host_rrd", $this->device);
Log::info($e);
}
}
}
This method is called by initDevice(), which is itself called by the handle() method (executed when the job starts).
\Rrd::name() simply concatenates a string following the format <LIBRENMS_INSTALL_DIR>/rrd/<DEVICE_HOSTNAME>.
Summary
With all this, an authenticated attacker can:
- Create a malicious Device with shell metacharacters inside its hostname
- Force the creation of directory containing shell metacharacters through the PollDevice job
- Modify the snmpget configuration variable to point to a valid system binary, while also using the directory created in the previous step via a path traversal (i.e: /path/to/install/dir/rrd/<DEVICE_HOSTNAME>/../../../../../../../bin/ls)
- Trigger a code execution via the shell_exec() call contained in the AboutController.php script
PoC
For proof of concept, we will create a file located at /tmp/rce-proof on the server's filesystem.
Consider the following command : /usr/bin/touch /tmp/rce-proof, encoded in base64 (L3Vzci9iaW4vdG91Y2ggL3RtcC9yY2UtcHJvb2Y=). This encoding is necesary whenever the command contains '/' characters, as this would otherwise generate invalid directory paths.
Create a new Device with a name that contains the command you wish to execute enclosed in semi-colons, ending with a '3' character:
Be careful to tick the "Force Add" option, otherwise the request will be rejected. Click add:
A directory matching the hostname of the Device will be created whenever a PollDevice job is launched. For the purpose of the demonstration, we will be triggering this manually with artisan:
We can confirm that this directory indeed exists on the system:
We can now update the snmpget parameter value to point to any binary on the system, making sure that the specified path includes the directory that was just created:
Visiting the /about page will trigger the payload, then we can check that our code was indeed executed:
Impact
Server takeover
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 24.9.1"
},
"package": {
"ecosystem": "Packagist",
"name": "librenms/librenms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "24.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-51092"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-15T15:54:18Z",
"nvd_published_at": "2026-05-08T06:16:10Z",
"severity": "CRITICAL"
},
"details": "### Summary\nAn authenticated attacker can create dangerous directory names on the system and alter sensitive configuration parameters through the web portal. Those two defects combined then allows to inject arbitrary OS commands inside `shell_exec()` calls, thus achieving arbitrary code execution.\n\n### Details\n#### OS Command Injection\nWe start by inspecting the file `app/Http/Controllers/AboutController.php`, more particularly the index() method which is executed upon simply visiting the /about page:\n```php\npublic function index(Request $request)\n {\n $version = Version::get();\n\n return view(\u0027about.index\u0027, [\n \u003cTRUNCATED\u003e\n\n \u0027version_webserver\u0027 =\u003e $request-\u003eserver(\u0027SERVER_SOFTWARE\u0027),\n \u0027version_rrdtool\u0027 =\u003e Rrd::version(),\n \u0027version_netsnmp\u0027 =\u003e str_replace(\u0027version: \u0027, \u0027\u0027, rtrim(shell_exec(Config::get(\u0027snmpget\u0027, \u0027snmpget\u0027) . \u0027 -V 2\u003e\u00261\u0027))),\n\n \u003cTRUNCATED\u003e\n ]);\n }\n```\n\nWe can see that the `version_netsnmp` key receives a value direclty dependent of a `shell_exec()` call. The argument to this call reflects a configuration parameter with no sanitization. Should an attacker identify a way to alter this parameter, the server is at risk of being compromised.\n\n#### Configuration parameters poisoning\nWe now focus on the `update()` method of the `SettingsController.php` script. This method is called when the user visits the route `/settings/{key}` via HTTP PUT. The key parameter here is simply the name of the configuration key the user wishes to modify.\n```php\npublic function update(DynamicConfig $config, Request $request, $id)\n{\n $value = $request-\u003eget(\u0027value\u0027);\n\n if (! $config-\u003eisValidSetting($id)) {\n return $this-\u003ejsonResponse($id, \u0027:id is not a valid setting\u0027, null, 400);\n }\n\n $current = \\LibreNMS\\Config::get($id);\n $config_item = $config-\u003eget($id);\n\n if (! $config_item-\u003echeckValue($value)) {\n return $this-\u003ejsonResponse($id, $config_item-\u003egetValidationMessage($value), $current, 400);\n }\n\n if (\\LibreNMS\\Config::persist($id, $value)) {\n return $this-\u003ejsonResponse($id, \"Successfully set $id\", $value);\n }\n\n return $this-\u003ejsonResponse($id, \u0027Failed to update :id\u0027, $current, 400);\n}\n```\n\nWe can see that some protections are implemented around the configuration parameters by `$config_item-\u003echeckValue($value)`, with a format of data being expected depending on the data type of the variable the user wants to modify.\nSpecifically, the `snmpget` configuration variable expects a valid path to an existing binary on the system.\nTo summarize : if an attacker finds a valid full-path to a system binary, while that full-path also holds shell metacharacters, then those characters would be interpreted by the `shell_exec()` call defined above and allow for arbitrary command execution.\n\n#### Arbitrary directory creation\nWhen creating a new Device through the \"Add Device\" page, the server allows the user to send malformed or impossible hostnames and force the data to be stored, with no sanitization being performed on this field.\n\nIn the file `app/Jobs/PollDevice.php`, the `initRrdDirectory()` method is responsible for creating a directory named after the Device\u0027s hostname. We can see the `mkdir()` call inside the try block:\n```php\nprivate function initRrdDirectory(): void\n{\n $host_rrd = \\Rrd::name($this-\u003edevice-\u003ehostname, \u0027\u0027, \u0027\u0027);\n if (Config::get(\u0027rrd.enable\u0027, true) \u0026\u0026 ! is_dir($host_rrd)) {\n try {\n mkdir($host_rrd);\n Log::info(\"Created directory : $host_rrd\");\n } catch (\\ErrorException $e) {\n Eventlog::log(\"Failed to create rrd directory: $host_rrd\", $this-\u003edevice);\n Log::info($e);\n }\n }\n}\n```\n\nThis method is called by `initDevice()`, which is itself called by the `handle()` method (executed when the job starts).\n`\\Rrd::name()` simply concatenates a string following the format `\u003cLIBRENMS_INSTALL_DIR\u003e/rrd/\u003cDEVICE_HOSTNAME\u003e`.\n\n#### Summary\nWith all this, an authenticated attacker can:\n- Create a malicious Device with shell metacharacters inside its hostname\n- Force the creation of directory containing shell metacharacters through the PollDevice job\n- Modify the `snmpget` configuration variable to point to a valid system binary, while also using the directory created in the previous step via a path traversal (i.e: `/path/to/install/dir/rrd/\u003cDEVICE_HOSTNAME\u003e/../../../../../../../bin/ls`)\n- Trigger a code execution via the `shell_exec()` call contained in the `AboutController.php` script\n\n#### \n\n### PoC\nFor proof of concept, we will create a file located at `/tmp/rce-proof` on the server\u0027s filesystem.\n\nConsider the following command : `/usr/bin/touch /tmp/rce-proof`, encoded in base64 (`L3Vzci9iaW4vdG91Y2ggL3RtcC9yY2UtcHJvb2Y=`). This encoding is necesary whenever the command contains \u0027/\u0027 characters, as this would otherwise generate invalid directory paths.\nCreate a new Device with a name that contains the command you wish to execute enclosed in semi-colons, ending with a \u00273\u0027 character:\n\n\nBe careful to tick the \"Force Add\" option, otherwise the request will be rejected. Click add:\n\n\nA directory matching the hostname of the Device will be created whenever a PollDevice job is launched. For the purpose of the demonstration, we will be triggering this manually with artisan:\n\n\nWe can confirm that this directory indeed exists on the system:\n\n\nWe can now update the `snmpget` parameter value to point to any binary on the system, making sure that the specified path includes the directory that was just created:\n\n\nVisiting the `/about` page will trigger the payload, then we can check that our code was indeed executed:\n\n\n\n### Impact\nServer takeover",
"id": "GHSA-x645-6pf9-xwxw",
"modified": "2026-05-12T13:29:29Z",
"published": "2024-11-15T15:54:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/librenms/librenms/security/advisories/GHSA-x645-6pf9-xwxw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51092"
},
{
"type": "PACKAGE",
"url": "https://github.com/librenms/librenms"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/linux/http/librenms_authenticated_rce_cve_2024_51092.rb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "LibreNMS has an Authenticated OS Command Injection"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.