Three supply chain attacks hit GitHub repositories, PyPI packages and Docker images

Socket researchers said on Nov. 9, 2026 that a malicious GitHub Actions workflow had spread to tens of thousands of repositories, including ones owned by organizations. A second supply chain attack hit LiteLLM in 2026 after a compromised release reached PyPI and Docker on October 21. JFrog Security Research identified 42 breached third-party GitHub repositories on Oct. 27._

Accounts controlled by henrywoo and kitao introduced a malicious workflow into hundreds of repositories they could modify on Oct. 8, 2026. The workflow arrived through commits labeled Add security audit workflow and another labeled Update security audit workflow, using the file name.github/workflows/security-audit.yml. Rather than running checks, the workflow gathered repository credentials and sent them to 193.32.204[.]199 using HTTP._

Socket researchers said the malicious file appeared in tens of thousands of repositories where write access was held by henrywoo or kitao. Vectors included henrywoo/pyllama and henrywoo/chatllama, AI projects created by henrywoo, along with kitao/pixel, typically distributed through PyPI and crates.io. The Uber-owned project uber/athenadriver was affected, with henrywoo holding write access as its original author. Repositories inactive for a decade were also hit, indicating automated rather than manual targeting.

The new variant scans repository files and full Git history for credentials with regular-expression patterns. It recovers secrets committed to source code or configuration files, including credentials from earlier file versions even after removal from the latest version. It also targets credentials for cloud providers and AI services, which could expose infrastructure, hosted applications, and third-party services.

On Oct. 9, 2026, examined repositories still carried the workflow on default branches, including uber/athenadriver and kitao/pyxel. Because it had successfully executed, credential theft was not limited to an attempted injection. Socket had not observed malicious package versions on PyPI or crates.io, but said that absence does not mean stolen credentials went unused.

GhostAction is a campaign that targets developer infrastructure on GitHub, and researchers first found it in September 2025. It breaks into legitimate developer accounts to plant malicious GitHub Actions workflows in repositories, using stolen Personal Access Tokens or credentials from infostealer logs and dumps. Attackers name workflow files things like Security Audit or GitHub Actions Security, and they aim to steal CI/CD secrets, cloud credentials, package registry tokens, and AI provider API keys._

A new GhostAction wave started on Aug. 31, 2026, with malicious workflows pushed to hundreds of repositories. GitGuardian described the wave as more experimental and manual than earlier waves, with a payload that changed over time. The first version added git history secret-scanning, with regular expressions matching AWS key IDs and cloud API keys. It also matched AI-related secrets, GitHub and GitLab tokens.

The second version of the payload grabs roughly two lines of context for each AWS key ID it finds, linking the IDs to matching secret access keys. A third variant can retrieve secret context while scanning git history.

The payload reached 160 previously observed victims first, then spread to 28,000 new repositories within twenty minutes from Oct. 8 to Oct. 9, 2026. More waves using the same payload appeared on Oct. 10 and Oct. 12. GitHub began blocking the workflow on Oct. 9, which stopped the later waves from extracting secrets._

The Oct. 8 and Oct. 9 spike broke into about 1,900 GitHub accounts. Attackers tried to pull 3,174 secrets from public repositories’ continuous integration during the spike, which affected over 30,000 repositories spread across 3,000 users and organizations. Some victims had been hit before, in the September 2025 and August 2026 waves, a pattern pointing to unrotated secrets.

LiteLLM experienced a second supply chain attack in 2026 when a malicious release went to PyPI and Docker registries on Oct. 21. The compromised version, 1.107.0, held compiled malware built to steal credentials and to load remote-code execution tools. All earlier versions were safe, and the affected releases were pulled.

The package stayed on PyPI from 11:39 to 13:23 UTC on Oct. 21. Docker images with tags v1.107.0, latest, main-latest, and main-stable served the bad build from 11:46 to 14:20 UTC on Oct. 21. Wiz researchers Benjamin Read and Rami McCarthy said the latest safe version was v1.106.2. Socket put LiteLLM’s weekly downloads at about 23 million, with seven builds covering macOS, Linux, and Windows.

Malicious code lived in Python startup files, so it ran whenever Python started in an affected environment. Build records pointed to a source repository named Berri-AI/litellm, one hyphen off from the real BerriAI/litellm project. The stealer targeted credentials for AWS, Azure, and Google Cloud. It also grabbed Kubernetes and Docker credentials, Git credentials, SSH and GPG keys, browser logins and cookies, browsing history, and shell history.

It also sought sign-in files for Codex, Claude, Gemini, and Cursor. It tried to read model settings and credentials from LiteLLM proxy deployment databases. Researchers warned that targeting databases shows intent, though it does not prove a specific deployment was breached. The collected information was encrypted and delivered to a healthcheck address on litellm[.]dev.

Roughly four and a half hours after data left victims’ systems, the attacker checked AWS credentials from compromised continuous integration runners and Kubernetes nodes. The attacker also checked whether the credentials worked with AI models on Amazon Bedrock. Wiz researchers tied this to LLMjacking. In a few environments, the attacker listed access keys, users, and IAM roles.

LiteLLM traced the attack to a master key that went into a public repository on May 27, 2026; the key was never revoked. It stayed active for 136 days. The attacker used it on Oct. 10. The intruder took a GitHub CLI OAuth token, which created a path to change continuous integration workflows.

About 49,000 downloads of the poisoned LiteLLM package happened before it was removed. The harvester, called privcollect, was built to take API keys and other secrets. The malicious version ran automatically when Python started, with no import needed. A prior LiteLLM breach in March 2026 exposed data via a compromised Trivy dependency.

JFrog Security Research found breaches in 42 third-party GitHub repositories, where attackers used payload blobs large enough to slip past GitHub search and API paths used to detect compromises. Victimized repositories held execution hooks for AI coding assistants, along with integrated development environments, and polymorphic wrappers up to 13.7MB decoded to the same hidden continuous integration publisher payload. A compiled native addon with no payload of its own decrypts a file called.napi_cache at runtime to reveal the real payload.

The investigation turned up exposed npm credentials, short-lived publishing branches, forged commit timelines, and account hijacks. Shellpanel artifacts tied this GitHub victim infrastructure to earlier GitHub Actions exploitation of internet-facing cPanel systems. JFrog said to revoke and rotate credentials for GitHub, GitLab, npm, PyPI, RubyGems, cloud services, SSH, Vault, Kubernetes, and AI providers. JFrog also said to audit repositories for execution hooks and configuration files such as.github/init.js and.claude/settings.json.

JFrog’s audit guidance covers.gemini/settings.json,.cursor/mcp.json,.cursor/rules/setup.mdc, and.vscode/tasks.json, plus composer.json or Makefile hooks and commits marked skip-checks:true. It said to remove chore/ci-* and deps/upd-* branches that were not authorized, to disable malicious workflows, and to remove fake CodeQL artifacts named scan-output.