CVE-2026-109356 in LibreNMSinfo

Summary

by MITRE • 10/12/2026

LibreNMS before 26.9.0 contains a missing authorization vulnerability in PortsController::purge that allows global-read users to physically delete ports without delete privileges. Attackers with read-only accounts can send DELETE requests to /ports/purge, using purge=all to irreversibly erase every deleted port on all visible devices.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/12/2026

The identified vulnerability resides within the LibreNMS network monitoring platform prior to version 26.9.0 and specifically affects the PortsController::purge functionality. This flaw represents a critical failure in access control mechanisms, classified under CWE-862 as Missing Authorization. The core technical issue stems from an insufficient verification of user privileges when processing HTTP DELETE requests directed at the /ports/purge endpoint. While the application correctly restricts certain administrative actions to users with elevated permissions, it fails to validate whether a global-read user possesses the specific delete privilege required for this operation. Consequently, any authenticated user possessing only read-only access rights can bypass these intended restrictions by sending a specially crafted DELETE request that includes the purge=all parameter.

From an operational perspective, this vulnerability allows attackers to irreversibly erase every deleted port on all devices visible to their account. In network monitoring environments like LibreNMS, ports are frequently marked as deleted during routine maintenance or when hardware is removed from service before being permanently purged from the database. The ability for a read-only user to trigger mass deletion of these records disrupts historical data integrity and can lead to significant gaps in network visibility. This action effectively destroys audit trails related to port status changes, making it difficult for administrators to track infrastructure modifications or diagnose past connectivity issues. Furthermore, such unauthorized destruction of configuration data constitutes a severe compromise of the system's availability and reliability, potentially masking malicious activities that occurred prior to the purge.

The exploitation vector is straightforward yet impactful, requiring only authenticated access with global-read privileges rather than full administrative rights. This lowers the barrier for entry significantly, as read-only accounts are often granted more broadly across organizations for monitoring purposes without strict oversight of their capabilities. The use of the purge=all parameter ensures that the action is not limited to a single port but affects all eligible records associated with visible devices, amplifying the scope and severity of the damage. This aligns with ATT&CK technique T1070, specifically Indicator Removal on Host or Data Destruction variants within cloud environments, as it involves the removal of evidence or data artifacts that are critical for operational continuity and forensic analysis.

To mitigate this vulnerability, organizations running LibreNMS versions earlier than 26.9.0 must upgrade to the latest patched release immediately. The developers have addressed the logic flaw in the PortsController by implementing stricter role-based access control checks that verify delete permissions before executing any purge operations. Until an upgrade is feasible, administrators should consider restricting network-level access to the LibreNMS web interface for users with read-only roles or disabling the /ports/purge endpoint entirely if it is not actively used. Additionally, enabling comprehensive logging of all administrative actions and DELETE requests can aid in detecting unauthorized attempts and support forensic investigations following a potential incident. Regular audits of user permissions are also recommended to ensure that privilege assignments align strictly with operational requirements, minimizing the attack surface for such authorization bypasses.

Responsible

VulnCheck

Reservation

10/12/2026

Disclosure

10/12/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!