CVE-2026-94382 in Beszel
Summary
by MITRE • 09/21/2026
Beszel before 0.19.0 contains an insecure direct object reference vulnerability in the POST and DELETE /api/beszel/user-alerts handlers that allows any authenticated user to create or delete alerts on systems they cannot access. Attackers can supply arbitrary system IDs in the request body to register alert rules and receive notifications disclosing target system names and metrics.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in Beszel versions prior to 0.19.0 represents a classic insecure direct object reference, commonly categorized under CWE-639 within industry standard classification systems. This flaw resides specifically within the API endpoints responsible for managing user alerts, namely the POST and DELETE handlers associated with /api/beszel/user-alerts. The core technical deficiency lies in the application's failure to validate whether the authenticated user initiating the request possesses administrative or monitoring privileges over the specific system identified by the ID provided in the request payload. Instead of enforcing an authorization check that maps the current session's permissions against the target resource, the server blindly accepts and processes any validly formatted system identifier submitted by the client. This architectural oversight allows a malicious actor who has obtained legitimate authentication credentials to manipulate alert configurations for systems outside their authorized scope.
From an operational perspective, this vulnerability enables two distinct but related attack vectors depending on which endpoint is targeted. When exploiting the POST handler, an attacker can inject arbitrary system IDs into the request body to register new alert rules. This action effectively registers the attacker's contact information or notification channel against a target server that they do not own or have permission to monitor. Consequently, when legitimate monitoring events occur on those unauthorized systems, such as high CPU usage, disk space exhaustion, or service outages, notifications are delivered directly to the attacker. These alerts serve as an indirect information disclosure mechanism, revealing sensitive operational details including specific system names and real-time performance metrics that were intended for internal administrators only. This capability transforms a simple authentication bypass into a reconnaissance tool, allowing attackers to map infrastructure topology and identify critical assets based on alert triggers.
The exploitation of the DELETE handler presents a different but equally damaging risk profile centered around availability and integrity rather than information disclosure. An authenticated user can send delete requests targeting alerts associated with systems they do not control. By removing these legitimate monitoring rules, an attacker effectively blindsides the system administrators regarding potential issues occurring on those specific servers. This denial of service against the monitoring infrastructure means that critical failures or security incidents on unauthorized targets may go undetected for extended periods, increasing the window of opportunity for further exploitation by other threat actors who might be targeting those same systems. The cumulative effect is a degradation of overall system observability and reliability across the entire monitored environment.
In terms of adversary behavior, this vulnerability aligns with techniques observed in the MITRE ATT&CK framework, particularly those related to resource hijacking or unauthorized access to monitoring capabilities. While not directly compromising confidentiality through data exfiltration in the traditional sense, it facilitates lateral movement by providing intelligence about other systems and degrades defensive postures by disabling alerts. The impact is significant because it undermines the trust model of multi-tenant or shared infrastructure environments where different teams manage distinct sets of servers but share a central monitoring platform like Beszel.
To mitigate this vulnerability, immediate action must be taken to upgrade all instances of Beszel to version 0.19.0 or later, as these updates include patches that enforce proper access control checks on the alert management endpoints. For environments where upgrading is not immediately feasible, network-level controls such as web application firewalls can be configured to restrict API access based on user roles if role-based information is available in session tokens. Additionally, developers should implement strict server-side validation logic for all object references involving external resources. This involves querying the database or authorization service to verify that the currently authenticated user has explicit permission to modify alert rules for the specified system ID before processing any POST or DELETE requests. Implementing comprehensive logging and monitoring of API access patterns can also help detect anomalous behavior indicative of exploitation attempts, such as a single account rapidly creating alerts across multiple unrelated systems.