Security vulnerabilities

Description After a user's mailbox permissions are revoked, the application correctly removes access to the mailbox through the user interface. However, the server still allows the user to directly access previously generated mailbox audit logs by requesting the log endpoint with the corresponding log ID.

This indicates that the application does not enforce authorization checks on the audit log resource based on the user's current permissions. As a result, a user whose mailbox access has been revoked can continue to access historical audit logs related to that mailbox.
CVSS v3.1 → Score: 4.3 (Medium)

Note: If the audit logs expose sensitive mailbox configuration or confidential information, the severity may be higher.

Steps to Reproduce 1- Login with User A.
2- Invite User B as an Administrator with mailbox management permissions.
3- Login as User B.
4- Navigate to the mailbox settings and make any configuration change.
5- Verify that an audit log entry is created for the action.
6- Login as User A and revoke User B's mailbox permissions.
7- Confirm that the mailbox section is no longer accessible through the UI for User B.
8- Login again as User B.
9- Intercept the request used to retrieve an audit log (or directly access the audit log endpoint).
10- Replace the current log ID with the previously generated mailbox audit log ID.
11- Send the request.

Actual Behaviour → Even after mailbox permissions have been revoked, the server returns the historical mailbox audit log when the user directly requests it using the known log ID.

Expected Behaviour → Once mailbox permissions are revoked, the server should validate the user's current authorization before returning any mailbox-related audit logs. Unauthorized users should receive 403 Forbidden (or an equivalent authorization error).

Impact → Users can continue accessing mailbox-related audit logs after losing mailbox permissions.
→ Authorization is enforced only in the UI, not on the backend resource.
→ Historical mailbox activity remains accessible despite permission revocation.

Business Impact → Violates the principle of least privilege.
→ Former administrators or users with revoked access may continue viewing historical mailbox activity.
→ May expose operational or sensitive mailbox information depending on the audit log contents.
→ Indicates inconsistent server-side authorization checks, increasing the risk of similar access control issues elsewhere in the application.

Remediation → Perform server-side authorization checks for every audit log request.
→ Validate the user's current permissions before returning mailbox-related logs.
→ Return 403 Forbidden when the user is no longer authorized.
→ Ensure audit log access follows the same permission model as the underlying mailbox resource.
Proof of Concept (PoC) Google Drive Link: https://drive.google.com/drive/folders/1c3fthnH3Vfq60bd4RacM3_aHF8zgmw88?usp=drive_link

Conclusion The application fails to properly enforce server-side authorization on mailbox audit log resources. Although mailbox access is removed from the user interface after permission revocation, previously generated audit logs remain accessible through direct requests using known log IDs. This represents a Broken Access Control issue because authorization is not consistently enforced on the backend.

Thanks