CVE-2026-47728: Multi-Tenant Isolation Bypass via Unscoped Debug ID Resolution in Bugsink

Bugsink is an open-source, self-hosted error tracking platform designed to be compatible with the Sentry protocol. It processes client-side crash events, including JavaScript exceptions and native minidumps, and maps obfuscated stack traces back to readable source code. To achieve this, the platform relies on uploaded metadata such as source maps and Debug Information Files (DIFs).

In multi-tenant or multi-project environments, different teams rely on Bugsink to maintain strict isolation between their respective projects. However, prior to version 2.2.0, the lookup mechanism for retrieving source maps and DIFs did not restrict queries to the project context of the event being processed. This missing logical boundary exposes sensitive source code and debugging metadata to unauthorized projects within the same instance.

The vulnerability is classified under CWE-862 (Missing Authorization). An attacker with low-privileged access to a single project on a shared Bugsink instance can exploit this behavior to resolve and read proprietary code layout and symbols belonging to other projects.

The primary root cause of CVE-2026-47728 resides in the database query logic within Bugsink's symbolication engine. When an error event is processed, Bugsink extracts the debug_id from the incoming stack trace to fetch the corresponding FileMetadata. In vulnerable versions, this query filtered solely on the debug_id and the file_type parameters, ignoring the project_id relationship.

Because the database search was globally scoped, any project could request symbolication for any arbitrary debug_id stored in the system. If a match was found, the system would retrieve the source map and apply it to the stack trace of the requesting project. This logic allows cross-project information leakage because ownership of the file is never verified during retrieval.

Additionally, a secondary bug in ingest/views.py exacerbated this issue during minidump processing. A positional argument mismatch in the invocation of process_minidump caused the project model instance to be mapped incorrectly to an HttpRequest object. When internal validation code attempted to access properties on this object, it returned None, forcing the application to default to the global, unscoped lookup mechanism.

The flaw and its remediation are evident when reviewing the changes introduced in commit a761c6d912ee39de137083d0b3b54abbc86bd826. Prior to this fix, the application queried FileMetadata objects without specifying a project attribute, as shown below:

# Vulnerable globally scoped query
metadata_obj_lookup = {
    metadata_obj.debug_id: metadata_obj
    for metadata_obj in FileMetadata.objects.filter(
        debug_id__in=debug_id_for_filename.values(), 
        file_type='source_map'
    ).select_related('file')
}

To address this, the database schema was modified to include an explicit foreign key relationship linking FileMetadata to a Project model instance. Unique constraints were also established at the database level to maintain consistency. The patched retrieval logic enforces project-specific scoping and implements a fallback query only for legacy, unscoped data:

def get_file_metadata_for_debug_ids(project, debug_ids, file_type):
    """Return {debug_id: FileMetadata} for debug files visible to project."""
    debug_ids = set(debug_ids)
    if not debug_ids:
        return {}
 
    # Restrict lookup strictly to the owning project
    result = {
        metadata.debug_id: metadata
        for metadata in FileMetadata.objects.filter(
            project=project,
            debug_id__in=debug_ids,
            file_type=file_type,
        ).select_related('file')
    }
    return result

Exploitation of CVE-2026-47728 requires an attacker to have valid access credentials or a DSN ingestion key for at least one project on the target Bugsink instance. This establishes the necessary 'Low Privilege' (PR:L) prerequisite. The attack does not require any administrative privileges or victim interaction.

An attacker first identifies the debug_id of the target project's build. Because modern frontend web applications distribute minified code alongside mapping headers, an attacker can extract these identifiers by analyzing public client-side assets or network requests of the victim's application. Once the target debug_id is acquired, the attacker constructs a synthetic error event.

This payload is sent to the ingestion endpoint corresponding to the attacker's own project. When Bugsink's symbolication engine processes the event, it resolves the victim's source map due to the missing boundary check. The symbolicated stack trace, containing original source filenames and code snippets, is then rendered directly within the attacker's project dashboard, leading to unauthorized information exposure.

The overall security impact of CVE-2026-47728 is assessed as Medium, with a CVSS v3.1 score of 4.3. The impact is restricted strictly to the confidentiality of stored assets (C:L), with no integrity (I:N) or availability (A:N) implications. The vulnerability does not permit remote code execution or arbitrary data modification.

Despite the moderate CVSS rating, the real-world impact in multi-tenant SaaS environments or enterprise deployments sharing a single server is significant. Source maps frequently expose sensitive internal IP addresses, environment variables, proprietary algorithms, and detailed structural designs of private software. The exposure of these assets significantly reduces the effort required for an attacker to identify secondary vulnerabilities within the primary application.

According to the First EPSS, the likelihood of active exploitation remains low at 0.00028. This is common for software components deployed primarily within private networks. However, organizations utilizing Bugsink for external client-side application monitoring should treat this as a high-priority update due to the public accessibility of client-side identifiers.

The definitive resolution for CVE-2026-47728 is upgrading the Bugsink deployment to version 2.2.0 or higher. The update modifies the database schema and introduces strict project boundary validation across all symbolication endpoints.

Because the software maintains backward compatibility with older, projectless files, legacy metadata remains vulnerable to global resolution even after the binary is upgraded. To address this risk, administrators must run the database cleanup routine to purge historical, unassociated mappings:

bugsink-manage delete_legacy_sourcemaps

Following the cleanup, development teams must re-upload their sourcemaps using updated clients that explicitly define the project owner during the upload process. The following command structure should be implemented in continuous integration pipelines to ensure proper scoping:

sentry-cli sourcemaps upload --project <target-project-slug> <build-output-directory>