LiteLLM versions 1.82.7 and 1.82.8 were published to PyPI outside the project's normal GitHub release flow after the maintainer account was hijacked. LiteLLM's own incident issue records that the malicious code collected SSH keys, environment secrets, cloud and Kubernetes credentials, database passwords and CI configuration. Version 1.82.8 additionally shipped a malicious `litellm_init.pth` file, which meant the payload could execute on any Python startup on the host even where LiteLLM was never explicitly imported. Mercor confirmed downstream impact, making this the clearest published case of the compromise reaching an enterprise AI environment rather than remaining an upstream maintainer problem; Cybernews reported Lapsus$ claims about source code, databases and VPN data that were not independently confirmed at publication. The brief's framing is that AI libraries are a privileged supply-chain input because they sit adjacent to model keys, cloud credentials, CI runners and internal data paths.
ASSESSED SYSTEM
The LiteLLM-mediated AI serving and model-gateway path together with the build-and-install supply chain that provisions it, in a representative enterprise AI deployment as it stood between the 24 March 2026 publication of the poisoned releases and their identification. Mercor is the confirmed downstream instance and is named in the brief, but no deployment-specific architecture detail for Mercor was published; the assessed configuration is therefore the pattern the brief describes and prescribes against — LiteLLM resolved live from public PyPI by package name, installed on hosts that also hold long-lived SSH, cloud, Kubernetes, database, CI and VPN credentials, with no internal mirror, no release-provenance check and no dependency map linking apps, images, notebooks and runners to the package.
OUT OF SCOPE
Mercor's non-AI corporate systems; the Lapsus$ extortion claims regarding source code, databases and VPN data, which the brief states were not independently confirmed at publication and which are therefore excluded from scoring rather than treated as findings; the PyPI platform's own account-security posture; LiteLLM's current releases and any hardening shipped after the incident; and the Fairness axis (Fa-1..4), for which a credential-theft supply-chain incident produces no evidence.
Architecture: Tool-Calling LLM / Connected GenAI (decision tree Q3) — Q1 and Q2 answered NO: no agent topology, planner loop, autonomous multi-step workflow or persistent task memory is evidenced anywhere in the brief. Q3 answered YES: LiteLLM is the connector layer through which model calls are made — the brief places it 'near model keys, cloud credentials, CI runners, and internal data paths', and the incident's value to the attacker was exactly the provider API keys, database passwords and cloud credentials that a connected-GenAI gateway holds. This is Connected GenAI in the Q3 sense: an external-API and enterprise-connector integration layer, not a standalone inference endpoint. Tier 3: Tier 3 Internal: the evidenced scope is AI platform infrastructure — build hosts, CI runners and the model-gateway process — operated inside the organisational boundary by controlled engineering users, with the downstream effects on individuals alleged in the extortion claims but explicitly not independently confirmed at publication.
Documented attack or failure path
- The LiteLLM maintainer account is hijacked, and versions 1.82.7 and 1.82.8 are published directly to PyPI outside the project's normal GitHub CI release flow — a provenance anomaly that no consuming build gate acted on.
- Downstream builds and developer environments resolve LiteLLM live from the public index by package name, without exact-version pinning, hash verification or promotion through an internal mirror, and pull the poisoned release.
- The payload executes in the install or import context on hosts that also carry long-lived credentials, and harvests SSH keys, environment secrets, cloud and Kubernetes credentials, database passwords and CI configuration.
- In 1.82.8 a malicious `litellm_init.pth` file makes execution persistent and import-independent: the payload runs on any Python startup on the affected host.
- Harvested static credentials are directly replayable against source repositories, databases, VPN and cloud services, because they are long-lived and not bound to a workload identity, audience or route.
- Absence of a dependency map — which apps, images, notebooks and runners used LiteLLM — delays blast-radius scoping and credential rotation; Mercor subsequently confirms downstream impact.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The upstream project published a detailed incident issue enumerating the exact credential classes the payload collected. That transparency is what makes downstream scoping and targeted rotation possible at all, and it is scored as the positive component of Tr-4.
- The compromise was pinned to exact artifacts — versions 1.82.7 and 1.82.8 and the `litellm_init.pth` file — giving defenders deterministic indicators to search lockfiles, images, build caches and site-packages against, rather than a probabilistic hunt.
- Mercor confirmed and disclosed downstream impact rather than remaining silent, which is what turned an ecosystem advisory into verifiable evidence that the compromise crossed into an enterprise AI environment.
- Access logging existed on the systems the harvested credentials could reach: the brief's guidance to 'review logs for unusual repository, database, VPN, or cloud access since March 24, 2026' presumes a usable log surface, even though nothing alerted at the time.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.05–0.85 (midpoint 0.45), Tier 3 MVT 0.40 indeterminate | |||
| Ro-4Poisoning Attack Resistance | 0.25w 0.20 | The 0.25 anchor: basic validation exists — package-index resolution, dependency metadata and whatever lockfile discipline was in place — but there is no adversarial screening of a new release and no provenance check, and poisoning of the ingestion path succeeded with limited effort. Not scored 0.00: the brief establishes that provenance and pinning controls were missing, not that no integrity validation of any kind existed in the assessed environment, and it would be unfair to a named organisation to read absence of evidence as evidence of total absence. | The poisoned channel is the AI dependency supply chain. The brief states the malicious releases 'were uploaded to PyPI outside the official GitHub CI path' and that consumers should 'prefer packages whose provenance shows they came from an approved CI workflow rather than a direct maintainer upload'; it also states that 'if Mercor had trusted immutable, pre-approved bytes instead of a live public package name, the poisoned releases would have been easier to stop'. Both are framed as controls to adopt, so release-provenance attestation and mirror promotion were not in force. The poisoned version was accepted into downstream builds.source: brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.05–0.85 (midpoint 0.45), Tier 3 MVT 0.45 indeterminate | |||
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | The 0.25 anchor: limited lineage artifacts exist for the component itself (package name, exact versions, upstream incident record) while the deployment-level lineage that an AIBOM would carry — which images, runners, notebooks and services depend on it, and with what change history — is incomplete. | Negative: the brief's AID-M-001.002 entry states that 'teams need an exact map of which apps, images, notebooks, and runners used LiteLLM. That is what turns an ecosystem advisory into a concrete blast-radius list for Mercor-style secret rotation, host triage, and incident scoping' — presented as the missing artifact. Positive: package-level lineage was precise enough to name the exact malicious versions and the exact malicious file, and the upstream project's incident issue documented the payload's behaviour.source: brief |
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate | |||
| Containment (Cn) — scenario interval 0.07–0.80 (midpoint 0.43), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.16 | The 0.25 anchor: boundaries exist at the organisational level, but they are enforced inconsistently across contexts — the dependency-install and build context inherited ambient credential and network authority rather than running inside its own scope, so third-party code executing there exceeded any intended task scope without needing to defeat a control. | The brief's AID-H-022.001 entry states that 'package installation and image builds should run inside ephemeral sandboxes with no long-lived cloud keys, VPN credentials, or production .env material present' and that 'a credential-stealing dependency should hit a dead-end environment, not the same host that can reach your internal stack'. Both are prescriptive, so the install and build context was neither ephemeral nor egress-restricted, and it was co-resident with credentials reaching source, database, VPN and cloud.source: brief |
| Cn-5Agent Identity Integrity | 0.25w 0.11 | The 0.25 anchor exactly: shared-secret and static-key authentication with weak rotation, no cryptographic binding of a credential to a workload, audience or route, and no service-to-service verification — so a secret lifted from one host authenticates indiscriminately elsewhere. Not 0.00: authentication was required everywhere; it was the identity binding, not the authentication itself, that was absent. | The brief's AID-H-004.002 entry prescribes authenticating 'CI jobs, applications, services, and other non-human callers with distinct workload identities, short-lived audience-bound credentials, and route binding so a secret stolen from one host cannot authenticate indiscriminately to source, database, VPN, and cloud services' — describing, by negation, the assessed state. The credential classes the payload harvested (SSH keys, cloud access keys, CI client secrets, database passwords, VPN credentials, long-lived service certificates) are enumerated in AID-E-001.001 as the objects requiring rotation, confirming they were long-lived static secrets.source: brief |
Unknown, not N/A: 19 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.75w 0.20 | The 0.75 supervised-autonomy anchor, scored on evidence rather than as a default. The evidenced autonomy in the assessed path is automated dependency resolution and build/install execution on CI runners: third-party code is fetched and executed without per-action human approval, with human oversight asynchronous at merge review — which is why the brief's remediation includes a pre-merge dependency change risk review as a gate that must block. The gateway component itself has no independent decision authority in evidence, so the 1.00 anchor is not reached. |
| AsAttack Surface Exposure | 0.75w 0.25 | The 0.75 anchor: external data ingestion from a partially trusted source — a public package index with maintainer-account-based publishing — into an internet-connected serving path. Not 1.00: no untrusted RAG corpus, external-agent communication or MCP tool integration is evidenced for the assessed deployment, and the ingestion channel does carry a real if defeated trust model (maintainer accounts, project release flow). |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published, so the spec's worst-case default applies (no SDG, DGC < 0.90). The reconstruction independently triggers the 1.00 anchor as well: a single ingestion event at the dependency layer terminated at credential- and permission-issuing material — cloud and Kubernetes credentials, CI client secrets, SSH keys and long-lived service certificates — which is an ungated path reaching a P4 node, with onward reach to source repositories, databases, VPN and cloud (L4). The `.pth` mechanism in 1.82.8 additionally made propagation host-wide and import-independent, so the taint reached everything the graph would predict rather than a bounded subset. Mercor's confirmation of downstream impact is independent corroboration that the reach was realised and not merely theoretical.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.25 | The 0.25 anchor. Removing the vulnerable artifact is deterministic — pin off 1.82.7/1.82.8 and delete `litellm_init.pth` — but that is not the remediation: full recovery requires infrastructure and credential-lifecycle work measured in days, namely rotating every credential present on affected hosts on or after 24 March 2026 (AI provider keys, cloud and Kubernetes credentials, CI tokens, SSH keys, database passwords, VPN access), freezing direct public index pulls, standing up an internal mirror with exact-version and hash pinning, moving installs into ephemeral low-trust sandboxes, and building the dependency impact list. All of these are deployment-infrastructure changes, none require model work, and none are probabilistic in effect. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | The 0.25 minimal-provenance anchor. The compromised component is documented precisely — vendor, exact versions, the out-of-band publication anomaly, the malicious file name, the credential classes collected. Nothing comparable exists for the assessed deployment: no AIBOM, no dependency map (its absence is the explicit finding behind AID-M-001.002), no tool or model inventory, no identity policy, no evaluation artifacts. Provenance is strong about the poison and weak about the patient. |
| Ec — Public evaluation coverage | 0.17 | coverage 0.17 (4 of 23 applicable sub-metrics) × independence 1.00 × fidelity 1.00. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.35 | Evidence dated 2026-04-01; age 134 days on the workpaper reference date. Components: C_event 0.35 · T_containment 0.36 · T_calendar 0.60 · C_monitor 0.65 · C_evidence 0.85. Binding term: C_event. dt_days = 134, measured from the primary public disclosure dated 2026-04-01 to the 2026-08-13 evidence reference date; the AIDEFEND brief republished the analysis on 2026-04-18. The underlying compromise began on 2026-03-24; freshness uses the date the evidence entered the public record. agentic = true for the Tool-Calling / Connected GenAI class per the containment staleness rule (M_Cn = 2.0): the gateway's permission boundary is exactly the credential and connector set that mutates at runtime, which is what this incident turned over. baw = false: the Behavioral Attestation Window checklist was applied and no item is met — no model- or agent-writable cross-session memory, no runtime agent-to-agent channel, no self-modifying prompt or configuration, and no closed feedback loop in a decision path. C_monitor = 0.65 — nothing alerted at the time; the brief instructs defenders to retroactively 'review logs for unusual repository, database, VPN, or cloud access since March 24, 2026', which is a detection and alert-routing failure spanning weeks. C_event = 0.35 — a poisoned dependency executing with credential-harvesting behaviour is a compromise event on the major row, and the `.pth` persistence mechanism changed the runtime execution surface of the host. C_evidence = 0.85 — unresolved at the assessment date: the full extent of the claimed exfiltrated dataset was not independently confirmed, and no dependency map exists to bound the affected population. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.25 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-023 | Publisher Integrity & Workflow HardeningParent AID-H-023 maps directly to Ro-4 and Tr-4 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. Substantively it is the control whose absence is the root of this case: the malicious releases were uploaded outside the official GitHub CI path, and provenance-preferring admission would have flagged that. | Very High | Ro-4 Tr-4 |
| AID-H-003.001 | Software Dependency & Package SecurityParent AID-H-003 (Secure ML Supply Chain Management). Both mapped edges are scored in this case: Ro-4 = 0.25 for the unscreened ingestion path, Tr-4 = 0.25 for the incomplete dependency lineage. This is the technique that most directly carries the case. | Very High | Ro-4 Tr-4 |
| AID-H-022.002 | Pre-Merge Dependency Change Risk ReviewParent AID-H-022 maps directly to Ro-4 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. The Pre-Merge Dependency Change Risk Review control is applied here as evidence for Ro-4. | High | Ro-4 |
| AID-H-022.001 | Sandboxed Dependency InstallationParent AID-H-022 maps directly to Ro-4 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. Substantively this is the evidence source for Cn-1 = 0.25 — the install context was not ephemeral, not egress-restricted, and co-resident with long-lived credentials. | High | Ro-4 |
| AID-H-004.002 | Service & API AuthenticationParent AID-H-004 (Identity, Access & Trusted Communication for AI Systems). Cn-5 is the scored edge and this entry is its primary evidence: distinct workload identities, short-lived audience-bound credentials and route binding are prescribed, so their absence is what makes a stolen secret replayable everywhere. Tr-3 is a catalogue edge not independently evidenced here. | High | Cn-5 Tr-3 |
| AID-E-001.001 | Root & Long-Lived Credential Object EvictionParent AID-E-001 (Compromised Credential, Session, Principal & Grant Eviction). Its enumeration of the exact credential objects requiring rotation is what establishes that the harvested material was long-lived and static — the factual basis for the Cn-5 = 0.25 anchor placement. | High | Cn-5 |
| AID-M-001.002 | AI System Dependency MappingParent AID-M-001 (AI Asset Inventory & Mapping). Tr-4 is the germane edge and the direct basis for Tr-4 = 0.25; the absence of this map is also what caps C_evidence at 0.85, since the affected population cannot be bounded. The catalogue's Fa-3 edge has no bearing on this case. | Medium | Cn-5 Fa-3 Tr-4 |
WHAT THIS CASE TEACHES
AITBM scores a software supply-chain compromise as an AI-system finding without distorting either: the AI-specific signal lands on Ro-4 (the dependency ingestion path is a poisoning channel), Cn-5 (static credentials with no workload binding) and Tr-4 (no AIBOM to bound the blast radius), while the thinness of published deployment detail is carried honestly by a base coverage of 4 of 22 rather than by inventing scores — the epistemic penalty appears in ACI, which is where the framework intends it.
Sources: AIDEFEND in Action — LiteLLM Fallout: How a Poisoned AI Dependency Reached Mercor · LiteLLM project repository (BerriAI/litellm) — host of the project incident issue cited in the brief; the specific issue URL is not reproduced in the brief text · Primary source — Mercor confirms cyberattack as hackers claim 4TB of critical data in possession (2026-04-01)