The extortion group ShinyHunters hacked the dark web leak site run by Clop, one of the most active ransomware operations in the world, defaced it with their own branding, and is now threatening to put Clop through the same extortion process Clop runs on its corporate victims.
The attack happened Friday night, September 19. ShinyHunters found an unauthenticated file upload flaw in Grav CMS, the content management system Clop was running its leak site on, and used it to push a text file directly onto the server. The file read: "THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p - Maybe don't try to threaten us next time." It also linked back to ShinyHunters' own Tor site. The file was confirmed live and downloadable directly from Clop's server.
Hours later, ShinyHunters said they had gone further. A visit to Clop's site showed the entire page replaced with ASCII art of Umbreon, the Pokemon ShinyHunters uses as its logo, and the line "rooting your systems since '19 ;)". The same Umbreon artwork had appeared when ShinyHunters defaced HackForums back in August 2020. Clop's defaced page was still live at the time of writing.
ShinyHunters claimed full access to the server and said they took source code, Grav CMS plugins, and everything stored in the server's /var/log directory, which typically holds authentication logs, system activity records, and the IP addresses of everyone who connected to it. They also claim to have pulled the private keys for Clop's Tor onion service. Those keys are what tie a .onion address to its server. With them, ShinyHunters could host a copy of Clop's site at the exact same onion URL, on infrastructure they control. "We have their onion keys. So if they kick us out it wouldn't matter at all because we control the private keys to host the same exact onion URL," the group said.
The plan is to post an extortion message on their own site and give Clop 72 hours to respond.
The defacement and the uploaded file are independently confirmed. The claims about stolen source code, server logs, and Tor private keys come only from ShinyHunters and have not been independently verified. Clop has not commented.
The dispute behind this attack goes back about a year. In August 2025, Clop quietly began exploiting a zero-day vulnerability in Oracle E-Business Suite, tracked as CVE-2025-61882, a server-side request forgery flaw that gave attackers remote access to enterprise systems without authentication. Oracle did not patch it until October 2025, after Mandiant confirmed active exploitation. By then, Clop had already sent mass extortion emails to executives at dozens of companies, including Cox Enterprises, The Washington Post, Logitech, Michelin, and Estee Lauder.
ShinyHunters says that exploit was originally theirs and that Clop used it without authorization. In October 2025, ShinyHunters, operating under the name "Scattered Lapsus$ Hunters," leaked the proof-of-concept publicly. Oracle confirmed it matched the exploit used in the Clop attacks. ShinyHunters said the leak was deliberate, intended to disrupt Clop's campaign and expose what had been taken from them.
What followed, according to ShinyHunters, was a direct threat from a Clop representative. "During the Oracle EBS campaign they ran and stole from me last year, someone from cl0p personally messaged me and said, and I quote (translated from Russian): I have more money than you and all of your people combined, I'll kill you soon," the group said. Those allegations have not been independently verified.
This is not the first time criminal groups have turned on each other. In March 2025, DragonForce defaced the leak sites of rival operations BlackLock and Mamona. Later in 2026, two groups called 0APT and KryBit hacked and leaked each other's operational data until both were left severely damaged. The difference in the Clop case is the scale of the target. Clop's leak site is the operational center of its entire extortion model, the platform it uses to name victims and apply public pressure when ransoms go unpaid. Losing control of it, and potentially the keys that anchor its onion address, is not a minor disruption.
ShinyHunters' own Tor site went offline shortly after the attack. No connection to Clop has been established.
A three-person security research team quietly walked into OpenAI's internal infrastructure last July, submitted a pull request inside the company's private monorepo as proof, and then stopped. The whole operation, from first vulnerability discovery to confirmed repository access, took under 72 hours. The tool that made it possible was not a custom-built hacking suite. It was Claude Opus 5.
The researchers, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, work at Hacktron, an AI-assisted security research firm. They published their full technical account on September 13. OpenAI confirmed a fix roughly 14 hours after receiving the initial report on July 25, and paid out a $6,500 bounty on September 1.
The case is one of the clearest demonstrations yet of what skilled human researchers can accomplish when they hand the grinding, iterative work of exploit development to a capable AI model. It is also a story about a mundane but persistent failure: software that depends on unpatched libraries, and login systems that trust services they probably should not.
The Chain That Got Them In
The attack surface was not OpenAI's flagship products. It was the company's public help forum, community.openai.com, which runs on Discourse, an open-source forum platform used by tens of thousands of organizations.
Discourse allows users to upload images. For most formats, it relies on a tool called FastImage to inspect files before processing them. But FastImage does not support HEIC or HEIF images, the high-efficiency formats popularized by Apple. So Discourse passes those files to ImageMagick instead, which in turn calls an underlying library called libheif to do the actual decoding.
That handoff is where the vulnerability lived. libheif version 1.19.7, the version running inside Discourse's Docker image at the time, contained a heap buffer overflow. A specially crafted HEIC file could corrupt server memory, giving an attacker the ability to manipulate program execution. The flaw is tracked as CVE-2026-32882 and carries a severity score of 8.8 out of 10 in Discourse's own advisory, which classifies the result as remote code execution.
The patch for this bug had been available since libheif 1.22.0, released in May 2026. The CVE existed. The fix existed. But Discourse's Docker image, built on Debian 12, still shipped the old, vulnerable library when the Hacktron team looked in July. Debian had not yet backported the fix into its packaged version. That two-month window between upstream patch and downstream delivery is what the researchers walked through.
Once they had code execution on the Discourse server, the path to OpenAI employee accounts ran straight through the forum's login button. OpenAI's forum offers a "Sign in with OpenAI" option, the same single sign-on system its staff uses for ChatGPT, Codex, and other internal services. With control of the forum server, the researchers could hijack that authentication flow and take over the accounts of any OpenAI employee who had ever used it. The victims did not have to click anything or be online at the time.
Hacktron was explicit in their writeup about what this means: the forum was one path, not the problem. "If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to the same access," the team wrote. The identity flaw was OpenAI's, not Discourse's.
After confirming the account takeovers, the researchers used one employee's Codex account, which was connected to OpenAI's GitHub organization, to open a single pull request inside OpenAI's internal monorepo. They read nothing, merged nothing, and touched no customer data. The pull request was the proof. Then they stopped and filed their report.
Where the AI Came In
The libheif heap overflow gave the researchers memory corruption primitives, which is a starting point, not a working exploit. Memory corruption bugs require additional work to become reliable code execution, particularly on modern systems protected by Address Space Layout Randomization (ASLR), a defense that scrambles where code sits in memory to make it harder to redirect program flow.
This is where most vulnerability research slows down. Turning a crash into a reliable, weaponized exploit requires significant expertise, patience, and time. The Hacktron team decided to find out how much of that work an AI could absorb.
They started with Claude Opus 4.8, the previous flagship model from Anthropic. Across multiple sessions, it managed to help develop a working exploit when ASLR was disabled. When they enabled ASLR, matching the configuration of real servers, Opus 4.8 struggled and failed to produce anything reliable.
On the evening of July 24, Anthropic released Claude Opus 5. The researchers started a fresh session.
Within three hours, Opus 5 had produced a working exploit for an ARM64 Mac environment. They asked it to adapt the exploit to x86-64 and to the jemalloc memory allocator configuration that Discourse uses. By 6:00 a.m. on July 25, they had confirmed local code execution through an image upload.
The researchers then placed Claude in what they describe as an autonomous "/goal" loop, pointed at their own Discourse Cloud instance, framed as a capture-the-flag practice target. Opus 5 has guardrails meant to prevent it from writing exploits for real systems, so the team disguised the target. When they checked again at 10:00 a.m., the agent had achieved code execution on their cloud instance on its own, demonstrating access by reading /etc/hosts. They then used the generated exploit on OpenAI's forum and confirmed it worked there too.
The researchers are careful to note that this was not fully autonomous hacking. Skilled human judgment and direction were required throughout. But the gap between what they could accomplish in hours with Opus 5 versus the days or weeks such work might have taken without it was significant.
The cost of the entire Discourse and OpenAI portion of the project: a few days of AI compute and a few hours of human time.
One Bug, Many Targets
The OpenAI breach was not a standalone operation. It was one piece of a broader research campaign Hacktron calls HEIF Heist, a multi-month investigation into how widely the libheif library is embedded in major internet services, and how many of those services were running vulnerable versions.
Over roughly two months, the three researchers say they traced the same class of image-decoding flaws across software used by Slack, Meta, GitHub Enterprise, and web frameworks including Next.js, Astro, and Gatsby. The total cost of the entire campaign was under $3,000 in AI model usage, spread across roughly sixty days of work.
The team found that adapting each exploit to a new target environment generally took only one or two days with AI assistance. They report that the only company that appeared to detect their testing activity was Shopify, even after thousands of test images were sent to various targets and image processors at several of those companies crashed repeatedly under the load.
Not all of the claims have been independently verified. The Next.js vulnerability is confirmed in Vercel's own advisory. libheif's maintainers confirmed a working code-execution exploit against Meta's deployment of the library. The wider claim of successful code execution across the full list of targets has not been corroborated by external sources as of publication.
The HEIF Heist project also surfaced a difference between AI models. For cases where the team had information about the target environment, Claude Opus 5 was the primary tool. For targets where they had almost no prior knowledge of the deployment configuration, they switched to OpenAI's GPT-5.6 Sol, which they found performed better in those conditions. Each major model jump brought a clear capability improvement: Opus 5 succeeded where Opus 4.8 failed, and GPT-5.6 Sol handled blind exploitation scenarios that Opus 5 struggled with.
The report documented Russia-linked espionage operations using Claude to run nearly fully automated phishing campaigns against Ukrainian, European, and diplomatic targets. It described a Chinese group, including operators identified as university students in Hunan province, who used Claude as the core engineering layer of an offensive program that found multiple zero-day vulnerabilities in a major security product. It also described a French-speaking hacktivist who used Claude to attack European political parties, media organizations, and think tanks at a scale that previously would have required a well-resourced team.
Anthropic's core observation across all of those cases was the same observation the Hacktron team made in their own writeup: AI is closing the gap between what a small, budget-constrained team can do and what used to require state-level resources.
The Hacktron team put it plainly: "Work that once required a well-resourced team and months of effort can now be compressed into days."
That assessment lines up with what Anthropic itself told the company's own threat report readers, and with what security researchers have been warning about for the past year. The Hacktron operation is the first time those warnings have been backed by a public, step-by-step technical demonstration against one of the most scrutinized technology companies on the planet.
What Needs to Change
The specifics of the OpenAI fix have not been made public. The company acknowledged the finding through payment and remediation rather than through a detailed disclosure of the login flaw.
On the Discourse side, the forum platform responded fast: they received the report on a Saturday, replied on Sunday, had a fix ready on Monday, and published their advisory on Tuesday. They also added image-processing sandboxing as a hardening measure, running ImageMagick in a restricted environment so that even a successful exploit against the image library cannot directly execute arbitrary code on the host server.
The security promise was simple. A plugin marketplace reviews a piece of code, locks it to a specific, verified version, and every AI coding agent that installs it gets exactly what was reviewed. No surprises or swaps. That promise just got broken, simultaneously, across every major AI coding agent on the market.
On September 17, cybersecurity startup AIR Security publicly disclosed Plugin4Shell, a zero-click, high-severity remote code execution vulnerability affecting Anthropic's Claude Code, OpenAI's Codex, Microsoft's GitHub Copilot, and Google's Gemini CLI. The name is a deliberate echo of Log4Shell, the 2021 Apache flaw that shook enterprise security teams for months. This one hits a faster-moving target: the plugin ecosystems that have quietly become critical infrastructure for millions of software developers.
The researchers who found it, Or Nevo, Dor Granat, and Niv Hoffman, describe it as the first supply-chain vulnerability of the AI agent ecosystem. That is not a small claim, and the technical details back it up.
How the Attack Works
To understand Plugin4Shell, you need to understand SHA pinning, the mechanism it breaks. When a marketplace approves a plugin, it records a cryptographic commit hash, a 40-character string that uniquely identifies an exact snapshot of the plugin's code. From that point forward, every agent that installs the plugin is supposed to check out precisely that commit. Reviewed code, nothing else, forever.
The vulnerability is a single missing verification step. Affected agents fetch the pinned commit during installation but never confirm that the code they actually land on matches it. That gap opens the door to a Git reference resolution trick.
For Claude Code, Codex, and GitHub Copilot, an attacker who controls a plugin repository can create a branch whose name is the exact 40-character pinned commit hash, set it as the repository's default branch, and point it at malicious code. When the agent runs its checkout, Git resolves the branch name instead of the commit object, because Git prefers a matching reference when the name is ambiguous. The agent installs attacker-controlled code, reports a clean install at the trusted hash, and nothing looks wrong.
Gemini CLI has a slightly different variant. Its installer fetches the target commit and then checks out FETCH_HEAD, but if the repository's default branch is itself named FETCH_HEAD, that checkout resolves to the branch instead. The fetched commit gets silently discarded.
What makes this zero-click is auto-update. Claude Code and Codex update installed plugins in the background by default. When a plugin's pinned commit is swapped upstream, an already-installed, already-trusted plugin gets silently replaced with a malicious version. No prompt. No reinstall. Nothing for the user to notice or decline.
Plugins run with the permissions of the developer operating the agent. That means an attacker who succeeds here lands in the developer's machine with access to source code, cloud credentials, SSH keys, internal repositories, and production systems.
The Context Makes It Worse
Plugin4Shell is the third installment in a series of findings from AIR Security, each one showing a different layer of the AI plugin ecosystem collapsing under scrutiny.
In earlier research called "The Story of Skills," the team published a malicious skill to a trusted marketplace and watched it spread to over 26,000 agents. In SkillJacking, they found 925 skills already in active use had been quietly hijacked from their original maintainers, affecting 134,000 agents, by taking over the repositories behind them.
The industry's answer to SkillJacking was SHA pinning. Plugin4Shell is the answer to that answer. The takeovers AIR demonstrated in SkillJacking can now be combined with Plugin4Shell to bypass the exact safeguard that was supposed to contain them. The chain is proven end to end.
Vendor Responses
AIR found the vulnerability in May 2026, built working proof-of-concept exploits against all four agents, and disclosed everything to the vendors in June. What happened next drew a clear line between the companies that acted and the ones that did not.
Anthropic patched Claude Code in version 2.1.179. OpenAI patched Codex in version 0.146.0. Both confirmed fixes after disclosure.
Microsoft has not shipped a fix for GitHub Copilot. GitHub has argued that its platform blocks branch and tag names that resemble commit hashes, which limits the attack surface for GitHub-hosted plugins. AIR's counter is that Copilot also supports marketplaces hosted on Bitbucket and self-hosted git servers, which permit such names, and that GitHub's restriction does nothing for those configurations. The two positions describe different scopes. Copilot users currently have no patch.
Google's response was to deprecate Gemini CLI entirely. The company confirmed in August that no fix would ship, directing users to migrate to an alternative product called Antigravity. Every existing Gemini CLI installation remains permanently vulnerable.
What Users Should Do Now
The fix, technically, is a single line of verification that every affected agent was missing: after checkout, compare the actual HEAD commit against the pinned hash and abort if they do not match. Because the check runs inside the agent rather than at the marketplace, no marketplace can enforce this guarantee on its own. Only an agent-side fix closes it.
Claude Code users should update to version 2.1.179 or later. Codex users should update to version 0.146.0 or later. Gemini CLI users should migrate away from the product. GitHub Copilot users have no patch available and no confirmed timeline for one.
For enterprise teams that have built internal vetting processes around SHA pinning, Plugin4Shell is a harder problem. The review passed. The pin was written. Different code got installed. Every downstream security process built on that guarantee inherits the failure.
The most striking detail in AIR's disclosure is not the vulnerability itself. It is that four independent engineering teams at four separate companies all made the same mistake, building the same flawed assumption into their auto-update pipelines, and none of them caught it until an outside lab did. That is not an implementation error in one product. That is a design assumption the entire industry shared, and nobody questioned it.
Docker has patched two vulnerabilities in Docker Sandboxes that could allow malicious code running inside an isolated sandbox to cross its intended workspace boundary and interact with resources on the host system.
The more severe issue, tracked as CVE-2026-77179, affects Docker Sandboxes versions 0.28.0 through versions before 0.42.0 on macOS and is rated Critical. Docker fixed the vulnerability in Sandboxes 0.42.0, released September 7. The company disclosed the security issues publicly on September 15.
Docker Sandboxes are designed to give AI coding agents their own microVM environment where they can execute code, install packages and use development tools without directly accessing the host. The security architecture treats the microVM as the primary trust boundary, with the agent receiving full control, including "sudo", inside that environment. Resources such as a developer's project directory are selectively exposed across the boundary.
The problem in CVE-2026-77179 occurs in the virtio-fs host server, which handles filesystem sharing between the macOS host and the sandbox. Docker said the component could follow a symbolic link when reopening an unlinked file through a previously stored pathname.
A malicious process inside the VM could exploit this behavior by changing a parent directory into a symbolic link after the original path had been accepted. When the host subsequently reused the stored path, the operation could be redirected to a different location outside the authorized workspace.
This creates a path traversal condition across the VM boundary. Docker said an attacker could consequently read or modify arbitrary host files available to the account running the virtual machine monitor. Depending on what files can be changed, the access could potentially be turned into host-side code execution.
The requirement for malicious code to already be executing inside the sandbox does not eliminate the security concern. Docker Sandboxes are intended to contain precisely the type of untrusted code that an autonomous coding agent might encounter through a compromised repository, malicious dependency, poisoned package or manipulated instruction. If that code can alter host-visible filesystem paths, the microVM's isolation boundary becomes vulnerable at the point where the host performs the subsequent filesystem operation.
The second vulnerability, CVE-2026-79994, affects versions 0.37.0 through versions before 0.42.0. Docker rates it High with a CVSS 4.0 score of 8.7.
This issue affects the guest-to-host relay used for Unix domain sockets. The relay initially verified that a requested socket was located inside an authorized workspace, but later established the connection by using the pathname again. A malicious guest could change an intermediate directory into a symlink during that interval, causing the host to connect to an AF_UNIX socket outside the permitted workspace.
The vulnerability is classified as a time-of-check to time-of-use (TOCTOU) race condition, because the security decision is made against a pathname whose meaning can change before the privileged operation occurs. The resulting connection could expose data or host-side capabilities provided by the targeted socket.
Together, the two flaws expose different host interfaces through a similar underlying weakness: trusting a pathname after an attacker-controlled environment has had an opportunity to alter what that pathname resolves to.
The risk is amplified by how Sandboxes share development workspaces. Docker says "sbx run" normally mounts the current directory into the sandbox with read-write access, meaning an agent can directly modify the developer's working tree. Docker also warns that files such as Git hooks, CI configuration, IDE task definitions and project scripts can affect subsequent host-side development activity.
For users unable to update immediately, Docker recommends clone mode and advises against additional read-write host mounts. Clone mode mounts the repository read-only at "/run/sandbox/source" while the agent works from a private clone inside the VM. However, it is not a confidentiality boundary: files available in the mounted repository, including untracked files such as ".env", may still be readable by the agent.
Docker has reported no exploitation of either vulnerability. Neither issue was listed in CISA's Known Exploited Vulnerabilities catalog at the time of disclosure.
The company credited Oren Yomtov of accomplish.ai with discovering CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994.
The fixes arrived amid wider security scrutiny of AI coding environments. Earlier research from Cyera Research Labs demonstrated how a prompt-injected coding agent operating inside a Docker-based environment could be used as part of an attack chain against the host through a separate Docker Engine vulnerability. The latest disclosures reinforce the importance of treating autonomous coding agents as potentially hostile workloads, even when they are placed inside purpose-built isolation mechanisms.
Users running affected Sandboxes versions should upgrade to 0.42.0 or later. Docker Sandboxes 0.43.0, released September 15, is the latest stable release as of September 18.