An Authentication Bypass vulnerability in Sentry before R10.8.2, R10.7.3 and R10.6.4 allows a remote unauthenticated attacker to gain administrative level access.

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.

Sentry 8.2.0 contains a remote code execution vulnerability that allows authenticated superusers to execute arbitrary commands by injecting malicious pickle-serialized objects through the audit log entry data parameter. Attackers can submit crafted POST requests to the admin audit log endpoint with base64-encoded compressed pickle payloads in the data field to achieve code execution with application privileges.

Impact A critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via Sentry's private bug bounty program.

The vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.

Self-hosted users are only vulnerable if the following conditions are met: - They have more than one organization configured (SENTRYSINGLEORGANIZATION = False). - A malicious user has existing access and permissions to modify SSO settings for another organization in their multi-organization instance.

Patches - Sentry SaaS: The fix was deployed in April. No action is required. - Self-Hosted Sentry: If only a single organization is allowed (SENTRYSINGLEORGANIZATION = True), then no action is needed. Sentry recommends upgrading to version 26.4.1 or higher.

Workarounds User account-based two-factor authentication prevents an attacker from being able to complete authentication with a victim's user account. Organization administrators cannot do this on a user's behalf, this requires individual users to ensure 2FA has been enabled for their account.

Users can manage their two-factor authentication settings through Account Settings > Security page. For step-by-step details, please see the Sentry helpdesk article.

Resources

- https://github.com/getsentry/sentry/pull/113720

Please note that this is distinct vulnerability from the similar https://github.com/getsentry/sentry/security/advisories/GHSA-7pq6-v88g-wf3w from 2025.

Impact A critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via our private bug bounty program.

The vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.

For self-hosted users, you are only vulnerable if the following conditions are met: - You have more than one organization configured (SENTRYSINGLEORGANIZATION = False). - A malicious user has existing access and permissions to modify SSO settings for another organization in your multo-organization instance.

Patches - Sentry SaaS: The fix was deployed on February 18, 2026. No action is required. - Self-Hosted Sentry: If only a single organization is allowed (SENTRYSINGLEORGANIZATION = True), then no action is needed. We recommend upgrading to version 26.2.0 or higher.

Workarounds User account-based two-factor authentication prevents an attacker from being able to complete authentication with a victim's user account. Organization administrators cannot do this on a user's behalf, this requires individual users to ensure 2FA has been enabled for their account.

You can manage your two-factor authentication settings on your Account Settings > Security page. For step-by-step details, please see our helpdesk article.

A cross-organization Insecure Direct Object Reference (IDOR) vulnerability has been identified in Sentry’s GroupEventJsonView endpoint.

A cross-organization Insecure Direct Object Reference (IDOR) vulnerability has been identified in Sentry’s GroupEventJsonView endpoint.

Sentry is a developer-first error tracking and performance monitoring tool. Prior to version 25.5.0, an attacker with a malicious OAuth application registered with Sentry can take advantage of a race condition and improper handling of authorization code within Sentry to maintain persistence to a user's account. With a specially timed requests and redirect flows, an attacker could generate multiple authorization codes that could be used to exchange for access and refresh tokens. This was possible even after de-authorizing the particular application. This issue has been patched in version 25.5.0. Self-hosted Sentry users should upgrade to version 25.5.0 or higher. Sentry SaaS users do not need to take any action.

In Sentry 25.1.0 through 25.5.1, an authenticated attacker can access a project's issue endpoint and perform unauthorized actions (such as adding a comment) without being a member of the project's team. A seven-digit issue ID must be known (it is not treated as a secret and might be mentioned publicly, or it could be predicted).

Impact During routine testing, we identified a scenario where a specific error message generated by our platform could include a plaintext Client ID and Client Secret for an application integration. The Client ID and Client Secret would not be displayed in the UI, but would be returned in the underlying HTTP response to the end user. This could occur under the following conditions: - An app installation made use of a Search UI component with the async flag set to true (default: true), - A user types types into the Search Component which creates a request to the third-party for search or query results, and - That third-party response may then fail validation and Sentry would return the select-requester.invalid-response error code along with a serialized version of a Sentry application containing the integration Client Secret.

Should this error be found, it's reasonable to assume the potential exposure of an integration Client Secret. However, an ID and Secret pair alone does not provide direct access to any data. For that secret to be abused an attacker would also need to obtain a valid API token for a Sentry application.

Impact for SaaS Users For Sentry SaaS users, we have confirmed that only a single application integration was impacted and the owner has rotated their Client Secret. We have also confirmed that no abuse of the leaked Client Secret has occurred.

Potential Impact for Self-Hosted Users Sentry self-hosted does not ship with any application integrations. This could only impact self-hosted users that maintain their own integrations. In that case, search for a select-requester.invalid-response event. Please note that this error was also shared with another event unrelated to this advisory so you will also need to review the parameters logged for each named event. You may review selectrequester.py for the instances where these errors can be generated. With the security fix this is no longer a shared event type.

Patches - Sentry SaaS users do not need to take any action. - Sentry self-hosted users should upgrade to 24.11.1 or higher.

