Bugsink before 2.2.0 resolved sourcemaps and debug files by debug ID without scoping that lookup to the project that owned the uploaded metadata. An authenticated user with access to one project could cause event processing in that project to use sourcemap/debug-file metadata uploaded for another project in the same Bugsink instance, if the same debug ID was referenced.
Bugsink issue event pages accept a direct event identifier from the URL and, in affected versions, look up that event without also requiring it to belong to the issue in the URL. This is a project-boundary authorization issue: a logged-in user with access to one project can view another project’s event data through an issue they are allowed to access. However, the issue is mitigated by two factors. First, the …
Bugsink’s issue list supports bulk actions such as resolving or muting selected issues. In affected versions, the issue list view authorizes access through the project in the URL, but applies the requested bulk action to the submitted issue IDs without also requiring those issues to belong to that project. This is a project-boundary authorization issue: a logged-in user with access to one project can change the state of an issue …
In affected versions, Bugsink stores every tag supplied with an incoming event. An event with an unusually large number of custom (i.e. supplied by an attacker) tags can therefore make ingestion spend more time than intended writing tag rows. Bugsink uses a single-writer database architecture. That keeps the implementation simple, but it also means one expensive write transaction can delay other event digestion while it is running. In this case, …
Bugsink’s webhook URL validation in versions 2.1.2 and earlier could be (partially) bypassed because of a mismatch in URL parsing. In some malformed URLs, Python’s standard URL parser (urllib) and the HTTP client stack (requests / urllib3) do not agree on which host is actually being targeted. That could allow a webhook URL to pass Bugsink’s outbound-host checks while the actual HTTP request is sent somewhere else.
An authenticated file write vulnerability was identified in Bugsink 2.1.0 in the artifact bundle assembly flow. A user with a valid authentication token could cause the application to write attacker-controlled content to a filesystem location writable by the Bugsink process. This issue requires authentication and affects only version 2.1.0. The issue is fixed in 2.1.1.
An unauthenticated attacker who can submit events to a Bugsink project can store arbitrary JavaScript in an event. The payload executes only if a user explicitly views the affected Stacktrace in the web UI.
In affected versions, a specially crafted Brotli-compressed envelope can cause Bugsink to spend excessive CPU time in decompression, leading to denial of service. This can be done if the DSN is known, which it is in many common setups (JavaScript, Mobile Apps).
In affected versions, brotli "bombs" (highly compressed brotli streams, such as many zeros) can be sent to the server. Since the server will attempt to decompress these streams before applying various maximums, this can lead to exhaustion of the available memory and thus a Denial of Service. This can be done if the DSN is known, which it is in many common setups (JavaScript, Mobile Apps).
In affected versions, ingestion paths construct file locations directly from untrusted event_id input without validation. A specially crafted event_id can result in paths outside the intended directory, potentially allowing file overwrite or creation in arbitrary locations. Submitting such input requires access to a valid DSN. While that limits exposure, DSNs are sometimes discoverable—for example, when included in frontend code—and should not be treated as a strong security boundary.