SUP-COMPROMISE-002 Typosquat
A direct or transitive dependency matches a catalogued typosquat incident: the package name impersonates a real upstream (one-letter change, swapped scope, homoglyph) and carries attacker code. Typosquats usually run at import time, so one npm install or pip install compromises the host.
What Vulkro detects
Every (ecosystem, name, version) found by the dependency scan is looked up in the curated compromised-release catalog. A row of kind typosquat whose versions[] contains the installed version produces this finding.
Severity comes from the catalog row (typically High). Confidence High. Evidence signal: compromised-release-exact-version-match, weight 1.0.
This rule covers hand-classified real incidents only. General edit-distance typosquat scoring is a separate heuristic elsewhere in the scanner.
Catalogued incidents include:
INCIDENT-2022-pytagora(PyPIpytagora@1.0,1.1): a PyTorch typosquat that fetched a second stage on import.INCIDENT-2024-solana-token-utils(npmsolana-token-utils@1.0.0,1.0.1): a@solana/web3.jshelper typosquat that stole wallet keys.
Non-compliant code
pytagora is the typosquat; the real PyTorch package is torch.
{
"default": {
"pytagora": { "version": "1.0", "hashes": [] }
}
}
Compliant code
[[package]]
name = "torch"
version = "2.4.0"
How to fix
- Replace the dependency with the correct upstream name, checked against the project's official docs or registry page, not search results.
- Audit build artefacts from the affected window: the payload has likely already run.
- Rotate every credential the host could see in that window.
References
- CWE-1357: Reliance on Insufficiently Trustworthy Component
- CWE-506: Embedded Malicious Code
- OWASP A08:2021 Software and Data Integrity Failures
See also: vulkro respond, SUP-COMPROMISE-001, SUP-COMPROMISE-003.