# Fork Claim and Community Package Impersonation

- **Severity:** Medium
- **Signature ID:** `8528ae50-ef46-45bb-b5ff-187ed0971afe`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise), AML.T0010.005 (AI Agent Tool)
- **OWASP:** ASI04 (Memory and Context Poisoning), LLM06 (Excessive Agency)

## Summary

Attackers publish AI agent skills or packages that claim to be community forks, enhanced versions, or unofficial alternatives of trusted tools. These packages often describe their permissions in vague, harmless-sounding terms to hide what they actually access, like calling network and filesystem access simply 'internet' and 'storage'.

## How the attack works

An attacker names a malicious package to look like a fork or improved variant of a well-known tool, borrowing its trust and search visibility. The package listing uses soft, generic capability descriptions instead of specific ones, so a reviewer or an AI agent evaluating it doesn't recognize dangerous permissions like network access or file system control. A person or an automated agent installs it believing it's a legitimate community variant with limited, benign needs. Once installed, the package can use the capabilities it never clearly disclosed.

## Why it matters

An organization can end up running a package with broader access than intended, including network or filesystem reach, because the description made those capabilities sound harmless. This can lead to data exposure, unauthorized network calls, or code execution under the guise of a trusted-looking tool.

## What you can do

- Manually verify any package or skill claiming to be a 'fork', 'enhanced version', or 'unofficial alternative' by checking its actual source repository and commit history against the original project.
- Require permission declarations to state concrete capabilities (network, filesystem, process execution) rather than accepting vague terms like 'internet' or 'storage'.
- Review the maintainer identity and provenance of forks before granting install or execution approval, especially for packages used by autonomous agents.
- Keep a list of known legitimate forks of tools you use so reviewers can distinguish real community variants from impersonators.

## Known benign look-alikes

- A README or changelog document that describes a legitimate community-maintained fork of an open-source project using language like 'community fork of the official repository', triggering Layer 1 even though it is a genuine open-source contribution with transparent provenance.

## References

- https://agentthreatrule.org/en/rules/ATR-2026-00134

---
Source: https://www.netzilo.com/threats/atr-fork-claim-and-community-package-impersonation