CVE-2026-27614: Bugsink Error Tracking XSS Vulnerability

CVE-2026-27614 Overview

CVE-2026-27614 is a stored Cross-Site Scripting (XSS) vulnerability affecting Bugsink, 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.

The vulnerability stems from improper output sanitization in the Pygments syntax highlighting fallback code path. When Pygments returns more lines than expected (a known upstream quirk triggered with Ruby heredoc-style input), the _pygmentize_lines() function in theme/templatetags/issues.py falls back to returning raw input lines. The mark_safe() function is then applied unconditionally—including to those unsanitized raw lines—allowing JavaScript injection.

Critical Impact

Unauthenticated attackers can inject malicious JavaScript that executes in administrator browsers, potentially compromising the entire Bugsink installation and all tracked error data.

Affected Products

• Bugsink versions prior to 2.0.13
• Self-hosted Bugsink installations with publicly accessible DSN endpoints
• Any Bugsink deployment following standard Sentry protocol configuration

Discovery Timeline

• 2026-02-25 - CVE CVE-2026-27614 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27614

Vulnerability Analysis

This stored XSS vulnerability exploits a gap in Bugsink's Pygments syntax highlighting integration. The root issue lies in how the application handles edge cases where Pygments returns a different number of lines than provided as input. This mismatch occurs specifically with certain Ruby heredoc-style input patterns, triggering a fallback code path that bypasses sanitization.

The vulnerability is particularly dangerous because DSN (Data Source Name) endpoints are public by design under the Sentry protocol, meaning no authentication is required to submit events. An attacker only needs to know or discover a project's DSN to inject malicious payloads. Once injected, the malicious JavaScript persists in the database and waits for an administrator to view the crafted event, at which point it executes with the administrator's privileges within Bugsink.

Root Cause

The root cause is the unconditional application of Django's mark_safe() function to output lines in theme/templatetags/issues.py. When the Pygments library returns an unexpected line count (a documented upstream behavior), the fallback path returns raw, unsanitized input directly. Since mark_safe() is applied regardless of whether the content was sanitized by Pygments or returned raw, attacker-controlled JavaScript passes through to the rendered HTML without escaping.

Attack Vector

The attack follows a stored XSS pattern requiring the following conditions:

1. Event Submission Access: The attacker must know the DSN or have access to a client using it
2. Network Reachability: The Bugsink ingest endpoint must be accessible to the attacker
3. User Interaction: An administrator must explicitly view the crafted event in the UI

The attacker crafts an error event containing Ruby heredoc-style code that triggers the Pygments line count mismatch. Embedded within this code is malicious JavaScript. When an administrator views the stacktrace, the unsanitized payload executes in their browser context, enabling session hijacking, privilege abuse, or data exfiltration.

# Security patch from theme/templatetags/issues.py
# Source: https://github.com/bugsink/bugsink/commit/e784d6aeb0d5f29b40c2779d2544c2b9ef097ee9

     result = _core_pygments(code, filename=filename, platform=platform).split('\n')[:-1]
     if len(lines) != len(result):
         capture_stacktrace("Pygments line count mismatch, falling back to unformatted code")
-        result = lines
+        result = [escape(l) for l in lines]

     return result

The fix applies escape() to each line in the fallback path, ensuring that even when Pygments fails to process the input correctly, any HTML special characters are properly escaped before rendering.

Detection Methods for CVE-2026-27614

Indicators of Compromise

• Unusual event submissions containing HTML tags or JavaScript syntax in stacktrace data
• Events with Ruby heredoc patterns (<<-, <<~) combined with script tags or event handlers
• Ingest endpoint access from unexpected IP addresses or without associated application errors
• Browser developer console errors indicating blocked inline scripts (if CSP is configured)

Detection Strategies

• Monitor Bugsink event ingestion logs for submissions containing <script>, onerror=, onload=, or similar HTML injection patterns
• Implement Web Application Firewall (WAF) rules to detect XSS payloads in event submission requests
• Review database entries in the events table for suspicious JavaScript or HTML content in stacktrace fields
• Deploy Content Security Policy (CSP) headers to detect and block inline script execution attempts

Monitoring Recommendations

• Enable verbose logging on the Bugsink ingest endpoint to capture full request bodies
• Set up alerts for high-volume event submissions from single sources that may indicate injection attempts
• Periodically audit stored events for suspicious content patterns
• Monitor administrator session activity for anomalous behavior following event viewing

How to Mitigate CVE-2026-27614

Immediate Actions Required

• Upgrade Bugsink to version 2.0.13 or later immediately
• Review recently submitted events for potential XSS payloads before viewing in the UI
• Rotate DSN keys if unauthorized access is suspected
• Implement Content Security Policy headers to mitigate XSS impact as a defense-in-depth measure

Patch Information

The vulnerability is fixed in Bugsink version 2.0.13. The patch modifies theme/templatetags/issues.py to properly escape raw input lines when the Pygments fallback path is triggered.

• Security Advisory: GitHub Security Advisory GHSA-vp6q-7m36-pq3w
• Patch Commit: Commit e784d6aeb0d5f29b40c2779d2544c2b9ef097ee9
• Release: Bugsink 2.0.13

Workarounds

• Restrict network access to the Bugsink ingest endpoint to trusted application servers only
• Implement IP allowlisting for DSN endpoints if public exposure is not required
• Deploy a reverse proxy with XSS filtering capabilities in front of Bugsink
• Avoid viewing stacktraces from untrusted or unexpected event sources until patched

# Configuration example - Restrict ingest endpoint access via nginx
# Add to nginx server block for Bugsink

location /api/ingest/ {
    # Allow only trusted application servers
    allow 10.0.1.0/24;
    allow 192.168.1.100;
    deny all;
    
    proxy_pass http://bugsink_upstream;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

# Optional: Add CSP headers for XSS mitigation
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;