PhantomFix: a fabricated bug that hijacks an AI autofix agent (CVE-2026-90999)

About this research. This is part of our open research into the security of AI agents — the attack patterns, failure modes, and design flaws that surface as teams move agents into production. Everything we describe is built and tested on our own accounts and infrastructure; we never touch systems we don't own. When our research turns up a specific product that's exploitable, we report it to the vendor first, and we hold exploit specifics until there's a fix.

We reported a critical vulnerability in Sentry Seer, the automated analysis and remediation feature in Sentry. In its autonomous configuration, Seer can take an incoming error, hand it to a coding agent, and let that agent investigate and draft a fix on its own. We found that a remote attacker — with no account on the victim's organization — can submit a fabricated error report that steers this autonomous agent into fetching and running attacker-controlled code. The result is code execution in the agent's environment and access to the source repositories connected to the project. It has been assigned CVE-2026-90999.

We call it PhantomFix: the reported bug never happened, and the agent's own fix is what runs the attacker's code.

What makes this class of issue hard is that every step is individually reasonable. Handed a plausible bug report, an autonomous agent does roughly what a competent engineer would — and nothing in that chain looks wrong, which is why a normal review doesn't catch it. The exposure isn't a single mistake; it's the pattern itself: an agent with real capabilities acting on untrusted input. That's not specific to one team or one product.

The concrete case behind our earlier post

In August we described this as a general class of attack: fake bug reports that hijack coding agents. At the time we noted that we'd validated one case end to end, disclosed it to the vendor, and were holding all specifics until it was fixed.

This is that case. The vendor is Sentry, the feature is Seer's autonomous autofix, and the finding now has a CVE. The mechanism is the one we already laid out in that post; what's new here is that it's a named, confirmed, critical instance in a widely used product.

What happens, at a high level

To collect frontend errors, a site ships a Sentry DSN — an endpoint and a client key — in its own code. It's public by design; that's how a browser reports errors. That key only lets you send events, but that's enough: anyone can submit an error report, and an error report arriving at a monitoring tool does not mean the error actually happened. The sender controls every field.

When Seer is configured to hand issues to a coding agent automatically, a carefully shaped — but entirely fabricated — error report can travel through Seer's analysis and become the agent's task. Acting on that task, the agent fetches and runs attacker-controlled code as a normal part of investigating the "bug." That happens inside the agent's environment, which holds the project's source and a credential scoped to the connected repositories — so the attacker gains code execution there and can read, modify, and push to those repos. Notably, it happens while the agent is still working, before any pull request exists for a human to review.

We're holding the exact report, the trigger, and the reproduction steps until there's a fix.

Who should pay attention

This affects you if all of the following are true:

• You use Sentry Seer.
• Seer is set to hand issues to a coding agent automatically.
• Automated remediation is enabled — the agent acts without a human starting each run.
• The project collects frontend errors through a public DSN, which is essentially any web frontend.

If a human triggers and reviews Seer before the agent acts, the automatic path we're describing doesn't apply in the same way.

This isn't about one model

One finding stood out. We took the same manipulation we used in this exploit and ran it against every leading LLM we could — each one followed it. This is not a weakness in a particular model, and it isn't a mistake by a particular team. It's a property of how autonomous agents treat untrusted input that has been reshaped to look like a legitimate task. We've built this into a repeatable test and will publish the benchmark results shortly.

What's coming

Over the next few days we'll share more: the cross-model benchmark, and a full walkthrough with a demo video. We're staging it deliberately — leading with this heads-up and holding the reproducible details — so teams have time to review their own configuration first.

What you can do now

If you use Sentry on a frontend project (public DSN) and let a coding agent automatically resolve issues, you might want to pause that automated integration for now — at least until you've reviewed it or a fix is available.

More broadly, the hardening is the same as for any automated-remediation pipeline, and we covered it in detail in the earlier post: don't pass an untrusted report to the agent as if it were a trusted instruction, confirm a bug is real before acting on it, don't let the agent install new packages on its own, and scope repository credentials to the narrowest possible access.

Disclosure

We've disclosed this to Sentry and are holding exploit specifics until there's a fix. The issue is tracked as CVE-2026-90999 and in CERT/CC's vulnerability note VU#212479. We'll update this post as more information becomes public, including the full technical write-up.