Skip to content

AI Governance

Researchers used Claude to hack into OpenAI in 72 hours. Here is the login risk behind every AI tool your business uses.

In July 2026, a small security research firm called Hacktron AI used Anthropic's Claude to build a working exploit chain, reported it to OpenAI through OpenAI's own bug bounty program, and both companies fixed it within days. The direct answer for a business owner: the interesting part is not that OpenAI had a bug, every company does. It is that the way in was a minor, unrelated service, OpenAI's community forum, and the way out was OpenAI's own login system, which let the researchers reach employee ChatGPT and Codex accounts and, through those, an internal code repository. If your business has employees logging into AI tools with a shared vendor login, or has connected an AI tool to your email, code, or chat systems, this is worth ten minutes of thought, not a headline about someone else's problem.

By Fabio Rabelo · Founder, ATLACIS ·

What happened

Hacktron AI, a three-person security startup, spent about 72 hours in late July finding and chaining two separate flaws to reach inside OpenAI. The first was ordinary: a photo-upload feature on OpenAI's own community help forum ran on outdated image-decoding software with a bug that had actually been fixed upstream months earlier, but the fix was never formally flagged as a security patch, so it never made its way into the version the forum was running. A specially crafted image file was enough to run unauthorized code on the forum's server. Getting that exploit to work reliably was the hard part, and this is where Claude comes in. The researchers first tried Claude Opus 4.8, an earlier version made available to vetted security researchers, and it could not build a working exploit against a server running standard memory protection, even after several attempts. The evening of July 24, Anthropic released Claude Opus 5. Given the same unsolved problem, a fresh session produced a working exploit in about three hours, and by the next morning the team had confirmed it worked against the exact setup OpenAI's forum used. The second flaw is the one that turned a forum bug into an OpenAI problem. OpenAI's forum let visitors log in with their OpenAI account through a single sign-on connection. Once the researchers had control of the forum's server, a weakness in that login flow let them take over any ChatGPT or Codex account that had ever signed into the forum, without the account owner doing anything or getting any warning. They used one compromised OpenAI employee's account, connected through Codex to OpenAI's internal GitHub organization, to open a harmless test pull request inside OpenAI's own private code repository, proving they had reached it, then stopped and reported everything. Both companies moved fast. OpenAI fixed its side of the login flaw about 14 hours after the report, the forum software vendor shipped its own fix two days later, and OpenAI paid Hacktron a bug bounty. This was authorized, disclosed research from the start, not an AI system acting on its own.

Why it matters for business owners

Most businesses now have at least one AI tool where an employee logs in with a shared account, a company email, or a connected login rather than a fully separate password. That login often reaches further than the one product a business actually pays for and uses day to day. In this case, the path in was not the main ChatGPT product at all. It was a community help forum, the kind of secondary service a business would never think to ask about when evaluating an AI vendor's security. But because that forum shared a login system with the accounts that mattered, a flaw in the forum became a flaw in the accounts. The same pattern applies to any AI tool your business uses. A ChatGPT, Codex, Copilot, or similar account is often connected to other services: GitHub for code, Slack or email for messages, cloud storage for files. If one account is compromised, whatever it is connected to becomes reachable too, quietly and without the account holder noticing anything unusual.

What owners should not misunderstand

This is not evidence that Claude, or AI models generally, are trying to hack anything. Every action here was directed by human researchers working inside an authorized bug bounty program, using a version of Claude specifically made available to vetted security researchers for exactly this kind of work. That is a different situation from an AI agent independently escaping a test environment on its own, which is a separate pattern that other reporting has covered this year. This is also not evidence that OpenAI is unusually insecure. The underlying problems, an unpatched library and a login system that trusted a connected service more than it should have, are common mistakes that could exist at almost any software company managing dozens of connected services. What makes this story worth attention is the identity architecture problem it reveals, not a verdict on one vendor. Finally, this is not a reason to stop using AI coding or workflow tools. The same capability jump that helped researchers build a working exploit is the capability a business's own defenders, and the vendors themselves, can use to find and fix these problems faster too. The story is about verifying what is connected to what, not about avoiding the tools.

The operational lesson

