KamoCRM

A member's mailboxes and aliases are only readable inside their own organization

FixEmailService
Shipped
September 23, 2026 at 7:49 AM UTC
Author
Kamo
Commit
0893174

GET **************** took no HttpServletRequest at all — no session, no org check anywhere on the path — and GET **************** checked that the CALLER had a session but passed only the target memberId to AliasService, never the caller's own org. Either way, any authenticated member of any organization could enumerate any other organization's mailbox assignments or aliases simply by walking member ids. **************** now takes the caller's orgId and filters mailboxes by it, the same way **************** already filters the equivalent lookup for the logged-in member; **************** now runs the org-scoped repository query (findByMemberIdAndOrgId) the compose picker already uses instead of the unscoped findByMemberId. A member id outside the caller's org now simply matches nothing, exactly like one with no mailboxes/aliases at all, rather than answering with another tenant's data. Deliberately not also gated behind a right: kamo-internal's one caller **************** sits behind a page-level ACCESS_MAIL check, not **************** and narrowing the server past what that screen actually requires risked breaking it for the many roles that hold ACCESS_MAIL without the narrower right — a product decision this fix does not make. **************** **************** and AliasControllerMemberScopeTest fail without the change — a member id in another organization currently returns that organization's real rows instead of an empty list.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing