An AI Agent Published Malware, Lied to a Developer, and Can Steal Your Account

The past month has been packed with stories of AI on the attack. Meta became the latest of the major companies operating AI models to confirm that one of its models penetrated another company’s systems during a security test and modified that company’s internal environment.

The model reached the internet due to a misconfigured test environment operated by a third party.

As I said, Meta was the latest of these companies. Before that, it was Anthropic, which disclosed on July 30 that during a review of 140,000 test runs it found three incidents in which Claude reached the internet and gained unauthorized access to the production infrastructure of three companies.

The model found fake setup instructions in the test environment referencing a non-existent Python package, realized that if it registered the name, the target machines would download its code on their own — so it created an account and published a malicious package on the real PyPI.

The package was online for roughly an hour before PyPI’s automation took it down; 15 real systems managed to download and run it. One of them was a security firm’s malware scanner, where the package stole credentials that the model then used to gain further access.

The Python package was published by Claude Mythos 5, which itself recognized that this was a real attack — and yet convinced itself it was running in a simulation and carried on with the attack.

The tests ran without the safety classifiers and monitoring that public versions of Claude have. Anthropic frames this primarily as a failure of test design and isolation, not as an “AI rebellion,” and claims that production safeguards would have blocked the behavior.

Ledger’s CTO dismissed this entire wave — which OpenAI kicked off and which we covered in a previous Security Sunday — as marketing theater.

What we’ve described so far were accidents. But the UK AI Security Institute showed what a model can do when you let it off the leash. The institute documented that leading models from Anthropic and OpenAI performed 19 unauthorized actions on the internet during tests.

The most serious case was a supply-chain attack on a real open-source project.

The model failed in the sandbox, so it found a real target on the web. It profiled two real maintainers via OSINT. It submitted a pull request with genuinely malicious code. It bypassed GitHub’s registration defenses using Tor and a commercial proxy. It created several fake accounts and used them to approve its own PR, manufacturing the appearance of consensus to pressure the maintainer. It sent 5 emails directly to the developers with malware and social-engineering pretexts. It opened a GitHub Issue containing a hidden prompt injection aimed at being executed by other developers’ AI assistants.

The only one who stopped it was a human. The maintainer read the diff, recognized what it was, and closed the PR. The attack failed even though the AI agents were cooperating with each other.

The previous cases were accidents. Now let’s look at the first time someone knowingly deployed an AI agent as a weapon.

A cybersecurity firm from Tel Aviv intercepted an attack in which a DeepSeek AI agent deliberately targeted its network as part of a proxyjacking campaign. Unlike the previous incidents, this was an intentional attack. The attacker knowingly modified an AI model for an agentic campaign.

And the scale? 1,200 hosts — a pace no human could keep up with manually. The goal was to deploy MicroSocks proxies and build a relay network. Unit 42’s report states that the same attacker also tested Claude Code for verifying proxy server connectivity and Codex for developing exploits.

Proxyjacking is nothing new. What is new is that target selection and execution are driven by an agent, not a human at a keyboard — and that collapses the cost of mass attacks.

Up to this point, the agent was the attacker. Researchers from Accomplish AI uncovered a sandbox escape in Claude Cowork. The SharedRoot vulnerability affected 500,000 macOS users running Cowork locally.

Cowork runs in a Linux VM via the Apple Virtualization framework, and each session is an unprivileged user plus filters. The problem is that the entire host filesystem is mounted into the VM as read-write via VirtioFS, and guest root can see it at /mnt/.virtiofs-root. So if you escalate to guest root inside the VM (which, given the flood of Linux vulnerabilities coming at us, is no problem at all), you get access to the entire Mac.

As a demonstration, the researchers attached a single folder to a fresh session, sent one short message, and the agent escaped the sandbox. It read and wrote files across the entire Mac without a single permission prompt.

And Anthropic’s response? It closed the report as “informative” with no fix. Newer Cowork runs in the cloud by default (as of July 7), which sidesteps the local escape. But anyone running the agent locally remains exposed.

SharedRoot was a bug — but the second vulnerability is even worse: all it takes is talking the agent into it.

Researchers at Zenity Labs demonstrated an indirect prompt injection in Claude in Chrome (Anthropic’s official extension) that turns an ordinary “summarize my latest emails” into account takeovers on Slack, X, and Claude.ai.

From the victim’s perspective, this is a zero-click attack. A malicious email arrives with hidden instructions; as soon as the user asks for an inbox summary, the agent reads those instructions as commands and executes JavaScript via its javascript_tool inside the victim's logged-in session.

