> ## Content Index > Fetch the complete content index at: https://nextwith.ai/llms.txt > Use this file to discover other available public pages before exploring further. # AI-assisted bug-bounty chain reached OpenAI employee accounts. The larger signal is security work at machine speed - URL: https://nextwith.ai/bug-bounty-researchers-say-claude-helped-them-access-openai-employee-accounts/ - Published: 2026-09-18T14:10:26.000Z - Updated: 2026-09-19T03:42:23.000Z - Description: Researchers say an AI-assisted bug-bounty chain combined a third-party flaw with an OpenAI sign-in weakness. The security lesson is not that one chatbot acted alone, but that AI can compress skilled offensive work while ordinary identity and dependency controls still determine the impact. - Author: NextWith.ai Editorial Desk - Tags: Safety & Policy, News **Security researchers say an authorised bug-bounty test combined an exploit in forum software with an OpenAI sign-in weakness, reached employee ChatGPT and Codex accounts, and demonstrated a path into an internal code repository.** OpenAI says it fixed the reported issues and paid the researchers a $6,500 bounty. The incident is significant because AI-assisted tooling appears to have shortened work that still depended on a human-led chain of conventional security failures. That last distinction matters. The public account does not show a model independently deciding to attack OpenAI, nor does it establish an ongoing compromise of customer accounts. It describes researchers using Anthropic’s Claude and other tools during an authorised disclosure effort, then reporting the findings. The security lesson is less dramatic and more useful: capable models can reduce the time and specialised effort needed to investigate, develop and connect vulnerabilities, while the eventual impact remains governed by software maintenance, identity design and access controls. ## What the reporting establishes Accounts from the researchers and subsequent reporting describe a chain rather than a single failure. The starting point was OpenAI’s Discourse-hosted community forum. SecurityWeek reports that an image-handling path involving HEIC or HEIF uploads exposed a flaw in a library used by the forum software. The researchers then combined that foothold with an OpenAI-side sign-in or single-sign-on weakness. The reported outcome was access to OpenAI employee ChatGPT and Codex accounts, followed by a demonstration of access to an internal repository. Reporting says the researchers used a benign pull request as proof rather than reading or extracting sensitive source material. OpenAI paid a bounty for the OpenAI-side finding; reporting also notes that the third-party forum testing fell outside the company’s bug-bounty scope. Those details are important because they narrow the claim. This was not a report that Claude found one magic vulnerability and accessed OpenAI by itself. It was a human-directed attempt that linked an unpatched or insufficiently governed dependency, a trust boundary and an account-access weakness. The result is still serious: a chain that crosses systems can turn a local fault into access to a more valuable environment. ## What AI changed in the account Hacktron, the research team, says it used Claude to help develop parts of the work and later used additional AI tools, including OpenAI models. The Guardian reported the team’s claim that work which previously required a well-resourced group and months could be compressed into days. That is a statement from the researchers, not an independently audited productivity measurement, but it fits the risk security teams already need to plan for. AI can assist with code comprehension, hypothesis generation, test construction, documentation review and the repetitive iteration involved in a research workflow. None of those capabilities removes the need for operator judgement. They can, however, lower the cost of trying more paths, reading more technical material and adapting work when an initial approach fails. In practice, that can make time-to-exploit a more important defence metric. The article should not turn that into a claim that a particular model is uniquely responsible. The reports describe a broader toolchain. Nor is there evidence here that an autonomous agent crossed the boundary without human control. The relevant development is the accessibility of capable assistance to skilled researchers operating in a real security environment. ## The controls that decide the blast radius For organisations running AI systems, this is a reminder to separate model-safety claims from application security. A model may be subject to misuse controls, while a deployment can still be exposed through a dependency, an image-processing path, an identity federation setting or an overly broad connection between a community service and internal accounts. The first task is asset and dependency visibility. Teams need to know where open-source components process untrusted files, how vulnerabilities are classified and patched, and whether an update that is not assigned a familiar identifier can still matter. The second is identity segmentation: a forum or community account should not silently inherit a route to sensitive staff systems. The third is proof-oriented incident response. A benign test action can demonstrate a serious path without becoming an excuse to collect more data than necessary. AI changes the tempo, not the fundamentals. Strong patch management, least privilege, short-lived credentials, monitored sign-in flows and practical red-team exercises remain the controls that restrict an attacker’s options when a model makes research faster. ## What remains unknown Public reporting does not provide a complete independent technical audit of every step in the chain, the number of accounts affected, or the full scope of systems the researchers could have accessed. It also does not establish a current customer-data exposure. The correct reading is therefore conditional: the researchers’ account is corroborated by OpenAI’s reported remediation and bounty payment, but the full technical evidence is not public. That limitation does not weaken the news value. It defines it. This is a responsibly disclosed, bounded case study of AI-assisted offensive security work. It is evidence that security teams should model faster human-led campaigns—not evidence that a chatbot autonomously breached a frontier lab. ## Why it matters now OpenAI has recently disclosed separate cases of concerning model behaviour under evaluation. Those reports concern model monitoring and alignment; this bug-bounty disclosure concerns the security of systems around a model provider. Combining the two into one story about an “AI hack” would blur a useful line. One asks what systems do under test. The other asks whether a company’s software, identity and supply-chain controls withstand an increasingly capable human adversary. That is the question this incident puts in focus. As AI compresses research and development cycles for defenders and attackers alike, organisations will be judged on whether they can close ordinary security gaps before a skilled team turns them into a chain. ## Sources - [TechCrunch: researchers used Anthropic’s Claude to hack into OpenAI](https://techcrunch.com/2026/09/18/researchers-used-anthropics-claude-to-hack-into-openai/?ref=nextwith.ai) - [The Guardian: OpenAI ‘ethically hacked’ with help of Anthropic’s Claude](https://www.theguardian.com/technology/2026/sep/18/openai-hacked-anthropic-claude-chatbot?ref=nextwith.ai) - [SecurityWeek: AI-built exploit and sign-in flaw opened path to internal OpenAI code](https://www.securityweek.com/ai-built-exploit-and-sign-in-flaw-opened-path-to-internal-openai-code/?ref=nextwith.ai) For security teams, the useful next check is to map every third-party component that can touch employee identity or support accounts, then confirm its owner, access scope and patch route. That turns a controlled disclosure into a concrete review of a similar boundary in your own stack.