Summary
lamp-cloud contains an authorization bypass in the deleteMyNotice endpoint, allowing an authenticated user to delete notifications belonging to other users. The issue becomes risky when the endpoint accepts a notification identifier without verifying that the requesting user is the intended recipient.
Affected context
The vulnerability occurs in deployments of lamp-cloud where the notification deletion endpoint is accessible to authenticated users and relies on a client-supplied notice ID. The affected behavior is present when the application does not enforce ownership or recipient checks before permanently deleting a notification.
Exploit preconditions
- Attack surface: The authenticated HTTP DELETE notification endpoint
- Required access: A valid authenticated user account
- Trigger point: Processing a deletion request for a supplied notice identifier
- Why exploitation is possible: The server may authorize the deletion request without confirming that the referenced notification belongs to the requesting user
Why this happens
The underlying flaw is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The endpoint appears to trust a user-controlled notification identifier as sufficient authority to perform deletion, rather than enforcing a server-side relationship between the authenticated principal and the target notification.
Potential impact
- Unauthorized users may delete notifications belonging to other recipients
- Important user communications could be permanently removed
- Notification availability and data integrity may be reduced
- Repeated abuse could disrupt workflows that depend on in-app notices
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the data-access layer for every object-level operation.
Common defensive patterns include:
- Verify that the authenticated user is the notification recipient or an explicitly authorized administrator
- Apply ownership checks within the deletion query or service method, rather than only in client-side logic
- Avoid treating user-supplied object identifiers as proof of authorization
- Use deny-by-default authorization policies and separate administrative permissions
- Return consistent responses that do not disclose whether unauthorized identifiers exist
- Preserve audit records for sensitive deletion operations where appropriate
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis and code review checks for direct object access using request-supplied identifiers
- Review of delete, update, and read endpoints for missing ownership predicates
- Authorization tests that compare access to owned, unowned, and nonexistent notification IDs
- API policy enforcement requiring object-level authorization for authenticated operations
- Monitoring for repeated deletion requests involving objects outside the caller's normal ownership scope
