CVE-2026-90999 is a trust-boundary failure in Sentry Seer, the AI debugging capability in Sentry’s application-monitoring service. The problem is not that an attacker needs to break into a Sentry organisation first. A person on the internet can submit a fabricated exception event to a project’s public DSN—the client-facing endpoint applications use to send telemetry—and that untrusted report can ultimately influence a privileged coding agent.
Sentry is run by development, platform engineering and application-operations teams to collect exceptions, stack traces, logs and performance data from production applications. Seer uses that material, along with linked source repositories, to investigate an issue, propose a fix and, when automation is enabled, progress work toward code changes or a pull request. That makes incoming telemetry more than diagnostic data: in this configuration, it can become input to an actor with access to development systems.
From fabricated exception to agent instruction
CERT/CC’s technical description says attacker-generated events entering through a public DSN can affect Seer’s root-cause analysis and become instructions supplied to the coding agent. The reported demonstration went further: the agent fetched and executed attacker-controlled code before a pull request reached human review. In practical terms, an attacker is trying to turn a monitoring event into code execution in the automation environment; the eventual impact depends on that agent’s repository credentials, network reachability, secrets and package-installation rights.
The exposed combination is specific. An organisation must use Seer, allow it to hand issues automatically to a coding agent, enable automated rather than human-started remediation, and accept front-end telemetry through a public DSN. This puts the issue most squarely in organisations operating web, mobile or backend applications with Sentry connected to GitHub or GitLab: SaaS companies, online services and internal software teams are more likely to have that workflow than teams using Sentry only for manual triage.
The researchers call the technique PhantomFix and say they reproduced it in accounts and infrastructure they controlled. That establishes the chain, but it is not evidence of attacks against unrelated victims. As of the September 19 research cutoff, no confirmed exploitation in the wild, victim incident or named campaign had surfaced. CVE-2026-90999 is also absent from the checked CISA Known Exploited Vulnerabilities catalogue.
No public fix, so remove the handoff
There is no reproducible public proof of concept or exploit code. The researchers published a high-level account while withholding the malicious report, trigger and reproduction steps until a fix exists. That distinction matters: defenders have enough information to act, but not a turnkey public exploit.
No vendor-supplied patch, fixed version or conventional affected-version range was publicly confirmed by the cutoff. CERT/CC says it received no vendor patch information; it also records that Sentry’s legal entity was notified but had provided no statement. The reported September 18 update could not be confirmed as a change to the CERT/CC note or a Sentry publication.
Teams using this workflow should disable automated remediation or the Seer-to-coding-agent handoff now, rather than relying on review of a resulting pull request. Sentry’s configuration material says a project’s Automation Steps can be set to “No Automation”; teams should also filter telemetry before Seer sees it and restrict package installation in the agent environment.
This is a useful reminder that public observability intake becomes a security boundary when it drives autonomous code changes. Until a fix and scope are published, inventory affected workflows, reduce the agent’s privileges, and use SecAlerts to monitor the software an organisation actually runs for newly relevant vulnerabilities.
