Software Blog

Andrea Cosentino Apache Camel PMC Chair

Thoughts about programming, open source and more

© 2026 Andrea Cosentino

Source on GitHub

AI security incidents of the week: 27 October to 2 November 2026

13 min read

This week the two halves of the AI security story met in the middle. On one side the attackers ran as agents: CrowdStrike tied a China-nexus group to an agent framework that drove intrusions at more than two hundred organisations at once, and Chainalysis said it was breached through what it called “offensive agentic techniques”. On the other side the developers’ own agents were the target: a worm seeded 42 hijacked GitHub repositories with auto-run configuration for Claude Code, Gemini and Cursor, and a dev-tool vendor breach spilled users’ agent logs. The attacker is an agent and the agent is the attack surface, inside the same seven days.

This is the first of these AI write-ups, a companion to the weekly Java one. A CVE number and a score tell you a component is vulnerable; an incident tells you how a real system broke, what the attacker actually controlled, and how far it reached, which is the part I can take back to my own setup. The longer argument for looking at mechanism instead of the number is in the CVE stigma post. The window is 27 October to 2 November 2026.

Timeline

The two I want to walk through are the worm and the Warp breach, because together they draw the new boundary cleanly: one is about what your agent reads, the other about what your agent writes down.

Spotlight: the testmetest worm and the files your coding agent trusts

For years the threat model for cloning a repository was simple enough to hold in your head. The danger was in running it: the build script, the postinstall hook, the dependency you pulled. Reading the repo was safe, and opening it in an editor was safe, because an editor does not execute the project just because you looked at it. An AI coding agent broke that assumption quietly, and this worm is the first wide campaign I have seen built around the break.

JFrog Security Research published the analysis, and the shape is worth going through slowly. The attackers took over 42 GitHub repositories belonging to 11 real owners, using hijacked accounts and contributor access rather than throwaway projects, so the repos carried the trust of their legitimate names. Into each one they committed two things. The first was a payload file at .github/init.js, deliberately enormous at 12.9 to 13.7 MB, large enough that GitHub’s code search does not index it and the Contents API does not return it, so JFrog had to pull it as a raw Git blob through the Trees API to even see it. The second was a set of execution and configuration files for Claude Code, Gemini, Cursor and VS Code.

That second part is the one that matters. Per JFrog, those configs were arranged so that starting one of those agents in the project, or opening it as a VS Code workspace with the right settings, could launch .github/init.js without the developer ever typing a command. I am keeping JFrog’s own hedge here, “could”, because the trigger depends on how each tool is configured and the public writeups do not claim it fires every time. The point stands regardless: the act that used to be inert, opening a cloned repo, is now a candidate execution path because an agent sitting in that directory reads the repo’s files as its own instructions and settings.

Once it ran, the payload behaved like a worm with a commercial-malware budget. It harvested GitHub and npm credentials, modified repositories and CI configuration, and propagated by using whatever npm publishing permissions it found, with recovered code that performed GitHub OIDC token exchanges to get npm publish credentials automatically. It checked for CI runners, containers, debuggers and analysis tools and went dormant when it saw them. SafeDep, whose work on the npm side heise and GBHackers both cite, reports that it also installs a wiper that deletes the victim’s home directory the moment the stolen GitHub token is revoked, which turns the obvious cleanup step into the trigger for data loss. The npm lineage traces back to an earlier worm family (SafeDep had described the package side as early as 22 October, and JFrog notes a resemblance to Shai-Hulud variants), though attribution to the original operators is unproven.

If you want the mechanism in miniature, without the worm machinery around it, look at the Forever Security work from 25 October, two days before this window opened. Gal Weizman and colleagues showed that an AGENTS.md or CLAUDE.md file placed in a directory an agent treats as its working directory gets loaded as instructions with no prompt. In their tests a reconstructed chain made OpenAI Codex open the calculator app around 90% of the time, and a malicious CLAUDE.md redirected Claude Code’s API traffic to a server they controlled, exposing the agent’s OAuth token and letting the server return tool calls that executed code in roughly half of runs. Their own conclusion is the part I keep coming back to: “There is nothing here for OpenAI or Anthropic to patch.” It is not a memory-safety bug or a missing bounds check. It is an agent doing exactly what it is designed to do, reading the config and instruction files in its working directory, in a world where those files can arrive from anyone.

