CVE-2026-47716: Broken Object Level Authorization in Bugsink Bulk Issue Actions

Bugsink serves as a self-hosted, Sentry-compatible error tracking server designed to centralize and manage application exceptions. The core interface organizes diagnostic errors into distinct projects to maintain administrative isolation between different software components. Access control rules are evaluated at the project level to restrict users to specific issue trackers.

The vulnerability is located within the issue list controller that processes bulk operations such as resolving, muting, or deleting issues. While standard read operations validate the user's project association via the URL path, the endpoint responsible for updating multiple issues fails to extend this project-level validation to the individual issue records specified in the request payload.

This architectural oversight introduces an Insecure Direct Object Reference (IDOR) flaw, classified under CWE-639. An authenticated attacker who possesses access to a single project can submit state-changing actions containing identifiers of issues belonging to projects for which they lack authorization.

The root cause of this vulnerability lies in the unconstrained database queries performed during bulk state modifications. In Bugsink, issues are modeled with a direct database relationship to their parent projects. When a user submits a bulk action POST request, the application relies on the _issue_list_pt_1 controller in issues/views.py to fetch and update the target records.

In vulnerable versions, the application parses a list of issue identifiers from the issue_ids[] POST parameter. The backend then constructs a Django Object-Relational Mapping (ORM) query using Issue.objects.filter(pk__in=issue_ids) to retrieve the target issue instances. This query is executed globally across the entire database without any conditional scoping to the parent project.

Although the parent routing controller validates the user's authorization against the project identifier parsed from the HTTP request path, it does not confirm that the retrieved issues belong to that specific project. The database layer executes the bulk modification on all matching primary keys, bypassing the logical boundary established at the application layer.

To understand the scope of the vulnerability, we analyze the implementation of the inner view function _issue_list_pt_1 in issues/views.py. The vulnerable iteration of this function extracts the client-supplied issue identifiers and queries the database globally.

# Vulnerable implementation in issues/views.py
def _issue_list_pt_1(request, project, state_filter="open"):
    if request.method == "POST":
        # Extracts the raw client-supplied array of issue UUIDs
        issue_ids = request.POST.getlist('issue_ids[]')
        
        # UNCONSTRAINED QUERY: No verification that these issues belong to 'project'
        issue_qs = Issue.objects.filter(pk__in=issue_ids)
        
        illegal_conditions = _q_for_invalid_for_action(request.POST["action"])
        # Bulk modification operations proceed on issue_qs

The patch introduces strict scoping by forcing the Django ORM to filter the queried issues by both the validated project context and the deletion status of the records. This ensures that even if an attacker injects unauthorized issue UUIDs, the database query filters them out during the lookup phase.

# Patched implementation in issues/views.py (v2.2.0)
def _issue_list_pt_1(request, project, state_filter="open"):
    if request.method == "POST":
        issue_ids = request.POST.getlist('issue_ids[]')
        
        # SCOPED QUERY: Added project constraint and is_deleted check
        issue_qs = Issue.objects.filter(project=project, is_deleted=False, pk__in=issue_ids)
        
        illegal_conditions = _q_for_invalid_for_action(request.POST["action"])
        # Bulk modification operations now apply only to validated issues

Additionally, the regression tests added in the patch confirm this behavior by instantiating two projects and validating that a bulk action target referencing the second project from the context of the first project does not execute. The test asserts that the foreign issue remains unresolved after the request.

Exploitation of this vulnerability requires the attacker to satisfy two principal conditions. First, the attacker must have a valid session and belong to at least one active project within the target Bugsink instance. Second, the attacker must obtain the 128-bit Universally Unique Identifier (UUID) of the target issue belonging to the unauthorized project.

Because UUIDv4 identifiers contain 122 bits of entropy, brute-force enumeration of issue IDs is computationally infeasible. An attacker must gather these identifiers through secondary channels, such as leaked application logs, collaborative chat notifications, webhook payloads, or shared diagnostic links.

Once a target UUID is acquired, the attacker intercepts a bulk action request targeting their authorized project. By replacing the values in the issue_ids[] array with the target cross-project UUID and transmitting the request, the attacker triggers the modification. The server returns a status code of 200, and the database status of the target issue is updated globally.

The primary security impact of this vulnerability is the unauthorized modification of resource metadata across logical tenant boundaries. An attacker can resolve, mute, or transition issues belonging to other projects, potentially leading to missed critical alerts and diagnostic blind spots for development teams.

The CVSS v3.1 base score is calculated as 3.1, indicating a low-severity threat. The score reflects high attack complexity due to the requirement of obtaining specific issue UUIDs, and low privileges required because the attacker must hold valid credentials to at least one project. The impact is limited strictly to integrity, as the vulnerability does not disclose confidential issue data or allow arbitrary code execution.

The Exploit Prediction Scoring System (EPSS) rating of 0.00029 aligns with the low probability of automated exploitation in the wild. This vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there are no public reports of weaponized exploits.

The definitive remediation is upgrading the Bugsink deployment to version 2.2.0 or later. This release ensures that all bulk operations evaluate database queries within the confines of the validated project context. Administrators can apply this update by upgrading the container image or updating the PyPI dependency.

If immediate patching is not possible, organizations should implement strict access control policies to minimize the exposure of issue UUIDs. Since exploitation requires knowing these identifiers, limiting the integration of Bugsink notifications into shared channels reduces the risk of credential leakage.

Additionally, implementing network-level access controls and monitoring application logs for anomalous POST requests can help detect unauthorized activity. Security teams should inspect logs for instances where users submit bulk modifications with ID counts that do not align with their typical activity patterns.