It took researchers at security startup Hacktron less than 72 hours to get from a bug in OpenAI’s community forum to OpenAI’s internal GitHub monorepo, where they opened a single harmless pull request and stopped. Monorepos make it easier to work across a codebase, but they don’t isolate projects the way separate repositories do. AI coding agents raise the stakes because they can have broad, persistent access.

In a blog post, Hacktron researchers detailed how they used Anthropic’s Claude models to help chain two critical vulnerabilities together to compromise OpenAI employee ChatGPT accounts. From there, a compromised employee’s Codex environment gave them access to OpenAI’s internal GitHub monorepo.

The researchers stopped short of reading OpenAI’s source code or testing how much further they could go.

“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,” they wrote. 

How Hacktron reached OpenAI’s monorepo

Hacktron's research team started with the Discourse forum at community.openai.com. Because the forum supported “Sign in with OpenAI” via auth.openai.com, the researchers theorized that compromising it could give them a path into broader OpenAI services.

The researchers traced a remote code execution (RCE) vulnerability to Discourse’s image-upload pipeline. After Opus 4.8 struggled to make the exploit reliable, they used the newly released Opus 5 to confirm that local RCE could be achieved through an image upload.  

They placed Claude in an autonomous goal loop against their own Discourse Cloud instance as a capture-the-flag exercise after Opus initially refused to write an exploit chain for a remote instance. Four hours later, Claude had achieved RCE on their Discourse Cloud instance. On July 25, the researchers achieved RCE on OpenAI’s instance.

Hacktron said a separate misconfiguration in OpenAI’s SSO identity infrastructure then allowed the compromised forum to be used to take over ChatGPT and Codex accounts of users who had logged into it, without further interaction. The researchers then took over an OpenAI employee account whose Codex environment was connected to OpenAI’s GitHub organization and used it to open the proof-of-concept PR in the internal monorepo. The process took less than 72 hours, from initial discovery to repo access.

Hacktron reported the issue to OpenAI and separately to Discourse. About 14 hours after the initial OpenAI submission, OpenAI confirmed that its issue had been fixed. OpenAI did not respond to a request for comment by publication time.

What one compromised identity can reach

Independent technology analyst Carmi Levy called the OpenAI incident “something of a warning shot” for the industry. Monorepos may be convenient because they consolidate development resources for multiple projects, but when an identity has broad access across the repository, they can also become what Levy called a “monolithic target” for attackers looking to get more from a single compromise.

Erik Avakian, a technical counselor at Info-Tech Research Group and former CISO for the Commonwealth of Pennsylvania, said monorepos aren’t dangerous on their own. The issue is the concentration of risk. While monorepos can contain code for many different applications, services, libraries, and internal systems, they are one repository, and if a particular identity has broad access, the potential blast radius can become much larger than people realize. 

AI coding agents are consequential because they are designed to search code, understand relationships between components, and make changes across a codebase, Avakian noted. They can navigate that code much faster than a human attacker manually trying to determine where important code, dependencies and configurations are located.

“Those are incredibly useful capabilities, but if the agent, or the identity it is operating under, gets compromised, those same capabilities can work against you,” Avakian said. 

Avakian said access should follow least-privilege principles. If an agent only needs to read code, for example, it shouldn't have write access. GitHub Apps can be limited to selected repositories, granted different levels of repository permission, and use installation tokens that expire after an hour. But those permissions still operate at the repository level. In a monorepo, they don't create separate read boundaries between directories.

GitHub has separate controls over what gets changed or merged. It can require reviews from code owners, while branch protections and rulesets can require reviews, status checks, and other conditions before changes are merged. Those controls can restrict what gets changed or merged, but they don’t limit what the identity can see.

What security teams need to audit

Enterprises shouldn't be treating this as completely new territory, Avakian noted. Approaches like OAuth, service identities, short-lived credentials, and least-privilege access have been around for quite some time, and are now being extended to AI agents. 

“Right now, I would tell CISOs not to start with the agent,” Avakian said, “but with the credential.”

Security teams should first identify which credential the coding agent is using and what identity it represents, Avakian said: an employee OAuth token, GitHub App, service account, personal access token, Secure Shell (SSH) key, or another delegated credential. From there, security teams can assess its effective permissions:

  • Which repositories can it read? 

  • Which can it write to? 

  • Can it create pull requests, modify workflows, access secrets, or reach other connected systems? 

“That becomes the agent's real attack surface,” Avakian said. “And if nobody can answer those questions quickly, that's probably the first problem to fix.”

Avakian said coding agents should be treated as privileged actors and, wherever possible, given dedicated non-human identities, short-lived credentials, and the “narrowest repository permissions possible." He also recommended inventorying every coding agent and every credential or connector an agent can use and mapping its effective access, not just assumed permissions. That includes identifying agents operating with inherited employee credentials or broad OAuth scopes. 

But there does come a point where logical controls aren't enough, Avakian said. “If two pieces of code represent genuinely different security or trust boundaries, putting them in the same monorepo may end up inadvertently introducing unnecessary risk,” he said.