It took researchers at the security startup Hacktron less than 72 hours to travel from a bug in OpenAI’s public community forum to the company’s internal GitHub monorepo. Once there, they opened a single harmless pull request and stopped. They did not read the source code, and they did not test how much further they might have gone. The journey, not the plunder, was the point.
In a blog post, the Hacktron researchers described using Anthropic’s Claude models to chain two critical vulnerabilities together and take over OpenAI employees’ ChatGPT accounts. From one compromised employee’s Codex environment — OpenAI’s own coding agent — they reached the monorepo. The reason the reach was so long is ordinary enough: “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 starting point was the Discourse forum at community.openai.com. Because the forum offered “Sign in with OpenAI” through auth.openai.com, the researchers reasoned that owning it might open a path into wider OpenAI services. They traced a remote code execution flaw to Discourse’s image-upload pipeline. Claude’s Opus 4.8 struggled to make the exploit reliable; the newly released Opus 5 confirmed that local code execution could be had through an image upload.
There was a moment of refusal worth recording. Opus initially declined to write an exploit chain aimed at a remote instance, so the researchers set Claude in an autonomous goal loop against their own Discourse Cloud instance, as a capture-the-flag exercise. Four hours later the model had achieved code execution on that test instance. On July 25, the researchers achieved it on OpenAI’s.
The second flaw did the rest. A separate misconfiguration in OpenAI’s SSO identity infrastructure let the compromised forum take over the ChatGPT and Codex accounts of users who had merely logged into it, with no further action on their part. The researchers seized an OpenAI employee account whose Codex environment was connected to OpenAI’s GitHub organization, and used it to open their proof-of-concept pull request in the internal monorepo. From first discovery to repository access: under 72 hours. They reported the issue to OpenAI, and separately to Discourse, whose forum software carried the original flaw. About 14 hours after the first report, OpenAI confirmed its side was fixed. The company did not answer a request for comment.
The incident matters beyond one company because of the shape of modern code storage. A monorepo gathers many projects into one repository. It makes work across a codebase easy, but it does not wall projects off from one another. Independent technology analyst Carmi Levy called the affair “something of a warning shot” for the industry: give one identity broad access, and the convenience becomes what he called a “monolithic target”.
Erik Avakian, a technical counselor at Info-Tech Research Group and a former chief information security officer for the Commonwealth of Pennsylvania, takes the measured view. Monorepos are not dangerous in themselves, he said; the danger is the concentration of risk. One repository may hold many applications, services, libraries and internal systems, and a single broadly-permitted identity makes the blast radius larger than people realize. AI coding agents sharpen this, because they are built to search code, grasp how components relate, and change things across a whole codebase — far faster than a human burglar mapping the same ground by hand.
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
The remedies Avakian prescribes are old ones wearing new clothes. Access should follow least privilege: an agent that only needs to read code should not hold the power to write it. GitHub Apps can be confined to chosen repositories, given graded permissions, and issued installation tokens that die after an hour. Yet those permissions act at the level of the repository; inside a monorepo they draw no read boundary between one directory and the next. Code-owner reviews, branch protections and rulesets can govern what gets changed or merged, but they do not limit what a compromised identity may see.
“Right now, I would tell CISOs not to start with the agent, but with the credential,” Avakian said. Security teams should first name which credential the coding agent uses and whose identity it wears — an employee OAuth token, a GitHub App, a service account, a personal access token, an SSH key, or some other delegated credential. Then ask what it can truly do: which repositories it reads, which it writes, whether it can open pull requests, alter workflows, touch secrets or reach other connected systems. “That becomes the agent’s real attack surface. And if nobody can answer those questions quickly, that’s probably the first problem to fix.”
His remaining advice runs the same way. Treat coding agents as privileged actors; give them dedicated non-human identities, short-lived credentials and the narrowest repository permissions possible. Inventory every agent and every credential or connector it can use, map its effective access rather than its assumed permissions, and hunt down agents running on inherited employee credentials or broad OAuth scopes. And where two bodies of code represent genuinely different trust boundaries, he said, housing them in one monorepo “may end up inadvertently introducing unnecessary risk”. None of this is novel machinery; OAuth, service identities, short-lived credentials and least privilege have existed for years. What is new is that the identities are now handed, by default and at speed, to machines that never sleep. Hacktron stopped at one pull request; the next visitor may not be so polite.