Security Security United States Amazon

Wiz Says Credentials Stolen in the LiteLLM Compromise Were Used Within Hours to Check for Amazon Bedrock Access

Wiz says that about 4.5 hours after exfiltration, the attacker behind the malicious LiteLLM 1.107.0 release validated stolen AWS instance-role credentials and listed available Bedrock models, activity Wiz calls 'consistent with LLMjacking'; Wiz does not report models being run. LiteLLM says the release also reached its Docker Hub and GHCR images, via GitHub tokens it believes were taken from an exposed internal server's logs.

Times of AI Desk Oct 21, 2026 6 min read Global View as Markdown

Updated October 22, 2026 (afternoon): Wiz says credentials stolen through the malicious release were used within hours to check for access to Amazon Bedrock. The new section directly below covers it; the morning update and the original October 21 report follow unchanged.

October 22 afternoon: Wiz says stolen cloud credentials were checked for Bedrock access#

Wiz's account moves the stolen-credential risk from a possibility to observed activity, although what it describes is credential checks and model listings, not use of the models. In an update to its write-up at 19:05 UTC on Wednesday, October 21, Wiz Research said it had observed abuse of stolen credentials starting about 4.5 hours after exfiltration. Between 16:20 and 17:01 UTC, it says, the attacker validated AWS instance-role credentials harvested from compromised CI runners and Kubernetes nodes across multiple environments. Wiz says each credential was checked with an identity call followed by calls listing the foundation models available on Amazon Bedrock, activity it calls "consistent with LLMjacking." In a small number of environments, Wiz says, the attacker also enumerated IAM roles, users and access keys and performed general discovery.

Wiz also says the stealer queries the database of the LiteLLM Proxy directly to extract configured provider credentials, and that the payload "has strong indications of LLM-aided development," citing verbose variable names, overly defensive error handling and a code module that was defined but never called. That is Wiz's reading of the code's style. The Hacker News, which carried Wiz's findings, reports that Socket said "the public evidence reviewed so far doesn't establish a connection to the March attack" on LiteLLM.

Limits of the October 22 afternoon update#

The post-exploitation activity is Wiz's observation; The Hacker News's account of it relies on Wiz's, and no other source we opened reports it. Wiz's post describes credential checks and model listings, not model invocations.
Wiz published two attacker IP addresses; Times of AI is not reproducing them.
What we checked: at 09:14 UTC on October 22, LiteLLM's post still showed its 20:30 UTC October 21 update as the latest, PyPI listed 1.106.2 as the current release, and we found no public response from Anthropic to LiteLLM's Claude Code finding.
Note, October 22: GitHub's advisory database now lists 1.107.0 in its malware advisory GHSA-92x9-889m-jgmw, first published for the March releases and last updated at 00:32 UTC on October 22, after our October 21 check below found no advisory for 1.107.0. LiteLLM itself has still published no repository advisory for it.

Updated October 22, 2026: LiteLLM's own incident post says its Docker Hub and GHCR images were also poisoned and sets out how the release was published. The new section directly below covers it; the original October 21 report follows, unchanged except that its headings now sit one level lower under a dated section.

October 22: LiteLLM says the containers were hit too, and traces the breach to stolen GitHub tokens#

The maintainer's own account widens the incident from a bad PyPI release to its official container images, and places the cause in developer credentials rather than in LiteLLM's source code. LiteLLM's incident post, signed by its CEO, CTO and director of security among others and last updated at 20:30 UTC on Wednesday, October 21, says all seven 1.107.0 wheels were live on PyPI from 11:39:51 to about 13:23 UTC. It says the Docker Hub tags v1.107.0, latest, main-latest and main-stable pointed to a compromised image from 11:46:56 to 14:20 UTC, and that the same tags on GHCR, GitHub's container registry, did so until they were made unavailable by 13:51 UTC. Customers using LiteLLM's private enterprise registry were not affected, it says.

How LiteLLM says the release was published#

LiteLLM says the attacker held GitHub CLI credentials belonging to three developers. A token belonging to one of the company's two GitHub organisation owners was used to override branch protection and change the private release workflow, which was then run against a lookalike repository and signed and published the poisoned artifacts; a third developer's credentials were used to delete the workflow records, limiting the logs available. LiteLLM says it had hardened its pipeline after a prior incident in March, moving releases to a private repository with trusted publishing, immutable Docker tags and signed images.

