Version Anomaly Detection

Why Version Numbers Matter

Version numbers follow predictable patterns. A new open-source project typically starts at 0.1.0 or 1.0.0 and increments according to semantic versioning. When a package appears on a public registry for the first time at version 100.0.0 or higher, it strongly suggests the package was crafted to exploit version resolution logic.

Package managers like pip and npm will prefer higher version numbers when resolving dependencies. An attacker can exploit this by publishing a package with the same name as an internal package but with a version number far higher than any legitimate release. The package manager then installs the attacker's version because it appears to be "newer."

How Hextrap Detects Version Anomalies

When a new package is analyzed, Hextrap checks the version number against several heuristics:

• High first version: Major version >= 100 on the first-ever publication
• New package, high starting version: First-seen packages starting above v10.0.0 when there's no prior version history
• Version jump correlation: Combined with other signals like internal-looking names, version anomalies increase the overall risk score

Version anomaly detection runs as part of Phase 1 analysis, meaning it evaluates the package metadata inline before the package is allowed through the firewall.

Common Attack Patterns

Version anomalies are frequently paired with dependency confusion attacks. The attacker identifies an internal package name and publishes it to a public registry at an impossibly high version number. Common patterns include:

• v999.0.0 — maximum version to guarantee resolution priority
• v100.0.0 — suspiciously round major version with no prior releases
• v99.99.99 — near-maximum to avoid exact-pattern blocking

$ pip install acme-config

ERROR: Package blocked by Hextrap
Reason: Version anomaly
  Version: 999.0.0 (first publish)
  No prior versions exist
  Signal: VERSION_ANOMALY (MEDIUM)