WHAT THE FORTY MINUTES COST

DFEI.011's main issue names the LiteLLM/TeamPCP supply-chain breach as the incident that shows permission and identity infrastructure failing in exactly the domain it was supposed to cover: credential and dependency trust. The original compromise happened in March 2026 and was largely resolved within roughly forty minutes, the window CloudSEK's own research says the malicious PyPI packages were live. But an active FBI advisory says the consequences aren't resolved at all; harvested credentials remain live ammunition months later. This report turns that gap, between "the intrusion stopped" and "the exposure ended," into a self-check any organization running AI infrastructure can run against its own dependency chain.

Most organizations treat a disclosed supply-chain breach as resolved once the malicious package is pulled from the registry and the immediate intrusion is contained. CloudSEK's own reporting on the LiteLLM/TeamPCP breach, and the FBI's own advisory about it, both say plainly that this assumption is wrong for credential-harvesting breaches specifically: once a credential (an SSH key, a cloud token, a CI/CD secret) has been exfiltrated, removing the malicious package does nothing to un-expose it. The specific failure this VSR addresses: organizations check whether they're still running the compromised package, not whether anything the compromised package could have reached has since been rotated.

CloudSEK's own report, fetched directly, documents the scale: a March 2026 compromise of the LiteLLM package, orchestrated by the threat actor group TeamPCP, with a reconstructed exposure dataset covering 2,500+ organizations and 434,000+ potentially exposed CI/CD pipelines, and named high-confidence victims including AWS, Samsung, Cisco, Siemens, ServiceNow, Airbus, John Deere, and the London Stock Exchange Group. The malicious PyPI packages themselves were live for only about forty minutes. The FBI's July 2026 FLASH advisory (FLASH-20260702-01) warns that affiliated threat actors are likely to weaponize the harvested credentials well after the original intrusion window, which is exactly why CloudSEK is still actively identifying and notifying new victim organizations five months later, in this coverage window.

This is directly relevant to the Table's central question in DFEI.011: this is a domain, credential and dependency security, where identity and permission infrastructure is specifically supposed to help, and the breach happened anyway, at scale, because the failure occurred one layer below where most permission tooling looks (in the dependency supply chain itself, not in who was granted access to what).

Did anything in your stack touch the compromised dependency chain, directly or transitively, and if so, has every credential it could have reached been rotated since?

This reframes the check from "are we still vulnerable to the original intrusion" (almost certainly no, the malicious packages are gone) to "are we still exposed by what the intrusion touched" (frequently still unresolved, and frequently never explicitly checked).

5.1 Direct and Transitive Dependency Check

Direct and Transitive Dependency Check answers:

Does your stack use LiteLLM, or anything that depends on it transitively, even indirectly through another package?

Examples: - Direct use of LiteLLM as a model gateway or routing layer - Transitive exposure through the Telnyx Python SDK or Checkmarx KICS, both confirmed by security researchers to have been affected in the same propagation chain - CI/CD pipelines that pulled any affected package during the live window, even if the dependency was later removed

Failure pattern:

Organizations check their current dependency manifest, which shows the malicious package is gone, and conclude they're clear, without checking whether the package was ever present during the live window and what it could have reached while it was.

5.2 Credential Blast-Radius Mapping

Credential Blast-Radius Mapping answers:

Everything a compromised CI/CD pipeline could have exposed — not just what the pipeline was designed to use.

Examples: - SSH keys, cloud credentials (AWS/GCP/Azure), Kubernetes tokens, and LLM API keys reachable from the same runtime environment - Any secret stored in the same CI/CD system, even for unrelated pipelines, if the compromise could have reached the broader secrets store - Downstream systems accessible using any of the above credentials, which is where the real, ongoing risk the FBI is warning about lives

Failure pattern:

Teams rotate the specific credential they know was used by the compromised package, and stop, without mapping what else was reachable from the same blast radius.

Resolved-Package, Unresolved-Exposure Gap

