> By 6:00 a.m. on July 25, we had confirmed local RCE through an image upload. We then placed Claude in an autonomous /goal loop against our own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a CTF target as Opus refused write exploit for remote instances.

> When we checked again at 10:00 a.m., the agent had achieved RCE on Discourse Cloud and demonstrated access by reading /etc/hosts. Using the generated exploit script, we managed to get RCE on OpenAI’s instance.

Between this and the HuggingFace hack, we've built systems that are so goal-oriented, and so capable, that they will do almost anything if they are convinced it is justified - or if they are playing a "game" where there is no goal but to win.

Of course I want my software to be able to audit its own security, and to defend against attackers who have the benefits of their own agentic systems. But at a certain point, did we need it to be trained so much on CTF games?

It feels like an entire industry watched https://en.wikipedia.org/wiki/WarGames and ended up thinking "this is a challenge, we can just build a better WOPR, of course it will know when it's playing a game. Let's play Global Thermonuclear War."

> Until two months ago, any user or OpenAI employee logging into OpenAI’s own help forum (community.openai.com) could have had their ChatGPT and Codex accounts taken over. Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.

> The entire timeline from initial discovery to access to OpenAI repo access took place in less than 72 hours.

Great, and openAI's the company working with the 'department of war' to power autonomous killer AI.

Reading the patch[0] for libheif the bug which lead to the vuln was around bounds checking for image overlays. the container can have multiple images and you can compose them in the output.

heif also supports rotating, cropping, alpha channels, thumbnails and a ton of other features that a web forum where a user is uploading photos or screenshots doesn't need.

It's a much, much larger attack surface than plain old school JPEG.

I'd suggest rather than wait for the next bug to appear in this or another image lib to keeping things simple - stick to plain JPEG and handle image conversion in the client (wasm in the browser) if you really need to support users uploading iphone images.

Media decoding is so hard - there have been tons of bugs in ffmpeg and imagemagick and the core libs. You really need to think about how much of it you expose via a web server

[0] https://github.com/strukturag/libheif/commit/85e21ad44eba931...

It is super amazing that 3 years later, none of the models' weights developed by Anthropic or/and OpenAI have leaked so far. Not a single one.

Windows internal builds have leaked for years, early game versions, GTA videos, secret documents, whatnot. But somehow even though all the whistleblowing, not a single model was leaked. What level of security do these companies have? Do they bring encrypted DVDs to AWS to run the services or really...how's it even possible?

Unsandboxed ImageMagick is known for being a security nightmare even back when PHP ruled the world (not saying sandboxing is a panacea either, it just requires a different and potentially harder exploit to develop a full chain). Difference is it's easier than ever to turn vulnerabilities into full compromises. At some point we'll have to replace all parsers with something at least as safe as https://github.com/google/wuffs right? Otherwise ImageMagick and co. will just keep giving.

Update on the Discourse side, we now run all external binaries, including magick via a landlock sandbox.

The gem we use is here: https://github.com/discourse/ruby-landlock highly recommend all Rubyists out there consider this. We are also in the process of moving away from Magick to Vips (which also runs in a sandbox, not in process)

HEIF is patched, but I doubt this is the last buffer overflow in HEIF, I will not be surprised if in the upcoming weeks or months someone will discover something in libpng or some other native image library. Given where stuff is at, defense in depth is critical.

Another thing worth mentioning to all self hosters, always be updating! The rate of CVEs this year across all open source software is through the roof, self hosting now is double scary, you need to have some routines setup to update monthly if not weekly.

This is legal to do without written permission? $6,500 for this feels like peanuts. The potential reach of such a hack is insane, especially with access to Github. OAI is lucky they were ethical and didn't sell this for several hundred thousand to a malicious third party.

>...researchers found a bug in the way that the community-discussion forum Discourse processed certain image files. The researchers had access to a special version of Claude Opus 4.8... >At first, it didn’t work. That evening, however, Anthropic released Opus 5 and by the next day, Claude had found a way to exploit the bug...

Is this speed of capability because hacking is almost entirely machine verifiable, thus training quicker/deeper than other domains?

We need to be prepared to write less software, with a smaller attack surface. Less is more.

Bloated code is the critical problem. Once upon a time, I read C function

> char gets(char str);

is the first buffer overflow entry point, because it does not check the size of the destination buffer.

Sadly we cannot remove it from standard-C yet AFAI Know.

The success of Rust versus other languages is its secure-by-compile-time promise.

Also a lean java could help, but Java is so verbose/slow to start it bumps you away.

Interesting to note their monorepo is already up to issue / PR 1,186,742. And so assuming 10 years old it would average out to around 450 PRs/issues each workday.

Related: Mistral seems to also have been hacked, https://frenchbreaches.com/blog/mistral-ai-de-nouveau-pirate... (NOTE: in French).

A $6500 bounty is insulting.

It's crazy that we still rely on these unsafe C dependencies, in an era where migrating code to Rust (or other languages) is so easy.

There's really no excuse.

This is one of the best arguments against letting one or two companies own all the intelligence (and I think most of OpenAI would agree)

> Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.

That's why I'm always sceptical about using the AI for such things! Less surface idea and isolation is always good for the security.

There was something I was hoping to find in the article, which is this common situation where employees are also the customer of their companies product, they happen to have elevated privileges and yet the credential rules applicable to those accounts are same as regular customers. This is across all the product lines, some companies do a better job than others but its still a problem that exists and gets exploited.

The immediate worry isn't superintelligence, it's scalable/bruteforce "good enough" intelligence.

Good video on the topic: https://www.youtube.com/watch?v=gjHh9g7yo9Y

Interesting that Claude agreed to assist in crafting this exploit. Don’t these models usually reject such requests?

> we used the employee’s Codex to open a PR #1186742 in OpenAI’s internal monorepo

Slightly interesting to learn how many PRs the openai has done

>Interestingly, the vulnerable code had been changed upstream the previous year, but the commit was not documented as a security fix and received no CVE.3 This might be a reason why Debian 12 and 13 have not received the security relevant backports in time.

Ooof, keeping packages like this up to date with the rate of updates and churn is a mess.

Everybody at OpenAI is working like a summer intern or researcher. Not much care for the production side of things.

I really hope those model weights are more secure than this

They used a heif payload to get server access but they never describe the SSO flaw they used to actually get repo access (the juicy part!), bummer!

Wish they shared that interesting piece since that's the interesting part.

Also pretty shocking that openai uses github. I would have expected a company of that size with that much to lose would be using self hosted stuff.

I did not see it mentioned; did the $3000 expense in token usage earn them a free t-shirt?

$6 500 bounty for this is a joke. The black market price would be smth like $6 500 000 or more

Discourse didn't pay bug bounty?

$6.5K bounty when OpenAI raised $122 billion yesterday...if anyone at OpenAI is reading this, come on...do the right thing here

This whole blog-post is impressive with the chain of vulnerabilities involved. However...

> OpenAI also paid us a $6,500 bounty.

?

That amount for this payout is beyond pathetic for a near $1.2T company, who just got themselves breached with a complete potential source code leak.

This is like getting close to breaching the main monorepo at Google: google3.

If this was on the black market and the leak included unreleased models and training material, it would easily be worth tens of millions. Even reporting crypto smart contract flaw pay way more than that on average of $100k - $10M.

Come on.

[dead]

[dead]