On September 18 and 19, 2026, TechCrunch, The Hacker News, and The Register each reported the same story: three security researchers at a small firm called Hacktron AI had chained a bug in OpenAI's community forum software together with a login misconfiguration to take over OpenAI employees' ChatGPT and Codex accounts, then reach OpenAI's internal GitHub organization. The vulnerability was found in July 2026, reported through OpenAI's bug bounty program, and patched the same day. OpenAI paid a bounty. No account is still exposed. What made the story newsworthy two months later was not the breach itself, it was one detail buried in the researchers' own writeup: an earlier Claude model could not produce a working exploit across several attempts, and a newer one, Claude Opus 5, did it within hours of its release.
What Actually Happened, According to the Disclosure
The entry point was mundane. Apple's HEIF photo format, the one iPhones save images in by default, was the trigger. OpenAI's community forum, hosted on Discourse software at community.openai.com, processed uploaded images through ImageMagick, which in turn called a library named libheif to decode them. Libheif versions 1.19.7 and 1.19.8 contained a heap buffer overflow, a memory-corruption bug that let a maliciously crafted image run code on the server handling the upload. That bug alone was serious: Discourse's own advisory for the issue, tracked as GHSA-vhm9-85gw-x335 and CVE-2026-32882, carries a CVSS severity score of 8.8, in the high range.
What turned a forum bug into an account-takeover story was a second, separate flaw: a misconfiguration in the single sign-on system connecting the community forum to OpenAI's broader identity infrastructure. Chained together, the two flaws meant that compromising the public help forum could lead to compromising the same login system trusted by employees' ChatGPT and Codex accounts.
The forum angle made the bug easy to trigger without any special access. Uploading a photo, including one taken on an iPhone and saved in HEIF format by default, is an entirely ordinary action on a support forum. Someone posting a screenshot of an error message, or a photo of a device, would have no way of knowing their upload was being parsed by a vulnerable library on the other end. No insider access or special privileges were needed to reach the vulnerable code path, only a normal forum account and an image.
From a Forum Post to an Internal Repository
Using that chain, the Hacktron team says it reached multiple OpenAI employees' ChatGPT and Codex accounts, then used a compromised Codex session to reach OpenAI's internal GitHub organization. To demonstrate access without going further, the researchers opened a single, harmless pull request in an internal repository rather than reading or taking any source code or customer data. OpenAI later confirmed the finding and said the bounty it paid recognized, in its words, the OpenAI-side finding, not the actions against Discourse, the separate open-source forum software whose maintainers issued their own fix and public advisory independently.
- Vulnerability found and an initial exploit chain built: around July 23 to 25, 2026
- Reported to OpenAI through its Bugcrowd bug bounty program: July 25, 2026
- OpenAI's fix confirmed: within about 14 hours of the report, the same day
- Discourse published its own advisory and patched releases for the underlying libheif issue: July 28, 2026
- OpenAI paid a $6,500 bounty for the OpenAI-side finding
- Public reporting broke: September 18 to 19, 2026
The Detail Driving the Headlines: One Model Failed, the Next One Didn't
Patched bug bounty findings surface constantly and rarely make news outside security circles. What made this one different is a detail the researchers included in their own writeup. Working to turn the libheif memory-corruption bug into a working exploit, the team first used Claude Opus 4.8, and by their account it struggled across multiple sessions to produce reliable code against a system protected by ASLR, address space layout randomization, a standard defense that randomizes where code runs in memory specifically to make this kind of exploit harder to write. Then, within hours of Anthropic releasing Claude Opus 5 on July 24, 2026, the same team used the new model and says it generated a working exploit the same day.
Why a Few Hours Matters More Than the Bug Itself
Individual zero-days get found and patched constantly, that is what bug bounty programs exist for. What is harder to patch is a shift in how quickly offensive capability can move. The researchers put it directly: work that once needed a well-resourced team and months of effort, they wrote, can now be compressed into days. Whether one research team's account should be read as an industry-wide baseline is a fair question. The underlying pattern is easier to verify on its own terms: model capability on a task like exploit generation is not fixed between releases, and a defense that holds against one model generation is not guaranteed to hold against the next. That is a different risk model than the one most security teams have planned around, where an attacker's tools mostly stay constant and only their time and skill vary.
The OpenAI chain was also not an isolated target. Hacktron's researchers describe a broader project, nicknamed HEIF Heist internally, that examined the same class of image-parsing vulnerability across other platforms including Slack, Meta, GitHub Enterprise, and frameworks built on Rails and Node.js, reportedly for under $3,000 in combined token costs over about two months with a three-person team. That detail matters less for whatever specific bugs turned up elsewhere, most of which have not been detailed publicly, and more for what it says about cost: a research effort that would once have required a well-funded team now fits inside a small startup's compute budget.
Patched, Paid, and Responsibly Disclosed
It is worth being precise about what this story is not. It is not an active, unpatched vulnerability sitting in the wild. OpenAI fixed the SSO issue and the underlying libheif bug, revoked the affected authentication sessions, and paid Hacktron's team a bounty through its Bugcrowd program. OpenAI has said only that it has resolved the issues Hacktron uncovered, without detailing the login flaw itself. Discourse, whose forum software was the entry point, published a separate GitHub security advisory and shipped patched releases for the underlying image-processing bug in late July. The researchers, for their part, say they stopped at a single proof-of-concept pull request rather than reading further into OpenAI's codebase. Every part of this, discovery, disclosure, patch, payment, is the bug bounty system working as intended, not a breach still in progress.
Responsible disclosure means a researcher reports a bug privately to the affected company, gives it time to fix the issue, and only goes public after a patch ships. That is the pattern this story follows, from a private July report to public coverage in September, two months after the fix.
The Honest Takeaway: This Is an Account Architecture Story, Not a Memory Story
It would be easy to read a headline like this one and assume it says something about ChatGPT's memory feature, or about AI memory being unsafe generally. It does not. Nothing in the reporting ties this incident to what ChatGPT or Codex remember about a conversation. The vulnerability lived in a forum's image-upload pipeline and a login system, components that would exist regardless of whether any product involved had a memory feature at all. The real lesson is about identity and blast radius: what happens when one login is trusted by more systems than it should be.
Blast Radius: What One Compromised Login Can Reach
Single sign-on exists to make life easier: one login, many connected systems, fewer passwords to manage. That convenience is also the mechanism this story turns on. Because OpenAI's community forum trusted the same identity infrastructure as employee ChatGPT and Codex accounts, a bug in a public-facing forum's image parser became a path toward an internal code repository. That is not a criticism unique to OpenAI. Most large organizations run some version of the same tradeoff, connecting a public-facing surface to internal systems through shared identity infrastructure, because rebuilding a separate login for every system creates its own operational headaches. The lesson generalizes past this one company: the more systems a single login can reach, the more that login's weakest connected surface, in this case a help forum nobody would have flagged as sensitive, becomes everyone's problem.
A single office key that opens the lobby, the supply closet, and the server room is convenient, right up until someone picks the lobby lock. Nobody puts a strong lock on the lobby door because nobody thinks of it as sensitive, until it turns out to open everything else too.
Why This Is Worth Thinking About for Personal AI Memory, Too
That same structural question applies, at a smaller scale, to how people use AI assistants day to day, and it has nothing to do with whether this specific bug is fixed, it is. Most people now have one login controlling both an AI assistant and a growing store of what that assistant remembers: past conversations, documents, preferences, sometimes months or years of context. If that login is the only thing standing between an attacker and everything an assistant knows about someone, the assistant's memory feature is not the risk, the concentration is. A compromised password, a phished session, or a misconfigured integration does not just hand over a chat window, it hands over whatever memory sits behind it.
This is not a claim that any particular AI product handles that risk poorly, or that OpenAI's incident says anything about its memory architecture specifically. It does not, and the bug described above never touched it. It is a fair, general point about where personal context lives and how many systems one login controls. MemX's approach is to keep that memory layer separate from any single chatbot's account: memory lives in MemX, described honestly as private by architecture rather than end-to-end encrypted or zero-knowledge, and it works across ChatGPT, Claude, and Gemini rather than being tied to one vendor's login. That does not make MemX immune to every category of risk a login-based system faces. It does mean a compromised login on any one of those three assistants is not, by itself, a path to the memory layer behind it, a structurally different arrangement than one login controlling both an assistant and everything it remembers.
None of this is specific to AI assistants either. Password reuse, SSO sprawl, and one login controlling too much have been security fundamentals for decades, long before language models entered the picture. What has changed is the speed at which a weak point in that architecture can be found and turned into a working exploit. A gap that might once have sat unnoticed for months, because building a reliable exploit took a skilled team weeks, went from forum bug to internal repository access in under three days in this case. That compression is the part of the story likely to outlast this particular headline, regardless of which AI lab or which login system is involved next time.
| What's at Risk | Memory Built Into One Assistant's Login | MemX (Private by Architecture) |
|---|---|---|
| Where memory data lives | Inside the same account and identity system as the assistant itself | In a separate layer outside any single chatbot's account |
| What one compromised login can reach | Potentially the assistant and whatever it remembers, plus anything else tied to that same identity system | The assistant session; the memory layer sits behind a separate login |
| Cross-assistant exposure | Memory typically stays locked to one vendor's ecosystem | One memory store usable across ChatGPT, Claude, and Gemini, not duplicated inside each vendor's own account |
| Security model, as described | Varies by vendor and product | Private by architecture: per-user isolation and encryption at rest, not end-to-end encryption or zero-knowledge |
What Security Teams and Everyday AI Users Should Take From This
For security teams, the through-line is not really about OpenAI, or even about Discourse's HEIF-parsing bug specifically. Any organization connecting a public-facing surface to internal systems through shared identity infrastructure has the same shape of risk sitting somewhere in its architecture. For everyday AI users, the practical takeaway is smaller but concrete: the account securing an AI assistant now secures more than a chat window. It is worth treating that login, and whatever memory sits behind it, accordingly, whichever assistant is in use and wherever that memory actually lives.
01Did Claude actually hack into OpenAI?
Not on its own. Three researchers at Hacktron AI used Claude Opus 5 as a tool to help write exploit code for a vulnerability chain they had already found. An earlier model, Claude Opus 4.8, struggled to produce a working exploit for the same bug; the researchers say Claude Opus 5 succeeded within hours of its July 24, 2026 release.
02Is the OpenAI vulnerability still active?
No. OpenAI patched the SSO misconfiguration and the underlying libheif bug, revoked the affected authentication sessions, and paid Hacktron a bounty. Discourse, the separate forum software involved, published its own fix and advisory in late July 2026. Public reporting followed in September, after the fix was already in place.
03What did the researchers actually access at OpenAI?
According to their own account and subsequent reporting, they reached several employees' ChatGPT and Codex accounts and, through a compromised Codex session, OpenAI's internal GitHub organization. They opened one harmless pull request as proof of access and said they did not read or take any source code or customer data.
04Was this vulnerability related to ChatGPT's or Claude's memory features?
No. The bug chain involved a community forum's image-upload pipeline and OpenAI's single sign-on configuration, components unrelated to either company's memory features. Nothing in the reporting connects this incident to what either assistant remembers about users.
05How does MemX's privacy approach differ from a typical AI assistant account?
MemX keeps a person's memory layer separate from any single chatbot's login, described as private by architecture rather than end-to-end encrypted, and works across ChatGPT, Claude, and Gemini instead of being tied to one vendor's account system.
