An iPhone Photo Opened OpenAI's Monorepo: The Attack Chain That Cost Less Than a MacBook

What happened, in one sentence

A photo uploaded to an internet forum accomplished what seemed impossible: it opened a door into OpenAI's internal systems. Not through magic or one giant mistake, but by chaining three small flaws nobody had connected. And an AI did much of the work.

First, the three concepts you need

To follow the story you only need three ideas:

• The photo format. When you take a picture with an iPhone, the file isn't an old-fashioned JPG: it's a format called HEIC, more efficient but less compatible. Many web servers don't know what to do with it.
• The flaw registry (CVE). When a security bug is found in a program, it should be published in a public catalog called the CVE — the police report of the bug. That's how server administrators know what needs urgent updating. If a fix exists but was never entered into that catalog, then for the world the fix doesn't exist: we keep running the vulnerable program without knowing it.
• A repository (or "repo"). It's where a company keeps all its code, the set of "recipes" its products run on. OpenAI's monorepo is the single vault where everything lives. Getting in there is like reaching the kitchen where ChatGPT is cooked.

The chain, step by step

1. The entry — an ordinary photo. OpenAI's public help forum runs on a program called Discourse, very popular for communities. When someone uploads a HEIC photo, the forum's usual processor doesn't understand the format and hands it to an old component called ImageMagick, which hands it to another one called libheif. Inside that old image processor lived the bug.
2. The bug — writing outside the notebook. The flaw was a heap buffer overflow: imagine a program writing data in a 100-line notebook, and because of the bug, someone can write past line 100, trampling whatever is on the following pages. On a computer, those following pages can hold instructions the server will execute. Whoever controls what gets written controls the machine. This bug had been fixed in the original code for months… but the fix was never registered as a CVE. Nobody knew an update was needed. OpenAI's forum was still running the vulnerable version.
3. The AI enters the game. The researchers, a firm called Hacktron, asked Claude — Anthropic's model — for help. The version available (Opus 4.8) found the bug and explained how to exploit it, but tripped on a defense of the operating system called ASLR — a measure that "shuffles" memory addresses every night so the attacker doesn't know which page to write on — and couldn't build a reliable attack. That same evening of July 24, Opus 5 came out; by the next morning, ~10 a.m., it had a working attack and the researchers controlled the forum's server. That's called remote code execution: writing orders to a machine that isn't yours.
4. The second bug — the real one. Here's the important part: the forum was just the entry. The researchers discovered that a session started on the forum also worked for ChatGPT and Codex, OpenAI's coding tool. It's the classic "sign in once, get into everything" (SSO, single sign-on), comfortable for users but dangerous when one part is weak: like using the same key for the fence, the front door and the safe. And this problem lived in OpenAI's account infrastructure, not in the forum.
5. The finishing touch. With an employee's session —whose Codex tool was connected to the company's GitHub account— the researchers sent that Codex one order: "open a change request in the internal repository." It did. That request was proof they had reached the kitchen. They didn't open a single sensitive file: they demonstrated the path and stopped there.

OpenAI fixed the session problem in ~14 hours, and Discourse patched and sandboxed its image processor within days. OpenAI paid a $6,500 bounty.

The detail that should worry you: the AI refused… until the label changed

When the researchers wanted the AI to attack a live production server directly, Claude refused: its rules prevented it from writing attacks against other people's systems. The way around it, per The Register, was to put one of their own servers behind an address disguised as a "practice challenge" (capture the flag, a hacking game). With that label, the refusal vanished and the AI carried out the attack on its own.

Think of it this way: the capability was there all along. What changed wasn't the AI's skill but the name given to the target. If a frontier model's safety measure falls to a change of wording, what protects us from someone with bad intentions using the same trick?

The real news: it worked everywhere

Hacktron adapted the same technique — it even has a name: the "HEIF Heist" — to other companies in one or two days per case: Slack, Meta, GitHub Enterprise, Rails, Next.js. Guess how many noticed? One. Shopify, and by the noisiest route: the image processor kept crashing while thousands of test photos flowed through it. Nobody else noticed a thing.

One security expert summed up the new landscape: for about $200 a month in model subscriptions, anyone can attempt today what Hacktron did.

What you can check on your own services today

If you run a home server, a forum, or any self-hosted service, this story is your to-do list. Each item takes minutes:

• Look at what programs handle your images. ImageMagick and libheif are installed on millions of servers nobody remembers (Rails, Node.js, forums). On Linux one command lists them: dpkg -l | grep -E 'imagemagick|libheif'. Old image processors are among the most attractive targets for attackers, precisely because everyone assumes "an image is just an image".
• Distrust fixes without CVEs. The bug had been fixed for months and the server was still vulnerable because nobody knew. "Everything is up to date" doesn't mean it's safe.
• Audit fallback paths. If your service sends certain file types to a different processor than the usual one (a "fallback"), that alternate path is exactly where the attackers got into OpenAI.
• Don't use the same key for everything. If signing into a small service also opens the door to important ones, a small failure becomes a big disaster. Sessions that expire soon and minimal permissions between services.
• Treat crashes as signals. The only company that noticed, noticed because its system kept failing. If something on your server starts failing without explanation, don't just restart and forget: it may be the evidence of a break-in attempt.

The number that says the most: $6,500

There's an uncomfortable epilogue. OpenAI paid $6,500 for an attack chain that reached its internal code — and also noted that the forum where it all started was outside its bounty program's rules. In other words: it barely counted as a report. That the leading AI company values a complete path to its own kitchen in the low five figures says something about the market: carrying out these attacks became dirt cheap, but nobody is paying what they're worth. That gap can't last, and the correction will probably arrive through the wrong side before it arrives through bounties.

What I'm taking with me

• Attacks don't start where you look: they start in the forgotten little program you inherited without realizing it.
• A fix that isn't published doesn't exist for those of us who run systems. Disclosure is part of security, not paperwork.
• Current AI safety rails are labels, not locks. The "practice challenge" trick wasn't a sophisticated hack — it was wording.
• "Sign in once" is comfortable for users and a risk multiplier for administrators.
• Of all the companies attacked, only one noticed. Detection — not prevention — is where everyone is investing the least.

I keep measuring this stuff from my homelab in Peru. If you checked your own services after reading this and found any surprises, I'd love to hear about them.

Sources: Quartz, The Register (via AI Edge Briefing), VentureBeat (via EveryDev), Wall Street Journal (via AI Chat Daily). Hacktron's original technical writeup. Figures attributed to Hacktron come from its own account.