PhantomFix: Public Error Telemetry Hijacks Sentry Seer’s Autofix Coding Agent (CVE-2026-90999)

In plain language

Your website ships a public Sentry key so browsers can report crashes. That is normal. What is not normal is wiring those reports straight into an AI that is allowed to “fix” the bug by installing packages and touching your repos—without a human starting the run. PhantomFix shows that anyone who can post a fake error to that public key can fabricate a bug story, have Seer’s analysis embed it into the coding agent’s prompt, and get attacker-chosen code running in the agent environment before any pull request exists to review. Pause automatic Seer→agent remediation until you hard-gate package installs and require a human to start each fix.

The Incident

A frontend ships with a Sentry DSN in the browser bundle. That key is public by design: visitors’ exceptions need somewhere to land. Overnight, an error appears that nobody on the team remembers reproducing—odd stack frames, a missing dependency, a “broken” package name that looks almost real. Seer, configured for autonomous autofix, rates the issue auto-fixable from the event fields alone and hands it to the integrated coding agent. The agent does what a helpful engineer would do: investigate, fetch the implied package, run it. There is still no PR. The “fix” already executed in an environment that holds source and a credential scoped to connected repositories.

Here is why the lock failed.

Why existing thinking failed

The comfort story: telemetry is operational data, not an instruction channel; a public DSN only allows submit, so it cannot escalate; Seer’s root-cause write-up is “analysis,” therefore safer than raw attacker text; coding-agent risk is bounded because humans review pull requests; autonomous remediation is just faster triage on the same path a human would take.

That fails when ingest trust and agent task trust collapse. A public DSN need not be a secret—only a write path into privileged automation. CERT: Seer’s analysis embeds attacker-controlled fields into the coding agent’s initial prompt. PR review never fires if package execution precedes any PR. This is not a model jailbreak; it is an untrusted task presented as legitimate codebase work.

Research proves it

Confirmed in CERT/CC VU#212479 (16 September 2026) and CVE-2026-90999: when Seer automatically hands issues to a coding agent, exploitation yields code execution in that agent environment and access to connected repositories. Chain: fabricated public-DSN events → Seer RCA from attacker-controlled fields → analysis embedded in the coding agent’s initial prompt → attacker package runs before any PR review.

Confirmed (agyn PhantomFix, 14 September 2026): the bug never happened; the “fix” path runs attacker code. In scope: automatic handoff + automated remediation. Out of scope for their automatic path: human-triggered Seer with review before the agent acts.

Confirmed mitigations at disclosure: CERT—no vendor patch info/statement; disable automated remediation/handoff, restrict agent package installs, filter telemetry before Seer. agyn—pause the automated integration on frontend projects until review or a fix.

Unknown / deferred: exact event recipes (PoC held); SaaS remediation date; version range (CVE: “Web site”); victim count.

Engineering takeaway

Autofix is an agent control plane. Anything that can become the agent’s task prompt without an independent authenticity check is an instruction channel—error telemetry included. Public write endpoints plus autonomous privileged tools plus “analysis” that still carries attacker fields is one failure class: untrusted data → trusted agent work → package/exec before human gate. That is the APRF Core map below.

Why this matters

Stake: if error telemetry can become an agent task that installs packages with repo credentials, a visitor to your marketing site sits one fabricated stack trace away from your source and CI identity.

Owners of Sentry (or sibling) projects with Seer→coding-agent autofix, AppSec reviewing “AI remediation,” and anyone shipping a public frontend DSN should treat this as in-scope. Class: Agents + Tools + CI-adjacent automation. MCP is optional; any coding agent with install + repo access qualifies. Pure chatbots without those tools are a weaker fit.

Can a startup ignore it? No if auto-handoff + package install is on. Maybe if every remediation is human-started and agents cannot install new packages. DSN rotation raises targeting cost; it does not fix the class.

Timeline

Root Cause

Three properties coincide: public unauthenticated write into the issue pipeline (DSN); analysis that preserves attacker-controlled fields as the agent’s task brief; autonomous privileged tools (package download/exec + repo credentials) that run before human PR review.

Root cause class: indirect prompt injection / trust-boundary collapse from untrusted telemetry into an autofix agent—not a Sentry DSN “leak” in the secret-key sense, and not a model-weight jailbreak. The platform’s AI is the amplifier: it turns attacker event fields into a polished investigation narrative the coding agent is configured to obey.

