Librenms Cross-site Scripting

A user is able to enable their own account if it was disabled by an admin while the user still holds a valid session. Moreover, the username is not properly sanitized in the admin user overview. This enables an XSS attack that enables an attacker with a low privilege user to execute arbitrary JavaScript in the context of an admin's account. (2022-11-20, CVE-2022-4068)

Cross-site Scripting (XSS) - Generic in GitHub repository librenms/librenms prior to 22.10.0. (2022-11-20, CVE-2022-3561)

Cross-site Scripting (XSS) - Generic in GitHub repository librenms/librenms prior to 22.10.0. (2022-11-20, CVE-2022-4069)

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 22.10.0. (2022-11-20, CVE-2022-3516)

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 22.10.0. (2022-11-20, CVE-2022-3562)

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 22.10.0. (2022-11-20, CVE-2022-4067)

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 22.9.0. (2022-09-17, CVE-2022-3231)

LibreNMS v22.6.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the component oxidized-cfg-check.inc.php. (2022-08-30, CVE-2022-36746)

LibreNMS v22.6.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the component print-customoid.php. (2022-08-30, CVE-2022-36745)

LibreNMS v22.3.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /Table/GraylogController.php. (2022-06-02, CVE-2022-29711)

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 22.2.2. (2022-02-27, CVE-2022-0772)

Cross-site Scripting (XSS) - Stored in Packagist librenms/librenms prior to 22.1.0. (2022-02-15, CVE-2022-0589)

Cross-site Scripting (XSS) - Generic in Packagist librenms/librenms prior to 22.1.0. (2022-02-14, CVE-2022-0576)

Cross-site Scripting (XSS) - Stored in Packagist librenms/librenms prior to 22.2.0. (2022-02-14, CVE-2022-0575)

Librenms 21.11.0 is affected by a Cross Site Scripting (XSS) vulnerability in includes/html/common/alert-log.inc.php. (2021-12-01, CVE-2021-44277)

Librenms 21.11.0 is affected by a Cross Site Scripting (XSS) vulnerability in includes/html/forms/poller-groups.inc.php. (2021-12-01, CVE-2021-44279)

LibreNMS through 21.10.2 allows XSS via a widget title. (2021-11-03, CVE-2021-43324)

In LibreNMS < 21.3.0, a stored XSS vulnerability was identified in the API Access page due to insufficient sanitization of the $api->description variable. As a result, arbitrary Javascript code can get executed. (2021-09-08, CVE-2021-31274)

An issue was discovered in LibreNMS through 1.47. Many of the scripts rely on the function mysqli_escape_real_string for filtering data. However, this is particularly ineffective when returning user supplied input in an HTML or a JavaScript context, resulting in unsafe data being injected into these contexts, leading to attacker controlled JavaScript executing in the browser. One example of this is the string parameter in html/pages/inventory.inc.php. (2019-09-09, CVE-2019-10670)

LibreNMS v1.54 has XSS in the Create User, Inventory, Add Device, Notifications, Alert Rule, Create Maintenance, and Alert Template sections of the admin console. This could lead to cookie stealing and other malicious actions. This vulnerability can be exploited with an authenticated account. (2019-08-28, CVE-2019-15230)

Persistent Cross-Site Scripting (XSS) issues in LibreNMS before 1.44 allow remote attackers to inject arbitrary web script or HTML via the dashboard_name parameter in the /ajax_form.php resource, related to html/includes/forms/add-dashboard.inc.php, html/includes/forms/delete-dashboard.inc.php, and html/includes/forms/edit-dashboard.inc.php. (2018-10-18, CVE-2018-18478)

Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.

The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:

https://server.com/confirmation?message=Transaction+Complete

what results in:

<span>Confirmation: Transaction Complete</span>

In that case the message can be modified to become a valid Javascript code, e.g.:

https://server.com/confirmation?message=<script>dangerous javascript code here</script>

and it will be executed locally by the user's browser with full access to the user's personal application/browser data:

<span>Confirmation: <script>dangerous javascript code here</script></span>