Cross-organization IDOR allows unauthorized event-data access in getsentry Sentry

Sentry is a developer-first error tracking and performance monitoring tool. Versions prior to 26.1.0 have a cross-organization Insecure Direct Object Reference (IDOR) vulnerability in Sentry's GroupEventJsonView endpoint. Version 26.1.0 patches the issue.

• getsentry Sentry: versions < 26.1.0 are identified as affected.
• Sentry 26.1.0 is identified as the patched version.
• The record does not establish the status of parallel release branches or custom builds outside the stated boundary.

The flaw is in the GroupEventJsonView endpoint, where the user-controlled group_id is not correctly bound to the organization being authorized. In the affected implementation, GroupEventJsonView.get calls get_group_with_redirect without passing organization, so organization-level authorization checks are not applied to the requested resource. The permission path checks the active organization and the event:read scope, but does not verify that the group belongs to that organization. An attacker needs an authenticated Sentry account with event:read permission in their own organization and can then send a network request to the endpoint with a group_id belonging to another organization. The fix passes organization into the group lookup and adds tests that deny cross-organization access. Other implementation details beyond this endpoint and authorization flow are not established by the available evidence.

The vulnerability is remotely reachable through Sentry's HTTP endpoint and requires an authenticated account with event:read permission in the attacker's own organization. The public advisory documents a proof of concept in which a non-administrator user changes group_id while retaining the slug of their own organization in the URL to retrieve event data from another organization. Victim interaction is not required by the documented flow. The advisory states that group IDs can be relatively easy to guess because they are commonly consecutive, although this may depend on the deployment and data. The record confirms a public exploit or proof of concept; exploitation in any particular deployment has not been established.

The confirmed technical impact is loss of confidentiality for event data across organization boundaries. The attacker needs an authenticated account with event:read permission, but does not need administrator status and does not require victim interaction. The scope crosses organization boundaries within the same Sentry deployment, allowing data belonging to one tenant to be read by a user from another tenant. The advisory does not document data modification, privilege escalation, or denial of service. The actual harm depends on the type of information stored in event payloads and how long the instance ran an affected version.

• A user belonging to one organization may read event data from another organization, breaking tenant or organization isolation.
• Event data may contain sensitive information depending on application content and deployment configuration, so disclosure may affect business information, user data, or operational details.
• The incident may require investigation, scope assessment, and security notification if the exposed events contain protected data.
• The available evidence confirms unauthorized read access only; it does not document data modification or service disruption.

1. Upgrade getsentry Sentry to 26.1.0, which is identified as fixing the issue.
2. Verify the actual version of every instance, image, or custom build; do not assume that another release branch is fixed solely because 26.1.0 contains the patch.
3. After upgrading, test authorization between two separate organizations with dedicated test accounts and confirm that GroupEventJsonView rejects a group or event outside the current organization.
4. If an immediate upgrade is not possible, temporarily restrict network access to Sentry and review the sensitivity of stored event data. This is a precaution, not a vendor-confirmed mitigation in the available evidence.
5. Review access logs for requests made before patching that may indicate access to groups or events outside the requesting user's organization.

• Inventory every getsentry Sentry deployment and identify the running version before assessing exposure.
• Review logs or telemetry for requests to routes associated with GroupEventJsonView, especially where the organization slug in the URL does not correspond to the organization that owns the requested group or event.
• Search for event:read accounts accessing event data outside their organization, where the deployment records resource-level authorization or group ownership.
• Perform a controlled authorization test in a non-production environment using separate organizations and confirm that a group or event owned by one organization is denied to a user from another.
• No specific IOC is provided. The absence of matching log evidence does not prove that the deployment was not accessed or is safe.