AgentForger: One Link Turned ChatGPT Into an Attacker's Employee

One phishing email, disguised as a productivity tip, was enough to turn a victim’s own ChatGPT account into an attacker’s inside employee — one with real connector access to Outlook, Slack, and Teams, and no approval prompt standing in the way.

What Happened

Zenity Labs disclosed “AgentForger,” a vulnerability in OpenAI’s ChatGPT Workspace Agents that exploited two URL parameters in the Agent Builder — the template selector and an initial prompt field. Normally, deploying a new agent against a company’s connected accounts requires a user to review and approve its permissions. AgentForger skipped that step entirely: a crafted link caused ChatGPT to auto-build an agent with every permission set to “Never ask,” then launch it immediately against the victim’s real, already-authorized accounts.

Once live, the forged agent polled the attacker’s inbox every five minutes for new instructions — effectively giving the attacker a standing, remote-controlled foothold inside the victim’s workspace. Zenity researcher Mike Takahashi demonstrated the forged agent could map an organization’s structure across Outlook, Slack, Teams, Drive, SharePoint, and Calendar; pull M&A documents and board presentations; harvest credentials accidentally left in Slack messages; and impersonate the victim to send phishing messages or request wire transfer approvals from colleagues who trusted the sender.

Zenity reported the flaw to OpenAI through its Bugcrowd program on June 4, 2026. OpenAI confirmed it within 24 hours and removed the vulnerable URL parameter by June 8 — a four-day turnaround with no evidence the flaw was exploited before the patch shipped.

Why It Matters

The technical novelty here isn’t prompt injection — it’s what Zenity calls cross-site agent forgery, a CSRF attack adapted for agent infrastructure. Classic CSRF tricks a browser into replaying a user’s session against a web app. AgentForger tricks ChatGPT into building and authorizing a new piece of software — an agent — using a session the victim never consciously created. The victim’s click didn’t leak a password or a cookie; it manufactured a standing employee with real permissions, on the attacker’s schedule.

That distinction matters because it sidesteps the security assumptions most enterprises have already made about chat-based AI tools. Credential leaks get caught by rotation policies and MFA. A phishing email that spawns its own persistent, connector-authorized agent doesn’t look like credential theft at all — it looks like normal product usage, right up until it starts exfiltrating board decks.

The Pattern

This is the fourth agentic-AI security incident Stack Archive has covered in as many months — following the Hugging Face agent hack (Jul 20), the jump in self-replicating agent success rates from 6% to 81% (May 10), and AI-generated exploits closing the 90-day patch-disclosure window to 30 minutes (May 12). The common thread: agent autonomy is outrunning the approval and monitoring controls built for human-paced software.

What This Means for Builders

Any team building or deploying agent frameworks with connector access should treat URL-triggered agent creation as an attack surface in its own right, not just a convenience feature. Concretely: require explicit, non-bypassable confirmation before any agent is granted “Never ask” permissions, and audit whether your own agent builder accepts configuration via query parameters at all. The four-day fix window here is the good outcome — it depended on a researcher finding this before an attacker did.

Source: The Decoder

Content created with AI assistance and reviewed for accuracy.