LiteLLM Supply-Chain Findings Highlight External Dependencies in Drupal AI Workflows

Security researchers examining a March 2026 software supply-chain campaign have published new August findings that distinguish the wider Trivy compromise from the later attack on LiteLLM. CloudSEK reported on 11 August 2026 that its reconstructed exposure dataset contained more than 2,500 organisations and about 434,000 CI/CD pipelines potentially exposed. A separate Resecurity analysis published on 14 August 2026 examined an archive containing 415,427 secret-capture files associated with 898 GitHub owners and 2,038 repositories. Those figures come from different datasets and should not be treated as counts of organisations that installed the malicious LiteLLM packages.

The Drupal connection is narrower but direct. The contributed LiteLLM AI Provider connects Drupal's AI framework to a LiteLLM instance configured separately by the site administrator. None of the incident sources reviewed for this story identifies Drupal core, the provider module, or a Drupal site as compromised. The relevance is therefore the external service and infrastructure on which a Drupal AI integration can depend, rather than a compromise inside Drupal's own package ecosystem.

The attack reached LiteLLM through compromised upstream tooling. JFrog Security Research reported on 24 March 2026 that LiteLLM's security-scanning workflow installed Trivy without pinning an exact version or verifying its integrity. According to JFrog, malicious Trivy version 0.69.4 then executed inside LiteLLM's CI pipeline and exposed credentials that attackers used to publish backdoored LiteLLM packages.

LiteLLM's incident record identifies 1.82.7 and 1.82.8 as the compromised PyPI releases and says they were uploaded outside the project's official GitHub release process. Version 1.82.7 contained malicious code in proxy_server.py, while 1.82.8 also added litellm_init.pth, allowing code to run during Python startup without an explicit LiteLLM import. LiteLLM said the affected packages were deleted, maintainer accounts were rotated, and users of its proxy Docker image were not affected because its dependencies were pinned.

Later analysis changed the interpretation of the campaign's wider blast radius. SecurityWeek reported on 14 August 2026 that SOCRadar examined records for 2,188 organisations and found that collection activity for 95% of them ended before the poisoned LiteLLM packages appeared on 24 March. That chronology associates most of those records with the earlier Trivy compromise rather than installation of the malicious LiteLLM releases. The wider figures should therefore be treated as exposure associated with the broader supply-chain campaign, not as thousands of confirmed LiteLLM compromises.

Resecurity provides another view of the credentials exposed through automated development environments. Its researchers said the archive they acquired contained 415,427 secret-capture files associated with 898 GitHub owners and 2,038 repositories. In a recoverable sample of 1,073 files, Resecurity reported that GitHub Actions tokens appeared in about 98% of the files, alongside cloud, registry, application, and signing credentials. These measurements describe Resecurity's acquired archive and sample rather than a complete census of organisations affected by the campaign.

The Drupal integration crosses a separate operational boundary. Installing the LiteLLM AI Provider adds the Drupal-side integration, while administrators configure the URL of a LiteLLM instance that operates outside Drupal's PHP dependency tree. A Drupal application's AI functionality can therefore depend on the security of that service's runtime, Python packages, deployment pipeline, and credentials even when the Drupal site's own Composer packages have not been compromised.

For Drupal teams operating LiteLLM alongside Drupal, the incident extends security review beyond the site repository itself. LiteLLM advises users of the affected releases to rotate credentials that were accessible to compromised systems, pin dependencies to exact versions, and verify packages against expected releases, while JFrog recommends auditing for versions 1.82.7 and 1.82.8 and isolating affected hosts. The available evidence does not show that Drupal core, the LiteLLM AI Provider, or Drupal sites were compromised through this campaign.