How Hacktron Hacked OpenAI: What I Learned from an AI-Assisted Attack Chain

A few days ago, I came across a security research report from Hacktron that caught my attention.

The researchers described how they chained multiple vulnerabilities to compromise OpenAI employee accounts and reach internal GitHub repositories.

What makes the story particularly interesting isn't just the final impact.

It's the attack chain.

The initial vulnerability involved image processing. From there, the researchers were able to move through Discourse, OpenAI's authentication infrastructure, employee accounts, and connected GitHub integrations.

Even more interestingly, AI models were used throughout parts of the research process.

This made me want to break down the attack at a high level and understand what developers can learn from it. Disclaimer: This is my analysis of publicly reported security research by Hacktron. I'm intentionally not reproducing exploit code, credentials, or instructions that could be used to compromise real systems.

The attack chain

The entire chain can be simplified to:

The important part is that this wasn't a single vulnerability magically giving researchers access to OpenAI's internal repositories.

It was a chain of different trust boundaries.

Hacktron's published research describes the chain as involving a libheif image-decoding vulnerability, Debian's security backport situation, ImageMagick, Discourse image uploads, an OpenAI SSO issue, and eventually connected GitHub access. ([Routley News][1])

And that's probably the biggest lesson from the whole story.

It started with an image upload

Image uploads are something developers deal with constantly.

You upload an image.

The application validates it.

Maybe it generates a thumbnail.

Maybe it converts the format.

Maybe it extracts metadata.

From the application's perspective, it can look like a simple feature.

But behind the scenes, an image might pass through several native libraries.

In this case, Hacktron focused on the processing of HEIF/HEIC images and the native libraries involved in decoding them.

The important detail is that the application itself didn't necessarily contain the vulnerable code.

A web application can depend on:

This creates a dependency chain that developers don't always think about when looking at their own source code.

According to Hacktron's research, the vulnerability in libheif could be leveraged during image processing to obtain remote code execution in the affected environment. ([Routley News][1])

The dependency problem

This is one of the parts I found most interesting.

When we think about dependency security, we usually think about:

But production software is often much deeper than that.

A project might use:

And vulnerabilities can exist several layers below the code we're actually writing.

Hacktron reported that the underlying libheif issue had previously been fixed upstream but had not gone through the usual security advisory process, meaning the vulnerable version could remain present in downstream env…