A Hijacked AI Assistant Login Can Reach Your Connected Apps

Security researchers at Hacktron took over the ChatGPT accounts of several OpenAI employees on July 25, 2026 by exploiting a flaw in OpenAI's single sign-on reached through the company's public help forum, then used an employee's connected Codex coding agent to open a pull request in OpenAI's internal monorepo. Hacktron published the account on September 13, 2026; the flaws were reported on discovery, patched, and OpenAI paid a $6,500 bounty. Hacktron said the escalation was a sign-on problem rather than a forum problem, meaning any service using the same sign-on could have been the way in, and that every AI assistant connected to GitHub, Google Drive, email, Slack or a CRM carries the same shape of risk.

On July 25, 2026 researchers at Hacktron, a commercial security firm, took over the ChatGPT accounts of several OpenAI employees without any action by those employees. They got in through OpenAI's public help forum and a flaw in the company's single sign-on. Because the accounts had Codex, OpenAI's coding agent, connected to the company's GitHub, the researchers could reach internal repositories. To prove it without reading any code, they had one employee's Codex open a pull request in OpenAI's internal monorepo, then stopped. Hacktron published the account on September 13, 2026; the flaws were reported on discovery, patched, and OpenAI paid a $6,500 bounty. The reason it matters to anyone outside OpenAI is a sentence in the write-up: the escalation was not a forum problem but a sign-on problem, and any service using the same sign-on could have been the way in. Every AI assistant that can be connected to GitHub, Google Drive, email, Slack or a CRM now carries the same shape of risk. One login, once taken, reaches everything that login was allowed to touch. The facts below are Hacktron's, read on September 18, 2026; we did not find a separate public statement from OpenAI. 1. 01Nine links, under 72 hours, no click required.An image-decoding bug on a forum, an unpatched Linux package, and an SSO identity flaw gave account access to anyone who had logged in to the forum. Discovery to internal-repo access took less than three days. 2. 02The connectors were the blast radius.The accounts themselves held chats. What made them dangerous was Codex connected to GitHub, and the write-up notes Slack and email connectors would have been reachable the same way. 3. 03It is fixed, and it was not unique to OpenAI.Both vendors patched quickly by the researchers' account. The same design, one sign-on across a forum and a production app, exists at most companies that run both. 4. 04Your move is a connector audit, not a vendor switch.List every connector on every assistant account, cut scopes to read-only where you can, separate the accounts that can push to production, and put agent-authored code through review. 01 — The disclosureWhat happened, and when The work began on July 23, when the team reviewed how OpenAI's community forum, which runs on the open-source Discourse platform, handled uploaded images. Files in the HEIC and HEIF formats took an unusual route through a command-line image tool and into a decoding library called libheif, and the version of that library in the forum's Debian-based container lacked security fixes that had been made upstream without being labelled as such. That gave the researchers a way to run code on the forum. The second flaw was the one that turned a forum into a door: OpenAI let people sign in to the forum with their OpenAI identity, and a weakness in that identity flow meant a compromised forum could yield working ChatGPT and Codex sessions for anyone who had logged in there. Discovery to repository access From starting on the forum's upload path on July 23 to demonstrated access to internal repositories on July 25, by Hacktron's timeline. Window the write-up states Hacktron says that until two months before its September 13 post, any user or employee who logged in to the forum could have had ChatGPT and Codex accounts taken over. Bounty paid by OpenAI Reported to OpenAI and to Discourse on discovery. Discourse replied within a day and had a fix the next working day, and began sandboxing its image tool. OpenAI patched the sign-on flaw. 02 — The chainThe chain in plain words Hacktron lists the chain as nine components. Here it is with each link described by what it did, and nothing about how; the technical write-up exists for readers who need that. 1. An image decoder libheif had a memory bug in the code that reads HEIC files. 2. A Linux distribution Debian had not carried the upstream fix into its package, because the fix was never marked as a security fix. 3. An image tool ImageMagick used that decoder to convert uploads. 4. Forum software Discourse handed HEIC uploads to that tool. 5. OpenAI's community forum ran that software, so an uploaded image could run code on the forum server. 6. OpenAI's sign-on let forum users authenticate with their OpenAI identity, and a flaw in that flow let a compromised forum obtain sessions for those identities. 7. ChatGPT and Codex accounts of employees who had used the forum were therefore reachable. 8. A GitHub connector on the Codex of one employee was already authorised for the OpenAI organisation. 9. Internal repositories were reachable through that connector, demonstrated by a pull request and nothing more. Steps one to five are a supply-chain story that will repeat with other libraries. Steps six to nine are the part this post is about, because they are a property of how AI assistants are wired into a company, not of any one bug. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access - Discourse was merely one way of proofing it.Hacktron, 'Hacking OpenAI', September 13, 2026 03 — The lessonWhy the login is now a master key Two years ago a stolen chat-assistant login exposed chat history. Today the same login can carry a coding agent that pushes to your repositories, a connector that reads your shared drive, a connector that reads and sends email, and an integration with your CRM. The account has become an identity that acts, with the union of every permission its owner ever granted, and it is usually granted generously because each connector asked nicely, once. Hacktron's researchers did not need to break GitHub; they needed one account whose agent was already trusted by it. That is the same problem we described for service accounts and API keys in our agent identity playbook https://www.digitalapplied.com/blog/agent-identity-credentials-non-human-access-2026-playbook , arriving through the human side. Three consequences follow. The reach of a compromised assistant account is the sum of its connectors, so reducing connectors reduces the reach. An agent that can write, such as a coding agent with push rights, turns account access into change access, so agent-authored changes need the same review as a new contractor's. And a company's sign-on is only as strong as the least important service it covers; a help forum shared the identity of the production app. The same logic applies to Anthropic's Claude, whose merged chat and work app we covered in our post on what teams should set https://www.digitalapplied.com/blog/claude-chat-cowork-merge-docs-slides-what-teams-set , and to every other assistant with a connector directory. 04 — Your actionsThe checklist for connector users Nothing below requires a security team. It requires an admin, an afternoon and a spreadsheet, and it should be repeated whenever a new assistant or connector is adopted. | Our checklist, derived from the chain Hacktron described on September 13, 2026. The cadence column is our suggestion. | | | |---|---|---| | Action | Why, in this incident's terms | How often | |---|---|---| | List every connector on every assistant account, with its scopes | The blast radius was the GitHub connector nobody was thinking about when they logged in to a forum. You cannot reduce what you have not listed. | Now, then quarterly | | Prefer read-only scopes; remove write where the workflow does not need it | A read-only repository connector would have exposed code but not allowed a pull request. Most drive and mail connectors work fine read-only. | At each grant | | Separate the accounts that can reach production repositories or admin systems | An employee's everyday assistant account carried organisation-wide repository access. A dedicated account for privileged agents keeps casual use apart from it. | Once, then enforce | | Review which services share your sign-on, and which of them are low-trust | A community forum and a production app shared one identity. Anything public-facing that accepts uploads deserves its own login or a stricter flow. | Now, then on each new service | | Revoke unused connectors and stale sessions | The window the write-up describes was two months. A connector granted for one project and never removed is a standing grant to whoever gets the account. | Monthly | | Require review on any code an agent pushes, and log who prompted it | The proof of access was a pull request an agent opened on a stranger's instruction. Branch protection and required review turn that into a visible event rather than a merge. | Enforce in the repository | Hacktron's patch notice applies to anyone self-hosting Discourse: rebuild the installation rather than updating through the web interface, because older container images may still carry the vulnerable decoder. Its broader advice is to update libheif through your distribution's security channel, disable HEIF and AVIF decoding where you do not need it, and isolate image processing in a sandbox. Discourse's security advisory https://github.com/discourse/discourse/security/advisories/GHSA-vhm9-85gw-x335 has the versions. 05 — ProcurementWhat to ask a vendor Every assistant vendor now sells connectors, and the questions below are fair to put to any of them, including the one you already pay. They are the questions this incident would have answered early. - Which of your services accept our organisation's sign-on, and does a session in one of them grant a session in the assistant? - Can an admin see every connector every user has authorised, with scopes and last use, and revoke any of them centrally? - Do you log the actions an agent takes through a connector, and can we export that log to our own systems? - Can we require approval before an agent performs a write action through a connector, and set that policy per connector? - What is your disclosure timeline for an identity flaw that affected customer accounts, and where is it published? A vendor that answers the second and third questions with a product page is ahead of one that answers with a roadmap. The evidence-logging side of that, which records to keep so an incident can be reconstructed, is in our post on agent incident evidence https://www.digitalapplied.com/blog/ai-agent-incident-evidence-logs-to-keep-sentinellabs . 06 — The economicsThe cost side, and the threat model The part of Hacktron's account that should change a threat model is what the attack cost. The firm says the OpenAI work took a few days of an AI agent's time and a few hours of human time, that the wider two-month campaign across several companies cost under $3,000 in model tokens for three researchers, and that adapting the exploit to each new target took one or two days. The researchers used Claude models to develop the exploit, and report that a task one model version failed at across several attempts succeeded within hours on the next. Their conclusion is that the expertise which used to make a known bug expensive to weaponise is being turned into compute. For a company that is not a frontier lab, the practical reading is not that attackers are now everywhere but that the price of exploiting a public, unpatched bug in a common library has fallen enough that ordinary businesses are now worth the effort. The defence that costs least is the one this post is about: assume a login will be lost at some point, and make sure that when it is, the account reaches as little as possible. If you would like an outside pair of eyes on how your assistants and agents are connected, our AI transformation service https://www.digitalapplied.com/services/ai-transformation starts every engagement with that map. 07 — Next stepOne account, and everything it was trusted with Audit your connectors before the next disclosure, not after Open the connector settings of every assistant your company uses and write down what each account can reach. Cut write access where nothing needs it, move privileged agents to their own accounts, and turn on required review for anything an agent pushes. It is an afternoon of work, and it is the difference between a lost login being an incident and being a breach.