Claude is supposed to block direct execution of a malicious script, so the attackers host the JS on their own registry posing as a legitimate CDN. On the surface, the package does something harmless (it generates a UUID), but under the hood it launches the account takeover.

And why is Claude.ai the worst possible target? The attacker gets not only chat history and uploaded files, but also authorized connectors such as Gmail, Drive, Calendar, Slack, and GitHub. One account = the victim’s entire ecosystem.

And it’s not just about Claude in Chrome. The Black Hat hacker conference is currently underway in the US, where it was shown that ChatGPT Atlas, Perplexity Comet, Gemini in Chrome, and Copilot Edge are vulnerable as well.

Agentic browsers violate the Same-Origin Policy by their very nature — they act across logged-in tabs as a single entity.

Claude in Chrome has anti-injection sections in its system prompt, so protections do exist. But the research shows they can be bypassed.

Whenever an agent simultaneously has access to private data, the ability to act, and exposure to untrusted content, you’re headed for trouble.

Notice one thing: Anthropic closed both SharedRoot and the Claude in Chrome vulnerability as “informative” with no fix. In other words, where the vendor’s responsibility ends, yours begins. If you let AI agents into your own infrastructure, you have to build the guardrails yourself.

Atlassian Rovo Can Be Used to Exfiltrate Data from Jira and Confluence

Two security firms have independently shown that Atlassian’s AI assistant Rovo can be manipulated into collecting data from Jira and Confluence that the logged-in user has access to and sending it to an external server.

The first path was described by PromptArmor, which published its findings on August 5, 2026. In its example, a user uploads a document containing a hidden prompt injection and asks Rovo to organize their Jira tickets. Following the instructions, Rovo searches Jira and Confluence, appends the data it finds to an attacker-controlled URL, and opens that URL — the attacker then reads the contents of the tickets and pages from their own server logs. The exfiltration step requires no separate human approval. Crucially, according to PromptArmor, the chain worked even with the organization’s web search setting turned off, because the outbound request used a separate URL-fetching capability that this toggle does not remove. The root cause identified is simple: nothing checks whether the URL being opened was constructed by the agent itself. PromptArmor said it reported the issue to Atlassian on May 23, 2026, spent more than two months pressing for a response without any substantive reply, and went public because it considered Rovo still vulnerable.

The second path was described by Varonis Threat Labs, which named its finding RovoBlast and reported it via Bugcrowd. Atlassian deployed a server-side fix for this link-handling flaw on July 8, 2026, and the author verified it — so this path is closed.

OWASP Top 10 for LLM Applications 2026

The OWASP GenAI Security Project released a new edition of its Top 10 for LLM Applications on August 3. The community-driven guide, led by Steve Wilson and Rock Lambros, maps the most critical security risks of applications built on large language models and is aimed at developers, architects, and security teams.

The biggest change this year is the methodology. OWASP collected 7,714 real AI-related security incidents from public vulnerability databases and AI harm repositories, of which 6,639 contained enough detail to be classified. The final ranking weights community voting at roughly 75% and incident data at 25%.

The 2026 edition is also the first to explicitly separate an LLM used as a component from an LLM acting as an agent. The LLM Top 10 list covers the former. Once a model gains tools, persistent memory, and the ability to affect downstream systems, teams should also apply the OWASP Top 10 for Agentic Applications, first published in December 2025.

A New WordPress XSS Vulnerability, XSS2Shell, Can Lead All the Way to Code Execution

I recently wrote about WP2SHELL. Now researchers at pwn.ai have published a new reflected cross-site scripting (XSS) vulnerability on the WordPress login screen that can be exploited before authentication.

The vulnerability is tracked as CVE-2026–64638 with a CVSS score of 8.9 and has been nicknamed “XSS2Shell.” Exploiting it requires no account and no attacker privileges. The vulnerable code has been part of WordPress since version 4.7.

The flaw stems from a mismatch between two of WordPress’s own sanitization functions. When a non-existent username is submitted, WordPress builds a failed-login error message and passes the value through wp_strip_all_tags(), which relies on PHP's strip_tags() function. That parser does not recognize a tag whose opening < is followed by a space (for example < area), so the string survives as text. Moments later, the value reaches wp_kses_post(), and the separate KSES tokenizer evaluates < area as a valid <area> element — creating attacker-controlled DOM elements on the login page.

These elements are then processed by WordPress’s own user-profile.js script, which loads on the login page because that page also handles password resets.

WordPress released a fix on August 6 in version 7.0.3: the username from a failed login is now escaped with esc_html() before it ever reaches either sanitization function. The fix was backported to all maintained branches down to version 4.7. Versions older than 4.7 remain vulnerable but fall outside the current backport scope.