Bugsink
by Bugsink
Source repositories
CVEs (5)
| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-40162 | Hig | 0.46 | 7.1 | 0.00 | Apr 10, 2026 | Bugsink is a self-hosted error tracking tool. In 2.1.0, 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 vulnerability is fixed in 2.1.1. | |
| CVE-2025-64509 | Hig | 0.42 | 7.5 | 0.00 | Nov 10, 2025 | Bugsink is a self-hosted error tracking tool. In versions prior to 2.0.6, 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). The issue is patched in Bugsink 2.0.6. The vulnerability is similar to, but distinct from, another brotli-related problem in Bugsink, GHSA-fc2v-vcwj-269v/CVE-2025-64508. | |
| CVE-2025-54433 | Hig | 0.40 | — | 0.00 | Jul 30, 2025 | Bugsink is a self-hosted error tracking service. In versions 1.4.2 and below, 1.5.0 through 1.5.4, 1.6.0 through 1.6.3, and 1.7.0 through 1.7.3, 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, potentially exposing them. 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. This is fixed in versions 1.4.3, 1.5.5, 1.6.4 and 1.7.4. | |
| CVE-2026-44502 | med | 0.19 | — | — | May 8, 2026 | ## Summary 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 the HTTP client - this does not give arbitrary control over every possible request path In other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive. ## Technical Details The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post. For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public hostname during validation, while the HTTP client actually connects to a different host. ## Fix The fix has two parts: 1. Bugsink now normalizes webhook URLs using the same HTTP client stack that will later send them, and applies validation to that normalized form. 2. Bugsink now outright rejects raw webhook URLs containing characters outside the RFC URL character set, rather than relying on downstream normalization of malformed input. Together, these changes remove the parser discrepancy and make webhook URL handling stricter and more predictable. ## Workarounds If users cannot upgrade immediately: - restrict who can configure or modify webhook URLs - review existing webhook configurations for malformed or unusual URLs - prefer tightly controlled outbound network policy at the deployment level | |
| CVE-2026-27614 | 0.00 | — | 0.00 | Feb 25, 2026 | Bugsink is a self-hosted error tracking tool. In versions prior to 2.0.13, 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. 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. Successful exploitation requires that the attacker to be able to submit events to the project (i.e. knows the DSN or can access a client that uses it), the Bugsink ingest endpoint is reachable to the attacker, and an administrator explicitly views the crafted event in the UI. Under those conditions, the attacker can execute JavaScript in the administrator’s browser and act with that user’s privileges within Bugsink. Version 2.0.13 fixes the vulnerability. |
- risk 0.46cvss 7.1epss 0.00
Bugsink is a self-hosted error tracking tool. In 2.1.0, 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 vulnerability is fixed in 2.1.1.
- risk 0.42cvss 7.5epss 0.00
Bugsink is a self-hosted error tracking tool. In versions prior to 2.0.6, 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). The issue is patched in Bugsink 2.0.6. The vulnerability is similar to, but distinct from, another brotli-related problem in Bugsink, GHSA-fc2v-vcwj-269v/CVE-2025-64508.
- risk 0.40cvss —epss 0.00
Bugsink is a self-hosted error tracking service. In versions 1.4.2 and below, 1.5.0 through 1.5.4, 1.6.0 through 1.6.3, and 1.7.0 through 1.7.3, 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, potentially exposing them. 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. This is fixed in versions 1.4.3, 1.5.5, 1.6.4 and 1.7.4.
- risk 0.19cvss —epss —
## Summary 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 the HTTP client - this does not give arbitrary control over every possible request path In other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive. ## Technical Details The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post. For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public hostname during validation, while the HTTP client actually connects to a different host. ## Fix The fix has two parts: 1. Bugsink now normalizes webhook URLs using the same HTTP client stack that will later send them, and applies validation to that normalized form. 2. Bugsink now outright rejects raw webhook URLs containing characters outside the RFC URL character set, rather than relying on downstream normalization of malformed input. Together, these changes remove the parser discrepancy and make webhook URL handling stricter and more predictable. ## Workarounds If users cannot upgrade immediately: - restrict who can configure or modify webhook URLs - review existing webhook configurations for malformed or unusual URLs - prefer tightly controlled outbound network policy at the deployment level
- CVE-2026-27614Feb 25, 2026risk 0.00cvss —epss 0.00
Bugsink is a self-hosted error tracking tool. In versions prior to 2.0.13, 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. 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. Successful exploitation requires that the attacker to be able to submit events to the project (i.e. knows the DSN or can access a client that uses it), the Bugsink ingest endpoint is reachable to the attacker, and an administrator explicitly views the crafted event in the UI. Under those conditions, the attacker can execute JavaScript in the administrator’s browser and act with that user’s privileges within Bugsink. Version 2.0.13 fixes the vulnerability.