This is an IDOR in Laravel's DeleteNotificationController where the delete() method uses findOrFail($id) without any ownership validation. The lookup is unfiltered—you can delete any notification by any user by simply changing the ID. This is not a complex vulnerability; it's a straightforward authorization gap that's been overlooked.
What makes this analytically significant is the sibling controller in the same codebase: SetNotificationReadAjaxController correctly scopes its find() call with Auth::id(). The developers clearly knew how to write this properly. That they did it in one place but not the other suggests either a copy-paste from an earlier insecure template, or a code review that examined each controller in isolation without cross-referencing security patterns across similar endpoints.
Before patching, audit every other controller that uses findOrFail() or similar lookups without Auth::id() scoping. This codebase likely has more IDORs following the same pattern. The sequential ID architecture compounds the risk—you can script deletion of every notification across all users in an organization without needing valid IDs for specific users.
The CVSS 6.9 score is misleading. Combined with sequential enumeration and no deletion logging, this vulnerability enables silent bulk deletion of organizational communications. An attacker could destroy all notifications for every user over months without detection—that's a different severity than a single-object IDOR suggests.
Check your notification endpoints for ownership validation. Check whether deletes generate audit events. Check whether other object lookups in the codebase follow the same unsecured pattern. The fix for this specific controller is one line of ownership scoping; the broader exposure is whatever else follows this template.