CVE-2026-113599 in Modoboa
Summary
by MITRE • 10/20/2026
Modoboa before 2.8.0 contains an insecure direct object reference vulnerability that allows authenticated users to create auto-reply messages for arbitrary mailboxes by supplying another user's mbox value. Attackers can POST to /api/v2/armessages/ to inject attacker-controlled auto-reply subject and content into victims' settings or break their auto-reply management via MultipleObjectsReturned errors.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Modoboa versions prior to 2.8.0 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference (IDOR) under the Common Weakness Enumeration standard as CWE-639. This flaw resides within the API endpoint responsible for managing auto-reply messages, located at /api/v2/armessages/. The core technical deficiency lies in the server-side validation logic which fails to verify that the mailbox identifier provided by the authenticated user actually belongs to them. Instead of binding the action strictly to the session's associated identity, the application trusts the client-supplied mbox value without performing a secondary authorization check against the database records linked to the current user context. This architectural oversight allows any validly authenticated account to manipulate resources belonging to other accounts simply by altering the object reference in the HTTP request payload.
From an operational perspective, this vulnerability enables two distinct categories of malicious activity depending on how the attacker exploits the flaw. First, by successfully submitting a POST request with another user's mbox value alongside controlled subject and content fields, an attacker can inject arbitrary auto-reply messages into victims' mailboxes. This capability facilitates phishing campaigns where attackers impersonate legitimate users to their contacts or disrupt normal business communications by flooding inboxes with misleading automated responses. Second, the vulnerability allows for denial-of-service conditions through error-based exploitation. By supplying malformed mbox values that trigger database integrity violations, specifically MultipleObjectsReturned errors, an attacker can cause the application to crash or return internal server errors when attempting to manage auto-replies for specific users. This not only degrades service availability but may also expose sensitive stack traces or configuration details in debug modes, further aiding reconnaissance efforts by potential adversaries.
The impact of this vulnerability extends beyond immediate functional disruption as it compromises the integrity and confidentiality of user communications within the Modoboa environment. Since auto-reply messages are often used for out-of-office notifications containing personal availability information or internal routing instructions, their manipulation can lead to significant social engineering risks. Furthermore, the ability to break auto-reply management via error injection undermines the reliability of the email system's automated features, potentially causing missed communications and operational inefficiencies for organizations relying on Modoboa for mail services. The lack of proper object-level authorization means that even users with minimal privileges can escalate their impact by targeting higher-privilege accounts or critical infrastructure components within the same instance.
Mitigation strategies must prioritize immediate patching to version 2.8.0 or later, where this access control flaw has been addressed through rigorous input validation and ownership verification. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls can be configured to monitor for anomalous patterns in POST requests to the /api/v2/armessages/ endpoint, particularly those involving rapid changes in mbox values or repeated error responses. Additionally, implementing strict server-side checks that cross-reference the authenticated user's ID with the mailbox owner ID before processing any modification request is essential to prevent exploitation. Developers should also ensure that API endpoints enforce principle of least privilege by validating resource ownership at every step of data manipulation, thereby aligning security practices with industry standards for secure coding and preventing similar direct object reference vulnerabilities in future releases.