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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: Medium
All four notification queries in
api/notifications.php(assign, comment, status-change, mention) are scoped purely bycreated_by/assigned_to/ticket_watchersmembership and audit_log contents — never bycanUserAccessTicket().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.