References - Bug introduced in https://github.com/getsentry/sentry/pull/79377 - Security fix in https://github.com/getsentry/sentry/pull/81038

Cross Site Scripting vulnerability in Sentry v.6.0.9 allows a remote attacker to execute arbitrary code via the z parameter.

Impact An authenticated user can mute alert rules from arbitrary organizations and projects given a known given rule ID. The user does not need to be a member of the organization or have permissions on the project.

In our review, we have identified no instances where alerts have been muted by unauthorized parties.

Patches A patch was issued to ensure authorization checks are properly scoped on requests to mute alert rules. Authenticated users who do not have the necessary permissions are no longer able to mute alerts.

Sentry SaaS users do not need to take any action. Self-Hosted Sentry users should upgrade to version 24.9.0 or higher.

Affected Versions The rule mute feature was generally available as of 23.6.0 but users with early access may have had the feature as of 23.4.0.

Update As of 2024-10-25 and after additional we've updated the Severity scoring to reduce Privileged Required from Low to None and Integrity from High to Low. Thanks again to @emanuelbeni for the correction on Privileges Required.

References - Prevent muting alerts

Impact An authenticated user may delete user issue alert notifications for arbitrary users given a known alert ID.

Patches A patch was issued to ensure authorization checks are properly scoped on requests to delete user alert notifications.

Sentry SaaS users do not need to take any action. Self-Hosted Sentry users should upgrade to version 24.9.0 or higher.

References - Prevent muting user alerts

Impact An unsanitized payload sent by an Integration platform integration allows the storage of arbitrary HTML tags on the Sentry side. This payload could subsequently be rendered on the Issues page, creating a Stored Cross-Site Scripting (XSS) vulnerability. This vulnerability might lead to the execution of arbitrary scripts in the context of a user’s browser.

Self-hosted Sentry users may be impacted if untrustworthy Integration platform integrations send external issues to their Sentry instance.

Patches The patch has been released in Sentry 24.7.1

Workarounds For Sentry SaaS customers, no action is needed. This has been patched on July 22, and even prior to the fix, the exploitation was not possible due to the strict Content Security Policy deployed on sentry.io site.

For self-hosted users, we strongly recommend upgrading Sentry to the latest version. If it is not possible, you could enable CSP on your self-hosted installation with CSPREPORTONLY = False (enforcing mode). This will mitigate the risk of XSS.

References Sentry Docs: Integration platform / Create an External Issue Sentry Docs: Self-hosted CSP The fix: https://github.com/getsentry/sentry/pull/74648 PortSwigger: Stored XSS

Impact When authenticating as a superuser to a self-hosted Sentry instance with a username and password, the password is leaked as cleartext in logs under the event: auth-index.validatesuperuser. An attacker with access to the log data could use these leaked credentials to login to the Sentry system as superuser.

Patches - Self-hosted users on affected versions should upgrade to 24.4.1 or later. - Sentry SaaS users do not need to take any action. This vulnerability is not applicable to SaaS.

Workarounds Users can configure the logging level to exclude logs of the INFO level and only generate logs for levels at WARNING or higher. For details on configuring self-hosted Sentry's logging level see our documentation at: https://develop.sentry.dev/config/#logging

References - Bug introduced in https://github.com/getsentry/sentry/pull/66393 - Security fix in https://github.com/getsentry/sentry/pull/69148

Sentry is an error tracking and performance monitoring platform. Sentry’s integration platform provides a way for external services to interact with Sentry. One of such integrations, the Phabricator integration (maintained by Sentry) with version <=24.1.1 contains a constrained SSRF vulnerability. An attacker could make Sentry send POST HTTP requests to arbitrary URLs (including internal IP addresses) by providing an unsanitized input to the Phabricator integration. However, the body payload is constrained to a specific format. If an attacker has access to a Sentry instance, this allows them to: 1. interact with internal network; 2. scan local/remote ports. This issue has been fixed in Sentry self-hosted release 24.1.2, and has already been mitigated on sentry.io on February 8. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Symbolicator is a service used in Sentry. Starting in Symbolicator version 0.3.3 and prior to version 21.12.1, an attacker could make Symbolicator send GET HTTP requests to arbitrary URLs with internal IP addresses by using an invalid protocol. The responses of those requests could be exposed via Symbolicator's API. In affected Sentry instances, the data could be exposed through the Sentry API and user interface if the attacker has a registered account. The issue has been fixed in Symbolicator release 23.12.1, Sentry self-hosted release 23.12.1, and has already been mitigated on sentry.io on December 18, 2023. If updating is not possible, some other mitigations are available. One may disable JS processing by toggling the option Allow JavaScript Source Fetching in Organization Settings > Security & Privacy and/or disable all untrusted public repositories under Project Settings > Debug Files. Alternatively, if JavaScript and native symbolication are not required, disable Symbolicator completely in config.yml.

Impact A ReDoS (Regular expression Denial of Service) vulnerability has been identified in Sentry's Astro SDK 7.78.0-7.86.0. Under certain conditions, this vulnerability allows an attacker to cause excessive computation times on the server, leading to denial of service (DoS).