APRF Lens

Failure class (APRF / threat-map vocabulary): Prompt Injection (indirect, via telemetry) enabling Agent Hijacking / Excessive Agency and Tool Abuse, culminating in Supply Chain Compromise when the agent installs an attacker-chosen package. Informative only—not certification. Soft link: /aprf/threats/.

Profile: Core only (this week’s scope). Agents/Tools/CI are affected systems, not extra auditor lenses.

Check families in play (APRF 0.11.0; threat-map grounded):

Mapped threats (informative): Prompt Injection, Tool Abuse, Excessive Agency, Agent Hijacking, Supply Chain Compromise; ATLAS cues include AML.T0051 / AML.T0051.001 and AML.T0053—not “these Checks would have prevented CVE-2026-90999.”

Good evidence: human-initiated handoff only; deny-by-default package install with allowlist; HITL on high-impact tools; traces from event ID → Seer decision → agent → package digest.

Standing caveat: APRF assessments can miss evidence. A repository is not the only source of truth. Runtime Sentry/Seer toggles, coding-agent OAuth scopes, CI variables, production prompts, and vendor SaaS versions often never appear in source control. Absence of a finding is not proof of readiness. Threat-map rows are not certification.

APRF mapping confidence: High. Auditor confidence: Medium — offline Core+Agents on open `getsentry/sentry` + `tenet-security/agent-jackstop` (pattern libraries); hosted Seer SaaS and withheld PoC not scored.

Abuse Path Analysis

- Attacker → DSN: Public write is expected for browser SDKs—cut impact later, not by pretending the DSN is secret. Raise cost with project isolation; do not treat rotation as the fix.

- Seer → Prompt: Cut with SEC-M1—analysis text cannot become authorization for privileged tools; SEC-M3—suites that never feed fabricated telemetry into autofix miss the class.

- Task → Install: Cut with TOL-M1 / TOL-M2 / TOL-M3 / SCI-M2—package admission is a platform decision with inventory and allowlists, not a consequence of a polished RCA.

- Install → PrePR: Cut with HUM-M1—human must start (and preferably approve) remediation before tools fire.

- Observability: Without OBS-M1, “weird Sentry event” and “mystery package install in agent logs” never share a timeline.

Abuse path confidence: High — CERT’s published workflow is primary; agyn corroborates configuration prerequisites and pre-PR timing. Speculative only for unpublished vendor mitigations and exact event field recipes (intentionally withheld).

Standing caveat (brief): APRF assessments can miss evidence; a repository is not the only source of truth. This graph is the disclosed chain, not your production Sentry toggles or agent IAM.

Relevant Controls

These IDs are failure-class mappings from CERT/CVE/agyn + threat map, aligned with offline Auditor statuses on public pattern repos (`auditorRun: ran`). Prefer Relevant over Missed: gate FAIL on those trees is not “Sentry SaaS failed APRF.”

Patterns from public repos (not a CVE re-test)

Assessment evidence: `npx @stackrail-io/aprf@0.1.3 audit --profile core --lens agents` (offline, 2026-09-24) on getsentry/sentry @ `0cc5a63be6241dc569d6f93d116caf737c591299` and tenet-security/agent-jackstop @ `5a2b0fd21885a3c1d7484b8e5def8a3ee6474a3c`.

Neither is a PhantomFix victim; exploit specifics remain withheld; hosted Seer is not these clones. Offline Core+Agents gate FAIL on both is expected. Do not read grade F as “Sentry failed the CVE.”

getsentry/sentry (autofix / handoff surface)

TOL-M1 / TOL-M2 / TOL-M3 Not Demonstrated. SEC-M1, SEC-M3, HUM-M1, SCI-M2, OBS-M1 Partial (signals without measured deny rates, HITL inventory proof, pin/review coverage, or linkedTracePct).

Manual pattern: in-tree `automation_handoff`, coding-agent handoff records, and `AutofixStoppingPoint` / `auto_create_pr` preferences—the control plane CERT scopes when automation is on. Tip includes markdown sanitization toward agents—defense-in-depth pattern, not proof hosted Seer remediates CVE-2026-90999.

tenet-security/agent-jackstop (host hardening pack)