The boundary that moved is the working directory, and the new executable input is the instruction file. The lesson generalises past these four tools: an AGENTS.md, a CLAUDE.md, an MCP server definition, a .vscode/tasks.json, any file your agent auto-loads is now content you have to review before the agent reads it, exactly as you would review a shell script someone mailed you. The practical controls are unglamorous and they work. Start agents in the project root you meant to open, never in ~/Downloads or a broad parent directory. Keep the agent’s approval prompts and sandboxing on rather than running it with the brakes off for convenience. Treat cloned repositories from outside your trust boundary as untrusted until a human has read their agent-facing files. And scope the tokens your agent can reach, because a GitHub or npm token that cannot publish is a token this worm cannot use to spread. In OWASP’s LLM Top 10 terms this sits on top of LLM01, prompt injection, with the injected instructions arriving as committed files rather than chat, which is the version that scales.

Spotlight: Warp and the agent logs you did not know you were keeping

The worm is about what an agent reads. Warp is about what an agent writes down, and where that ends up.

Warp is an agentic development environment, a terminal that runs an AI agent in your command line, and its own site claims more than 800,000 users. On 27 October, as BleepingComputer reported, founder Zach Lloyd disclosed what he described as “an active and narrow-banded exploitation of a vendor in Warp’s infrastructure”. Warp says it detected the activity within hours and moved to remediate, estimates that roughly 1% of users may have been affected, has notified the users it identified, and has brought in external help and informed law enforcement.

What was exposed is the interesting part, and it is interesting partly because of what Warp did not say. The data is described as “agent decision logs and telemetry”. The company did not clarify whether those logs included source code, prompts, credentials or other sensitive detail, and the article does not define the terms further. That gap is the whole lesson, so I want to be careful not to turn it into a complaint. An agent decision log is a new category of data that did not exist in your estate a couple of years ago. It records what the agent was asked, what it decided, which files and commands it touched, and the shape of the work it did. Even when it contains no password, it can contain the contents and structure of whatever a developer was building, which for many teams is the sensitive thing. And because a tool like this streams that telemetry to third-party observability and analytics vendors, the data lands in systems you did not choose and may not know the names of. When one of those vendors is breached, as here, the exposure is your developers’ sessions, through a door you never audited.

The article also carries an unattributed line that the attack was “powered by an agent swarm” using “a very sophisticated penetration and escalation technique”. I cannot verify that, no analyst is named, and I would not build anything on it, but it rhymes with the week: if it holds, the agent logs of a tool were taken by agents.

The control that would have changed this is knowledge you can gather today, before a vendor forces the question. For every AI tool your team runs, you should be able to answer three things: what does it log, where does that log go, and how long is it kept. Then the agent-trace vendors belong in the same third-party risk review as your other data processors, with retention and minimisation asked of them explicitly. Warp could not tell its users what was in the logs on day one; the useful move is to make sure you could answer that about your own tooling without a breach to prompt you. This is CWE-200, exposure of sensitive information, with the twist that the sensitive information is a brand-new artifact of how we now write software.

CVE radar

A short list of AI and ML software bugs with fixes this week, kept deliberately brief. The incidents above are the main event.

What connects them

Two threads run through the week, and they are really the same thread seen from both ends.

The first is that the agent now stands on both sides of the incident. VAPOR PANDA’s ARTEX swarm, the “offensive agentic techniques” Chainalysis named, and the “agent swarm” the Warp analysis reaches for are all the attacker operating as an agent, at a tempo and a parallelism a human team does not have. The worm and the Forever Security demo are the other end, the defender’s own agents turned into the way in. The same capability, an autonomous thing that reads context and takes actions, is being pointed in both directions, and a lot of this week’s news is just that capability maturing faster than the controls around it.

The second is more concrete and more useful on Monday. The trust boundary that moved is the file an agent reads without being told to, and the data an agent writes without you watching. For twenty years “open the repo” was safe and the log files were yours. Neither is quite true once an agent is in the loop: the repo can carry instructions written for your agent, and the logs can carry your work to a vendor you never vetted. So the things to go check are small and specific. Enumerate where your team runs coding agents and from which directories, and treat every AGENTS.md, CLAUDE.md, MCP config and editor task file in an untrusted repo as code to review before an agent sees it. Write down what each AI tool logs and where it sends that, and put those endpoints in your breach-surface map. Scope the tokens your agents hold so a stolen one cannot publish to your registry. And for the plain old servers in the CVE radar, MLflow most of all, do not leave them reachable without authentication. None of that is exotic. It is the same hygiene we already know, applied to a component, the agent, that most teams have not yet put on the asset list.

References

Notes on sources: the two press accounts of the worm differ by a day on their own publication date (GBHackers 28 October, heise 29 October) and neither dates JFrog’s post itself; I date the item to the first press coverage. For Flowise, the CVE record describes the affected range as “through 3.1.4” while its structured data reads “< 3.1.4”, so the exact fixed release is unclear from the record, and the Flowise advisory is the thing to check before you rely on a version number. The Warp timeline is thin on dates: the company said it became aware “on Friday” and the report is dated 27 October, so I anchor to the disclosure rather than guess the detection date.

Read next