The order came from a text file

The blocked install, on its own, was routine. Security tools stop known malicious packages every day, and this package was already known: it belongs to a malware campaign other researchers had documented separately — CloudSEK and Checkmarx, who named it MALFEX, per The Hacker News.

What made Forever Security look twice was the source of the instruction. It did not come from a dependency, a repository or anything the customer had asked the agent to do. It came from an AGENTS.md file sitting in the customer's Downloads folder.

Coding agents can load project or directory instruction files such as AGENTS.md and CLAUDE.md. When those files come from an untrusted location, their instructions may influence agent behavior unless the tool applies effective trust boundaries. In a project you control, that is useful. The file in Downloads was written to look like unremarkable engineering guidance, with the harmful instruction placed where a reader skimming for malware would be least likely to stop.

Forever did not establish how the file arrived in the customer's Downloads folder. Its separate proof of concept demonstrated one possible web-based delivery route, not the route used in this incident.

Two agents, two different failures

To test whether this was one product's problem, Forever tried to reproduce the attack against both agents. The results differ, and the difference is worth keeping straight.

Against Codex, the firm used the actual file from the customer's machine, inside an isolated virtual machine. Codex ran the payload in more than 90% of attempts. The more serious detail is persistence: the instruction changed the agent's own machine-wide configuration, so the attacker's setup would load in later sessions in any folder. Leaving Downloads would not have removed it.

Against Claude Code, the customer file did not transfer. Forever wrote a different file for that test, framed as routine internal setup, which aimed to redirect the tool's API traffic to a server the researchers controlled. That route exposes the session's login token, which on its own is account takeover, and the write succeeded in about half of attempts. Claude Code more often required a person to approve the change, or refused it. This was a controlled test with a researcher-crafted file, not a second real-world incident.

So the headline numbers are not two scores in the same test. One is a real attack file replayed against the tool it was written for. The other is a researcher-built file, against a different tool, using a different mechanism, succeeding half as often. Both are bad. They are not the same bad.

Why ordinary file trust breaks down

A downloaded executable does not run until a person approves it. Operating systems spent years building that gate. A text file never needed one, because a text file could not do anything.

An agent changes that calculation. The file still cannot run itself. It does not have to. It only has to be read by something that can run commands, and that trusts the file by design. Forever's summary line is that markdown is the new executable. Strip the slogan away and the mechanism underneath it holds: the protection was built around the file type, and the risk now sits in the reader.

Forever argues that the underlying behavior is intentional rather than a conventional software bug. That does not establish that vendors cannot introduce stronger protections or change how agents handle untrusted instructions.

Forever's own telemetry suggests the exposure is not exotic. About half of the firm's customers run a coding agent inside their Downloads folder, and roughly a quarter of agent sessions open a browser. Those are Forever's customers and Forever's sessions, not an industry-wide statistic, and a browser opening in a session is not itself evidence of a download. What the pair describes is the two conditions in one place: an agent starting in the one folder the web can write to, and an agent doing the browsing itself, with nobody watching a file arrive.

A two-minute first check

Forever's advice needs no new software, and it is the practical reason to read this story today rather than file it.

Do not start a coding agent in Downloads. If you have, check that folder, and any repository you cloned recently, for an AGENTS.md or CLAUDE.md you did not write, and read it before an agent does. Check the agent's own configuration, both machine-wide and project-level, for entries you did not add. Leave approval prompts and sandboxing on, and treat any instruction that asks for them to be switched off as the warning sign it is.

If you find an unfamiliar instruction file, stop the session and inspect recent agent actions and configuration changes. If credentials may have been exposed, revoke or rotate the affected tokens and review relevant account activity.

None of that is difficult. All of it depends on knowing the folder was a risk in the first place, which until this month most agent users had no reason to think about.

What is still unknown

Three things remain open, and any version of this story that omits them is overselling it. How the file reached the customer's Downloads folder is unknown. Whether any machine beyond that one customer was hit this way is not reported. And neither OpenAI nor Anthropic had issued a patch or a statement in the reporting as of October 26. That absence is a reporting status, not a settled conclusion about what the vendors will or will not do.

What is established is narrower and still useful: on one real machine, an agent took a harmful order from a text file in Downloads, and in controlled tests both major agents could be made to follow planted instructions often enough that “I would notice” is not a defence.

Sources

  1. [1] Forever Security, “Markdown Is the New Executable: Attackers Are Dropping Agent Instructions Into Your Downloads Folder From the Web”, October 22, 2026 — the intercepted incident, the Codex and Claude Code tests, and the firm's telemetryRead source
  2. [2] The Hacker News, “Malicious File in Downloads Folder Tries to Trick AI Coding Agent Into Installing Malware”, October 26, 2026 — the campaign attribution to CloudSEK/Checkmarx (MALFEX) and the test distinctionsRead source
  3. [3] BleepingComputer coverage via secondary reporting, October 25, 2026 (attack-path boundaries and test distinctions)Read source
  4. [4] Brandefense tracker, “AGENTS.md Prompt Injection via Downloads”, updated October 26, 2026 (no vendor patch or statement reported)Read source