Supply Chain Malicious PyPI Package vedang-cli Installation
A package published on PyPI under the name vedang-cli (also seen as vedang_cli) markets itself as a toolkit for AI agents, MCP servers, and Web3 'agent readiness'. Installing it runs attacker code that can harvest environment variables, API keys, and cloud credentials from the machine, and from any AI agent system that later pulls the package in.
How the attack works
An attacker publishes vedang-cli to PyPI with a name and description designed to attract developers building AI agents or MCP integrations. A developer or an automated agent runs a package manager command (pip install, pip download, etc.) to fetch it. Because the package ships as an sdist, installing it triggers setup.py or PEP 517 metadata hooks, which execute arbitrary code before the package is even fully installed. That code can read environment variables and credential files and exfiltrate them. Even a 'download only' command still triggers this, because pip runs the metadata hooks as part of resolving the package.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 9f3c1d7a-4b62-4e8f-a1c5-2d7b6e04f3ab
- Severity
- High
Why it matters
Any host or CI/agent pipeline that installs this package can leak API keys, cloud credentials, and other secrets to the attacker, and the compromise can propagate into downstream systems that depend on the package.
What you can do
- →Block or pin dependencies from an internal package index rather than allowing arbitrary PyPI installs on agent hosts and CI runners.
- →Search build logs, CI history, and developer machines for any reference to vedang-cli or vedang_cli and treat any hit as a credential-compromise incident, not just a bad dependency.
- →Rotate API keys, cloud credentials, and any secrets that were present in the environment of a host where the package was installed.
- →Require review of new/unfamiliar package names before they're added to project dependencies, especially ones marketing AI-agent or Web3 'readiness' features.
Known benign look-alikes
- Malware analyst or incident responder deliberately installing vedang-cli inside an isolated analysis sandbox to reverse the payload. Expected and intentionally not filtered — the same command line is indistinguishable from a real compromise.
- `pip download vedang-cli` performed for offline inspection. Deliberately NOT filtered: pip still executes the sdist's PEP 517 metadata hooks, so the credential-theft code runs.
- Remediation (`pip uninstall vedang-cli`) and metadata lookups (`pip show vedang-cli`, `pip index versions vedang-cli`) — suppressed by filter_remediation / filter_metadata_query.
- Dependency scanners (pip-audit, safety, osv-scanner, guarddog, CycloneDX) that echo the flagged package name into their command line — suppressed by filter_supply_chain_tooling.
- Shell one-liners that grep or echo the package name out of a requirements/SBOM file while triaging the advisory — suppressed by filter_string_inspection.
- A future unrelated internal tool that legitimately takes the executable name `vedang-cli`. None is known to exist; if one is adopted, retire this rule rather than widening the filters.