Applications that are using Sentry's Astro SDK are affected if:

1. They're using Sentry instrumentation: - they have manually registered Sentry Middleware (affected versions 7.78.0-7.86.0); - or configured Astro in SSR (server) or hybrid mode, use Astro 3.5.0 and newer and didn’t disable the automatic server instrumentation (affected versions 7.82.0-7.86.0). 2. They have configured routes with at least two path params (e.g. /foo/[p1]/bar/[p2]).

Patches The problem has been patched in @sentry/astro@7.87.0. The corresponding PR: https://github.com/getsentry/sentry-javascript/pull/9815

Workarounds We strongly recommend upgrading to the latest SDK version. However, if it's not possible, the steps to mitigate the vulnerability without upgrade are: disable auto instrumentation if you're using Astro 3.5.0 or newer and remove the manually added Sentry middleware (if it was added before).

After these changes, Sentry error reporting will still be functional, but some details such as server-side transactions (and consequently, distributed traces between client and server) will be omitted. We therefore still recommend to update to 7.87.0 as soon as you can.

References Sentry docs: Manual Setup for Astro Release notes: sentry-javascript 7.87.0 npm: @sentry/astro@7.87.0

Symbolicator is a symbolication service for native stacktraces and minidumps with symbol server support. An attacker could make Symbolicator send arbitrary GET HTTP requests to internal IP addresses by using a specially crafted HTTP endpoint. The response could be reflected to the attacker if they have an account on Sentry instance. The issue has been fixed in the release 23.11.2.

Impact An unsanitized input of Next.js SDK tunnel endpoint allows sending HTTP requests to arbitrary URLs and reflecting the response back to the user. This could open door for other attack vectors: client-side vulnerabilities: XSS/CSRF in the context of the trusted domain; interaction with internal network; read cloud metadata endpoints (AWS, Azure, Google Cloud, etc.); local/remote port scan.

This issue only affects users who have Next.js SDK tunneling feature enabled.

Patches The problem has been fixed in sentry/nextjs@7.77.0

Workarounds Disable tunneling by removing the tunnelRoute option from Sentry Next.js SDK config — next.config.js or next.config.mjs.

References Sentry Next.js tunneling feature The fix More Information

Credits Praveen Kumar

Impact

An attacker with sufficient client-side exploits could retrieve a valid access token for another user during the OAuth token exchange due to incorrect credential validation. The client ID must be known and the API application must have already been authorized on the targeted user account.

Remediation

- Sentry SaaS customers do not need to take any action. Those with the highest risk will be contacted directly by Sentry. - Self-hosted installations should upgrade to version 23.7.2 or higher.

Workarounds

There are no direct workarounds, but users should review applications authorized on their account (User Settings > Authorized Applications) and remove any that are no longer needed.

Impact An attacker with access to a token with few or no scopes can query /api/0/api-tokens/ for a list of all tokens created by a user, including tokens with greater scopes, and use those tokens in other requests.

There is no evidence that the issue was exploited on https://sentry.io. For self-hosted users, it is advised to rotate user auth tokens via https://your-self-hosted-sentry-installation/settings/account/api/auth-tokens/.

Patches The issue was fixed in https://github.com/getsentry/sentry/pull/53850 and is available in the release 23.7.2 of sentry and self-hosted.

Workarounds There are no known workarounds.

Impact

An authenticated user can download a debug or artifact bundle from arbitrary organizations and projects with a known bundle ID. The user does not need to be a member of the organization or have permissions on the project.

Patches

A patch was issued to ensure authorization checks are properly scoped on requests to retrieve debug or artifact bundles. Authenticated users who do not have the necessary permissions on the particular project are no longer able to download them.

Sentry SaaS users do not need to take any action. Self-Hosted Sentry users should upgrade to version 23.5.2 or higher.

References

- Restrict file downloads to Project

Sentry SDK is the official Python SDK for Sentry, real-time crash reporting software. When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application.

In order for these sensitive values to be leaked, the Sentry SDK configuration must have sendDefaultPII set to True; one must use a custom name for either SESSIONCOOKIENAME or CSRFCOOKIENAME in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names.

As of version 1.14.0, the Django integration of the sentry-sdk will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the beforesend callback method and for performance related events (transactions) one can use the beforesendtransaction callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the $http.cookies, $http.headers, $request.cookies, or $request.headers fields to target with a scrubbing rule.

Sentry is an error tracking and performance monitoring platform. In versions of the sentry python library prior to 22.11.0 an attacker with a known valid invite link could manipulate a cookie to allow the same invite link to be reused on multiple accounts when joining an organization. As a result an attacker with a valid invite link can create multiple users and join an organization they may not have been originally invited to. This issue was patched in version 22.11.0. Sentry SaaS customers do not need to take action. Self-hosted Sentry installs on systems which can not upgrade can disable the invite functionality until they are ready to deploy the patched version by editing their sentry.conf.py file (usually located at ~/.sentry/).