Summary
MailWatch for MailScanner does not verify message ownership when an authenticated user performs quarantine actions. A user with a valid session and CSRF token may supply another message identifier to release quarantined mail to its inbox or permanently delete it.
MailWatch for MailScanner does not verify message ownership when an authenticated user performs quarantine actions. A user with a valid session and CSRF token may supply another message identifier to release quarantined mail to its inbox or permanently delete it.
Affected context
The issue occurs in MailWatch quarantine actions when the application accepts a message identifier and retrieves the corresponding quarantine record without applying the role-specific filtering used by listing and viewing interfaces. It affects deployments where authenticated users have access to quarantine action endpoints and message identifiers can be discovered or enumerated.
The issue occurs in MailWatch quarantine actions when the application accepts a message identifier and retrieves the corresponding quarantine record without applying the role-specific filtering used by listing and viewing interfaces. It affects deployments where authenticated users have access to quarantine action endpoints and message identifiers can be discovered or enumerated.
Exploit preconditions
- Attack surface: The authenticated quarantine action endpoint.
- Required access: A valid MailWatch account with a role permitted to use
quarantine actions, such as a user, domain administrator, or host role.
- Trigger point: A release or delete request submitted to
mailscanner/quarantine_action.php.
- Additional requirement: A valid CSRF token from the attacker's own
authenticated session.
- Why exploitation is possible: The requested message identifier is used
to select a quarantine record, but the application does not enforce
ownership or the caller's role-based global_filter for the action.
- Attack surface: The authenticated quarantine action endpoint.
- Required access: A valid MailWatch account with a role permitted to use
quarantine actions, such as a user, domain administrator, or host role.
- Trigger point: A release or delete request submitted to
mailscanner/quarantine_action.php.
- Additional requirement: A valid CSRF token from the attacker's own
authenticated session.
- Why exploitation is possible: The requested message identifier is used
to select a quarantine record, but the application does not enforce
ownership or the caller's role-based global_filter for the action.
Why this happens
The underlying bug is an object-level authorization failure. The application treats a client-supplied message identifier as sufficient authority to act on a quarantine record, while omitting the per-user, domain, or host ownership checks applied by other views. This maps primarily to CWE-566, Authorization Bypass Through User-Controlled Key, and is also related to CWE-639, typically described as authorization bypass through a user-controlled identifier.
The underlying bug is an object-level authorization failure. The application treats a client-supplied message identifier as sufficient authority to act on a quarantine record, while omitting the per-user, domain, or host ownership checks applied by other views. This maps primarily to CWE-566, Authorization Bypass Through User-Controlled Key, and is also related to CWE-639, typically described as authorization bypass through a user-controlled identifier.
Potential impact
- An authenticated low-privilege user may release another user's quarantined mail.
- An attacker could permanently delete messages belonging to other users or domains.
- Forced delivery of malicious, fraudulent, or otherwise unwanted email could occur.
- Quarantine-based administrative and compliance controls may be weakened.
- Mail handling records and user trust could be affected.
- An authenticated low-privilege user may release another user's quarantined mail.
- An attacker could permanently delete messages belonging to other users or domains.
- Forced delivery of malicious, fraudulent, or otherwise unwanted email could occur.
- Quarantine-based administrative and compliance controls may be weakened.
- Mail handling records and user trust could be affected.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the action boundary,
rather than relying on filtering performed by listing or read views.
Common defensive patterns include:
- Resolve the requested quarantine record and verify ownership, domain scope,
host scope, and role permissions before every release or deletion operation.
- Apply server-side authorization policies consistently to both read and
state-changing endpoints.
- Avoid treating user-controlled identifiers as proof of access; use opaque
references where appropriate and still perform authorization checks.
- Enforce least privilege for quarantine actions and separate release and
deletion permissions when operationally appropriate.
- Preserve CSRF protections, while recognizing that CSRF validation does not
replace object-level authorization.
- Record and monitor sensitive quarantine actions for unexpected cross-account
access patterns.
Mitigation generally focuses on enforcing authorization at the action boundary,
rather than relying on filtering performed by listing or read views.
Common defensive patterns include:
- Resolve the requested quarantine record and verify ownership, domain scope,
host scope, and role permissions before every release or deletion operation.
- Apply server-side authorization policies consistently to both read and
state-changing endpoints.
- Avoid treating user-controlled identifiers as proof of access; use opaque
references where appropriate and still perform authorization checks.
- Enforce least privilege for quarantine actions and separate release and
deletion permissions when operationally appropriate.
- Preserve CSRF protections, while recognizing that CSRF validation does not
replace object-level authorization.
- Record and monitor sensitive quarantine actions for unexpected cross-account
access patterns.
How teams detect issues like this
Detection approaches may include:
- Static analysis and code review rules that flag database lookups by
user-controlled identifiers before authorization checks.
- Reviewing every quarantine mutation path for explicit ownership, tenant,
domain, and role validation.
- Comparing authorization logic between listing, viewing, release, and delete
endpoints to identify inconsistent filtering.
- Dynamic tests that attempt actions against records outside the authenticated
user's permitted scope using valid sessions and CSRF tokens.
- Policy enforcement requiring centralized authorization checks for object-level
operations.
Automated code review and application security testing tools may help identify
missing authorization checks, but business-scope tests remain important.
Detection approaches may include:
- Static analysis and code review rules that flag database lookups by
user-controlled identifiers before authorization checks.
- Reviewing every quarantine mutation path for explicit ownership, tenant,
domain, and role validation.
- Comparing authorization logic between listing, viewing, release, and delete
endpoints to identify inconsistent filtering.
- Dynamic tests that attempt actions against records outside the authenticated
user's permitted scope using valid sessions and CSRF tokens.
- Policy enforcement requiring centralized authorization checks for object-level
operations.
Automated code review and application security testing tools may help identify
missing authorization checks, but business-scope tests remain important.
