GhostSquatting: Model Theft and RCE via Abandoned Names in AI Agent Files

TL;DR

• AI-agent instruction files (skills and SKILL.md, CLAUDE.md, AGENTS.md, .cursorrules, and MCP configs) hardcode hundreds of cloud buckets and hundreds of software packages that no longer exist or were never registered, and whoever claims a name first inherits every agent run that follows the instruction.
• We claimed the vacant bucket names and turned on logging. Pipelines from dozens of organizations sent us thousands of requests: pushing model weights and database backups toward storage we controlled, and asking us for specific files by path that we could have answered with poisoned data or malware.
• The same pattern hits npm and PyPI: across those instruction files we found hundreds of npx, uvx, and pip install commands pointing at packages that don't exist. We claimed those too, and over 200 machines installed them.
• Both classes hand an attacker remote code execution and silent data exfiltration across many companies at once.

The name that finally resolved

An engineer at a large AI company kicked off what should have been a forgettable task: a routine sync of training data to the team's dataset bucket, the kind of job their pipelines and agents had run dozens of times. On every earlier run, one of the bucket names written into the configuration had quietly failed to resolve, and the agent had done what agents are built to do, catching the error and correcting it on the fly so the pipeline sailed on, entirely seamless to the developer who never knew a name had failed. This time the same name was resolved cleanly on the first attempt. The upload of freshly trained model weights went straight through, the logs stayed calm, and nothing gave anyone a reason to look twice. The only thing that had changed lived entirely on our side of the connection: we had registered that unclaimed bucket name, so the reference that used to fail, and used to be silently repaired, now pointed at a real bucket that happened to belong to us.

A few days earlier we had started a research project with a narrow question: which resources named in AI agent instruction files have quietly been abandoned? These are the files that tell an agent which bucket to read, which artifact to download, and which package to install, and the resources they point at get orphaned in a handful of ways. Sometimes an agent hallucinates a name into a config and it was never real to begin with. Sometimes a bucket or a package that was genuinely in use gets deleted or unpublished while every reference to it lives on. And sometimes a name resolves somewhere it should not, at the wrong cloud or the wrong registry, so it works on its author's machine and misfires everywhere else. However it happens, the name ends up sitting in a public file, unclaimed, waiting for something to answer it.

So we answered. We took the unclaimed names, buckets and packages alike, and registered them in a research account before anyone with worse intentions could, then turned on logging and watched what came back. It did not take long. Within days, production systems from dozens of unrelated organizations were listing our buckets, downloading files from us, and uploading their data into storage we owned. We ran this as coordinated disclosure, reaching out privately to every affected organization before publishing, and we hold the registered names for return. What follows is what reached us, and why it keeps happening.

‍

Why AI agents make an old bug new

Dangling buckets and dependency confusion have been understood for years, and it matters to say so plainly, because the classic fix still applies: own your names and pin your dependencies. What is new is where these references now live and how much power they carry once they are there, and that comes down to three things.

• The files are written by agents: They are generated by the same models that write the code, and inherit the same hallucinations and confident mistakes, except a made-up bucket or package is written as a step to run, not a line to review. It fails quietly while the agent works around it, until someone claims the name and the failures stop.

• The files are inherited, and almost never read: They ride along with the public skills, templates, and plugins people adopt, then keep running without anyone opening them again. One author's mistake becomes everyone's default; we found the same hallucinated name mirrored across five or six repositories.

• The files are instructions, wired into what the agent does: Unlike a poisoned document the agent merely reads, an instruction file is loaded as directives it follows, so one hijacked line becomes an action: fetch from here, upload there, install this and run it. Owning a name in one of these files is closer to owning a line of the agent's program than to feeding it a bad fact.

Buckets: a global namespace with a short memory

The most direct version of owning a name is owning a bucket. A skill refers to a bucket by name, and that name is a single global identifier across all of S3 or GCS. When no bucket answers to it, because it was never created, sits on another cloud, or was deleted, anyone can create one that does and inherit every request meant for the original. We scanned more than 20,000 instruction files across roughly 1,400 public repositories and pulled out close to 2,000 unique bucket names. Wherever a referenced bucket had vanished and its name was free, we registered it, held it empty, and turned on access logging. That came to 264 buckets, 209 on AWS and 55 on Google Cloud.

Why the names were there in the first place

For every dangling bucket we went back to the file that referenced it and asked a simple question: why was this name ever written down? A few stories repeat.

• Decommissioned infrastructure: A backup target, Terraform state, or audit-log bucket that was real, then torn down when a project ended, while the name stayed in the skill. One backup skill still ships nightly database dumps to a bucket that stopped existing long ago.
• Cross-cloud shadowing: The bucket lives on Cloudflare R2, Oracle OCI, or MinIO, but the skill tells the agent to reach it with plain aws s3 commands. Those calls go to real AWS S3 instead and land on whoever holds the name there. The bucket is alive, and its traffic is being misrouted right now.
• Templates taken literally: Names like landing-bucket or acmecorp-internal were written to illustrate a point for a human. An agent runs them verbatim.
• Side-project leftovers: A one-developer repo that grabbed a global name for a weekend project, then went quiet and left it dangling.

