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.
Security researchers at JFrog disclosed the vulnerability on Tuesday, assigning it the identifier CVE-2026-90894 and the nickname "ParaShells." JFrog rates the flaw 7.8 out of 10 on the CVSS severity scale. The bug does not allow remote attacks over a network. An attacker needs code already running on the machine as an ordinary local user, but once that condition is met, exploitation does not require administrator rights, a signed Parallels client, or an active virtual machine.
What Parallels Desktop Is and Why This Matters
Parallels Desktop runs Windows and Linux inside virtual machines on a Mac. It installs a background service called prl_disp_service that runs as root, because its work includes setting up host networking and unpacking virtual machine packages. The flaw is on the Mac side of the product, so the machine at risk is the Mac itself rather than the virtual machines on it.
That distinction is important. Many Mac users who run Parallels think of security risks as something that might affect the virtual Windows or Linux environment inside. ParaShells skips the guest entirely and compromises the Mac host directly.
How the Attack Works
The exploit chains together three separate weaknesses, none of which would be enough on its own.
The vulnerability combines three security weaknesses: a world-writable Unix socket, weak local client authentication, and argument injection during appliance extraction. On a default installation, prl_disp_service listens through /var/run/prl_disp_service.socket. JFrog researchers found that the socket could have 0777 permissions, allowing any local process to connect.
The login call that follows, PrlSrv_LoginLocal, checks only the credentials the kernel reports for the connecting process. It needs no Parallels code signature and works for an account that is not an administrator.
The third piece is where things get technically interesting. To install a virtual machine appliance, the service builds its unpack command as one line of text, tar -xf "%1" -C "%2". It then splits that text back into separate arguments using Qt's QProcess::splitCommand. The caller chooses part of that text, because it picks the folder the new virtual machine goes into. A double quote inside the folder name closes the quoting early, so whatever the attacker put after it becomes extra options for tar instead of part of a path.
The option JFrog used was --use-compress-program, which tells macOS tar to hand the archive to another program first. Because tar is running as root here, that program runs as root too. JFrog's test script wrote a passwordless sudo rule and opened a root shell.
In the lab demonstration, the sequence plays out in seconds: connect to the socket, send a crafted appliance install request with a poisoned directory path, and watch the compression program execute as uid 0. JFrog assembled this into a one-liner but has chosen not to publish that script, releasing the technical breakdown without the ready-to-fire weapon.
Yuval Moravchick, JFrog's vulnerability research team lead, explained: "The chain is short: A world-writable Unix socket, a login that trusts peer credentials rather than a Team ID, and an appliance unpack path that builds tar arguments using Qt string splitting. A quote in the parent path injects --use-compress-program=, and macOS tar runs the attacker's script as uid 0."
Who Is Most at Risk
The danger is highest on developer laptops, where a single poisoned Homebrew formula or malicious npm preinstall script can go from local user to full control, and on shared university and corporate machines that have many local accounts.
The threat model here is real and not hypothetical. Software developers routinely run third-party tools through package managers like Homebrew or execute npm scripts from projects they pull from the internet. Every one of those code paths represents a potential entry point for an attacker who knows the machine has Parallels installed. On a shared training lab or university computer lab Mac with a dozen local accounts, a single weak password or compromised student account is all it takes.
"From root, the attacker can replace system software, read other users' data, and persist via launchd," Moravchick noted. That last point about launchd persistence is particularly concerning because an attacker who establishes root access through this chain can survive a reboot by registering their own background processes with macOS's system daemon manager.
JFrog also confirmed no virtual machine needs to be actively running. The vulnerable service, prl_disp_service, starts automatically via a launch daemon at load, runs as root, and exposes the socket regardless of whether any VM is open. Simply having Parallels Desktop installed is enough to create the exposure.
The Patch Is Out, With a Catch
JFrog reported CVE-2026-90894 to Parallels maker Alludo, which fixed it in Parallels Desktop v27.0.0, released at the beginning of September 2026. The fix is real, but getting to it is not straightforward for a meaningful portion of Parallels' user base.
Parallels Desktop 27 needs a Mac with an Apple silicon chip. Its system requirements list Apple silicon only for the processor and macOS Sonoma 14.7 or newer for the operating system. On earlier releases of macOS, including Ventura 13, the installer sets up an older version of the product instead. Parallels removed Intel Mac support in version 27 and says the change follows Apple's plans rather than its own.
For Intel Mac users, the situation is murky. Intel users are told to stay on Parallels Desktop 26. "Parallels Desktop 26 fully supports Intel-based Mac computers today, and that will not change," the company wrote on 25 August, three weeks before this flaw became public, adding that Intel users can keep using version 26 and "expect future security and maintenance updates."
The problem is that according to JFrog, "Hosts that stay on the 26.x line, including 26.4.2, do not have that extract change." JFrog does not say it tested 26.4.1 or 26.4.2, and its writeup says it did not check older builds.
Parallels has not published a statement about CVE-2026-90894, and its list of security fixes, which maps each flaw to the version that repairs it, has not been reviewed since May 2025 and does not include this one. That leaves Intel Mac users running Parallels in a difficult position: a confirmed flaw, a fix that requires hardware they do not have, and no public acknowledgment from the vendor about plans for their platform.
The release notes for Parallels Desktop 26.4.2, which shipped on September 8, describe a single change related to Enterprise edition deployment and say nothing about a security fix for the extract path.
What Organizations Should Do Now
JFrog's immediate guidance comes in three parts: find every Mac in your environment running Parallels Desktop, restrict who can log in to those machines locally, and upgrade to version 27.0.0 or later where possible.
Two commands can confirm exposure without making any changes to the system. Running defaults read "/Applications/Parallels Desktop.app/Contents/Info" CFBundleShortVersionString reports the installed version, and ls -l /var/run/prl_disp_service.socket shows the socket permissions. JFrog says a socket showing srwxrwxrwx on a build at or near 26.4.0 should be treated as exposed until a patched build is confirmed.
Administrators using device management to push updates should check version rules before pushing anything. Parallels warns that a policy which sends out new major versions automatically will try to install version 27 on Intel Macs and fail.
One more complication: none of the published material says whether installing a fixed build removes access an attacker has already taken. JFrog notes that an attacker who reaches root can keep a foothold through launchd, which a product update would not clear. For any machine where compromise is suspected, an update alone is not enough.
Acronis has confirmed that attackers are actively exploiting a high-severity security flaw in its backup plugin for cPanel and WebHost Manager (WHM), urging system administrators to install available patches without delay.
The vulnerability, tracked as CVE-2026-87886 and rated high severity, allows local privilege escalation through insecure file permissions. Classified under CWE-276 (incorrect default permissions), the flaw affects Linux-based installations of the Acronis backup plugin and, if exploited successfully, could allow a threat actor to compromise system confidentiality, integrity, and availability.
The flaw received its CVE designation on Tuesday, September 16, after Acronis quietly published a brief initial advisory over the weekend. The company assigned it a CVSS severity score of 7.8.
What the Plugin Does
To understand the risk here, it helps to know what this software actually sits on top of. The Acronis Backup plugin for WHM and cPanel gives hosting providers and web professionals cloud backup capabilities and granular, self-service recovery for end clients, including the ability to back up an entire cPanel server to cloud storage.
Acronis is a cybersecurity and data protection technology company that is popular among web hosting providers and managed service providers, since its platform lets them offer backup and security to their clients under their own branding. Its backup add-ons connect cPanel and Plesk to Acronis' cloud infrastructure, letting administrators back up and recover sites, databases, and mailboxes.
That puts the plugin in a particularly sensitive position on any server it runs on. An attacker who can escalate privileges inside this kind of environment has a direct path to the backup data of every customer account on that server.
The market footprint here is worth noting. According to the 2026 Web Hosting Trends Report by WebPros, cPanel/WHM leads the hosting control panel market with 64% adoption, while Plesk accounts for 31%. Both platforms are affected by this vulnerability, though active exploitation so far appears confined to cPanel and WHM deployments.
How the Attack Works
CVE-2026-87886 stems from insecure file permissions and allows authenticated attackers to achieve local privilege escalation without any user interaction. The vulnerability's CVSS string indicates that it can be exploited in low-complexity attacks, meaning the attack does not require special conditions or circumstances beyond the attacker's control to succeed.
In plain terms: an attacker who already has a low-level foothold on a vulnerable Linux server running this plugin can use this flaw to climb to higher privilege levels, without needing to trick a user or wait for any specific system event. Depending on the access gained, this could allow sensitive data to be accessed or modified and could potentially disrupt the server.
The type of data at risk includes backup data, system files, and customer account data.
Targeted Attacks, Limited Disclosure
Acronis' advisory language around the exploitation is measured but direct. The company stated that "exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel and WHM deployments."
However, the disclosure comes with some important caveats. BleepingComputer reported that Acronis based that assessment on a single report from a potentially affected customer. That is enough to justify urgent patching, but it is not the same as evidence of broad, automated exploitation across hosting providers.
There are currently no signs of active exploitation on Plesk deployments. Still, the extension for Plesk remains vulnerable and should be patched regardless.
Acronis has not published detailed technical information about the flaw, saying it wants to give system administrators time to apply available patches before sharing further details. The company has also identified no specific indicators of compromise and has not disclosed when the activity occurred or what attackers achieved beyond the privilege escalation impact described in the advisory.
What Needs to Be Patched
Acronis pushed out security updates for the affected plugins before the CVE was formally assigned. The versions administrators need to be on are:
Acronis Backup plugin for cPanel and WHM builds earlier than 1.9.3.1021, now fixed in version 1.9.3 HF3, and Acronis Backup extension for Plesk builds earlier than 1.8.11.638, fixed in version 1.8.11.
For shared hosting providers, the guidance is to check every server image and automation path, rather than assuming the version on one control-plane node represents the entire fleet. Once patched, administrators should also focus review on systems where initial access was plausible: servers hosting compromised sites, accounts with recent credential resets, and hosts that allow customers to upload or execute code.
One additional note worth flagging: a cPanel or Plesk server without the Acronis plugin or extension is outside the scope of CVE-2026-87886. This is an Acronis integration issue, not a blanket advisory for every cPanel, WHM, or Plesk installation.
Acronis is a Swiss cybersecurity company headquartered in Schaffhausen and operates a global network of cloud data centers, supporting over 20,000 service providers that protect approximately 750,000 businesses worldwide. That scale makes vulnerabilities in its hosting integrations a high-priority concern for the managed service provider community, where a single compromised server can cascade into customer data across dozens or hundreds of accounts.
The company has not indicated whether it plans to release a more detailed post-mortem on the exploitation activity once patching rates improve, which is a common practice after actively exploited flaws. For now, the immediate priority is getting affected installations onto the fixed builds before whatever foothold attackers have found gets wider use.