Parameter.ai took over ChatGPT accounts. Here's what to rotate.

What happened

Parameter.ai's security lab published a writeup titled *We Found a Gap at OpenAI* describing a working account-takeover chain against ChatGPT. The post landed on Hacker News at 134 points and climbing, which is the usual signal that a vendor-disclosed flaw actually works in the wild rather than being a theoretical paper finding.

The attack doesn't rely on a single memorable CVE — it chains together assumptions OpenAI's auth surfaces make about each other, so a request that looks legitimate to one component is trusted blindly by the next. The researchers walked through a flow where an attacker could coerce a victim's browser into completing an OAuth-style handshake against an attacker-controlled context, then redeem the resulting session on the attacker's side. The net effect: full access to the victim's ChatGPT account, including conversation history, custom GPTs, connected Actions, memory, and anything the victim had wired up through the Apps/Connectors surface.

Parameter.ai says they reported the issue through OpenAI's disclosure channel and that the specific gap they exercised has been closed. The writeup is deliberately light on the exact mechanics — enough detail to be credible to practitioners, not enough to be a copy-paste exploit kit. That's the right tradeoff for a disclosure post, but it also means you can't fully derive your blast radius from the post alone.

Why it matters

Two things make this worse than a typical SaaS auth bug.

First, ChatGPT is no longer a chat UI. It's a credential vault. A compromised ChatGPT session now exposes whatever OAuth tokens the victim granted to Gmail, GitHub, Google Drive, Jira, Notion, Zapier, and every custom Action an enterprise admin wired up — that's the real blast radius, not the chat logs. The industry spent the last eighteen months pushing "AI agents with tool access" from demo to production, and the identity model never meaningfully caught up. OAuth scopes were designed for a world where the client was a known binary with a known UI, not a general-purpose agent that will cheerfully use any token you hand it.

Second, this is the second high-signal auth incident around AI vendors in the past month. We've now seen a plausible pattern: the auth seams between a vendor's web app, their mobile app, their API, their enterprise SSO, and their third-party Actions ecosystem are where the bugs live. Any one of those surfaces is probably well-tested in isolation. The handoffs between them are not. Pentest firms are structured around testing *a* product; the exploitable attack surface in modern AI platforms lives at the boundaries between five products that share a cookie jar.

The community reaction on the HN thread splits predictably. One camp — mostly people who've shipped auth code — reads the Parameter writeup as a textbook "redirect validation / state parameter / origin check" chain, exactly the class of bug OAuth has been shipping with since 2012. The other camp — mostly ChatGPT power users — is realizing for the first time that their chat history isn't the asset at risk; the Google Drive connector they wired up six months ago and forgot about is. Both are correct. The underlying bug class is boring. The deployment context is not.

It's also worth being honest about what we don't know. Parameter.ai is a security vendor publishing a lab finding; the post functions partly as marketing. The HN discussion includes at least one request for OpenAI to publish its own post-mortem with a timeline. Until that lands, you're trusting a single vendor's reconstruction of events. Treat the disclosure as credible enough to act on, but not as the complete picture — assume there was a window during which this was exploitable in the wild and plan rotation accordingly.

What this means for your stack

If your team or company uses ChatGPT in any meaningful way, you have work to do this week, not next sprint. Concretely:

Rotate ChatGPT-adjacent API keys first. Any OpenAI API key stored in a ChatGPT custom GPT, in a Playground session, or pasted into a conversation should be considered potentially read. Generate new keys, scope them narrowly, and delete the old ones in the OpenAI dashboard — don't just mark them inactive. If you've been meaning to move from org-wide keys to per-project keys, this is the forcing function.

Audit Actions and Connectors. In the ChatGPT UI, walk through every custom GPT your organization has published and every Connector (Google Drive, GitHub, Gmail, Microsoft 365, etc.) attached to any account. For each one, revoke the connection on the *provider* side — Google's security dashboard, GitHub's authorized OAuth apps page, Microsoft's My Apps portal. Then re-grant only what's actively used. Revoking inside ChatGPT alone is insufficient if the underlying refresh token was issued before the fix.

Force-logout active sessions. OpenAI's account settings include a "log out of all devices" option. Use it. For ChatGPT Enterprise/Teams admins, invalidate all SSO sessions from your IdP (Okta, Entra, Google Workspace) and require re-authentication with MFA. This is the only way to be sure no attacker-redeemed session is still live.

Check memory and shared conversations. ChatGPT's memory feature retains strings across conversations. If an attacker had access, they may have planted content designed to persist — a prompt-injection payload that triggers on future questions, or exfiltrated data stashed in a shared link. Clear memory, review shared conversation links, and delete anything you don't recognize.

Treat the chat log as sensitive. For the paranoid — and in 2026 that's just "the competent" — assume anything you've pasted into ChatGPT in the past several months is readable. Secrets, internal URLs, customer data, proprietary code. If any of that matches an incident-response trigger in your policy, trigger it. The uncomfortable truth is that most organizations have no idea what their employees have typed into ChatGPT, which means they have no idea what to rotate.

The timeline matters. OpenAI confirms fixes privately but has not, as of this writing, published a disclosure with affected-window dates. Assume the exploitable window was weeks, not hours, and work backward from there. If you have logs of OAuth consent grants to ChatGPT from your IdP, pull them and look for anomalies — unusual geographies, consent events outside business hours, scope grants that don't match the GPT a user says they were installing.

Looking ahead

This won't be the last one. The AI platforms are now the connective tissue between every SaaS tool an engineer touches, and the identity primitives holding that tissue together were designed for a simpler era. Expect more auth-chain disclosures across OpenAI, Anthropic, Google, and the agent-framework startups over the next twelve months — and expect each one to feel individually boring and collectively alarming. The right posture is to stop treating your AI vendor as a chat product and start treating it as an identity provider you didn't choose. Rotate keys on a schedule. Audit connectors quarterly. And when the next Parameter.ai writeup drops, assume you have about a week before the proof-of-concept shows up on GitHub.