How bad a takeover gets depends on what the bucket holds, and the corpus was full of sensitive ones: database backups, Terraform state (a full map of a company's cloud, secrets included), CloudTrail security logs, a bucket that distributes signed firmware, and clinical datasets down to hospital brain scans. Claiming any one of them puts an attacker in position to steal the data flowing in, or to poison whatever the pipeline pulls back out.

What the traffic proved

It works, and it works unusually well against agents. Twenty-nine of the buckets we held drew live external traffic, thousands of requests in total, from many different organizations. Almost none of it came from internet scanners. It came from production pipelines and CI jobs that already knew the exact paths they wanted and asked us for them by name, run after run, certain they were talking to their own storage. A human might notice a bucket that used to fail and now answers; an agent following a written instruction just trusts the name and connects, which is what makes this land so reliably.

The spotlight: model theft and code execution in a single workflow

The most complete story we captured belonged to a large AI company. One of their dataset buckets did not live on AWS at all; it sat on a different S3-compatible cloud, and their repository was set up to reach it there. One of their skill files had the destination wrong. It told the agent to use plain AWS S3 for that bucket instead of the provider it actually lived on, so the agent did as it was told, its aws s3 calls went to real AWS S3, and they landed on the exact name we were holding.

From there the pattern was almost domestic in its regularity. Their pipelines searched for specific dataset and checkpoint paths, and their jobs handed us the crown jewels without a second thought: trained model weights in .safetensors form, training datasets, and packaged code bundles, all sent to a bucket we owned, by dozens of their engineers, across thousands of requests.

The downloads were worse. We watched their pipelines pull PyTorch checkpoints, plain .pt files, straight from our bucket, and a PyTorch checkpoint runs whatever code is pickled inside it the moment torch.load() opens it. One poisoned checkpoint served back would have been remote code execution inside their training run. Their data came to us; our code could have gone to them, over the same wire.

‍

Packages: install the name, run the code

The packages came out of the very same files. When a skill tells an agent to run npx create-thing, uvx some-mcp, or pip install some-lib, that line is a runtime execution command, so we extracted every reference of that shape and checked each name against the public registry.

The result reframed the project. The corpus held more than 3,600 unique package names, of which 603 were genuinely dangling across npm and PyPI, more than the 264 claimable buckets. A package name is even cheaper to hallucinate than a bucket, and it lands directly inside a command the agent runs.

‍

Why the names were there in the first place

The same pattern holds, with its own recurring causes:

• MCP servers never published (the largest group): A skill tells the agent to npx foo-mcp or uvx foo-mcp, but the server only ever ran locally from source, or the author meant to publish it and never did. The "just pull it from the registry" line points at a shelf that was always empty.
• Unregistered scopes: Internal or monorepo scopes appear in public files while the scope itself sits unclaimed on npm. One company documented its entire internal MCP line, more than a dozen @company/xxx-mcp packages, with the @company scope unregistered, so whoever claims it can publish all of them. We also found invented official-looking scopes, like an @anthropic-style inspector that does not exist.

• Hallucinated helper tools: A quick-start says npx ai-backup-script "PostgreSQL daily to S3" because the model that wrote the skill invented a package to do the job. It was never built, and the command to run it now waits in public repos for someone to supply the code.

• Real tools, wrong name: An OSINT tool absent from PyPI under the name given, a scaffolder guessed as create-remotion, a CLI guessed as zenn instead of zenn-cli. Every confident wrong guess is another free name.

Of those 603, 331 are direct-execution forms (npx, uvx, pipx run), where the code runs the instant the agent obeys, with no install step and no confirmation in between.

The names are live

To measure the real exposure, we published our own placeholder packages under some of the dangling names, each with a post-install beacon that only records that an install happened. Those placeholders logged more than 100 installs in the first five hours and over 200 in all, from developer laptops and CI machines. An attacker publishing under the same names would have been running arbitrary code on every one of those hosts.

How to protect yourself

This is an old threat, and some of the fixes are old too: own your names, pin your dependencies. What is new is that the agent runtime gives you places to enforce them that did not exist before.

• Treat agent files as code: They carry shell commands, install steps, and network destinations, so they belong in code review, with pinned and checksummed downloads, like any other executable artifact.
• Verify every name resolves to you: Every bucket, endpoint, and package an instruction file references should point at a resource you control. When an endpoint or a scope is missing, fail closed instead of defaulting to a public one a stranger might own, and register your own external bucket names on AWS so they cannot be shadowed.
• Gate egress with hooks: Use agent hooks to inspect what the agent is about to do and block any outbound call to an unverified destination, whether that is an upload to an unknown bucket, a download from a name you do not own, or an install of a package with no history. The dangerous window sits between the instruction being approved and the command running, and a hook is where you close it.

How Capsule helps

• Reputation service: Capsule knows which buckets, endpoints, and packages are real and owned, and which are vacant, hallucinated, or freshly registered, so an agent can check a name against reality before it acts on it.
• Skills scan: We read skills and agent files (CLAUDE.md, AGENTS.md, .cursorrules, and MCP configs) and flag dangling buckets, unregistered packages, unclaimed scopes, and risky command chains before they reach an agent.
• Runtime detection: Capsule watches agent actions as they happen and stops the upload to an unknown bucket or the install of a phantom package as it occurs, with no changes to your code, agents, or architecture.

Every one of these buckets filled and every one of these packages ran for the same reason: the agent trusted a name that no one owned. Close that gap and the whole attack has nowhere left to land.

We conducted this research under coordinated disclosure and notified every affected organization we identified. The bucket names are held for return. If you suspect a name in your own agent files may be exposed, contact us at info@capsule.security.

‍