A photo, Claude, and the road to OpenAI

The story didn't start with a "rebellious" AI. It started with a photo.

Between July 23 and 25, three researchers from Hacktron AI found a chain of flaws that allowed them to demonstrate access to OpenAI employee accounts and propose a harmless change in an internal repository. The research was disclosed in September, and OpenAI confirmed it fixed its part and paid a $6,500 bounty.

The headline "they hacked OpenAI with Claude" works great for social media. It also oversimplifies what happened.

Claude was an important tool for speeding up the creation and fine-tuning of an exploit. But it didn't choose the target, didn't single-handedly invent the entire chain, and didn't operate without people. There were researchers, an authorized bug bounty environment, technical decisions, and responsible disclosure. What did change was the time needed to turn a technical suspicion into a demonstration of impact.

What actually happened

The entry point was OpenAI's public forum, built on Discourse. When processing certain image formats like HEIC or HEIF, the system relied on auxiliary components to convert them. One of those components, libheif, contained a memory issue that could be exploited under specific conditions.

That flaw wasn't, by itself, "access to OpenAI." It was a first crack in a public service.

The second part was more delicate: a misconfiguration in the single sign-on flow, known as SSO. The combination allowed forum access to escalate to employees' ChatGPT and Codex accounts. From one of those connected accounts, the researchers demonstrated they could open a change request inside the internal repository.

According to the technical report published by Hacktron, they didn't read code or explore services like corporate email or chat. They left a controlled proof, stopped the test, and reported the finding.

Claude accelerated the exploit; it didn't replace the attack

This is the point worth discussing without the hype.

The researchers first tested with Claude Opus 4.8 and couldn't get a working exploit. With a later version of the model, they were able to move much faster. Claude helped analyze the flaw's behavior, suggest adjustments, and generate material for the demonstration.

That doesn't mean anyone can type "hack OpenAI" into a chat window and get access.

The team already understood the problem, had a permitted target, could validate results, and knew when to stop. AI lowered the cost of iterating: try an idea, fail, fix it, and try again. In security, that kind of time savings really is a massive difference.

SecurityWeek reported an important nuance: the library vulnerability and the exact way it was exploited require care when described. Solid learning doesn't depend on repeating the offensive detail. It depends on understanding that a forgotten dependency and an overtrusted identity become critical when they connect.

The real risk was in the trust chain

A modern application is rarely just one application.

A user logs into a service. That account enables an agent. The agent can see documents, repositories, email, or tasks. The service processes files with third-party libraries. Each piece can be reasonable on its own.

The problem shows up when a small flaw jumps context.

Before, compromising a forum could mean manipulating posts or stealing user data. Now it could be used to reach a corporate session, activate an agent with code access, and get a valid action inside internal tools. The attacker no longer needs to break down every door: they look for a door that has too many keys.

This isn't an argument for disconnecting everything or for stopping using AI. That would be a convenient and impractical response. It's a wake-up call to design permissions with the same seriousness we use to design infrastructure.

What teams should review

• Truly separate community, customer, and employee identities.
• Apply least-privilege permissions to agents and connectors.
• Treat repositories, email, and storage as sensitive capabilities, even when access comes "from a trusted account."
• Inventory the dependencies that process files uploaded by users.
• Revoke sessions and credentials when a peripheral service suffers an incident.
• Require human confirmation for sensitive agent actions, such as creating changes or accessing private information.
• Test escalation paths, not just isolated vulnerabilities.

The right question is no longer "Is my chatbot secure?" It's "What can a compromised account do after my chatbot, agent, or connector receives its permissions?"

My takeaways

Claude wasn't the villain or the sole protagonist. It was the accelerator.

The relevant story is that a small team went from a flaw in an image to an internal proof of impact in under 72 hours. A combination of legacy components, connected permissions, and automation shrank an investigation that used to take weeks.

There's also good news: the researchers reported it, OpenAI fixed it, and there was a bounty. That's how security research should work. The problem is that a real attacker would have the same technical incentives, but not the same ethical limits.

Conclusion

AI is making both offensive and defensive exploration cheaper at the same time. Teams that only look at the productivity side will be late to the conversation.

Your attack surface no longer ends at your public application. It includes every file you process, every dependency you don't update, every shared login, and every agent you give permissions to "because it's more convenient."

Tools are becoming more capable. Permission discipline has to become more boring, stricter, and much better executed.