Sentry Seer CVE-2026-90999 matters most to teams that let Seer automatically pass issue analysis into a privileged coding agent. CERT/CC says attacker-controlled telemetry can enter that workflow and, under the affected conditions, lead to code execution inside the coding-agent environment before a human reviews the resulting pull request. That can also expose connected source repositories or credentials available to the agent.
Does CVE-2026-90999 affect every Sentry installation?
No universal Sentry-wide exposure has been established. The confirmed path involves Seer workflows that automatically hand issue data to a coding agent for remediation. If your organization uses Sentry but does not use that automated Seer-to-agent path, the reviewed evidence does not justify assuming that your deployment is affected in the same way.
The practical question is therefore not simply whether your organization uses Sentry. It is whether attacker-influenced telemetry can cross the trust boundary from Sentry event ingestion into Seer analysis and then into a coding agent that has permission to execute code, install packages, access repositories or use development credentials.
What is the CVE-2026-90999 attack path?
CERT/CC describes a chain in which an attacker submits crafted telemetry through a publicly reachable Sentry ingestion path. That telemetry becomes part of the issue context available to Seer. In an affected automated remediation configuration, Seer’s output can then be handed to a coding agent.
The important security boundary is the transition from untrusted telemetry to a privileged autonomous development environment. A coding agent may have far more capability than an ordinary error-reporting system: it may read repositories, create or modify files, run tools, install packages or use credentials provided to its execution environment.
CERT/CC says successful exploitation can result in attacker-controlled code executing inside that agent environment. The real impact depends on what permissions and repository access the affected agent has.
Why pull-request review is not enough
One of the most important distinctions in this vulnerability is timing. A team may assume that a generated code change remains safe because a human will review the pull request before anything reaches production.
That control does not address the full CVE-2026-90999 path. CERT/CC says code execution can occur inside the coding-agent environment before the pull request reaches human review. If the agent has repository credentials, package-installation capability or access to other development secrets, damage can occur before a reviewer sees the proposed code change.
How to check whether your Seer workflow is exposed
1. Check whether Seer automatically sends issues to a coding agent
Identify whether issue analysis or Autofix output is automatically handed to a coding agent for remediation. The reviewed vulnerability evidence centers on this automated handoff rather than ordinary Sentry telemetry collection by itself.
2. Identify what the coding agent can access
Review whether the agent can access private repositories, write code, execute commands, install packages or use credentials and tokens. These privileges determine the possible impact if untrusted input reaches the agent.
3. Treat externally influenced issue data as untrusted
Do not assume that telemetry is safe simply because it entered through an observability platform. Publicly exposed ingestion endpoints can receive attacker-controlled data, and the security problem appears when that data is promoted into a privileged automated workflow.
4. Contain the automated path if exposure is uncertain
CERT/CC’s current mitigation guidance includes disabling the affected automated remediation or coding-agent handoff and restricting package installation inside the agent environment. Those are containment measures while authoritative vendor remediation remains unclear.
5. Verify the vendor remediation state before restoring automation
Do not treat a generic configuration change as proof that the vulnerability is resolved. Restore the affected automation only after current Sentry or CERT/CC guidance establishes the applicable remediation or safe configuration for your environment.
Is a public Sentry DSN by itself the vulnerability?
No. A public ingestion identifier is relevant because it can allow attacker-controlled telemetry to enter the system, but CVE-2026-90999 is not accurately described as simply a leaked or public DSN problem.
The security failure is the downstream trust path: externally influenced telemetry is consumed by Seer and then reaches an automated coding agent with privileges that were designed for development work. Rotating or hiding an ingestion identifier alone should therefore not be presented as a complete remediation unless current vendor guidance specifically establishes that for the affected configuration.
What should teams disable or restrict now?
CERT/CC’s current note provides mitigation rather than a vendor-supplied patch. For teams that confirm or cannot safely rule out the affected automation path, the strongest immediate response is to reduce the privileges and autonomy available to that path.
That can mean temporarily disabling automated Seer-to-coding-agent remediation, restricting package installation or other execution capabilities inside the agent environment, and reviewing which repositories and credentials the agent can access.
These measures should be understood as containment. They are not evidence that Sentry has issued a final product fix for every affected configuration.
Has Sentry released a patch for CVE-2026-90999?
CERT/CC’s reviewed vulnerability note says it had not received vendor-supplied patch information. That statement is important, but it should not be stretched into a broader claim that Sentry has made no service-side changes or mitigation anywhere else.
The exact affected version boundary, whether a service-side mitigation has been deployed, and the final vendor-supported remediation path remain unresolved in the evidence reviewed for this article.
Is CVE-2026-90999 being exploited in the wild?
The reviewed evidence does not establish active exploitation in the wild. CERT/CC confirms the vulnerability and its impact, and the original researchers describe how the issue was discovered and reported, but TPS did not verify credible evidence of widespread real-world exploitation.
Teams should therefore treat the vulnerability seriously without describing it as an active-exploitation campaign unless newer evidence establishes that state.
What could an attacker access?
Successful exploitation can execute code in the coding-agent environment. From there, the practical impact depends on the privileges granted to that environment.
If the agent can access private source repositories, development credentials, package registries or other internal tools, those resources may become part of the exposure. A tightly isolated agent with minimal permissions presents a different impact profile from an agent connected broadly to production development infrastructure.
What should prove that the problem is resolved?
The safest resolution standard is not merely that an alert stopped appearing or an automated workflow was re-enabled successfully. Teams should look for authoritative Sentry or CERT/CC guidance that defines the affected configuration and remediation, then verify that their environment no longer permits attacker-controlled telemetry to reach a privileged coding agent through the vulnerable path.
If Sentry later publishes an affected-version range, a service-side fix, configuration requirement or explicit remediation procedure, that information should replace temporary containment guidance on this same canonical page.
What remains unknown?
- The exact affected-version or build boundary has not been established in the reviewed evidence.
- The reviewed CERT/CC note does not provide vendor-supplied patch information.
- TPS did not verify exploitation in the wild.
- Different coding-agent integrations may have different permissions and execution models.
- The impact for manually triggered or partially automated Seer workflows may differ from the fully automated path described by CERT/CC.
Sentry Seer CVE-2026-90999: direct answers
Should every Sentry user disable Seer?
No universal disablement requirement is established by the reviewed evidence. Teams should first determine whether their workflow automatically passes Seer issue analysis into a privileged coding agent.
Is repository access part of the risk?
Yes, when the affected coding-agent environment has access to connected repositories. The actual scope depends on the privileges granted to that agent.
Is human pull-request review enough protection?
No. CERT/CC says code execution can occur inside the agent environment before the pull request reaches human review.
Is there a confirmed vendor patch?
The reviewed CERT/CC note says no vendor-supplied patch information had been provided. Teams should check current Sentry and CERT/CC guidance before restoring affected automation.
Is active exploitation confirmed?
No active exploitation was confirmed in the evidence reviewed for this article.
Verification method
ThePulseSignal reviewed CERT/CC VU#212479, the original researcher disclosure, current Sentry documentation describing Seer automation and coding-agent handoff, and current vulnerability-reference coverage. The review separated confirmed attack mechanics from unresolved vendor-remediation and exploitation status.
Limitations
Exact affected-version boundaries, vendor remediation details, provider-specific coding-agent behavior and exploitation-in-the-wild status remain unresolved. Security teams should use the latest CERT/CC and Sentry guidance as the controlling source before consequential production changes.