Summary

Fixes an IDOR vulnerability in NotificationResource where the Update endpoint fetched notifications by ID using an unscoped query, allowing any authenticated user to read the contents of any other user's notification by guessing its sequential ID.

• The Index (listing) endpoint was correctly scoped via NotificationRepository — this is not affected
• The Update path falls through to AbstractDatabaseResource::find(), which uses an unscoped Eloquent query — this is the affected path
• The write side (marking as read) was separately protected by ownership enforcement in ReadNotificationHandler; the exposure was read-only

Fix: override scope() in NotificationResource to filter all queries by user_id = actor->id, ensuring any lookup returns 404 for notifications belonging to other users.

Introduced in: #3971 (the JSON:API rewrite). This did not exist in 1.x — the old UpdateNotificationController exclusively dispatched ReadNotificationHandler, which always enforced ownership. The new architecture separates the fetch from the action, and the fetch was left unscoped.

Tests

Five tests added/extended across UpdateTest and ListTest:

• user_cannot_read_another_users_notification — core IDOR: empty PATCH by another user returns 404
• user_cannot_mark_another_users_notification_as_read — PATCH with isRead: true returns 404 and leaves read_at unchanged
• admin_cannot_read_another_users_notification — admins are equally scoped; notifications are personal
• listing_only_returns_own_notifications — confirms the listing endpoint is not affected
• guest_cannot_update_notification — unauthenticated requests are rejected

The two IDOR tests fail against the unfixed code (returning 200) and pass after the fix.

Credit

Reported by Lakshmikanthan K (@l3tchupkt) via responsible disclosure. Thanks for the thorough and accurate report.

Changelog

Fixed: Authenticated users could read notification contents belonging to other users via the PATCH /api/notifications/{id} endpoint (IDOR). Reported by Lakshmikanthan K.