Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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, it makes ingestion of other events wait until the transaction that writes the tags finishes, which effectively causes a temporary denial of service for other events. Impact Submitting such an event requires a valid project DSN. DSNs are sometimes visible in client-side applications, so they should not be treated as a strong security boundary, but the issue is still limited to ingestion for a Bugsink instance that accepts the event. The impact is availability-only. The issue does not expose stored data, modify existing events, or allow…
Recommended action: Upgrade to 2.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact This could disclose source context or symbolication-derived context from another project on the same Bugsink instance. For sourcemaps, the documented upload flow used sentry-cli sourcemaps upload with --project=ignoredfornow. In other words, Bugsink did not historically treat the project value supplied during sourcemap upload as meaningful project ownership. This was documented, but at the same time the sentry-cli, which requires project as a parameter, was the recommended mechanism for uploads. This could reasonably lead people to expect that sourcemaps uploads would respect the provided…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 another project. However, the issue is mitigated by two factors. First, the attacker needs to already know a valid target issue UUID; there is no issue enumeration path here, and guessing UUIDs is not practical. Second, Bugsink is commonly self-hosted within a single trust domain, and Hosted Bugsink gives each tenant a separate Bugsink instance, so cross-project access does not normally imply cross-tenant access. This has been fixed by requiring bulk issue actions to operate only on issues belonging to the authorized project. Impact…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 attacker needs to already know a valid target event UUID; there is no event enumeration path here, and guessing UUIDs is not practical. Second, Bugsink is commonly self-hosted within a single trust domain, and Hosted Bugsink gives each tenant a separate Bugsink instance, so cross-project access does not normally imply cross-tenant access. The affected views include the stacktrace, details, and breadcrumbs pages for an issue event. This has been fixed by requiring direct event lookups to match both the authorized issue and the project. Impact Low-severity…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact This issue affects Bugsink’s outbound webhook integrations. An attacker who can supply or influence a webhook URL may be able to make Bugsink send an outbound HTTP POST request to a host that should have been blocked by the webhook validation logic, including loopback, private, or otherwise non-allowlisted destinations. The practical impact is limited: - this is an outbound webhook SSRF issue, not a general-purpose proxy - Bugsink does not follow redirects for these webhook requests - the request shape is constrained by how the malformed URL is normalized by…
Recommended action: Upgrade to 2.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authenticated arbitrary file write in artifact bundle assembly Summary 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. Impact This vulnerability allows an authenticated user to create or overwrite files within locations writable by the Bugsink service account. The practical impact depends on the deployment environment and filesystem permissions of the running process. Possible consequences include: modification of application data files corruption of uploaded assets or temporary files overwriting files in mounted writable volumes disruption of normal application behavior No unauthenticated exploitation is known. No direct code execution has been demonstrated as part…
Recommended action: Upgrade to 2.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When Pygments returns more lines than it was given (a known upstream quirk that triggers with Ruby heredoc-style input), `_pygmentize_lines()` in `theme/templatetags/issues.py:75-77` falls back to returning the raw input lines. `mark_safe()` at line 111-113 is then applied unconditionally - including to those unsanitized raw lines. Since DSN endpoints are public by Sentry protocol, no account is needed to inject. The payload sits in the database until an admin looks at the event. ```python issues.py:75-77 - fallback path, no escaping if len(pygmented) != len(lines): return lines raw HTML returned here issues.py:111-113 - unconditional mark_safe return [mark_safe(line) for line in result] ``` Operational Signals Exploitation attempts are likely to…
Recommended action: Upgrade to 2.0.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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). Patches Patched in Bugsink 2.0.6 References The vulnerability in this security advisory is similar to, but distinct from, another brotli-related problem in Bugsink: https://github.com/bugsink/bugsink/security/advisories/GHSA-fc2v-vcwj-269v
Recommended action: Upgrade to 2.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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). Patches Patched in Bugsink 2.0.5
Recommended action: Upgrade to 2.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, ingestion paths construct file locations directly from untrusted eventid input without validation. A specially crafted eventid 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. Impact A valid DSN holder can craft an eventid that causes the ingestion process to write files outside its designated directory. This allows overwriting files accessible to the user running Bugsink. If Bugsink runs in a container, the effect is confined to the container’s filesystem. In non-containerized setups, the overwrite may affect other parts of the system accessible to that user. Mitigation Update to version 1.7.4, 1.6.4, 1.5.5 or 1.4.3 , which require eventid to be a valid UUID and…
Recommended action: Upgrade to 1.7.4, 1.6.4, 1.5.5 or 1.4.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.