CVE-2024-45605

Executive Summary

CVE-2024-45605 is a missing authorization vulnerability in Sentry, a developer-first error tracking and performance monitoring platform. An authenticated attacker can delete user issue alert notifications for arbitrary users, provided they know the target alert ID. This allows a low-privileged user to disrupt monitoring capabilities for other users or teams by removing critical alert configurations. The vulnerability is patched in Sentry version 24.9.0. Self-hosted instances are at risk; Sentry SaaS users are already protected.

Supply Chain & Package Security

This vulnerability affects self-hosted Sentry deployments, which are typically managed via Docker images or Python packages. Organizations using Sentry as part of their internal toolchain should verify their deployment version and apply the patch immediately. The vulnerability does not directly impact the software supply chain of downstream projects, but it can degrade the monitoring and alerting infrastructure that those projects rely on.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low (alert deletion)
• Availability Impact: Low (alert deletion)

Threat Level: Medium. The vulnerability requires authentication and knowledge of a specific alert ID, but it can be exploited to delete alerts for any user, potentially causing significant operational disruption.

Deep Dive & Mechanics

The vulnerability resides in the API endpoint responsible for deleting user issue alert notifications. The endpoint fails to verify that the requesting user has authorization to delete the alert belonging to the target user. An attacker can enumerate or guess alert IDs and then send a DELETE request to remove those alerts.

Root Cause: Missing authorization check in the delete action of the user alert notification controller. The code only checks if the user is authenticated, not if they own the alert or have permission to modify it.

Attack Flow:

1. Attacker authenticates to Sentry (e.g., as a low-privileged user).
2. Attacker identifies or guesses a valid alert ID (e.g., via API enumeration or known patterns).
3. Attacker sends a DELETE request to /api/0/users/{user_id}/alert-notifications/{alert_id}/.
4. The server deletes the alert without verifying ownership.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-24.9.0):

# In the view or controller handling alert deletion
class UserAlertNotificationDeleteView(APIView):
    def delete(self, request, user_id, alert_id):
        # Missing authorization check
        alert = AlertNotification.objects.get(id=alert_id)
        alert.delete()
        return Response(status=204)

Patched Code (24.9.0+):

class UserAlertNotificationDeleteView(APIView):
    def delete(self, request, user_id, alert_id):
        # Authorization check added
        alert = AlertNotification.objects.get(id=alert_id, user_id=request.user.id)
        alert.delete()
        return Response(status=204)

The patch adds a filter to ensure the alert belongs to the requesting user (user_id=request.user.id), preventing deletion of other users' alerts.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Valid Sentry account (self-hosted instance)
• Knowledge of a target user's alert ID (can be obtained via API enumeration or social engineering)

Exploitation Steps:

1. Authenticate to Sentry and obtain a session token.
2. Enumerate alert IDs by observing patterns (e.g., sequential IDs) or using the API to list alerts for a known user.
3. Send a DELETE request to remove the target alert:

   curl -X DELETE \
     -H "Authorization: Bearer <token>" \
     "https://sentry.example.com/api/0/users/12345/alert-notifications/67890/"
   

4. Verify deletion by checking that the alert no longer appears in the target user's notification settings.

Note: No public exploit code is available for this CVE.

Blue Team

Detection:

• Monitor API logs for DELETE requests to /api/0/users/*/alert-notifications/*/ from users who do not own the target user ID.
• Alert on rapid deletion of multiple alerts across different users.

Hunting:

• Query logs for DELETE /api/0/users/*/alert-notifications/*/ and correlate with the requesting user's ID.
• Look for patterns where a single user deletes alerts for multiple different user IDs.

Indicators of Compromise (IOCs)

• Network: DELETE requests to /api/0/users/*/alert-notifications/*/ from unexpected users.
• Logs: User <id> deleted alert notification <id> for user <target_id> where id != target_id.
• System: Missing alert notifications for critical issues that were previously configured.

Detection Engineering

YARA Rule

rule sentry_alert_deletion_abuse {
    meta:
        description = "Detects unauthorized deletion of Sentry alert notifications"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-45605"
    strings:
        $s1 = "DELETE /api/0/users/" ascii wide
        $s2 = "/alert-notifications/" ascii wide
    condition:
        all of them
}

Sigma Rule

title: Sentry Alert Notification Deletion Abuse
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects unauthorized deletion of Sentry alert notifications (CVE-2024-45605)
author: Valters IT
date: 2024-10-27
logsource:
    category: webserver
    product: sentry
detection:
    selection:
        http.method: "DELETE"
        http.url|contains: "/api/0/users/"
        http.url|contains: "/alert-notifications/"
    condition: selection
falsepositives:
    - Legitimate deletion of own alerts
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-45605 - Sentry Alert Notification Deletion Abuse";
    flow:to_server,established;
    content:"DELETE"; http_method;
    content:"/api/0/users/"; http_uri;
    content:"/alert-notifications/"; http_uri;
    classtype:attempted-user;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade self-hosted Sentry to version 24.9.0 or higher.
2. If upgrade is not possible, restrict API access to the alert notification endpoints using a reverse proxy or WAF rules.
3. Monitor logs for suspicious DELETE requests to alert notification endpoints.

Long-term Measures:

• Implement strict authorization checks for all API endpoints.
• Use role-based access control (RBAC) to limit alert management to authorized users.
• Enable audit logging for all alert modification actions.

Workarounds: None officially provided. The only solution is to patch.

Valters IT signature: This report is provided for educational and defensive purposes only. Unauthorized exploitation of this vulnerability is illegal.