A login is not a single door. It is a chain, and the chain is only as strong as its weakest connected service, which is often not the product you actually think about. A business evaluating an AI vendor's security usually looks at the main product: does the chatbot encrypt data, does it retain conversations, does it train on your inputs. Few ask what else shares that same login, because most businesses do not know to ask, and most vendors do not volunteer the answer. The second lesson sits underneath the first. Claude Opus 4.8 could not solve this problem. Claude Opus 5 solved it within hours of being released. Whatever assumption a business made last quarter about what an AI model can or cannot do to help someone break into a system, or defend one, may already be out of date. Security postures built on "AI tools were not capable of that yet" have a shorter shelf life than most businesses plan for.

What a serious business should do next

List every service your employees have logged into using an AI vendor's shared login, not just the main product. Community forums, documentation sites, developer portals, and demo tools often use the same identity system as the account that actually matters. Check what each AI account is connected to today. A ChatGPT, Codex, or Copilot account tied into GitHub, Slack, email, or shared drives extends its reach to everything it touches. Remove connections nobody is actively using. Fewer connections mean a smaller blast radius if one account is ever compromised. Ask your AI vendor, or whoever manages your account, a direct question: if a secondary or unrelated service using our login was compromised, could that reach our main account and whatever it is connected to? A vague answer is itself useful information. Do not assume a vendor's announcement that something is patched means every service tied to your login received that patch. This incident happened specifically because a real fix existed upstream but never reached the version actually running. Ask what was patched, not just whether something was. Treat any decision to connect an AI tool to your source code, email, or messaging systems as a security decision with a real blast radius, not a convenience toggle to turn on and forget.

The Atlacis view

Atlacis helps business owners see past the assumption that an AI vendor's security is a single yes-or-no question. This story shows why it is not: a business can trust the product it actually uses and still be exposed through a connection it never thought to check, tied to a service it has never heard of. Atlacis helps owners map what their AI tools are actually connected to, where login boundaries really sit, and what a compromise of one account could reach, then builds the habit of rechecking those connections on a real schedule instead of assuming a setup approved months ago still means what it used to.

The short version

  • In July 2026, security firm Hacktron AI used Claude to chain a stale image-processing bug with a flaw in OpenAI's own login system, reaching employee ChatGPT and Codex accounts and OpenAI's internal code repository, confirmed by Hacktron's own published write-up and independently corroborated by TechCrunch, Business Insider, and CryptoSlate.
  • The way in was not OpenAI's main product. It was a community forum that shared a login system with the accounts that actually mattered, showing that a business's real exposure often runs through a service it never thought to check.
  • Claude Opus 4.8 could not build a working exploit for this bug across several attempts. Claude Opus 5, released the next evening, solved it in about three hours, a concrete reminder that AI capability can change faster than a business's security assumptions do.
  • This was authorized, human-directed research disclosed through OpenAI's own bug bounty program, not an AI agent acting independently. Both OpenAI and the affected third-party forum software patched within days.
  • Any AI tool connected to your code, email, or chat systems extends its reach to everything it touches. A compromised account can quietly expose those connections without the account holder noticing.
  • Inventory what your AI tool accounts are actually connected to, remove unused connections, and ask your vendor what shares your login boundary, not just whether the main product is secure.
Tags:AI governancevendor dependencyAI vendor riskdata privacyAI workflow auditsbusiness AIAI decision support
FAQ

Common questions

Does this mean ChatGPT or Codex are not safe to use?
No. The underlying flaws were an unpatched image library and a login system trusting a connected service more than it should have, common mistakes any software company managing many connected services could make. Both were fixed within days once responsibly disclosed. The lesson is about auditing what your AI accounts are connected to, not avoiding the tools.
Should my business stop connecting AI tools to GitHub, Slack, or email?
Not necessarily. Those connections are often useful. The point is to know what is connected, remove what you are not actively using, and understand that a compromised AI account can reach whatever it is linked to.
What is the one thing to check first after reading this?
List what your AI tool accounts (ChatGPT, Codex, Copilot, or similar) are connected to right now, and ask whether a compromise of that account could reach your code, email, or messaging systems. Remove any connection you do not actively need.

Make better AI decisions, starting with one call.

Book a free AI Fit Call. We will tell you what to use, what to avoid, and where to start. No jargon, no pressure.