AI ATTACKS AND THE FUTURE OF CYBER DEFENSE
How a forum upload reached OpenAI’s code.
How researchers used AI to break into OpenAI, what could have stopped them, and why Abnormal AI is building defenses that learn normal behavior and respond at machine speed.
Understand the attack Or read the written analysisHow an image upload led to a private code project.
Security researchers used two software flaws to take over an employee account, then directed its coding agent to propose a change inside OpenAI. The diagram shows how each step gave them more access.
The researchers uploaded a specially crafted image.
On July 25, 2026, researchers submitted an image to OpenAI’s community forum. They had used Claude to help develop an attack hidden in the file. The forum processed it automatically, so no employee had to click anything.
Technical details: How a picture upload ran code on the server
When someone uploads a picture, software on the server reads and processes the file. The server has to interpret data supplied by that person, including the image’s format and dimensions. If the image reader mishandles those values, a specially constructed file can exploit the mistake while the server processes it.
Hacktron describes FastImage falling back to ImageMagick, which used libheif to process the uploaded HEIF image. These are software libraries called by the forum’s upload feature. The vulnerable code ran on the server, so the researchers did not need an employee to download or open the picture.
The researchers used a memory-corruption flaw in that image processing to run their own instructions on the forum server. The uploaded file supplied the data that triggered the exploit. Discourse’s advisory addresses both the vulnerable image library and restrictions on what image-processing software can access.
Processing the image gave them control of the server.
A bug in the image-processing software let the file corrupt the server’s memory and run the researchers’ code. They could now execute commands on the computer running the forum.
Technical details: How the image reader mishandled memory
A program reserves areas of memory for its working data. The heap is storage it allocates while running. If software calculates a size or position incorrectly, it can read or write outside the area reserved for that operation. A write to the wrong location can corrupt other data the program relies on.
Hacktron’s account identifies a flaw in libheif’s image-overlay calculations. The upstream patch checks where image regions fit and uses wider signed arithmetic, so overlap calculations can represent a larger range of positive and negative values. The report says the deployed package did not include this fix. An available patch protects a server only after the corrected code reaches it.
A separate libheif advisory describes an alpha-stride over-read, a calculation problem that causes a read beyond the intended memory region. The public sources do not fully reconcile that description with Hacktron’s overlay-computation exploit. This explanation follows the researcher’s account and patch without assuming the two descriptions identify identical mechanics.
A login flaw let them take over an employee account.
OpenAI used a shared login system across services. A separate flaw in that system let the researchers turn control of the forum into access to OpenAI accounts, including an employee’s. The exact login flaw has not been published.
Technical details: How the forum takeover reached an OpenAI account
Single sign-on lets someone use one account to log in to several services. Each service should still grant only the access it is responsible for. A forum that accepts the shared login should not be able to act as that person in another application, even if someone takes over the forum.
In Hacktron’s report, the researchers used their access to the forum and a separate flaw in OpenAI’s login system to access OpenAI accounts associated with forum users. The image bug let them run instructions on the forum server. The login bug let them act through accounts beyond the forum.
Hacktron reports that OpenAI fixed the login issue in about 14 hours. That repair stops the reported method of gaining account access even if the forum remains compromised. The precise implementation error has not been published, so the account takeover cannot be attributed to a particular stolen token, OAuth mistake, or multifactor-authentication bypass.
They could now give the employee’s coding agent instructions.
The employee used Codex, OpenAI’s coding agent, with a connection to GitHub. Taking over the account let the researchers direct that agent and use the access it already had to private code.
Technical details: How researchers used Claude to develop the exploit
Hacktron began its investigation on July 23. On July 24, Opus 4.8 produced an exploit that ran with address-space layout randomization disabled but struggled when it was enabled. ASLR changes where parts of a program sit in memory. That makes it harder for an exploit to reliably reach the locations it needs.
The researchers report that Opus 5 produced a working exploit for their local ARM64 environment within three hours. They then adapted it to x86-64 and jemalloc, which change the processor instructions and how working memory is allocated. The autonomous testing loop ran against their own Discourse instance. A successful local test still required changes for the other environment.
Claude helped skilled researchers develop and test the exploit. Later, the researchers directed Codex through the compromised employee account, using its existing connection to GitHub. Those are two different uses of AI in the same incident. The human-led research demonstrates a capability under particular test conditions, not a general cost or success rate for breaking into organizations.
Codex proposed a change to OpenAI’s private code.
The researchers asked Codex to open a harmless pull request, which is a code change submitted for review. This demonstrated access to an internal OpenAI project. They say they avoided reading or downloading sensitive code. The report does not show the change being merged or deployed.
Technical details: What the internal pull request proved
A pull request proposes a change to a code project so other people can inspect and review it. Opening one shows that the account can submit a proposal to that project. It does not show that anyone approved the change, merged it into the code, or deployed it to a running system.
The researchers report using the employee’s connected Codex agent to open a harmless pull request in an internal OpenAI repository on July 25. They say they avoided inspecting or downloading sensitive source code. Their forum compromise, account access, and use of Codex nevertheless let them submit a change inside a private OpenAI project.
The report also discusses possible exposure through other integrations. Each account’s connections and permissions would determine what else it could access. The researchers did not demonstrate access to every service, and the reported pull request does not establish theft of model weights or customer data.
Based on Hacktron’s researcher disclosure and Discourse’s security advisory. The illustration shows the sequence of access, not OpenAI’s physical infrastructure. Claude helped develop the exploit. Codex carried out a task through the compromised account.
What could have stopped this attack
This attack depended on two software flaws and an agent’s existing permissions. Fixing either flaw, or restricting that permission, would have stopped the reported sequence at a different point.
Patch the image-processing software.
A repaired image reader would reject the exploit instead of running the researchers’ code. The forum server would remain protected from this vulnerability.
Patched image reader → no control of the forum.
Fix the shared login system.
Even if the forum were compromised, a secure login system would stop that access from becoming control of an employee’s OpenAI account. Hacktron reports that OpenAI fixed this flaw in about 14 hours.
Forum compromised → employee account still protected.
Limit the agent’s permissions.
If Codex had no access to that private repository, the researchers could not have asked it to propose a code change there. Smaller permissions limit the damage, although an agent still needs enough access to do its job.
Account compromised → private repository out of reach.
Why behavior helps detect attacks we haven’t seen before.
AI helps attackers develop more sophisticated techniques, run more attacks, and act faster. Defenses that depend on recognizing yesterday’s attacks or waiting for a human to respond cannot keep up on their own.
A bank can question a purchase made with your real card number because it differs from your normal spending. The same principle can help detect suspicious activity by people, software accounts, and AI agents.
THE EXAMPLE BELOW IS HYPOTHETICAL, NOT A RECONSTRUCTION OF OPENAI’S ACTIVITY.Past activity provides a baseline for evaluating new requests.
Learn what the account normally does.
Suppose an engineer uses a coding agent to maintain her team’s project. Over time, a defender can learn which projects she works on, which tools she uses, and what she usually asks the agent to do. That history establishes a normal pattern of behavior.
Recognize a request that fits that pattern.
The engineer asks the agent to fix a bug in the usual project. There is a matching work request, and the agent proposes a change for review. The account, project, and action are consistent with the work she normally does.
Detect an unusual request, even if the attack method is new.
Now the same account asks the agent to export files from an unrelated sensitive project. The login still works, but the behavior has changed. A defender can flag that combination for investigation without knowing how an attacker might have obtained the account.
Investigate and respond before the attacker does more damage.
If investigation confirms the account is compromised, a defender can automatically end the session under the company’s response policy. Ending the session stops further requests through it. Automating that action reduces the time between detecting the compromise and containing it.
An anomaly is a reason to investigate, not proof of an attack. Good detection combines several signals because legitimate work changes too. This example explains the defense strategy. We do not have OpenAI’s security data and cannot claim we would have stopped this incident.
Technical details: How behavioral AI finds unfamiliar attacks
A behavioral baseline describes how a person, machine account, or AI agent normally works: who it interacts with, which resources it uses, and what it asks those systems to do. The model learns these patterns from observed activity. Abnormal’s Attune learns identity, behavior, and content together, so it can evaluate a request in the context of the account and its relationships.
Comparing new activity with those patterns can expose an unfamiliar attack without a rule written for that exact attack. The hypothetical compares an account submitting the team’s expected code fix with the same account requesting an unexplained export of sensitive data. The account name is unchanged, but the behavior and requested data are different. Those differences give the defender evidence to investigate.
A defender can correlate that evidence, investigate the activity, and respond at machine speed, for example by revoking a compromised session. Abnormal already automates investigation and remediation of email threats. A baseline is not infallible: new legitimate work can look unusual, and attackers can imitate familiar behavior. Automated responses therefore need sufficient evidence, a supported action, and the customer’s policy. The hypothetical illustrates this reasoning, not a claim that Abnormal detected the OpenAI incident.
How we’re building behavioral defense at Abnormal AI.
I run Abnormal AI. Our strategy is to understand the normal behavior of every identity in a company, detect suspicious changes, and use AI to investigate and respond at machine speed. That includes employees, the accounts used by software, and increasingly the agents working alongside them.
Email, account, application, and agent activity contribute to a shared behavioral model.
Learn normal behavior for each digital identity.
We connect to the systems a company uses and learn from their activity. We model who each identity communicates with, which resources it accesses, and what actions it normally takes. We started with employees and email, and we’re extending that approach to software accounts and AI agents.
Use that understanding to recognize suspicious activity.
A request can look harmless by itself and suspicious in context. We connect what an identity normally does with what it is doing now. This gives us a way to detect unfamiliar attacks without first writing a rule for each new technique, whether the attacker is a human or an AI.
Use AI to investigate and act at machine speed.
The platform needs to turn a suspicious event into a decision and a response. We already automate email investigation and remediation. Our broader vision is to investigate across systems and contain compromised identities or agents through the controls a customer has authorized, without making every attack wait for a human decision.
WHAT IS AVAILABLE TODAY / SEPTEMBER 18, 2026
Email security, Identity Threat Protection, and AI Governance are available, including automated email investigation and remediation. AI Cloud Security is in private preview, with general availability planned for Q4 2026. It extends the approach to cloud identities and agent activity, with OpenAI Daybreak models supporting investigation.
Each product’s coverage and response actions depend on its integrations and the customer’s configuration. The diagram explains the platform strategy across these products.
Technical details: How Abnormal applies behavioral AI beyond email
We built Abnormal’s email security around learning how people communicate: who they work with, what they discuss, and which requests fit those relationships. Attune learns identity, behavior, and content together. That helps detect unfamiliar attacks even when an attacker uses convincing language and a legitimate account. We are applying the same method as more work moves to machines and AI agents.
Identity Threat Protection correlates email, identity, and SaaS activity, so an investigation can follow what an account does across connected services. AI Governance identifies AI tools and their permissions. These identity and AI-security products became available on August 3. Together, they connect suspicious activity to the account involved and the systems it can access.
AI Cloud Security entered private preview on September 3, with general availability planned for Q4 2026. It applies behavioral monitoring to cloud identities and AI agents, uses OpenAI Daybreak models to help investigate threats, and supports responses configured by the customer. Our goal is to learn normal work, detect deviations that indicate an attack, and respond fast enough to match AI-driven activity. Coverage depends on connected systems, observable activity, and the actions each integration supports.
WHAT THIS MEANS FOR CYBER DEFENSE
Preparing for attacks
we cannot predict.
I expect AI to produce attacks we have never seen before, at a volume and speed security teams cannot investigate manually. At Abnormal AI, we’re building toward a platform that learns normal behavior for every identity, detects risky changes, and responds at machine speed.
Read the full analysis and sources ↓THE WRITTEN ANALYSISRead the complete argument and sources +
On July 25, 2026, security researchers uploaded an image to OpenAI's public forum. They used two software flaws to take over an employee account, then asked its connected coding agent to propose a change to private OpenAI code. Hacktron's disclosure explains how they did it. The proposed change was harmless, and the researchers reported the vulnerabilities.
At Abnormal AI, we're building defenses for attackers who use AI and for companies whose own agents can be compromised. I think both require learning normal behavior, detecting risky deviations, and responding at machine speed.
How the researchers broke into OpenAI
The first flaw was in the software that processed uploaded images. OpenAI's forum used Discourse, which passed images through ImageMagick and a library called libheif. A specially constructed HEIF image could corrupt memory during processing and cause the forum server to execute the researchers' code. No employee had to open an attachment. The forum processed the file automatically.
Hacktron says the bug had already been fixed upstream, but the change had not been labeled as a security fix and had not reached the package used by the forum. The vulnerable software was still running when the researchers uploaded their image.
The second flaw was in OpenAI's single sign-on system, which lets one account sign in to multiple services. Control of the forum should not have given the researchers control of those accounts. A separate login flaw let them take over OpenAI accounts associated with forum users, including an employee's. Its exact mechanism has not been published.
That employee had connected Codex, OpenAI's coding agent, to GitHub. The researchers could give Codex instructions through the compromised account and use the access it already had. They asked it to open a harmless pull request in an internal OpenAI repository. A pull request is a code change submitted for review. Opening one demonstrated access to a private code project, without establishing that the change was approved, merged, or deployed.
The researchers say they avoided reading or downloading sensitive source code. Their report does not establish theft of model weights or customer data. It describes a researcher-led intrusion that they disclosed to OpenAI, which Hacktron says fixed the login flaw in about 14 hours.
AI played two different roles. Claude helped the researchers investigate the image-processing flaw and develop an exploit. The work involved human guidance and repeated testing in their own environment. Later, Codex carried out a task through the compromised employee account. The reported attack did not require prompt injection or an AI model deciding to turn against its owner.
The agent's existing permissions explain why the account takeover mattered beyond the account itself. A coding agent needs access to code to be useful. Someone who takes over the account directing that agent can try to use the same access.
What could have stopped this attack
Patching the image-processing software would have stopped the first exploit. Fixing the shared login system would have prevented control of the forum from becoming control of an employee account. Restricting Codex's access to the private repository would have prevented that agent from proposing a change there. Each control interrupts the reported sequence at a different point.
Isolation also limits the damage from a software flaw. Discourse's advisory describes both patching the dependency and adding restrictions around image processing. A process that only needs to read a picture should have very little access to the rest of a system.
These are essential defenses. But we cannot assume we will find every vulnerability before an attacker does, or remove every permission an employee or agent needs. We also need to detect attacks after they get past those controls.
Why behavior helps detect unfamiliar attacks
AI changes the problem in three ways. It helps attackers develop more sophisticated techniques, run attacks at greater scale, and execute actions faster. This incident is one example of AI assisting difficult exploit development. The broader challenge is that defenders cannot anticipate every technique an AI might develop and write a specific rule before it is used.
Behavior gives us another way to recognize an attack. We can learn what a person, software account, or agent normally does and identify activity that differs from those patterns. We do not need a previous example of the exact attack to notice that an account is acting differently and doing something risky.
Credit card fraud is a useful analogy. A purchase can use your real card number and still look suspicious because it differs from your normal spending. The bank can investigate the transaction without knowing the criminal's exact method for obtaining the card.
Suppose an engineer regularly uses a coding agent to fix bugs in her team's project. A request to make an assigned change fits that history. A request to export files from an unrelated sensitive project deserves investigation, even when it comes from the same valid account. The project, the action, and the absence of an expected task give the defender more information than the login alone.
An anomaly is not proof of compromise. AI changes legitimate work too. I use coding agents to do things that would have looked unusual for me a few years ago. Good behavioral detection needs to consider the task, related identities, and the risk of the action. Otherwise it will interrupt the work we're trying to enable.
Detection also needs a response that can keep up. If an attacker can take the next action before an analyst reads the alert, adding another alert does not contain the attack. AI can help investigate the evidence and take an authorized action, such as ending a compromised session, without waiting for every incident to reach a human.
This is a hypothetical example of how behavioral defense works. We do not have OpenAI's security data and cannot claim we would have detected or stopped this incident.
How we're building this at Abnormal AI
My background is in behavioral machine learning. At Abnormal AI, we started with email because understanding normal relationships helps detect fraud that looks convincing on its own. A real supplier account can send a request that passes authentication but makes no sense for that supplier's relationship with the customer.
Our platform strategy applies the same approach across human identities, machine identities such as service accounts, and AI agents. We want to understand what each identity normally accesses, what it does with that access, and how its activity relates to the people and systems around it.
The first part is building that understanding. Integrations bring together activity from email, accounts, applications, and agents. Our Attune model combines identity, behavior, and content to evaluate activity in the context of the company. For an agent with little history, we want to use context from the employee directing it, related identities, and the resources it accesses.
The second part is behavioral anomaly detection. We compare new activity with those patterns and connect related events. An unusual sign-in, a new application permission, and an unexpected request may be evidence of one account takeover. Our shared behavioral platform is designed to use that information across products, so each event can be evaluated with more context.
The third part is investigation and machine-speed response. We already automate email investigation and remediation. Our broader vision is to investigate attacks across systems and contain compromised identities and agents through controls customers have authorized. That could mean removing a malicious email, revoking an abused credential, or isolating a compromised workload. The available action depends on the product and integration, with human review where the customer's policy requires it.
As of September 18, email security, Identity Threat Protection, and AI Governance are available. AI Cloud Security is in private preview, with general availability planned for Q4 2026. It extends the approach to cloud identities and agent activity, with OpenAI Daybreak models supporting investigation.
I think the next generation of cyber defense has to work against attacks we cannot predict. Learning normal behavior gives us a way to recognize suspicious activity even when the technique is new. Combining that understanding with automated investigation and machine-speed response is the platform we're building at Abnormal AI.
-Evan
Sources
- Hacktron: Hacking OpenAI. Primary researcher disclosure of the intrusion and AI-assisted exploit development.
- Discourse: Remote code execution via malicious image uploads. Maintainer advisory, CVE-2026-32882, patch and isolation measures.
- Abnormal AI: Attune. How identity, behavior, and content inform detection.
- Abnormal AI: Platform overview. Shared behavioral understanding across products.
- Abnormal AI: Automate SOC Operations. Current automated investigation and remediation workflows.
- Abnormal AI extends its Behavioral Security Platform. Identity and AI-security availability beginning August 3, 2026.
- Abnormal AI brings OpenAI Daybreak models into AI Cloud Security. September 3 announcement and private-preview status.
More in AI × Cyber: AI Instructions Are Not Controls