This briefing was produced by AI from the linked sources and is scheduled for human editorial review within 24 hours. Read the sources directly for material decisions.
EVIDENCE — CERT/CC disclosed CVE-2026-90999 on 16 September 2026. The affected condition is specific: Sentry Seer must be configured to automatically hand eligible issues to a coding agent for remediation. A remote party can submit a crafted exception event through a front-end project's public DSN; attacker-controlled exception messages, stack traces, source context, and breadcrumbs then enter Seer's root-cause analysis. CERT/CC says that analysis is placed in the coding agent's initial prompt, where the fabricated context can lead the agent to download and execute an attacker-controlled package. Successful exploitation produces arbitrary code execution inside the coding-agent environment and may expose connected source repositories.
TELEMETRY CROSSED THREE TRUST BOUNDARIES — Error data begins as untrusted application input, becomes trusted-seeming diagnostic analysis, and then becomes instructions for an agent with a checked-out repository and an execution environment. Sentry's own published workflow explains that Seer gathers production context, passes its root-cause analysis to a cloud coding agent, and lets that agent run tests, start a development server, and use connected tools. Each capability is useful in isolation. Chained together without preserving the origin and trust level of the fields, they turn an observability ingestion endpoint into a route toward developer infrastructure.
PULL-REQUEST REVIEW IS TOO LATE — This is not primarily a malicious-code-review problem. CERT/CC says the attacker-controlled package executes while the agent investigates, before any human reviews a proposed pull request. A policy that requires approval before merge therefore protects the repository's main branch but does not protect the agent workspace, its network access, checked-out source, or credentials already present in that environment. The meaningful approval boundary must sit before untrusted telemetry can trigger an executable agent session—or the session must be isolated so thoroughly that execution cannot reach secrets, internal services, package registries, or durable repository credentials.
NO VENDOR PATCH WAS LISTED AT DISCLOSURE — CERT/CC reported that Sentry had not supplied patch information or a vendor statement when the note was published. The public record also does not establish active exploitation, affected hosted tenants, or a universal impact for every Seer deployment. Exposure depends on automatic coding-agent handoff, not merely on using Sentry or Seer. Until Sentry publishes definitive remediation, CERT/CC recommends disabling automated remediation flows or the Seer handoff, restricting package installation in coding-agent environments, and filtering telemetry before Seer analysis. Treat those as interim risk-reduction measures, not proof that historical sessions were safe.
WHAT TO CHECK — Inventory every Sentry project that accepts browser or other externally submitted events, then identify which projects have Seer automation and a coding-agent handoff enabled. Pause automatic handoff for exposed projects while the vendor response is unresolved. In the connected agent platform, review sessions spawned from Sentry issues since the integration was enabled; correlate unexpected package downloads, install commands, outbound DNS or HTTP connections, process execution, repository reads, branch creation, and pull requests. Rotate repository tokens and other agent-accessible secrets if suspicious execution is found. Longer term, require provenance labels on telemetry-derived prompt content, separate analysis from execution, allowlist dependencies and egress, use disposable workspaces with short-lived credentials, and put an explicit approval gate before any tool-capable agent receives attacker-influenced context.