Incident Exposure Quantification Via Public Telemetry

Issue 84 Edition 2026-03-25 4 min read

Not accepted General

Sources: 1 • Confidence: Medium • Updated: 2026-04-12 10:19

Key takeaways

During the 46-minute period when exploited LiteLLM versions 1.82.7 and 1.82.8 were live on PyPI, there were 46,996 downloads across those versions.
88% of packages that depend on LiteLLM did not pin versions in a way that would have avoided the exploited version.
Download counts for the compromised LiteLLM releases were estimated using the BigQuery PyPI dataset for the time window when the packages were live on PyPI.

During the 46-minute period when exploited LiteLLM versions 1.82.7 and 1.82.8 were live on PyPI, there were 46,996 downloads across those versions.
Download counts for the compromised LiteLLM releases were estimated using the BigQuery PyPI dataset for the time window when the packages were live on PyPI.

88% of packages that depend on LiteLLM did not pin versions in a way that would have avoided the exploited version.

What specific BigQuery query, dataset snapshot, and filtering rules were used to derive the download estimate (e.g., exact package names, version filters, timestamp boundaries, and de-duplication)?
How many of the recorded downloads correspond to unique environments and actual installations (as opposed to caching, CI pipelines, mirrors, retries, or bots)?
What was the exploit behavior in the compromised LiteLLM versions, and what concrete indicators of compromise (IOCs) were observed?
What portion of the ecosystem actually resolved to the exploited versions during the 46-minute window given typical resolver behavior and lockfile usage?
How was the 88% figure computed (dependency graph source, package sampling frame, and how requirement specifiers were parsed and classified as protective vs non-protective)?

Rising demand for software supply chain security and PyPI telemetry based incident scoping, since a 46 minute malicious window still produced an estimated 46,996 downloads.
Increased adoption of dependency pinning and lockfile enforcement tools, because 88% of dependent packages reportedly did not constrain versions to avoid the exploited releases.
More scrutiny of public registry safeguards and faster revocation workflows, since exposure estimates rely on brief publication windows and high automatic uptake risk.

Reproducible public queries and methods published that validate the 46,996 download estimate for LiteLLM 1.82.7 and 1.82.8 during the 46 minute window.
Post incident disclosures showing teams tightened version constraints, added lockfiles, or implemented policy gates after discovering permissive dependency specifiers.
Operational changes from registry operators or ecosystem tooling that reduce time to detect and remove compromised releases, paired with telemetry reporting of similar events.

Independent analysis shows the download estimate is materially overstated due to caching, bots, CI retries, mirrors, or de duplication errors, weakening the exposure narrative.
Evidence that few real environments actually resolved to the exploited versions during the window due to lockfiles or resolver behavior, implying limited practical impact.
The 88% non protective constraint figure is not reproducible or is based on an unrepresentative dependency sample, reducing confidence in ecosystem susceptibility claims.