They Hacked OpenAI in 72 Hours (Using Claude)

0:00 If you let users upload a photo, this next part is about you. A team took one uploaded image and turned it into access to OpenAI employee accounts and then into the company's own private code.

0:11 They did it in under 72 hours. Three researchers, none of them working at OpenAI, and an AI model writing most of the exploit for them. The team is a security startup called HacktRon. The AI

0:22 was Claude, Anthropic's Opus 5, and the unsettling part is how ordinary every single piece of it turns out to be. One thing up front because it matters. They never actually read OpenAI's source

0:33 code. They opened a single harmless pull request to prove they could, then stopped and reported it. By the end of this, you'll know exactly how they got there, one door at a time. So, the real

0:43 question is simple. How does a photo uploaded to a public help forum end up as a commit inside a company's internal code base? The answer is a chain through four doors. So, let's walk each one

0:54 together. At every door, I'll show you the single thing that should have stopped it cold. Look at the whole path on one screen. An image goes into the forum, code runs on the server, a login

1:04 gets hijacked, and a connected account reaches the repository. Let's follow that one image the whole way. Door one opens here at community.openai.com. It's OpenAI's help forum, and like most

1:16 forums, it happily lets you attach an image to your post. First, you upload a HEIC file. That's the photo format an iPhone saves by default, and what the forum does with it next is the entire

1:26 way in. The forum software, Discourse, screens uploads with a quick library called fastimage. Basically, a fast guard that peaks at a file to tell what it is. Fastimage doesn't understand

1:37 HEIC, so it does the worst possible thing. It waves the file straight through. To build a thumbnail, Discourse hands that file to ImageMagick, the standard image tool. ImageMagick then

1:48 hands the real decoding down to a library beneath it called libheif. Think of libheif as the translator that turns the raw file into pixels. That handoff is the risk hiding in a lot of apps.

1:59 Your own code doesn't call the dangerous library directly. A tool three layers down does, so the weak spot stays invisible when you audit the dependencies you think you have. Here's

2:08 the crack. That server ran lib hive version 1.19.7 on Debian. It had a known heap overflow, which just means code that writes past the edge of a chunk of memory. The bug

2:20 was public, the fix existed upstream, and Debian just hadn't shipped it to the machine yet. That gap is more common than it should be. Debian rarely takes the newest release.

2:29 It backports individual fixes into older versions, and until that lands, a server can run a library whose bug is public while the patch waits in a queue. So, a carefully crafted image decoded by that

2:40 unpatched library overwrites memory it was never meant to touch. That hands the attacker read and write access inside the process, and from there, their own code running on Open AI's forum server.

2:51 This step used to need a specialist. Turning a memory bug into a working exploit is slow, delicate craft. Opus 4.8 first spotted the missing patch. Then Opus 5 shipped in the middle of the

3:02 investigation. They handed it the same problem, and it wrote a working exploit in about 3 hours. They confirmed it by reading a system file straight off the server, proof they were really inside.

3:13 So, door one's lesson is blunt. If your fast check can't even recognize a format, don't let the slow one feed it to an unpatched parser. Patch it, sandbox it, or refuse the format. So,

3:24 that's door one, code running on the forum. On its own, that's a forum problem, not an Open AI problem. The second bug is what turned one into the other. Logins on that forum ran through

3:34 Open AI's single sign-on, which means one identity, your Open AI account, works across all of Open AI's sites, the forum included. Single sign-on is like one keycard for a whole building. One

3:46 login, many doors. The flaw was in how that login was wired. By controlling the forum, the researchers could turn forum access into a real login token for a person's actual Open AI account. Not a

3:57 look-alike, not a session on the forum, the real account. In their own words, any user or employee who ever logged into Open AI's help forum could have had their ChatGPT and Codex accounts taken

4:08 over. A side door cut with the building's master key. Door two's lesson is about trust. That forum wasn't even hosted by Open AI. It ran on Discourse's cloud. A service you don't run sitting

4:20 out on the edge should never be able to mint identity for your most valuable accounts. So far, code on the forum, then a hijacked employee login. Now the payoff. Logged in as that employee, they

4:32 had ChatGPT and Codex, and Codex is Open AI's coding agent, the one wired into real repositories. This employee's Codex was connected to Open AI's GitHub organization. A connected integration

4:44 carries its own standing permissions. So whatever you let it do, a stolen session can now do too. It's It's like leaving your work laptop open and logged in. So they sent a prompt to that Codex account

4:54 and asked it to open a pull request in Open AI/OpenAI, the internal mono repo. It did. An image upload had become a commit sitting inside Open AI's private codebase. They

5:05 stopped right there. No source code was read. The pull request was a harmless proof of concept, and the moment they'd shown it worked, they shut down testing and filed the report. Their disclosure

5:15 was by the book. They reported to Open AI and to Discourse the same day through the Bugcrowd and HackerOne programs. Discourse shipped a fix within days, and Debian followed with a security advisory

5:26 of its own. Door three's lesson is blast radius. A stolen session inherits every permission you left standing. Scope what your agents and integrations can reach. Keep those tokens short-lived because

5:37 that reach is exactly what an attacker walks away with. Now step back and look at all four doors together because the pattern underneath them is the real story. Not one of those bugs was new.

5:48 The overflow was public. The patch existed. The login issue was a plain misconfiguration. What was truly scarce here was never the bugs. It was the person who could chain a memory overflow

5:58 into working code execution, then carry it across two different chip architectures. That rare skill was the real lock on the door. That's the lock the AI just picked.

6:08 Hactron put it plainly, work that once needed a well-resourced team and months of effort can now be compressed into days by turning scarce expertise into cheap compute. To be fair about what the

6:19 model didn't do, it didn't pick the target, design the chain, or handle the disclosure. People did all of that. Claude collapsed the slow expert middle, and the researchers were clear that

6:29 human guidance stayed essential throughout. To OpenAI's credit, the response was quick. They confirmed a fix about 14 hours after the report landed. Discourse and Debian both shipped

6:40 patches within days, and OpenAI paid a $6,500 bounty. But that bounty came with a twist worth sitting with. OpenAI noted that testing its Discourse forum was explicitly out of scope, and

6:52 the money recognized the OpenAI side finding, not the forum attack. The scariest link in the chain ran on a server OpenAI had stopped counting as its own. And this isn't one team's word

7:03 to take on faith. OpenAI's own fix, the Discourse and Debian advisories, and independent reporting on the incident all line up on the same dates and the same chain. So here's where I land. This

7:14 story isn't really about Claude as a weapon or about OpenAI being careless. The real change is that the economics of attack just flipped. The bugs were fixable and known. The moat was the

7:24 expertise to weaponize them, and that moat is draining fast. One image, four doors, three patches nobody had gotten to yet. If you ship software, the fundamentals

7:34 didn't change, but the clock did. Backport your patches, isolate your logins, and scope your integrations, and watch the edges you forgot you owned. The forum, the side service, the thing

7:45 running on someone else's cloud, because that's where this one began. Subscribe and I'll trace one of these end to end every week.