CVE-2026-113598 in Modoboainfo

Summary

by MITRE • 10/20/2026

Modoboa before 2.8.0 contains an insecure direct object reference vulnerability that allows authenticated users to delete alarms of other domains via the POST /api/v2/alarms/bulk_delete/ action. Attackers can enumerate sequential alarm IDs to delete DNS, MX and blocklist monitoring alarms server-wide, hiding problems from responsible administrators.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/20/2026

The Modoboa web hosting control panel software version 2.8.0 and earlier suffers from a critical insecure direct object reference vulnerability within its API endpoint for bulk deleting alarms. This flaw stems from insufficient authorization checks on the POST /api/v2/alarms/bulk_delete/ action, which allows authenticated users to manipulate alarm records belonging to domains they do not own or manage. In a properly secured system, an application must verify that the requesting user has explicit permission to perform actions on specific resources identified by their unique identifiers. However, in this implementation, the server relies solely on the provided object identifier without validating whether that resource is associated with the authenticated session's permitted scope. This architectural oversight enables any valid account holder to bypass domain-level isolation boundaries and interact directly with global system state through sequential enumeration of alarm IDs.

The operational impact of this vulnerability is severe as it allows an attacker to systematically enumerate sequential integer-based identifiers for alarms across all domains hosted on the server. By iterating through these IDs, a malicious actor can delete monitoring alerts related to DNS configuration integrity, mail exchange record validity, and blocklist status checks. These alarms serve as critical early warning mechanisms for system administrators, providing visibility into potential service disruptions or security incidents such as misconfigured email routing or compromised domain reputation due to blacklisting. By deleting these records, the attacker effectively blinds the administration team to ongoing issues, creating a stealthy environment where malicious activities can proceed undetected while legitimate problems remain hidden from oversight.

This vulnerability aligns with CWE-639, which classifies insecure direct object references as flaws where an application exposes internal implementation objects like files or database keys via user-supplied input without proper access control validation. Furthermore, the exploitation technique maps to MITRE ATT&CK tactic T1078, specifically valid accounts and persistence mechanisms involving privilege escalation through improper authorization checks. The ability to delete security-relevant logs and alerts also correlates with defense evasion techniques aimed at obscuring malicious activity from monitoring systems. Such actions can facilitate further attacks by preventing timely response to other compromises that may have occurred on the same infrastructure, thereby increasing the window of exposure for sensitive data and services managed through the platform.

To mitigate this vulnerability, administrators must upgrade Modoboa to version 2.8.0 or later where these authorization checks have been corrected to enforce strict ownership verification before processing deletion requests. Until an update is applied, implementing a reverse proxy with advanced access control policies can help restrict direct API exposure and validate user permissions at the network layer based on domain associations defined in backend configurations. Additionally, enabling comprehensive audit logging for all administrative actions provides forensic visibility into unauthorized bulk deletions, allowing for rapid detection of such abuse even if the underlying application logic remains flawed. Regular security assessments focusing on object-level authorization controls are recommended to identify similar patterns across other API endpoints within the management interface.

Responsible

VulnCheck

Reservation

10/20/2026

Disclosure

10/20/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!