Security & Supply ChainAI Agent

Three Pre-Existing Authorizations, Two Days, into OpenAI's Internal Repository

The security research team of Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini is known as Hacktron. Their daily business centers on automated security testing, with commercial consultation links in the footer of their technical blog. On July 23, 2026, these three researchers turned their attention to OpenAI’s official technical community at community.openai.com and began examining its image upload interface.

The forum is open to the public, allowing registered users to upload local images when publishing posts. The community runs Discourse, an open-source forum system. When Discourse receives an image file uploaded by a user, it invokes the command-line utility ImageMagick for format conversion, which in turn calls the underlying open-source C library libheif to parse the incoming data stream. An execution path without strict memory isolation thus opened up: external input submitted via the browser passed straight into the memory space of an underlying C parser.

The researchers progressed along this path step by step. On July 24, they brought a large language model into the workflow to attempt generating exploit code that would trigger a memory crash. By the early hours of July 25, the testers had achieved remote code execution within the forum’s server environment, gaining administrative control over the forum’s backend.

Gaining administrative control over a forum typically signals only the compromise of a peripheral site. Here, however, authentication did not rely on an isolated user table; it was tied directly into OpenAI’s single sign-on system. Following trusted sessions synchronized across the system, the research team took over an internal engineer’s ChatGPT and Codex accounts without requiring any cooperation from the targeted employee. As part of a routine development workflow, that engineer had previously authorized and linked their personal GitHub account to the coding assistant Codex.

With valid active sessions in hand, the testing team used Codex to create a branch inside the core repository openai/openai and submitted a pull request. According to Hacktron’s official blog post, submitting the pull request was done solely to provide definitive proof of access:

To demonstrate impact without actually accessing any internal code

The Hacker News subsequently verified the boundaries of this testing activity:

It did not read any source code, merge or ship anything, or touch customer data

The test did not read any internal source code, merge or ship code changes, or touch customer data. In accordance with OpenAI’s requirements, the public disclosure redacted and omitted the pull request link that contained specific code paths.

Between 08:00 and 10:00 UTC on July 25, the research team submitted their report via the Bugcrowd vulnerability disclosure channel and ceased testing at 15:30 UTC. Approximately 14 hours after the report was filed, OpenAI confirmed the completion of technical remediation at 22:49 UTC that evening. From reviewing the interface on July 23 to branching in the internal repository on July 25, the entire process took less than 72 hours. Although the penetration occurred in late July, public coverage did not emerge until mid-September: Hacktron published its blog post on September 13, The Wall Street Journal ran an exclusive report in the early morning of September 18, and numerous industry outlets followed with coverage.

While this test caused no code leaks, it drew a solid line across the system’s engineering topology: an image processing interface on an external public forum, traversing successive hops of trust propagation, linked straight to a write endpoint in the core code repository. Three unrelated, pre-existing authorizations formed a complete, uninterrupted conduit directly into core assets.

An image parsing flaw in a peripheral forum flowed through a company-wide single sign-on system into repository write permissions that an employee had previously granted to a coding assistant, chaining three pre-existing authorizations into a direct pathway to the core internal repository.

None of the Layers Were New

From public image uploads to the internal core repository, every technical component and authorization setting along this entire chain was a long-standing, pre-existing configuration running in production.

At the front of the chain was image parsing. The anomaly’s root cause resided in a code defect within the open-source C library libheif during image overlay calculations. As early as May 5, 2025, upstream adjusted the relevant calculation logic in commit 85e21ad44eba931314337300a2376b8d28f085ae, with no security advisories accompanying the commit message. A year later, on May 19, 2026, the project released libheif v1.22.0, with release notes listing multiple fixes, including CVE-2026-32882.

Even after upstream patched the flaw, downstream Linux distributions were slow to adopt the fixes. On August 8, 2026, the Debian community issued security advisory DSA-6417-1, fixing 12 CVE vulnerabilities in its stable trixie branch; however, it has still not backported them to the oldstable bookworm branch running on production servers, leaving the issue officially open on its tracking dashboard. It was not until late August and early September that the libheif maintenance team successively rolled out versions v1.23.2, v1.23.3, and v1.23.4 to advance the remediation.

Discourse responded rapidly upon receiving the testers’ report via HackerOne: received on Saturday, replied on Sunday, and produced a remediation plan on Monday. On July 27, 2026, commit a07188016987de1613c961277e2e928aaa7c37ec introduced the Linux Landlock mechanism to sandbox image-processing subprocesses. On July 28, Discourse published official security advisory GHSA-vhm9-85gw-x335, rating it as an 8.8 High-severity vulnerability.