The organization confirms the malicious package is no longer in use and treats the incident as closed, without checking whether anything the package could have reached during the live window was ever rotated. This is the single most common failure pattern in supply-chain breach response, and it's exactly what the FBI's ongoing advisory is warning is still unresolved for LiteLLM/TeamPCP specifically.

Transitive Blindness

Organizations check their direct dependencies but not what those dependencies depend on. The LiteLLM/TeamPCP propagation chain specifically included the Telnyx Python SDK and Checkmarx KICS as secondary vectors, meaning an organization that never directly used LiteLLM could still have been exposed transitively.

Credential Scope Assumption

Teams assume a compromised credential's exposure is limited to what it was intended to access, rather than mapping what it was actually capable of accessing. A CI/CD secret scoped broadly "just in case" is exactly the kind of credential a supply-chain compromise turns into a much larger problem than its intended use case.

Purpose

Produces a prioritized, documented record of every credential potentially exposed by the LiteLLM/TeamPCP breach class, and its rotation status, so exposure closure is verifiable rather than assumed.

Use when

• Responding to any disclosed supply-chain breach involving a dependency your organization uses directly or transitively
• Conducting a periodic audit of credential exposure from past breaches, especially ones with an active law-enforcement advisory warning of delayed exploitation

What it creates

A single register listing every potentially exposed credential, its blast radius, and its rotation status, reviewed until every entry is closed.

Technical version

credential_rotation_register:
  breach_reference: "LiteLLM / TeamPCP, March 2026"
  dependency_exposure:
    direct_use: true/false
    transitive_use: []          # list any secondary vectors identified
    confirmed_live_window_exposure: true/false
  credentials:
    - credential_type:          # SSH key / cloud token / CI-CD secret / API key
      system:
      reachable_from_compromised_runtime: true/false
      rotated: true/false
      rotation_date:
      downstream_systems_accessible:
  monitoring:
    anomalous_use_detection_active: true/false
  status: open/closed
  last_reviewed:

Manual / no-code alternative

A shared spreadsheet with one row per credential, columns for system, blast radius, rotation status, and rotation date, reviewed weekly until every row reads closed.

Output

A documented, verifiable record of exposure closure, replacing an assumption ("we removed the package, so we're fine") with evidence.

Failure prevented

Long-tail credential exploitation following a supply-chain compromise the organization believed was already resolved.

A supply-chain breach is not over when the malicious package is removed. It's over when every credential it could have touched has been rotated.

Apply the register to the LiteLLM/TeamPCP case directly: an organization using LiteLLM in a CI/CD pipeline during March 2026 would document direct exposure, map every credential reachable from that pipeline (per CloudSEK's own findings, this commonly includes SSH keys, cloud credentials, Kubernetes tokens, and LLM API keys), and rotate each one, not just the credential LiteLLM itself used. Given the FBI's July advisory, the register's status field should remain open, with active anomalous-use monitoring, until enough time has passed without incident to reasonably close it, not simply until the rotation task is marked complete.

This VSR does not audit any specific organization's exposure to the LiteLLM/TeamPCP breach. It provides a self-check process; running it, and acting on its findings, is the reader's responsibility. It also does not claim comprehensive coverage of every secondary propagation vector, CloudSEK and other researchers may identify additional affected packages as their investigation continues, and the register should be treated as a living document, not a one-time check.

The distinction this VSR exists to hold: a supply-chain breach has two clocks. The first is how long the malicious code was live, which for LiteLLM/TeamPCP was about forty minutes. The second is how long the exposure it created remains exploitable, which the FBI says is still running, five months later, in this coverage window. Organizations that only track the first clock will believe they're clear while remaining exposed on the second. The permission and identity infrastructure DFEI.010 tracked exists specifically to prevent this kind of exposure, and this breach happened at scale anyway, one layer below where most of that tooling looks. Closing the gap isn't a tooling purchase. It's the discipline of tracking the second clock as carefully as the first.

DFEI.011 :: VSR-02 :: What the Forty Minutes Cost Dispatches From Emerging Intelligence