api/notifications.php: in-app notifications don't re-check current ticket visibility #48

New Issue

2026-08-31T21:36:17-04:00

jared commented

2026-08-31 21:36:17 -04:00

Severity: Medium

All four notification queries in api/notifications.php (assign, comment, status-change, mention) are scoped purely by created_by/assigned_to/ticket_watchers membership and audit_log contents — never by canUserAccessTicket().

Impact: If a ticket's visibility is later tightened to confidential, or a user's group/watcher access is revoked, a notification referencing that ticket's title and the event (e.g. a status-change delta) still surfaces in their bell dropdown. Clicking through is still blocked by the ticket view's own access check, but the notification itself already disclosed the ticket's title and that activity occurred, to someone who currently shouldn't have that visibility.

Fix: Re-check canUserAccessTicket() (or re-derive visibility) at notification-read time, not just trust the historical audit_log entry, and filter out notifications for tickets the user can no longer see.

**Severity:** Medium All four notification queries in `api/notifications.php` (assign, comment, status-change, mention) are scoped purely by `created_by`/`assigned_to`/`ticket_watchers` membership and audit_log contents — never by `canUserAccessTicket()`. **Impact:** If a ticket's visibility is later tightened to confidential, or a user's group/watcher access is revoked, a notification referencing that ticket's title and the event (e.g. a status-change delta) still surfaces in their bell dropdown. Clicking through is still blocked by the ticket view's own access check, but the notification itself already disclosed the ticket's title and that activity occurred, to someone who currently shouldn't have that visibility. **Fix:** Re-check `canUserAccessTicket()` (or re-derive visibility) at notification-read time, not just trust the historical audit_log entry, and filter out notifications for tickets the user can no longer see.