LiteLLM says it found an unexpected, innocuously named user account on its internal LiteLLM deployment, which was exposed to the public internet, and believes the attacker took the GitHub CLI tokens from that deployment's logs. It has not confirmed how the attacker got in, but says it "currently suspect[s] it was through a recently patched vulnerability." On how the tokens reached the logs, LiteLLM writes: "After a thorough investigation, we have observed specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs." That is LiteLLM's finding; it says it is still confirming parts of its account, and we found no public response from Anthropic.

Datadog Security Labs, a second security vendor, gives the same list of affected PyPI and container artifacts and describes LiteLLM as a library with about 23 million weekly downloads. It says the release also carried a remote-access backdoor that checked a GitHub-hosted file every hour for a domain to download code from, but that the file only ever held test values, so no second-stage payload was observed in the wild. Datadog calls this the second supply-chain compromise of LiteLLM in 2026 and says no connection between the two has been established. LiteLLM tells affected users to avoid running pip in an affected environment before removing the dropped files, to pin 1.106.2, and to rotate every credential the host could reach.

Limits of the October 22 update#

The attack chain, the internal-deployment finding and the Claude Code observation are LiteLLM's account, which it says is still being confirmed; Datadog's analysis relies on LiteLLM's for how the credentials were used.
Datadog's timeline differs from LiteLLM's: it puts the PyPI quarantine at 13:20 UTC and the Docker image removal at 13:53 UTC, against LiteLLM's 14:20 UTC for Docker Hub. The times above are LiteLLM's.
What we checked: at 03:00 UTC on October 22, LiteLLM's post still showed its 20:30 UTC update as the latest, PyPI listed 1.106.2 as the current release, and we found no public response from Anthropic.
Note, October 22: LiteLLM's post now confirms that its Docker Hub and GHCR images were affected and describes how the release was published, superseding the October 21 Limits statement below that the publishing method was unconfirmed.

Original report: AISLE flags the PyPI wheels, October 21#

LiteLLM, which security vendor AISLE calls "the popular Python package," shipped malware through its built packages rather than its source code, according to AISLE, the sole source for the technical detail here. AISLE says all seven wheels of LiteLLM 1.107.0 published to PyPI on Wednesday, October 21 contained a credential stealer, while the source distribution and the signed v1.107.0 tag on GitHub did not. It says the first file was uploaded at 11:39:51 UTC and its dependency firewall flagged the first wheel at 11:43:05 UTC.

By AISLE's account, the malware runs every time Python starts on an affected machine, even if code never imports LiteLLM, and collects browser-saved passwords, SSH, GPG and TLS keys, cloud and Kubernetes credentials, CI/CD secrets and environment variables. AISLE says a second component runs in the background and checks hourly for further code to execute. AISLE says this points to a compromised build or publish step or a stolen PyPI publishing token, adding: "This is a breaking story; we have not yet confirmed which." AISLE credits Upwind with the first public report.

AISLE says PyPI quarantined the release; when we checked at about 15:00 UTC, PyPI's JSON API returned no 1.107.0 release and listed 1.106.2 as the latest version. On the project's GitHub issue tracker, a LiteLLM contributor account wrote at 13:50 UTC that the team was treating the incident as SEV-0, and at 14:32 UTC that "the malicious docker images have been removed," that the publishing method had not yet been identified or locked down, and that users should pin 1.106.2 for now. StepSecurity, a second security vendor, separately reported the same malicious wheels and said LiteLLM's official Docker images had carried the same payload before they were removed.

Limits#

The technical analysis is AISLE's, with a matching account from StepSecurity; both are security vendors, and we did not analyse the files ourselves.
What we checked: PyPI's API returns no 1.107.0 release and lists 1.106.2 as latest, and the quarantine was confirmed on the issue tracker by a contributor account whose profile lists BerriAI.
As of about 15:10 UTC, neither LiteLLM nor GitHub's advisory database had published an advisory for 1.107.0, and how the release was published was unconfirmed.