On August 4, 2026, JFrog documented a new wave of the Shai-Hulud npm worm. It started with two well-known libraries, keyv and cacheable, and within hours reached more than 400 packages across more than 1,700 versions. The detail that should reorganize any engineering team's week: some of the malicious versions were published with valid provenance, signed through GitHub Actions.
Three months earlier, Socket had documented a different campaign, TrapDoor, that did not target code at all. It targeted the files that tell your AI coding assistant how to behave.
Both point at the same gap. The tools your team builds with — packages, editor extensions, MCP servers, coding assistants — entered the organization faster than any procedure to review them. If you run or evaluate technology operations in Latin America, where lean teams adopted these tools early, this is what happened, why vendor questionnaires miss it, and what to check this week.
What happened: two campaigns, one gap
Shai-Hulud, August 2026: malware with a valid signature
Shai-Hulud is an npm worm that has resurfaced in waves since 2025. It steals credentials from the machine where it lands and uses them to publish poisoned versions of other packages by the same maintainer, which infect whoever installs them next. It spreads on its own.
What JFrog Security Research documented on August 4, 2026 has two parts. The first is scale: the compromise began with keyv 6.0.0 and cacheable 2.5.1 and reached more than 400 packages across more than 1,700 versions. The second is mechanism, and that is the part that matters if you design controls.
In the OpenSearch case, the worm abused trusted publishing: it requested an OIDC token from GitHub Actions, exchanged it for an npm publish token, and published directly. It also produced a complete Sigstore bundle through Fulcio and Rekor. The malicious tarball shipped with valid provenance.
Provenance and signatures are the supply chain controls the industry has been recommending for years. They answer one question: did this artifact come from the expected pipeline? When the pipeline itself is what got compromised, the same chain of trust vouches for the malware.
What the worm steals is telling too. Beyond npm tokens, cloud configuration (AWS, Azure, GCP), Kubernetes config, SSH keys and crypto wallets, it goes after credentials for AI tools: OpenAI, Anthropic, Claude, Cursor. Attackers already know where the value moved.
TrapDoor, May 2026: the file your editor shows as empty
Socket documented TrapDoor starting May 22, 2026: more than 34 malicious packages and more than 384 versions spread across npm, PyPI and Crates.io. So far, a credential-stealing campaign like many others.
The novelty was a file. The payload planted .cursorrules and CLAUDE.md files in the project — the files that coding assistants such as Cursor and Claude Code read as context to learn how to work in that repository. Inside were instructions written in zero-width Unicode characters. The editor shows a nearly empty file. The assistant reads all of it, and the instructions nudge it into running a supposed "security scan" that actually exposes the machine's secrets.
The campaign also tried to enter high-profile open-source repositories through the most innocent door there is: pull requests that only added a .cursorrules file with "development standards." According to Socket, targets included projects from the agent ecosystem such as browser-use, LangChain and OpenHands.
I use Claude Code every day and keep a CLAUDE.md in every repository I work in. These files are useful precisely because the assistant obeys them. That is the good side. The other side is that whoever can write to that file can steer the tool, and almost no team reviews it with the rigor applied to a script.
Why the vendor questionnaire does not catch this
Software vendor assessment questionnaires ask roughly the same things everywhere: certifications, patch management, response times for CVEs. Reasonable questions for vulnerabilities. Useless for this.
Phoenix Security maintains a corpus of malicious campaigns across package ecosystems. Between June 2024 and June 2026 it recorded 59 campaigns and 657 malicious package indicators. CVEs assigned while those campaigns were active: zero.
Zero is not a technicality. It means the process the industry uses to catalog vulnerabilities does not even touch this class of attack. A poisoned package is not a flaw in the vendor's software: it is malicious content that entered through the build chain. No patching SLA covers it, because there is nothing to patch. There is a dependency that should never have been admitted.
The same corpus carries a number about the newest layer: of 3,267 AI-agent skills deep-scanned, 854 triggered a critical-risk finding. More than one in four. The one-click capabilities people bolt onto agents carry the same proportion of problems as any other third-party software, with considerably less scrutiny.
What this means for operations in Latin America
If you evaluate or run a technology operation in the region, expect a specific combination. Engineering teams are small, they adopted coding assistants and AI agents early because those tools multiply the people they have, and almost nobody inventoried who installed what. A twenty-person organization can easily have thirty AI extensions, a dozen MCP servers and rules files in every repository, all added in the last year and none of it with an owner.
From a regulatory standpoint the issue is accountability. Panama's Law 81 of 2019 and its Decree 285 of 2021 distinguish between the party that decides how personal data is processed and the party that merely handles it. The decision-maker keeps answering to the data subject even when the data flows through a vendor, an open-source package or an AI tool. If a worm that came in through an npm dependency ends up exfiltrating credentials that reach customer data, the regulator will not ask who maintained keyv. It will ask what controls the organization had over what entered its environment.
For entities under financial supervision, the evidence bar is higher still: saying that dependencies are reviewed is not enough. You have to show how, when and by whom.
I wrote earlier about persistent AI agents and why security is the deciding factor. This is the practical sequel: an agent is only as trustworthy as everything that gives it capabilities, and that includes whatever arrives through its supply chain.
What your company can do this week
Five actions a small team can execute now, without buying anything. They double as due-diligence questions if you are assessing a partner or an acquisition target in the region.
-
Inventory the AI tooling, with an owner per item. MCP servers, editor extensions, agent skills, packages an assistant added. For each: who installed it, when, what it can reach, and when it gets reviewed. The last field is the one everyone skips, and without it the inventory ages silently.
-
Treat agent rules files as code.
CLAUDE.md,.cursorrules,AGENTS.mdand their equivalents go through review with a visible diff. A pull request that only adds AI configuration deserves more scrutiny, not less: TrapDoor tried to walk in exactly that way. -
Detect invisible characters in the pipeline. A check that rejects zero-width Unicode characters in text files takes minutes to implement and would have stopped TrapDoor at the first commit.
-
Give every agent and every pipeline its own scoped, expiring credential. Never a developer's personal credential. Shai-Hulud spreads on publishing tokens and workflow trust; the blast radius is defined by the scope of what it steals. A publishing pipeline is an identity with standing permissions and should be governed like an admin account.
-
Treat provenance as a signal, not a verdict. Keep verifying signatures, but pin critical dependencies, review updates before adopting them, and alert on unusual republish events for the dependencies you care about. This is the kind of control an application and supply chain security program turns into routine instead of heroics.
My take
The sharp question for evaluating a tooling vendor is no longer how often they patch. It is how they control what enters their build: version pinning, origin verification, review of new dependencies, and what evidence they can show. The same question applies inward. If someone asked you tomorrow for the list of MCP servers and AI extensions installed across your organization, each with a named owner, would it come from a living document or from a machine-by-machine hunt?
The assistant does what its context tells it. The real question is who gets to write that context.
Frequently asked questions
Is a poisoned package the same thing as a vulnerability?
No. A vulnerability is a defect in legitimate software and gets fixed with a patch. A poisoned package is malicious content that entered through the build chain: there is nothing to patch, there is a dependency that should never have been admitted. That is why Phoenix Security's corpus records 59 active campaigns between June 2024 and June 2026 with zero CVEs assigned while they were active.
Why is a CLAUDE.md or .cursorrules file a security risk?
Because the AI assistant reads it in full as project context and follows it. In the TrapDoor campaign documented by Socket in May 2026, those files carried instructions hidden in zero-width Unicode characters: the editor showed a nearly empty file while the assistant received orders nudging it to expose the machine's secrets. Review them the way you review code.
If we have a contract with the vendor, does liability shift to them?
Not under Panama's data protection regime. Law 81 of 2019 and Decree 285 of 2021 distinguish between the party that decides how personal data is processed and the party that merely handles it; the decision-maker keeps answering to the data subject even when the code or the service comes from a third party. Contracts allocate operational duties; they do not transfer accountability.