Past the image parsing entry point, subsequent movement relied on trust propagation through the authentication system. Login for the community forum was integrated into a centralized single sign-on system. The research team noted that this cross-domain takeover was not an issue unique to Discourse; any peripheral service tied into this single sign-on architecture would yield the same outcome if compromised. In this test, the forum was merely an outer endpoint. OpenAI’s primary remediation also centered here: tightening the scope of community forum login tokens and revoking affected credentials and active sessions in bulk. Spokesperson Drew Pusateri confirmed this remediation in an interview with The Wall Street Journal, as quoted by name in The Straits Times.

The final link in the chain was the connection authorization configured by a developer for an assistant tool. An internal engineer had previously authorized and connected their personal GitHub account to the coding assistant Codex for daily operational needs. This configuration conformed to standard business requirements and involved no unauthorized elevation of privilege during setup, yet it ultimately defined the ceiling of impact the test could reach. Once the testers took over the single sign-on credentials, they directly inherited all write capabilities associated with that account on the external code platform.

At the input layer was an image parsing dependency with known vulnerabilities; in the middle was an identity integration architecture that broadly trusted external sites; at the top was a coding tool authorization routinely configured by an engineer. Taken individually, each of these three settings represents a common engineering reality, yet in this specific topology, they interlocked. Downstream stable distributions’ backlog of pending fixes left the peripheral service’s memory defect continually exposed to public internet inputs.

What AI Changed, and What It Didn’t

When media outlets covered the incident en masse in mid-September, most headlines placed their focus on how an AI model had breached defenses. Following the story initially, my own first reaction was that large language models had achieved a breakthrough in vulnerability discovery. But after cross-referencing the research team’s complete published logs and technical details item by item, I realized my initial attribution was off.

The core progress throughout the test was steered by human researchers. Human experts selected the attack surface, traced the cross-domain trust chain, validated exploit scripts against live services, and disclosed the vulnerabilities through compliant channels. The language model’s role was to generate the corresponding exploit code after humans had isolated the root cause of the memory defect, and to fine-tune the memory layout for the target runtime environment. Hacktron drew a clear line in their technical retrospective:

This was not completly autonomous hacking, and skilled human guidance remained important

The testing was by no means fully autonomous; expert human guidance proved essential at every stage.

In their blog post, the research team repeatedly emphasized the efficiency leap brought by the model upgrade, attributing the breakthrough to the new model’s reasoning capabilities. Yet examining the researchers’ operational timeline reveals that this perceived leap was intertwined with several external factors.

A critical prerequisite came from the prior context established manually by humans. While using Claude Opus 4.8 on July 24, the researchers invested substantial time in locating the root cause of the vulnerability, getting a prototype script working in an environment with address space layout randomization (ASLR) disabled, and sorting out memory structure offsets and debugging parameters. By the time the model took over the task, humans had already prepared the crash reproduction and memory offsets, eliminating the need for blind trial and error.

A coincidental release window also provided objective momentum. On the evening of July 24, Anthropic officially announced Claude Opus 5. The research team adopted the new model merely hours after its release, introducing it as an intentional technical variable after hitting roadblocks in their testing.

Manually reducing the complexity of the task was another vital step. Upon getting Opus 5, the researchers did not target the live system directly; instead, they ported the binary to a local ARM64 Mac to reproduce the environment, spent roughly 3 hours generating a working script adapted to the local architecture, and only then ported the validated logic to the cloud environment running an x86-64 architecture with the jemalloc memory allocator.

Bypassing safety guardrails also relied on deliberate engineering. The model’s built-in safety mechanisms would refuse requests to craft exploit scripts targeting remote production environments. To keep the model working, the research team configured a proxy network, disguised their own cloud servers as a capture-the-flag (CTF) range, bypassed the model’s moderation prompts, and prompted the model through multiple rounds of automated debugging and refinement.

In pure cyber-adversarial benchmarks, Opus 5 did not demonstrate a generational leap. According to Anthropic’s official system card data published alongside the model, Opus 5’s scores in exploit benchmarks lagged significantly behind specialized models:

far behind that of Mythos 5

Within Anthropic’s current model roster, there is a model called Mythos 5 whose official evaluations highlight exceptional cyber-adversarial capabilities; it is offered exclusively to a select few strictly vetted organizations. The Straits Times, citing a source, disclosed that the Hacktron team had no access to Mythos 5 at any point during their testing.

In their subsequent spin-off project, HEIF Heist, the research team also mentioned testing models from other vendors, such as GPT-5.6 Sol, claiming they could achieve automated reconnaissance within days. These claims span disparate technical architectures and operational environments, lacking a controlled baseline.

Using algorithms to assist in discovering software defects has clear precedent. Google Project Zero’s Big Sleep project, unveiled in October 2024, demonstrated a systematic approach to the automated discovery of a real-world zero-day vulnerability in SQLite; the security platform XBOW also secured top spots on bug bounty leaderboards with roughly 1,060 human-reviewed automated submissions. Compared to these industry milestones, the incremental advance shown by the Hacktron team was using a language model to accelerate writing memory exploit code for a complex, hardened environment—predicated on human experts already having identified the root cause and built out the debugging scaffold.

