CVE-2026-52794: Sentry ReDoS Vulnerability in Event Ingestion (CVSS 7.5)
Sentry, a widely-used error tracking and performance monitoring platform, contains a flaw in how it processes incoming event data. Attackers can craft malicious events with specially formatted fields that cause Sentry's regex pattern matching to consume excessive CPU resources, potentially overwhelming the service. This denial-of-service impact affects Sentry instances running versions 24.4.0 through 26.5.1. The vulnerability has been patched in version 26.5.2.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-1333
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-24 / 2026-06-27
NVD description (verbatim)
Sentry is an error tracking and performance monitoring tool. From 24.4.0 until 26.5.2, a Regular Expression Denial of Service (ReDoS) vulnerability exists in Sentry's event ingestion pipeline, where a regex applied to attacker-controlled fields on incoming events can be made to consume disproportionate CPU time. This vulnerability is fixed in 26.5.2.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-52794 is a Regular Expression Denial of Service (ReDoS) vulnerability in Sentry's event ingestion pipeline. The vulnerability stems from a regex pattern applied to attacker-controlled input fields within incoming events. Maliciously crafted regex patterns can trigger catastrophic backtracking, causing the regex engine to spend disproportionate computational time on pattern matching. This occurs during event processing before persistence, meaning attackers need only send a single malformed event to trigger CPU exhaustion on the Sentry instance. The issue affects all versions from 24.4.0 up to and including 26.5.1, resolved in 26.5.2.
Business impact
A successful attack disrupts error tracking and performance monitoring capabilities across dependent applications. Organizations relying on Sentry for observability lose real-time visibility into application health, errors, and performance metrics during the attack window. If a Sentry instance is shared across multiple internal teams or used by multiple customer-facing products, a single ReDoS attack can degrade service for all consumers. For SaaS customers, this may also impact Sentry's availability guarantees and SLA compliance.
Affected systems
Sentry versions 24.4.0 through 26.5.1 are affected. This includes self-hosted Sentry deployments and Sentry Cloud instances running vulnerable versions. Any organization ingesting events into an unpatched Sentry instance is at risk. The vulnerability does not require authentication or special privileges; any external or internal entity capable of sending events to the Sentry ingestion endpoint can trigger it.
Exploitability
The attack surface is broad: any event sent to a Sentry ingestion endpoint can serve as the attack vector. No authentication is required (unless Sentry's auth settings are explicitly enforced). Crafting a malicious event requires minimal knowledge—an attacker need only understand the structure of event payloads and how to design a regex pattern that triggers backtracking in the regex engine used by Sentry. The attack is repeatable and can be launched remotely over the network. This is a low-complexity, high-impact denial-of-service vector.
Remediation
Organizations must upgrade Sentry to version 26.5.2 or later. For self-hosted deployments, this involves updating the Sentry application code and redeploying. For Sentry Cloud customers, upgrades are typically handled automatically, but customers should verify they are on a patched version. No workaround is available short of blocking event ingestion or implementing upstream request validation to reject suspicious payloads before they reach Sentry.
Patch guidance
Verify against the official Sentry security advisory and release notes that your deployment is running 26.5.2 or newer. Self-hosted users should consult the Sentry upgrade documentation for their deployment method (Docker, Kubernetes, bare metal, etc.). Sentry Cloud customers should confirm patch status through the Sentry dashboard or support channels. Test the upgrade in a non-production environment first, and schedule production upgrades during maintenance windows to minimize service disruption.
Detection guidance
Monitor Sentry server CPU usage for sudden spikes or sustained high utilization without corresponding legitimate event volume increases. Examine Sentry logs for regex processing timeouts or performance warnings in the event ingestion pipeline. Review incoming event payloads for unusual patterns or malformed fields that deviate from normal application error formats. Network-level monitoring can help identify sources sending unusually formatted or high-volume event streams to your Sentry endpoint. Consider implementing rate limiting on event ingestion if not already in place.
Why prioritize this
This vulnerability warrants prompt patching due to the high CVSS score (7.5), the low barrier to exploitation, and the direct impact on service availability. Unlike vulnerabilities requiring authentication or user interaction, this ReDoS flaw can be triggered by any external or internal attacker with network access to the Sentry ingestion endpoint. Organizations using Sentry for mission-critical observability should deprioritize other non-critical updates in favor of this patch to restore full resilience.
Risk score, explained
The CVSS 3.1 score of 7.5 (HIGH) reflects an unauthenticated, network-accessible denial-of-service vector with no user interaction required and low attack complexity. The attack vector is network-based (AV:N), access control is not a prerequisite (PR:N, UI:N), and the scope is unchanged (S:U). The impact is limited to availability (A:H), with no confidentiality or integrity compromise, which prevents a Critical rating. The score appropriately captures a high-severity operational risk that does not result in data breach or unauthorized access.
Frequently asked questions
Will upgrading to 26.5.2 disrupt our monitoring?
Upgrades typically require a service restart, during which Sentry will be temporarily unavailable. Plan the upgrade during a maintenance window to minimize impact. Test the upgrade on a staging environment first. Most organizations complete the upgrade within 15–30 minutes depending on deployment size and method.
Are Sentry Cloud customers automatically protected?
Sentry Cloud customers should be on patched versions automatically, but you must verify with Sentry or check your account dashboard. Self-hosted and on-premises deployments are the responsibility of the customer to update. Contact Sentry support if you are unsure of your current version.
Can we apply a temporary workaround without upgrading?
There is no reliable workaround short of blocking event ingestion or implementing upstream validation to filter suspicious payloads before they reach Sentry. If immediate upgrade is not feasible, consider enabling strict rate limiting on your event ingestion endpoint to reduce the blast radius of a potential attack. However, upgrading to 26.5.2 is the definitive fix.
What should we monitor after we patch?
After patching, continue monitoring CPU usage, ingestion latency, and error logs to ensure normal operation. Verify that legitimate application events are still being ingested and stored correctly. If you observed attack attempts before patching, monitor for any recurrence; persistence of ReDoS attempts against a patched instance indicates a different issue or misconfiguration.
This analysis is provided for informational purposes to assist security teams in vulnerability management and risk prioritization. It is not a substitute for official vendor security advisories or professional security consultation. Organizations must validate patch applicability and compatibility within their specific environments before deployment. SEC.co makes no warranty regarding the completeness, accuracy, or timeliness of this information and disclaims liability for damages arising from its use or misuse. Always consult official Sentry documentation and your organization's change management and incident response procedures. Source: NVD (public-domain), retrieved 2026-08-02. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-42567HIGHSvelte ReDoS Vulnerability in Dynamic Element Tags
- CVE-2026-44496HIGHAxios XSRF Cookie Regex DoS Vulnerability – Security Patch Guidance
- CVE-2026-45617HIGHLiquidJS strip_html ReDoS Denial of Service Vulnerability
- CVE-2026-49293HIGHjs-toml TOML Parser CPU Exhaustion DoS (v1.1.0 and earlier)
- CVE-2026-49851HIGHMistune Markdown Parser CPU Exhaustion DoS Vulnerability
- CVE-2026-54268HIGHAngular DatePipe Denial of Service – High CVSS 7.5
- CVE-2026-8888HIGHSecurly Chrome Extension HTTP Regex DoS Vulnerability
- CVE-2025-71379MEDIUMvLLM ReDoS Vulnerability in Regex Parsing (0.6.3–0.9.0)