The photo you take with your iPhone is saved in a format called HEIC. You never chose it, it's been there by default for years, and it has one silly advantage: the same image weighs half as much as a JPEG. This format needs a reader, a piece of software that decompresses the file to display it, and that reader was what gave four researchers a way in to rummage through OpenAI's internal code. In less than 72 hours.

A clarification right away, otherwise what follows won't make sense: they had the right to try. The team at Hacktron AI, a small security company, found the flaw on July 25 and reported it that same day. OpenAI fixed it within the day and paid a $6,500 reward. Nothing illegal there, and nobody was robbed. What matters is how they got there, and how long it took. Because this time, there is real news.

An image isn't data, it's a program

Here's the part nobody has in mind. When your phone displays a photo, it isn't reading pixels neatly laid out in a file. It's running a program that decompresses, resizes and reconstructs the image. This program is written in a low-level language, the one we use when we want to go fast, and it's constantly juggling the machine's memory: it reserves space, releases it, starts over.

A single mistake in this accounting, and someone who carefully crafts their file can make the reservation overflow and write where they have no right to. That's exactly what was found in libheif, the library that decodes HEIC, HEIF and the related AVIF format. A memory overflow, rated 8.8 on the severity scale for flaws, which is very high, with code execution as the prize. Translation: the file is no longer an image you look at, it's a program you run.

Your image is the package. The program that reads it is the scanner. And the scanner itself runs whatever it finds inside

The exact path is even more ordinary than that. The target wasn't OpenAI's website, it was its community forum, the one where users ask their questions. This forum runs on Discourse, a very widespread forum software, which sends every uploaded image through a tool called ImageMagick to make thumbnails. And ImageMagick calls libheif. A photo posted in a message, and the flaw had been reached.

What the models did in a few hours

This is where the story becomes genuinely interesting, because the team didn't do it by hand. The work is credited to four researchers, Harsh Jaiswal, Mohan SRK, Rahul Maini and Sudhanshu Rajbhar, assisted by two models, including Claude Opus 5 from Anthropic.

The first attempt was still a failure. With Opus 4.8, the previous version, the team couldn't get a reliable attack, because the operating system changes where memory is placed on every run to muddy the trail. It's a protection as old as the hills, and it was still working. After moving to Opus 5, released on July 24, the model produced a working attack in a few hours. Then it rewrote it for another processor family, then adapted it to the precise memory allocator used by the forum.

The same workshop, but the tools have changed hands. What took a human weeks can now be measured in hours

The figure that makes me raise an eyebrow isn't the model's speed, it's this one, dropped by the researchers themselves: some of their attempts only worked after thousands of images had been sent. That's what agents can do that we can't: start over ten thousand times without getting tired, without getting discouraged, without telling themselves it will never work. The total time, from the first look at the library to access to OpenAI's internal code repository, is given as less than 72 hours.

The second lock wasn't in the image

Once the flaw had been exploited, the researchers were still only on a forum. The real treasure was elsewhere, and they reached it through a second hole, this one much dumber: the way OpenAI managed single sign-on between its services. You log in once, and you get in everywhere.

Result, the control of a forum account led to access to an employee's ChatGPT account, then to the possibility of reading and proposing changes in the company's private code repository. They opened a change request, one of those correction proposals that a developer sends so their work can be reviewed. Except theirs was meaningless: it was only there as proof they had passed through. They say they stopped there, without going to read the sensitive code.

OpenAI's response, in one sentence: the permissions of the forum login tokens were tightened, and the affected tokens and sessions were revoked. The researchers themselves insist on a point nobody wants to hear: this was not a Discourse vulnerability, it was a homemade design problem. The forum served as the door, the stupidity was behind the door.

What has already been fixed, and what we can't verify

The timeline is clean and public. Reported on July 25, fixed at OpenAI that same day, Discourse security advisory on July 28, and a fixed version of libheif, 1.23.4, released on September 6. If you run a server or a NAS, this is the version you need, and anything without the latest patches is potentially exposed.

Where I lose track is the rest of the announcement. Hacktron says the campaign spread to Slack, Meta, Zoom, Shopify and GitHub Enterprise, in other words platforms that half of us use every day. Except for those, there is not the same level of technical detail, and no confirmation from the parties concerned. A researcher saying “we also got into Meta” and a company replying “the vulnerability is fixed, nothing leaked”, that is not the same information. I note it, I don't take it at face value.

What you do Monday morning

Nothing spectacular, and that's just as well. The HEIC format is the one on your iPhone, so your photos go through a decoder somewhere, but the one on your phone is supplied by Apple and fixed through system updates. Same at Google. So the answer fits in one line: keep your phone and computer up to date, and if you put off an update because the timing was bad, now is the time.

The update you've put off three times. It's this one, and it takes ten minutes

Next, this mostly concerns tinkerers. If you host your photos on a box in the closet, if you run a Nextcloud, a forum, a library manager, a service that accepts images sent by others, go and see whether it uses libheif and which version. It's the kind of dependency you install without knowing it, inside a package you installed for something else. My own Synology has been organizing my photos for years and I had never looked at what was under the hood.

And one last point, outside your living room. The intake points that receive images sent by strangers are all in the same situation: a classified-ads site, a ticketing service, an application form with a photo. Each of these places is a scanner that swallows packages whose contents nobody knows.

What really changed, and it isn't the vulnerability

The vulnerability is fixed, the story would already be over. Except the real information is in the timeline. A memory vulnerability in an obscure library, exploited from start to finish with a complete chain, on several processor architectures, to work their way back to an internal code repository: that was a summer's work for a well-equipped human team. Here, the part assisted by models is counted in hours.

And this is not an isolated case. Last week, I was telling you what Anthropic's report says about Claude being misused, with people using it to spy and scam on a large scale. Same slope, other side. What was expensive becomes cheap, and a cheap vulnerability gets fixed faster than it gets exploited only if the software is maintained.

What bothers me is not that OpenAI lost the round and said so: it's the number of libheif installations sleeping in a project that nobody updates, with a volunteer maintainer, and a program waiting to be woken up by an image. How many are left, in all those closets?