Claims regarding testing costs and detection must be treated strictly as self-reported assertions. According to Hacktron’s post-hoc statements, during the two-month HEIF Heist project involving three researchers, total API token expenses were under $3,000, adapting to each new target took roughly 1 to 2 days, and fully automated runs typically achieved working code execution within 1 to 3 days. The researchers also claimed that the thousands of malformed images sent during testing caused frequent crashes across multiple tested platforms, with no vendor detecting anomalies except the major e-commerce enterprise Shopify. These figures remain purely unilateral assertions by the research team; the team did not publish API billing receipts or have access to the tested companies’ internal intrusion detection logs, and Shopify never publicly commented on this testing.

The model did not autonomously discover deep, unknown flaws in the system; its real utility lay in compressing the time required for manual reverse engineering and debugging. Aligning memory layouts—a task that would previously require days of effort from a senior security engineer in a lab—was shrunk down to a matter of hours by the assistant tool.

The connector Sets the Ceiling of Breach Consequences

Reflecting deeply on this incident, my focus gradually shifted from frontend model capabilities to backend privilege connections. For teams configuring multi-agent systems daily and connecting developer assistants to code repositories and credential stores, the mechanism exposed by this event can be captured in a single sentence: once a peripheral system or authentication credential is compromised, the extent to which damage can spread is dictated by the actual permissions granted to the connector, bearing little relation to the attacker’s technical sophistication.

Had the Codex connection configured by that internal employee held only read-only access to the repository, or had its scope been strictly confined to an isolated experimental project, the actions available to the testers—even after taking over the session—would have stopped short of the repository. In reality, Codex had been granted write access across the global codebase. Once the single sign-on credential was breached, the vulnerability in a peripheral service channeled directly into the core code repository through this pre-established conduit.

Systemic countermeasures become clear as a result. Teams must examine trust propagation across their identity topology, systematically auditing peripheral services to verify whether high-privilege core systems unconditionally trust and accept credentials issued by lower-security services. OpenAI’s rapid narrowing of community forum login token scopes in the aftermath was specifically aimed at severing the pathway through which trust could penetrate inward from the outside.

Parallel to identity topology is the auditing of the effective permissions held by automation tools, which cannot be reduced to merely logging their presence in an inventory. Every time a development environment or agent is linked to GitHub, cloud service keys, or communication endpoints, one specific question must be asked: assuming this external service is compromised tomorrow, which internal endpoints could an attacker invoke, and what data could they read using those existing credentials? Tightening write permissions to read-only, and narrowing organization-wide wildcard authorizations down to project-specific access, directly lowers the ceiling of damage that a potential breach can inflict.

Confronting such risks, defensive measures can easily drift into over-engineering. The lesson here is not that engineers should retreat to a manual era, nor should they stack cumbersome sandboxing layers and communication relays around development environments. Cumbersome isolation mechanisms often merely slow down development velocity, encouraging employees to seek informal workarounds. When it comes to maintaining dependencies, the traditional mindset that obscure, legacy libraries do not matter also requires updating: now that large language models have compressed the cost of exploiting complex memory vulnerabilities, low-level parsing libraries previously thought to have prohibitively high barriers to entry are now squarely within range of low-cost attacks, dismantling the security assumption that high attack costs alone provide safety.

Hacktron’s penetration testing differs fundamentally in its mechanics from the Anthropic evaluation incident discussed across the industry in August 2026. In that evaluation mistake, known within the industry as the Irregular incident, an operational configuration oversight left an evaluation environment directly connected to the public internet. This allowed an autonomously running model to reach live network assets of external enterprises, stopping on its own only upon encountering a login page—an automated boundary crossing caused by a lack of sandbox network isolation. In the OpenAI incident, by contrast, human researchers planned the route throughout, tested hypotheses against production systems, and submitted the disclosure, with the model serving as an assistant tool for coding and debugging.

When evaluating the security risks of automation tools, rather than stacking layers of protective shells, it is better to tighten the effective permissions of external credentials to the minimum scope required for the task.

Automation components have vastly boosted engineering productivity, but the credentials technical teams grant these tools often cross trust boundaries, leaving long-lived write conduits into internal systems.

There is one additional boundary that anyone recounting this story must keep in mind: OpenAI later paid a $6,500 bug bounty, but according to the official review feedback transcribed by Hacktron, that payment covered only the findings on the single sign-on system, as the forum itself was explicitly excluded from the bounty program; the research team proceeded to take over the employee’s account and submit an internal pull request even after submitting their report, an operation situated in a gray area of ambiguous authorization. A bounty awarded for an isolated vulnerability does not constitute retroactive approval of the entire testing chain. How far an account compromise can reach is ultimately bounded by the permissions you grant to the connector.