How HalluSquatting Attacks Trick AI Coding Assistants into Running Malicious Code and the Safeguards Enterprises Need
Published
Question: How does a HalluSquatting attack threaten enterprise security? Across the HalluSquatting attack chain, where can organizations detect and interrupt the intrusion? Which safeguards are recommended and supported by current evidence?
Ömer Faruk Diken, Technical Content Team Lead at SOCRadar
LLMs make up names for packages, repos, and skills that don't exist, and they make up the same fake names across repeated prompts. Roughly one in five AI-suggested packages don't exist, and 43% of those fake names show up every single time you ask. That predictability is what an attacker needs.
When a coding assistant is told to clone a repo or install a skill, it fetches and runs the attacker's version through its own terminal, with no human pausing to notice the name looks off.
That possibly hands the attacker code execution inside a trusted environment.
Everything past that point is a standard consequence of code execution, not a special property of this attack.
Once code runs with the agent's access, the attacker can read whatever the agent can read: source code, API keys, cloud credentials, SSH keys, project files. They can push a poisoned dependency into your build so it travels through your CI/CD pipeline.
If the agent holds broad, privileged access, that first foothold could become a starting point for reaching deeper systems.
The real multiplier is access. The more your agents can touch (internal repos, cloud, developer tooling), the more a single bad fetch is worth.
Where Organizations can Detect and Interrupt Intrusion
- Resource resolution: Before anything is pulled, check the repo owner, publisher, namespace, or domain against sources you trust, and treat brand-new or unseen resources as suspect.
- Clone and install: Watch for agents running git clone, package installs, or outside downloads, and require sign-off before pulling anything untrusted.
- Content ingestion: Scan what comes back for malicious code and hidden prompt injection before it runs.
- Tool execution: Monitor the shell commands, file access, and credential access the agent triggers, and gate sensitive actions behind human approval.
- Network activity: Flag unexpected outbound connections or uploads from agent processes to unfamiliar places.
- Post-compromise: Keep watching for stolen credentials, persistence, unauthorized repo changes, and odd access to enterprise resources.
The two stages with the most leverage are resolution and install, because that is where you can stop the fake resource before any code runs.
The latter stages are your safety net if it slips through, and they are the same detections you would use for ordinary malware.
Recommended Safeguards Supported by Current Evidence
The main mitigation supported by the research is to make the agent run a real search before it fetches anything, which meaningfully cuts the hallucination rate.
Put that check inside the fetch or install tool itself, so a cleverly worded prompt cannot talk the agent out of it.
This is the most attack-specific fix, and it comes from the single preprint, so read it as promising rather than battle-tested.
The rest are mature security practices that apply cleanly here, even though they were not invented for this threat:
- Treat everything the agent pulls in as untrusted, and scan it for malicious code and prompt injection before it runs.
- Give agents least privilege, so they only reach the credentials, code, and systems they actually need.
- Require human approval for high-risk actions like installs, shell commands, and outbound connections.
- Run agents in sandboxed or short-lived environments so a bad resource cannot spread.
- Log everything: Prompts, resolved resources, tool calls, commands, and network traffic, for both detection and cleanup.
Related