SEC-M3 / TOL-M1 / TOL-M2 / TOL-M3 / SCI-M2 Not Demonstrated; SEC-M1 Partial; HUM-M1 / OBS-M1 Not Applicable on this config-only tree.

Manual pattern: deny-by-default egress, approve-before-exec, credential-path blocks, treat tool/log output as data. Prompt-only “ignore untrusted data” is explicitly unreliable. Sibling class to PhantomFix (DSN→MCP/tool output), not a Seer-autofix retest.

Limits: no live Seer; no public DSN→autofix PoC; no production re-run of PhantomFix.

Soft CTA: /aprf/assess/ (self-attest, not certification) and the APRF Auditor skill for your agent host.

How to Prevent It

Next 24 hours

- Disable Seer (or sibling) auto-handoff to coding agents until package-install gates and human-start exist.

- Deny-by-default agent package installs; allowlist only what CI already pins.

- Inventory public-DSN projects with agent integrations; preserve Sentry + agent logs on suspicion; rotate repo tokens only with a supporting timeline.

Next 30 days

- HUM-M1: human-initiated remediation only on frontend DSN projects.

- TOL-M1 / TOL-M2 / TOL-M3 / SCI-M2: unknown packages never install from agent context; consider agent-jackstop-style egress/approval configs on coding agents.

- SEC-M3: fabricated “missing package” events must not reach install tools; treat monitoring bodies as untrusted context.

- OBS-M1: event ID → Seer decision → agent → package digest.

Longer term

Keep autofix analysis advisory—not the auth token for privileged tools. Prefer sandboxed agents without long-lived repo write creds for investigation. Treat every public write path that creates agent work items as an injection surface until proven otherwise.

Engineering Lessons

1. Public write ≠ low privilege when the reader is an agent with install and repo tools.

2. “Analysis” is still untrusted if it embeds attacker-controlled fields.

3. PR review is not a control for actions that complete before any PR exists.

4. Autofix inherits the agent threat model—faster triage without tool gates is just faster compromise.

5. DSN rotation is hygiene, not a root-cause fix—break the telemetry→tool authorization edge.

Could this happen to you?

- [ ] You use error monitoring with a public/client DSN

- [ ] An AI “autofix” or remediation feature can hand issues to a coding agent

- [ ] That handoff can run without a human starting each job

- [ ] The coding agent can install packages or run shell during investigation

- [ ] The agent holds credentials to connected source repositories

If two or more are true, PhantomFix is your failure class—even if you do not use Sentry by name.

Continues in the APRF Incident Corpus

- Related: ContextCrush — trusted channel injects into coding agents; here the channel is error telemetry + autofix RCA.

- Related: Deadbugz — delayed malicious guidance; PhantomFix is immediate once autofix accepts the fabricated issue.

- Related: GhostSplice — agent follows poisoned task shape; different delivery, same tool/HITL gates.

FAQ

Is a public Sentry DSN a vulnerability by itself? No. Browser SDKs need a public submit path. The failure is chaining that path to an autonomous privileged agent without treating event fields as untrusted for tool authorization.

Would assessing a public application repo with APRF have caught this? Assessing your agent host (package allowlists, HITL, traces) can surface TOL/HUM/OBS gaps. Offline Core+Agents on open `getsentry/sentry` shows Partial/Not Demonstrated on those families—useful for host readiness, not a score of hosted Seer. Absence of findings in an app repo does not prove Seer toggles are safe.

How is this different from Deadbugz? Deadbugz poisons MCP tool metadata after a call threshold via a malicious server. PhantomFix poisons the autofix task brief via fabricated monitoring events. Both are instruction channels into coding agents; delivery and trust boundaries differ.

What can APRF miss here? Runtime Sentry project settings, Seer handoff flags, vendor SaaS patches, coding-agent OAuth scopes, and whether package install is enabled only in a cloud sandbox you never commit to git.

References

1. CERT/CC — VU#212479: Sentry Seer vulnerability allows attacker-controlled input to be executed in a privileged environment (2026-09-16)

2. CVE Program — CVE-2026-90999

3. Nikita Benkovich & Vitalii Valkov / agyn — PhantomFix: a fabricated bug that hijacks an AI autofix agent (2026-09-14)

4. Related corpus: ContextCrush, Deadbugz, GhostSplice