CVE-2026-85749 in MailWatch
Summary
by MITRE • 10/28/2026
MailWatch for MailScanner is a web-based front-end to MailScanner. Prior to 1.2.27, any authenticated MailWatch user, including the U/user, D/domain-admin, and H/host roles, can release to inbox or permanently delete the quarantined mail of any other user or domain by supplying an arbitrary message `id` to `mailscanner/quarantine_action.php`. The action path calls `quarantine_list_items()` in `mailscanner/functions.php`, which selects from `maillog` by the supplied identifier without the per-role `global_filter` applied by listing and read views. The action requires a valid session and CSRF token, but the caller can submit a token from the caller's own session; ownership of the requested message is never checked. Message identifiers are enumerable, allowing a low-privilege user to invoke `quarantine_release()` or `quarantine_delete()` for other users' or domains' quarantined messages, force-delivering mail held by the quarantine or permanently deleting it. This issue is fixed in version 1.2.27.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in MailWatch for MailScanner prior to version 1.2.27 represents a critical Insecure Direct Object Reference (IDOR) flaw that allows authenticated users to manipulate quarantined email messages belonging to other users or domains. MailWatch serves as the web-based administrative interface for MailScanner, handling tasks such as viewing and managing emails held in quarantine due to security policies like spam or virus detection. The core technical failure lies within the `quarantine_action.php` script, which processes actions such as releasing a message to an inbox or permanently deleting it from quarantine. While this endpoint requires authentication via a valid session and includes protection against Cross-Site Request Forgery through CSRF tokens, it fails to enforce proper authorization checks regarding resource ownership. Specifically, when the action path invokes `quarantine_list_items()` in `mailscanner/functions.php`, the system queries the database using an arbitrary message identifier supplied by the user without applying the necessary per-role global filters that are present in listing and read views. This discrepancy means that while a low-privilege user can view only their own or their domain's quarantined items, they can directly interact with any item if they know its unique identifier.
The operational impact of this vulnerability is severe because it undermines the integrity and confidentiality of email communications managed by MailScanner. Message identifiers in the underlying database are typically sequential or easily enumerable, allowing an attacker to iterate through potential IDs until a valid message belonging to another user or domain is found. Once identified, the attacker can force-deliver mail that was intended to be blocked, potentially bypassing security controls such as anti-spam filters or malware detection systems. Alternatively, the attacker can permanently delete quarantined messages, which may result in data loss for legitimate users who rely on quarantine recovery features. This capability effectively grants low-privilege accounts administrative-level control over email handling functions reserved for higher-privileged roles like domain administrators or host admins. The existence of valid session and CSRF tokens does not mitigate this risk because the application logic trusts any token presented by an authenticated user, regardless of whether that token belongs to the owner of the target message.
From a classification perspective, this vulnerability aligns with CWE-284: Improper Access Control, specifically reflecting issues related to insufficient verification of object ownership before performing state-changing operations. It also maps to MITRE ATT&CK technique T1078: Valid Accounts, where an attacker leverages legitimate credentials to perform unauthorized actions within the application environment. The flaw highlights a common architectural weakness in web applications that separate read and write logic without maintaining consistent security contexts across both paths. To mitigate this issue, developers must ensure that all database queries involving sensitive resources apply appropriate access control filters regardless of whether they are part of a listing view or an action handler. Implementing strict ownership verification checks before executing `quarantine_release()` or `quarantine_delete()` functions is essential to prevent unauthorized manipulation of quarantined items. Organizations using MailWatch should upgrade immediately to version 1.2.27 or later, where these authorization gaps have been addressed by enforcing role-based access controls consistently across all quarantine management endpoints.