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
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 8.2.2 or 8.1.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 26.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Patches - Sentry SaaS: The fix was deployed on Jan 14, 2025. - Self-Hosted Sentry: If only a single organization is allowed (SENTRYSINGLEORGANIZATION = True), then no action is needed. Otherwise, users should upgrade to version 25.1.0 or higher. Workarounds No known workarounds. References - https://github.com/getsentry/sentry/pull/83407
Recommended action: Upgrade to 25.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 24.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 24.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 24.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 24.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching event == "slack." && name == "sentry.integrations.slack" && requestdata == . The deprecated slack verification token, will be found in the requestdata.token key. Example event: Patches - SaaS users do not need to take any action. - Self-hosted users should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token. - If you are only using the slack.signing-secret in your self-hosted configuration, then the legacy verification token is not used to verify the webhook payload. It is ignored. ⚠️ Sentry's support for validating…
Recommended action: Upgrade to 24.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 24.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 23.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 23.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 23.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Sentry API incorrectly returns the access-control-allow-credentials: true HTTP header if the Origin request header ends with the system.base-hostname option of Sentry installation. This only affects installations that have system.base-hostname option explicitly set, as it is empty by default. Impact is limited since recent versions of major browsers have cross-site cookie blocking enabled by default. However, this flaw could allow other multi-step attacks. Patches The patch has been released in Sentry 23.6.2. Workarounds For Sentry SaaS customers, no action is needed. For self-hosted Sentry installations that have system.base-hostname explicitly set, it is recommended to upgrade the installation to 23.6.2 or higher. There are no known workarounds. References - getsentry/sentry PR #52276 Credits - @andr0idp4r4n0id
Recommended action: Upgrade to 23.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
With a known valid invite link (i.e. not already accepted or expired) an unauthenticated attacker can manipulate the cookie to allow the same invite link to be reused on multiple accounts when joining an organization. Impact An attacker with a valid invite link can create multiple users and join the organization from which the invite link was generated. Patches This issue was patched in version 22.11.0. Workarounds Sentry SaaS customers do not need to take action. Self-hosted Sentry installs 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/). 1. Add the following line into sentry.conf.py: 2. Restart the Sentry web service. For more information If you have any questions or comments about this advisory: Visit our FAQs on this CVE Open an issue in getsentry/sentry Email us at security[@]sentry.io
Recommended action: Upgrade to 22.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.