Search/models[.]litellm[.]cloud
● IOC

models[.]litellm[.]cloud

Type
DOMAIN
Source
News extraction
First seen
Mar 25, 2026
Last seen
Aug 12, 2026
Look up on VirusTotal
Related Stories
3
TeamPCP Moves From OSS to AWS Environments
This is the second update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 001 covered developments through March 26. This update covers developments from March 26-27, 2026. CRITICAL: Telnyx Python SDK Compromised on PyPI -- New WAV Steganography TTP TeamPCP compromised the telnyx Python SDK (670,000+ monthly downloads) on PyPI, publishing malicious versions 4.87.1 and 4.87.2 at approximately 03:51 UTC on March 27, 2026. No corresponding GitHub releases or tags exist for these versions -- the attacker used stolen PyPI credentials rather than a repository compromise. The most significant technical finding is a new TTP: WAV audio file steganography. Payloads are embedded inside .wav files, which blend naturally with Telnyx's purpose as a voice and telecom API provider. Platform-specific payloads are delivered: Windows: A persistent binary dropped to the Startup folder as msbuild.exe Linux/macOS: A credential harvester following the same pattern as the LiteLLM compromise Forensic analysis by Aikido Security, JFrog, and SafeDep confirms the same RSA-4096 public key and tpcp.tar.gz exfiltration pattern seen in the LiteLLM compromise. Both malicious versions have been quarantined by PyPI. Recommended action: Check your Python environments and CI/CD pipelines for telnyx versions 4.87.1 or 4.87.2. If found, treat all credentials accessible to that environment as compromised and rotate immediately. The last known-safe version is 4.87.0. Also search for .wav files in unexpected locations, msbuild.exe in Windows Startup folders, and outbound connections to known TeamPCP exfiltration domains. This confirms the "expansion to additional PyPI packages" watch item from Update 001. TeamPCP's PyPI campaign is not limited to LiteLLM -- they are actively working through stolen credentials to compromise additional high-value packages. CRITICAL: TeamPCP Partners with Vect Ransomware and BreachForums for Mass Affiliate Program TeamPCP has formally partnered with the Vect ransomware-as-a-service operation and BreachForums. Per Cybernews and Infosecurity Magazine, the announcement states that all approximately 300,000 registered BreachForums users will receive personal Vect affiliate keys. The operational model: TeamPCP provides initial access via compromised supply chain packages and stolen credentials, Vect provides encryption and extortion tooling, and BreachForums provides the operator base. Analysts assess this represents a fundamental shift from supply chain credential theft to industrialized ransomware deployment. If even a small fraction of 300,000 users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed. The convergence of supply chain compromise, ransomware-as-a-service, and dark web forum mobilization at this scale is, to the best of our knowledge, unprecedented. Recommended action: Organizations that were exposed to any phase of the TeamPCP campaign (Trivy, Checkmarx, LiteLLM, Telnyx) should assume their stolen credentials may now be distributed to a large affiliate network. Credential rotation is no longer optional -- it is urgent. Monitor for Vect ransomware indicators. HIGH: LAPSUS$ Claims 3GB AstraZeneca Breach Using TeamPCP Credentials LAPSUS$ is publicly claiming a 3GB breach of AstraZeneca, as reported by SecurityWeek and CSO Online. The claimed data includes internal code repositories, cloud infrastructure configurations (AWS, Azure, Terraform), Spring Boot configs, GitHub Enterprise user information, and employee data. LAPSUS$ is selling access via Session encrypted messaging. This is the first named victim claim from the TeamPCP/LAPSUS$ partnership, confirming the "named victim breach disclosures" watch item from Update 001. AstraZeneca has not confirmed or denied the breach as of publication time. Recommended action: Organizations should not wait for public victim disclosures to take action. If you were exposed to any TeamPCP-compromised component, assume credential theft occurred and rotate proactively. The extortion timeline is accelerating. HIGH: LiteLLM CEO's Personal GitHub Account Was the Compromise Vector ReversingLabs has published new intelligence identifying the specific mechanism behind the LiteLLM PyPI compromise: TeamPCP compromised Krish Dholakia's personal GitHub account (LiteLLM co-founder and CEO) on March 23-24. This was not a generic CI/CD token sweep -- the attacker specifically identified and targeted a named executive's account from the stolen credential trove harvested during the Trivy/Checkmarx phase. This detail refines the attack chain narrative. TeamPCP appears to be triaging stolen credentials for maximum impact, targeting package maintainers with PyPI publishing privileges rather than indiscriminately using every credential they harvested. MEDIUM: CISA KEV Remediation Deadline Correction -- April 8, Not April 3 Update 001 reported the CISA KEV remediation deadline for CVE-2026-33634 as April 3, 2026. The official CISA KEV catalog entry shows the actual deadline is April 8, 2026. This update corrects the previously reported date. Additionally, Help Net Security reports that CISA simultaneously added CVE-2026-33017 (Langflow unauthenticated RCE, affecting versions prior to 1.8.2) alongside the Trivy CVE in the same KEV update. The pairing of two AI/ML infrastructure tool vulnerabilities in a single KEV addition signals that CISA is treating AI toolchain supply chain security as a systemic risk category. Federal agencies now face remediation deadlines of April 8 for CVE-2026-33634 (Trivy) and April 9 for CVE-2026-33017 (Langflow). INFO: LiteLLM's Compliance Certifications Performed by Embattled Auditor TechCrunch reported on March 26 that LiteLLM's SOC2 and ISO 27001 certifications were performed by Delve, a YC startup currently under scrutiny for allegations of "rubber-stamped" compliance audits. This intersection of two Silicon Valley scandals raises questions about the effectiveness of third-party compliance certifications in the AI/ML supply chain ecosystem. HIGH: First Responder Publishes Full Attack Transcript With New IOCs FutureSearch has published the full forensic transcript from Callum McMahon, the engineer who first discovered the compromised LiteLLM package and coordinated the PyPI quarantine on March 24. McMahon used Claude Code to perform real-time forensic analysis of the malicious litellm==1.82.8 package in an isolated Docker environment, producing what is likely the most detailed public record of this attack's execution. Key technical findings not previously documented in the campaign report: .pth file exploitation: The payload (litellm_init.pth , 34 KB) exploited Python's automatic.pth site-packages execution, triggering on every Python interpreter startup -- not just when LiteLLM was imported. This is a persistence mechanism that runs across all Python processes in the environment. C2 domain: models.litellm.cloud -- a typosquat of LiteLLM's legitimate infrastructure, used for HTTPS exfiltration with RSA encryption. Persistence path: ~/.config/sysmon/sysmon.py with systemd service registration. In McMahon's case, the write was interrupted at 0 bytes by a forced reboot. Kubernetes lateral movement: The payload attempted to create privileged alpine:latest pods and harvest service account tokens from/var/run/secrets/kubernetes.io/serviceaccount/token , usingnode-setup-* pod naming to blend with legitimate infrastructure. Multi-cloud credential sweep: A single payload targeted SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, and shell history simultaneously. Accidental fork bomb: The .pth auto-execution combined with subprocess spawning created exponential process multiplication -- each child Python process re-triggered the payload, causing resource exhaustion that inadvertently exposed the attack. The 72-minute timeline from detection to public PyPI quarantine demonstrates how AI-assisted forensic analysis dramatically accelerated incident response. This transcript is highly instructive for defenders studying the attack mechanics and should be reviewed by any team performing forensic analysis of TeamPCP-compromised environments. Recommended action: Search environments for the C2 domain models.litellm.cloud, the persistence path ~/.config/sysmon/sysmon.py, unexpected .pth files in site-packages directories, and node-setup-* pods in Kubernetes clusters. These IOCs supplement the indicators in the parent report. INFO: GitHub Announces Actions Security Roadmap in Response to Supply Chain Attacks GitHub has published a 2026 security roadmap for GitHub Actions that directly references the TeamPCP campaign. The blog post states: "incidents targeting projects like tj-actions/changed-file, Nx, and trivy-action show a clear pattern: attackers are targeting CI/CD automation itself." The roadmap introduces three categories of controls that, if implemented at the time of the Trivy compromise, would have materially altered the attack surface: Workflow dependency locking: A new dependencies: section in workflow YAML pins all direct and transitive action references to immutable commit SHAs. Hash mismatches stop execution before jobs run. This directly addresses the tag-rewriting TTP that TeamPCP used to redirect 76 trivy-action tags and all 91 ast-github-action tags to malicious commits. Public preview in 3-6 months. Policy-driven execution controls: Rulesets-based policies that restrict which actors can trigger workflows, which events are permitted, and which execution contexts can access secrets. Scoped secrets prevent a single compromised token from accessing all repository secrets. Public preview in 3-6 months. Egress firewall for hosted runners: Layer 7 network monitoring and enforcement for GitHub-hosted runners, restricting which external domains workflows can reach. This would have blocked the exfiltration to scan.aquasecurtiy[.]org andmodels.litellm.cloud . Public preview in 6-9 months. Analysts assess these controls represent the most substantive platform-level response to the GitHub Actions supply chain attack vector to date. However, the 3-9 month rollout timeline means organizations remain exposed to tag-rewriting and credential theft TTPs in the interim. Pinning actions to full commit SHAs remains the primary defensive measure until dependency locking reaches GA. Additional Intelligence Kaspersky publishes independent verification: Kaspersky published their own technical advisory characterizing this as a unified "trojanization" campaign, independently verifying the attack chain and broadening awareness to their enterprise customer base. GitGuardian draws "Shai Hulud" parallel: GitGuardian frames the campaign alongside the "Shai Hulud" attack pattern -- both targeting CI/CD pipelines to harvest secrets rather than attacking applications directly. Their analysis emphasizes that Aqua Security's non-atomic credential rotation was the root cause enabling the second compromise wave (Docker Hub images v0.69.5 and v0.69.6 on March 22). Corrections to Update 001 Aqua Security "additional findings" deadline: Update 001 stated "Aqua Security promised additional findings by end of day March 26" as a watch item. This was incorrect. On March 23, 2026, Aqua Security's blog stated they would "provide a further update, including additional findings, tomorrow end of day" -- meaning end of day March 24, not March 26. Aqua published their comprehensive incident report, "Trivy Supply Chain Attack: What Happened and What You Need to Know", on March 24 at 23:00 UTC, meeting their stated deadline. The report covers the full attack timeline, root cause (non-atomic credential rotation after the March 1 incident), and remediation details. This is no longer a watch item. CISA KEV remediation deadline: Also corrected in this update's MEDIUM finding above -- April 8, not April 3 as originally reported in Update 001. Watch Items Vect ransomware affiliate key distribution and first deployments linked to TeamPCP credentials Additional PyPI packages compromised via stolen credentials (telnyx confirms the pattern) AstraZeneca confirmation or denial of the LAPSUS$ breach claim Mandiant formal attribution report (BerriAI engagement announced, report pending) CISA standalone advisory or emergency directive (KEV entries issued, no dedicated advisory yet) Expansion to RubyGems, crates.io, or Maven Central (Endor Labs prediction, not yet confirmed) LiteLLM/BerriAI forensics completion and release resumption The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.
1 shared
Mar 31, 2026
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
This is the second update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 001 covered developments through March 26. This update covers developments from March 26-27, 2026. CRITICAL: Telnyx Python SDK Compromised on PyPI -- New WAV Steganography TTP TeamPCP compromised the telnyx Python SDK (670,000+ monthly downloads) on PyPI, publishing malicious versions 4.87.1 and 4.87.2 at approximately 03:51 UTC on March 27, 2026. No corresponding GitHub releases or tags exist for these versions -- the attacker used stolen PyPI credentials rather than a repository compromise. The most significant technical finding is a new TTP: WAV audio file steganography. Payloads are embedded inside .wav files, which blend naturally with Telnyx's purpose as a voice and telecom API provider. Platform-specific payloads are delivered: Windows: A persistent binary dropped to the Startup folder as msbuild.exe Linux/macOS: A credential harvester following the same pattern as the LiteLLM compromise Forensic analysis by Aikido Security, JFrog, and SafeDep confirms the same RSA-4096 public key and tpcp.tar.gz exfiltration pattern seen in the LiteLLM compromise. Both malicious versions have been quarantined by PyPI. Recommended action: Check your Python environments and CI/CD pipelines for telnyx versions 4.87.1 or 4.87.2. If found, treat all credentials accessible to that environment as compromised and rotate immediately. The last known-safe version is 4.87.0. Also search for .wav files in unexpected locations, msbuild.exe in Windows Startup folders, and outbound connections to known TeamPCP exfiltration domains. This confirms the "expansion to additional PyPI packages" watch item from Update 001. TeamPCP's PyPI campaign is not limited to LiteLLM -- they are actively working through stolen credentials to compromise additional high-value packages. CRITICAL: TeamPCP Partners with Vect Ransomware and BreachForums for Mass Affiliate Program TeamPCP has formally partnered with the Vect ransomware-as-a-service operation and BreachForums. Per Cybernews and Infosecurity Magazine, the announcement states that all approximately 300,000 registered BreachForums users will receive personal Vect affiliate keys. The operational model: TeamPCP provides initial access via compromised supply chain packages and stolen credentials, Vect provides encryption and extortion tooling, and BreachForums provides the operator base. Analysts assess this represents a fundamental shift from supply chain credential theft to industrialized ransomware deployment. If even a small fraction of 300,000 users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed. The convergence of supply chain compromise, ransomware-as-a-service, and dark web forum mobilization at this scale is, to the best of our knowledge, unprecedented. Recommended action: Organizations that were exposed to any phase of the TeamPCP campaign (Trivy, Checkmarx, LiteLLM, Telnyx) should assume their stolen credentials may now be distributed to a large affiliate network. Credential rotation is no longer optional -- it is urgent. Monitor for Vect ransomware indicators. HIGH: LAPSUS$ Claims 3GB AstraZeneca Breach Using TeamPCP Credentials LAPSUS$ is publicly claiming a 3GB breach of AstraZeneca, as reported by SecurityWeek and CSO Online. The claimed data includes internal code repositories, cloud infrastructure configurations (AWS, Azure, Terraform), Spring Boot configs, GitHub Enterprise user information, and employee data. LAPSUS$ is selling access via Session encrypted messaging. This is the first named victim claim from the TeamPCP/LAPSUS$ partnership, confirming the "named victim breach disclosures" watch item from Update 001. AstraZeneca has not confirmed or denied the breach as of publication time. Recommended action: Organizations should not wait for public victim disclosures to take action. If you were exposed to any TeamPCP-compromised component, assume credential theft occurred and rotate proactively. The extortion timeline is accelerating. HIGH: LiteLLM CEO's Personal GitHub Account Was the Compromise Vector ReversingLabs has published new intelligence identifying the specific mechanism behind the LiteLLM PyPI compromise: TeamPCP compromised Krish Dholakia's personal GitHub account (LiteLLM co-founder and CEO) on March 23-24. This was not a generic CI/CD token sweep -- the attacker specifically identified and targeted a named executive's account from the stolen credential trove harvested during the Trivy/Checkmarx phase. This detail refines the attack chain narrative. TeamPCP appears to be triaging stolen credentials for maximum impact, targeting package maintainers with PyPI publishing privileges rather than indiscriminately using every credential they harvested. MEDIUM: CISA KEV Remediation Deadline Correction -- April 8, Not April 3 Update 001 reported the CISA KEV remediation deadline for CVE-2026-33634 as April 3, 2026. The official CISA KEV catalog entry shows the actual deadline is April 8, 2026. This update corrects the previously reported date. Additionally, Help Net Security reports that CISA simultaneously added CVE-2026-33017 (Langflow unauthenticated RCE, affecting versions prior to 1.8.2) alongside the Trivy CVE in the same KEV update. The pairing of two AI/ML infrastructure tool vulnerabilities in a single KEV addition signals that CISA is treating AI toolchain supply chain security as a systemic risk category. Federal agencies now face remediation deadlines of April 8 for CVE-2026-33634 (Trivy) and April 9 for CVE-2026-33017 (Langflow). INFO: LiteLLM's Compliance Certifications Performed by Embattled Auditor TechCrunch reported on March 26 that LiteLLM's SOC2 and ISO 27001 certifications were performed by Delve, a YC startup currently under scrutiny for allegations of "rubber-stamped" compliance audits. This intersection of two Silicon Valley scandals raises questions about the effectiveness of third-party compliance certifications in the AI/ML supply chain ecosystem. HIGH: First Responder Publishes Full Attack Transcript With New IOCs FutureSearch has published the full forensic transcript from Callum McMahon, the engineer who first discovered the compromised LiteLLM package and coordinated the PyPI quarantine on March 24. McMahon used Claude Code to perform real-time forensic analysis of the malicious litellm==1.82.8 package in an isolated Docker environment, producing what is likely the most detailed public record of this attack's execution. Key technical findings not previously documented in the campaign report: .pth file exploitation: The payload (litellm_init.pth , 34 KB) exploited Python's automatic.pth site-packages execution, triggering on every Python interpreter startup -- not just when LiteLLM was imported. This is a persistence mechanism that runs across all Python processes in the environment. C2 domain: models.litellm.cloud -- a typosquat of LiteLLM's legitimate infrastructure, used for HTTPS exfiltration with RSA encryption. Persistence path: ~/.config/sysmon/sysmon.py with systemd service registration. In McMahon's case, the write was interrupted at 0 bytes by a forced reboot. Kubernetes lateral movement: The payload attempted to create privileged alpine:latest pods and harvest service account tokens from/var/run/secrets/kubernetes.io/serviceaccount/token , usingnode-setup-* pod naming to blend with legitimate infrastructure. Multi-cloud credential sweep: A single payload targeted SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, and shell history simultaneously. Accidental fork bomb: The .pth auto-execution combined with subprocess spawning created exponential process multiplication -- each child Python process re-triggered the payload, causing resource exhaustion that inadvertently exposed the attack. The 72-minute timeline from detection to public PyPI quarantine demonstrates how AI-assisted forensic analysis dramatically accelerated incident response. This transcript is highly instructive for defenders studying the attack mechanics and should be reviewed by any team performing forensic analysis of TeamPCP-compromised environments. Recommended action: Search environments for the C2 domain models.litellm.cloud, the persistence path ~/.config/sysmon/sysmon.py, unexpected .pth files in site-packages directories, and node-setup-* pods in Kubernetes clusters. These IOCs supplement the indicators in the parent report. INFO: GitHub Announces Actions Security Roadmap in Response to Supply Chain Attacks GitHub has published a 2026 security roadmap for GitHub Actions that directly references the TeamPCP campaign. The blog post states: "incidents targeting projects like tj-actions/changed-file, Nx, and trivy-action show a clear pattern: attackers are targeting CI/CD automation itself." The roadmap introduces three categories of controls that, if implemented at the time of the Trivy compromise, would have materially altered the attack surface: Workflow dependency locking: A new dependencies: section in workflow YAML pins all direct and transitive action references to immutable commit SHAs. Hash mismatches stop execution before jobs run. This directly addresses the tag-rewriting TTP that TeamPCP used to redirect 76 trivy-action tags and all 91 ast-github-action tags to malicious commits. Public preview in 3-6 months. Policy-driven execution controls: Rulesets-based policies that restrict which actors can trigger workflows, which events are permitted, and which execution contexts can access secrets. Scoped secrets prevent a single compromised token from accessing all repository secrets. Public preview in 3-6 months. Egress firewall for hosted runners: Layer 7 network monitoring and enforcement for GitHub-hosted runners, restricting which external domains workflows can reach. This would have blocked the exfiltration to scan.aquasecurtiy[.]org andmodels.litellm.cloud . Public preview in 6-9 months. Analysts assess these controls represent the most substantive platform-level response to the GitHub Actions supply chain attack vector to date. However, the 3-9 month rollout timeline means organizations remain exposed to tag-rewriting and credential theft TTPs in the interim. Pinning actions to full commit SHAs remains the primary defensive measure until dependency locking reaches GA. Additional Intelligence Kaspersky publishes independent verification: Kaspersky published their own technical advisory characterizing this as a unified "trojanization" campaign, independently verifying the attack chain and broadening awareness to their enterprise customer base. GitGuardian draws "Shai Hulud" parallel: GitGuardian frames the campaign alongside the "Shai Hulud" attack pattern -- both targeting CI/CD pipelines to harvest secrets rather than attacking applications directly. Their analysis emphasizes that Aqua Security's non-atomic credential rotation was the root cause enabling the second compromise wave (Docker Hub images v0.69.5 and v0.69.6 on March 22). Corrections to Update 001 Aqua Security "additional findings" deadline: Update 001 stated "Aqua Security promised additional findings by end of day March 26" as a watch item. This was incorrect. On March 23, 2026, Aqua Security's blog stated they would "provide a further update, including additional findings, tomorrow end of day" -- meaning end of day March 24, not March 26. Aqua published their comprehensive incident report, "Trivy Supply Chain Attack: What Happened and What You Need to Know", on March 24 at 23:00 UTC, meeting their stated deadline. The report covers the full attack timeline, root cause (non-atomic credential rotation after the March 1 incident), and remediation details. This is no longer a watch item. CISA KEV remediation deadline: Also corrected in this update's MEDIUM finding above -- April 8, not April 3 as originally reported in Update 001. Watch Items Vect ransomware affiliate key distribution and first deployments linked to TeamPCP credentials Additional PyPI packages compromised via stolen credentials (telnyx confirms the pattern) AstraZeneca confirmation or denial of the LAPSUS$ breach claim Mandiant formal attribution report (BerriAI engagement announced, report pending) CISA standalone advisory or emergency directive (KEV entries issued, no dedicated advisory yet) Expansion to RubyGems, crates.io, or Maven Central (Endor Labs prediction, not yet confirmed) LiteLLM/BerriAI forensics completion and release resumption The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.
1 shared
Mar 28, 2026
TeamPCP deploys Iran-targeted wiper in Kubernetes attacks
The TeamPCP hacking group has expanded its open source software campaign from the Trivy supply chain attack to NPM, Docker Hub, VS Code, and PyPI, and likely partnered with the Lapsus$ gang for monetization purposes. The attack on Aqua Security’s widely used Trivy vulnerability scanner started with the compromise of an access token in late February. Because the maintainers did not rotate all credentials and secrets simultaneously, the hackers were able to maintain access to the compromised environment. OpenSourceMalware reports with high confidence that the attackers compromised the Argon-DevOps-Mgt service account token, which provided them with write/admin access to both Aqua Security’s internal and public-facing repositories. The attack has been attributed to TeamPCP (also known as DeadCatx3, PCPcat, and ShellForce), which was behind a December worm-driven campaign that targeted Docker, Kubernetes, Ray, and Redis, and which also exploited the React2Shell vulnerability, according to Flare. In the Trivy supply chain attack, now tracked as CVE-2026-33634 (CVSS score of 9.4), the hackers released malicious package versions and modified GitHub Actions tags to push information-stealing malware that would harvest credentials, keys, tokens, and other sensitive data. In early March, a similar attack hit Xygeni: compromised credentials linked to repository automation were used to introduce malicious code. Initially, the attackers relied on pull requests, but when that failed, they modified a mutable tag to reference a malicious commit, leading to downstream infections. “While the attack leveraged a known GitHub Actions vulnerability involving mutable tags, the incident also highlights the importance of comprehensive repository protection, strict credential management, and defense-in-depth across CI/CD systems,” Xygeni notes in its incident report. The Trivy attack and blast radius TeamPCP started pushing malware to the Trivy repositories on March 19, but the multi-stage supply chain attack has been contained and is now in the remediation and documentation phase, Aqua said on Wednesday. However, it took five days to fully evict the attackers. Three days after the containment and remediation efforts started, the attackers published malicious Trivy Docker Hub images (v0.69.5 and v0.69.6), confirming that their access had not been blocked, Trivy’s maintainers revealed. “Working closely with Sygnia, we are developing formal documentation that includes the confirmed timeline, actions taken to remediate the incident, and supporting materials for customer assurance and attestation. This effort is informed by a comprehensive review of credentials, access controls, and affected systems,” Aqua says. What made the attack stand out was the use of modified GitHub Action tags to reference malware without any visible changes to the tag name, published dates, or the release page, allowing the attackers to operate under the radar. According to a SANS Institute report seen by SecurityWeek, more than 10,000 CI/CD workflows were affected by the Trivy incident. Every CI/CD pipeline referencing the modified GitHub Actions automatically executed the malicious code, dropping TeamPCP’s information stealer and exposing secrets, credentials, and infrastructure. To evade detection on the infected systems, malicious code contains instructions to remove all its temporary files after performing its multi-stage credential theft and exfiltration operation, CrowdStrike explains. “The remainder of the script is a functional copy of the real trivy-action entry point. It downloads and runs Trivy normally, producing expected scanner output. To an operator reviewing workflow logs, the step appears to have completed successfully,” the cybersecurity company notes. The Checkmarx attack On March 23, TeamPCP hit Checkmarx’s KICS open-source project, publishing malicious versions of the checkmarx.cx-dev-assist and checkmarx.ast-results VS Code plugins to the OpenVSX marketplace. Like the Trivy attack, the hackers injected malicious payloads into the plugins by force-pushing tags that were pointing to malicious commits. A total of 35 GitHub Action version tags were hijacked, SANS Institute says. Checkmarx has since updated GitHub Actions to ast-github-action v2.3.33 and kics-github-action v2.1.20 and permanently removed all previous versions from its repositories. The malicious plugin iterations, namely ast-results 2.53.0 and cx-dev-assist 1.7.0, should be immediately removed. “Upon discovery, we removed the malicious artifacts, pinned our workflows to safe verified commit SHAs, revoked and rotated all exposed credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise,” Checkmarx says. The cybersecurity firm warns all organizations that downloaded or ran a compromised version of the two plugins from Open VSX to rotate all secrets and environment variables. GitHub credentials, Personal Access Tokens (PATs), repository and organization secrets, SSH keys, Docker registry credentials, Kubernetes service account tokens, and GitHub, Microsoft Azure, Google Cloud (GCP), and AWS access tokens should be considered compromised and immediately rotated. As ReversingLabs points out, the two VS Code extensions have a combined download count of over 36,000 and are designed for use within VS Code and compatible integrated development environments (IDEs), such as Cursor, Kiro, and Windsurf, making the attack’s blast radius large. CanisterWorm and the NPM attacks Last week, TeamPCP’s campaign also targeted the NPM ecosystem, using read/write access tokens to push malware downstream and using the same infostealer from the Trivy attack. The NPM supply chain attack hit at least 64 unique packages and affected more than 140 package artifacts, injecting install-time malware that relies on an Internet Computer Protocol (ICP) canister dead drop to deliver follow-on binaries. Dubbed CanisterWorm, the final payload contains a component that uses compromised NPM publishing credentials to inject the payload into additional packages. To evade detection, it preserves the legitimate README files, Socket explains. As the attack unfolded, the hackers were seen updating their code, moving from using a postinstall hook to write a Python payload, install it as a systemd –user service, and execute it, to using a hardcoded Python dropper and using the service name pgmon for persistence. According to Aikido, the malware was initially similar to the one used in the Trivy attack, but was later updated with the worm component that allowed it to use harvested NPM tokens and environment variables and spawn a persistent background process using them, to infect additional packages. “Every developer or CI pipeline that installs this package and has an NPM token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats,” Aikido notes. The Kubernetes wiper targeting Iran The same ICP canister used in the CanisterWorm attack on NPM was also used in a campaign targeting Kubernetes. The main difference was that the code included a wiper aimed at Iran-based clusters. The payload contains standard Kubernetes pod detection, deploys privileged DaemonSets across every node, and drops the CanisterWorm backdoor on them as a systemd service, achieving persistence as PostgreSQL tooling. In more recent iterations of the attack, the malware added network-based lateral movement, using SSH via compromised keys and auth log parsing, and exploiting exposed Docker APIs, Aikido reports. The code also checks the system timezone and locale and, if it detects machines configured for Iran, drops a DaemonSet to wipe the entire cluster. Dubbed “kamikaze”, the wiper mounts the host’s root filesystem, erases the top-level content, and then forces a reboot. The operation is performed on all nodes, including the control plane, destroying the entire cluster. “The Kubernetes-native lateral movement via DaemonSets is consistent with TeamPCP’s known playbook, but this variant adds something we haven’t seen from them before: a geopolitically targeted destructive payload aimed specifically at Iranian systems,” Aikido notes. On non-Kubernetes systems configured for Iran, if root access is available, the malware wipes everything. If it does not have root access, it “tries passwordless sudo, then tries anyway. Even without root, it’ll destroy everything the user owns,” Aikido notes. The PyPI attack and LiteLLM compromise In its most recent phase, TeamPCP’s campaign moved to the PyPI ecosystem, compromising LiteLLM, an open source Python library and proxy server that has more than 95 million monthly downloads. LiteLLM versions 1.82.7 and 1.82.8 were injected with the same information-stealing and dropper malware observed in the other TeamPCP attacks, with the same goal: the compromise of valuable credentials for broad access. The malicious code in LiteLLM 1.82.8 “fires on every Python invocation in the environment” and “runs silently in the background without delaying Python startup,” EndorLabs explains. Used as a unified interface between applications and AI service providers such as Anthropic, Google, and OpenAI, LiteLLM supports over 100 LLM APIs and typically has access to sensitive information such as API keys and environment variables. “Additionally, the breadth of data targeted by the malware underscores how modern development environments — spanning local machines, CI/CD pipelines, and cloud infrastructure — are deeply interconnected. A single compromised dependency can expose credentials across multiple systems, dramatically increasing the potential blast radius,” Sonatype notes. LiteLLM compromise has provided the attackers with access to all the secrets the library touches, and the impact from the attack is broad: approximately 300GB of data was exfiltrated from around 500,000 infected machines, threat intelligence and research project Vx-Underground says. ReversingLabs says that the hackers likely compromised the GitHub account of LiteLLM co-founder and CEO Krish Dholakia on March 23 and then defaced the LiteLLM GitHub repositories in an automated manner the next day. Organizations that installed or executed the malicious LiteLLM versions should immediately remove the packages, rotate all credentials, and investigate the affected systems for suspicious connections, persistence mechanisms, and potentially affected packages. According to cybersecurity outfit Wiz, LiteLLM is present in 36% of all cloud environments, providing hackers with a foothold in highly sensitive parts of the development lifecycle. “In many cases, rebuilding affected systems from a known clean state may be the safest course of action,” Sonatype notes. The Lapsus$ connection In addition to expanding across multiple OSS communities, TeamPCP’s campaign has escalated to a monetization phase. The group is openly taking credit for the attacks and appears to have partnered with the Lapsus$ extortion group for financial gain. TeamPCP has boasted on its Telegram account about the Trivy compromise, the GitHub Actions attacks, the OpenVSX extensions incident, and the PyPI hack, stating a clear focus on security tools and high-leverage points within the OSS ecosystem. The group also claims its operation is still unfolding, saying that it will be “stealing terabytes of trade secrets with our new partners”, Socket reports. While the ‘partners’ were not named, it appears that the hacking group was hinting at Lapsus$, which boasted on its Telegram account about an upcoming supply chain attack from TeamPCP. According to Wiz, this explicit collaboration between the two threat actors is an ecosystem-wide ‘cascade’ aimed at the modern cloud-native and AI ecosystems. “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$,” Wiz lead researcher Ben Read told SecurityWeek. “By moving horizontally across the ecosystem – hitting tools like LiteLLM that are present in over a third of cloud environments – they are creating a ‘snowball effect.’ This isn’t an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand,” Read added. The partnership between the two groups also appears to explain why some security researchers linked the AstraZeneca data breach to TeamPCP’s campaign, while Lapsus$ has claimed responsibility for it. Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea Related: New ‘Sandworm_Mode’ Supply Chain Attack Hits NPM Related: Autonomous AI Agents Provide New Class of Supply Chain Attack Related: ‘PackageGate’ Flaws Open JavaScript Ecosystem to Supply Chain Attacks
1 shared
Mar 25, 2026
Connections
3 relationships
Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations
Two malicious LiteLLM releases sat on PyPI for about 40 minutes in March carrying credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from systems that installed them. Threat intelligence firm CloudSEK now says a dataset it obtained, built from roughly 434,000 files the attackers captured, maps potential exposure to more than 2,500 organizations. Those totals are not a victim count. CloudSEK told The Hacker News the material came from confidential intelligence sources and consists of captured loot and log files it assessed as belonging to the campaign, not data gathered from the organizations it names. The files were taken, in other words. CloudSEK has published the dataset as a public lookup, searchable by name or domain and filterable by confidence. Each row gives an organization's name and domain, a count of secrets exposed, a count of runs, and a label reading High or Medium. What a high-confidence match asserts is whose systems each file came from. That verdict keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and the organization's own domain has to appear before a match earns the top rating. Repository namespaces support only a medium-confidence call. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp are among the entries, and none of that establishes that stolen credentials were used, which is why both CloudSEK and LiteLLM tell affected parties to rotate rather than wait for proof. LiteLLM is an open-source AI gateway used to connect applications with multiple model providers. The project identified versions 1.82.7 and 1.82.8 as compromised and said they were live on March 24 from 10:39 UTC for about 40 minutes before PyPI quarantined them, though it tells users to treat any install that day up to 16:00 UTC as suspect. The Hacker News confirmed via PyPI on August 12 that neither version appears in the package's release history, while 1.82.6 and 1.83.0 remain available. The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows. A long-lived secret copied during that window, a static cloud key, an SSH key, or a publishing token, remains usable unless it has since been rotated or revoked. That is why the bureau's guidance is scoped to credentials rather than to the package, and why both it and Aqua tell teams to move away from long-lived tokens toward temporary ones. Version 1.82.8 included a file named litellm_init.pth that Python processes at interpreter startup, so it ran whenever a Python process started in that environment, whether or not anything imported LiteLLM. The compromised packages were designed to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords before encrypting and sending stolen data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project. Unit 42's campaign analysis records the payload reading environment variables that hold model API keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY. That behavior inverts the usual triage question. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it, and the project's advisory notes that an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could deliver it without anyone choosing it. The LiteLLM incident sits inside a wider TeamPCP supply-chain campaign linked to Aqua Security's Trivy scanner. Google tracks TeamPCP as UNC6780. Aqua said attackers retained access after an incomplete credential rotation and, on March 19, force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 release. The ecosystem compromise is tracked as CVE-2026-33634, added to CISA's Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components. Exactly how the malicious LiteLLM releases reached PyPI was disputed across the published accounts. CloudSEK's report said the poisoned build produced and published the releases, LiteLLM's own incident report pointed to a direct PyPI upload that bypassed its official CI/CD workflow, and Unit 42 described attackers targeting PyPI publishing tokens after the Trivy breach. Asked about the discrepancy, CloudSEK pushed back. "These are different stages of the same attack chain, not competing explanations," the company told The Hacker News. Its evidence covers how the credential was obtained, while the LiteLLM and Unit 42 findings cover how it was then used. PyPA's advisory for the malicious releases describes the same sequence: an API token exposed through the compromised Trivy dependency and then used to upload the two versions. BerriAI had not responded to questions about which account its own forensics support at the time of writing. Attribution inside the dataset runs through two independent checks, CloudSEK said. An index assigns each file using CI identity variables, and a separate ownership gate re-derives ownership from the fetched logs and can override that assignment. "If they disagree, the report is withheld," the company said, and the final verdict takes the lower of the two confidence levels. The 434,000 figure counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs. CloudSEK said one captured file is roughly one job execution, but it does not present the total as unique jobs without independent deduplication and verification. The company declined to discuss pre-publication notifications to the named organizations, and would not say whether any disputed its inclusion. The campaign's downstream impact is confirmed even if CloudSEK's scale figures are not. Checkmarx said credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories and the publication of malicious artifacts. Mercor said it was affected by malicious LiteLLM versions and contained unauthorized activity. CERT-EU separately assessed with high confidence that a European Commission AWS account was compromised through the Trivy supply-chain attack, with about 91.7 GB of compressed data exfiltrated. Organizations assessing exposure should take three steps: Check for LiteLLM 1.82.7 or 1.82.8 installations during LiteLLM's March 24 audit window of 10:39 to 16:00 UTC. Rotate any secrets those systems could access. Search their GitHub organizations for repositories named tpcp-docs or docs-tpcp, which the FBI lists as campaign indicators. Aqua's advisory for the CVE notes the malware created these with a tpcp-docs- prefix and uploaded stolen data as a release asset tagged data- , so an exact-name search can miss them.
thehackernews.comAug 12, 2026extracted
An AI gateway designed to steal your data
A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product. This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster. Repository compromise The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added. Technical analysis Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started. The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it. The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key. The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server. What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following data located on servers and within the infrastructures of various services: SSH keys GIT accounts .env files AWS, Kubernetes, email service, database, and WireGuard configurations files related to Helm, Terraform, and CI TLS keys and certificates A notable feature of this malware is that it does not limit itself to stealing files and configurations from the disk but also attempts to extract runtime secrets from the cloud infrastructure. The code above uses the addresses 169.254.169.254 and 169.254.170.2. The first corresponds to the AWS Instance Metadata Service (IMDS), through which an EC2 instance (a virtual server in AWS, a machine running in the cloud) can retrieve metadata and temporary IAM role credentials (an AWS account with a set of permissions that a service or application can use to obtain temporary credentials for calls to the AWS API). The second is used in Amazon ECS to issue temporary credentials to a container during execution. Thus, the malicious script targets not only static secrets but also those issued by the cloud that can grant direct access to AWS resources at the time of infection. Additionally, the script searches for crypto wallet configurations, as well as webhooks associated with Slack and Discord messengers. The latter indicates that the attackers are interested not only in infrastructure secrets and accounts, but also in communication channels within the development team. In the next stage, the malware moves from data collection to establishing a foothold in the Kubernetes cluster infrastructure: if it has sufficient access, it configures a privileged pod (the smallest execution unit in Kubernetes, containing one or more containers) by enabling the securityContext.privileged=true option and mounts the node’s root filesystem via hostPath. This allows it to escape the container and perform actions at the node level. Next, the malware executes another stage of infection: it saves a Base64-encoded script disguised as a legitimate system component to the Kubernetes node’s disk at the path /root/.config/sysmon/sysmon.py, and registers it via systemd. After launching, the script waits for an initial delay of 300 seconds, then begins periodically contacting the C2 node checkmarx[.]zone/raw, retrieving a link to the next payload from there. If the received value differs from the state previously saved in /tmp/.pg_state, the script downloads a new file to /tmp/pglog, makes it executable, and runs it in the background. At this stage, the attackers gain a foothold in the system and are capable of regularly delivering updated payloads without the need for re-injection. Since the malicious payload is written not to the container’s temporary file directory but directly to the Kubernetes cluster node, the attackers will retain access to the infrastructure even after the container has terminated. A similar scenario is used for local persistence: in the absence of Kubernetes, the sysmon.py script is deployed in the user’s directory at ~/.config/sysmon/sysmon.py and is also registered as a service via systemd. OpenVSX version of the malware While analyzing files communicating with the C2 server, we discovered malicious versions of two common Checkmarx software extensions: ast-results 2.53.0 and cx-dev-assist 1.7.0. Checkmarx is used for application security assessment. These trojanized extensions contained malicious code that delivered the NodeJS version of the malware described above. This version is downloaded from checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz using NodeJS package installation utilities and is named checkmarx-util. Its key difference from the Python version is that it does not attempt to elevate privileges to the Kubernetes node level and does not create a privileged pod for persistence. Instead, it implements local persistence within the current environment. This means that the NodeJS variant persists only where it is already running. Additionally, the list of folders to search for and steal secrets from is significantly smaller in this version than in the Python variant. Checkmarx extensions are used to scan code and infrastructure configurations, so their compromise is quite dangerous: an attacker gains access not only to project files but also to a significant portion of the development environment, tokens, and local configurations. Victimology While assessing the attack’s impact, we saw victims all over the world. Most infection attempts occurred in Russia, China, Brazil, the Netherlands, and UAE. Conclusion As the technical analysis shows, the malicious scripts found in the LiteLLM versions are dangerous not only because they steal files containing sensitive data, but also because they target multiple critical infrastructure components simultaneously: the local system, cloud runtime secrets, the Kubernetes cluster, and even cryptographic keys. Such a broad scope of data collection allows an attacker to quickly move from compromising a single system and Python environment to seizing service accounts, secrets, and entire infrastructures. Prevention and protection To protect against infections of this kind, we recommend using a specialized solution for monitoring open-source components. Kaspersky provides real-time data feeds on compromised packages and libraries, which can be used to secure the supply chain and protect development projects from such threats. Home security solutions, such as Kaspersky Premium, help ensure the security of personal devices by providing multi-layered protection that prevents and neutralizes infection threats. Additionally, our solution can restore the device’s functionality in the event of a malware infection. To protect corporate devices, we recommend using a complex solution such as Kaspersky NEXT, which allows you to build a flexible and effective security system. The products in this line provide threat visibility and real-time protection, as well as EDR and XDR capabilities for threat investigation and response. At the time of writing, the compromised versions of LiteLLM had already been removed from PyPI and OpenVSX. If you have used them, and as a proactive response to the threat, we recommend taking the following measures on your systems and infrastructure: Perform a full system scan using a reliable security solution. Rotate all potentially compromised credentials: API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets. Check hosts and clusters for signs of compromise: the presence of ~/.config/sysmon/sysmon.py files and suspicious pods in Kubernetes. Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions. Check for indicators of compromise (files on the system or network signs). Indicators of Compromise: URLs models[.]litellm[.]cloud checkmarx[.]zone Infected packages 85ED77A21B88CAE721F369FA6B7BBBA3 2E3A4412A7A487B32C5715167C755D08 0FCCC8E3A03896F45726203074AE225D Scripts F5560871F6002982A6A2CC0B3EE739F7 CDE4951BEE7E28AC8A29D33D34A41AE5 05BACBE163EF0393C2416CBD05E45E74
securelist.comMar 26, 2026extracted
Trojanization of Trivy, Checkmarx, and LiteLLM solutions | Kaspersky official blog
Millions of automated software development pipelines rely on security tools — such as Trivy and Checkmarx AST — integrated into the build process. And it was namely these trusted solutions that recently became the entry point for one of the largest and most dangerous supply chain attacks in modern history. In this post we discuss how to audit automated workflows and secure corporate cloud infrastructure. Timeline of the attack and known consequences On March 19, a successful targeted supply chain attack was carried out via Trivy, an open-source vulnerability scanning tool widely used in CI/CD pipelines. The attackers — a group known as TeamPCP — managed to inject malware into official GitHub Actions workflows and Docker images associated with Trivy. As a result, every automated pipeline scan made triggered malware that stole SSH keys, cloud access tokens, cryptocurrency wallets, and other valuable data from compromised systems. Given the critical nature of the incident, it was assigned the identifier CVE-2026-33634, with a near-maximum CVSS4B score of 9.4. Later that same day, the Trivy team detected the attack and removed malicious artifacts from the distribution channels, halting this phase of the attack. However, the attackers had already gained access to the environments of many Trivy users. On March 23, a similar incident was discovered in another application security tool: a GitHub Action for Checkmarx KICS, as well as Checkmarx AST. Three hours later, the malicious code was removed from there as well. TeamPCP also managed to compromise OpenVSX extensions supported by Checkmarx: cx-dev-assist 1.7.0 and ast-results. Reports on when this part of the incident was resolved vary. On March 24, a popular project using Trivy’s code scanning — the LiteLLM AI gateway, a universal library for access to various LLM providers — was attacked. Versions 1.82.7 and 1.82.8, uploaded to PyPI repository, were compromised. These versions were publicly available for about five hours. But the fact that the attack lasted only a few hours is no reason to dismiss it. Given the popularity of the affected projects, the malicious code could have been executed thousands of times — including within the infrastructure of very large companies. This allowed attackers to deploy persistent backdoors in Kubernetes clusters, as well as launch the self-replicating CanisterWorm across the JavaScript npm ecosystem. The attackers’ code has destructive capabilities that wipe out a Kubernetes cluster and all its nodes if it detects either Tehran’s time zone, or Farsi as the primary language on the compromised system. In other regions, the malware simply steals data using CanisterWorm. According to experts, more than 20,000 repositories are considered potentially vulnerable. The attackers claim to have stolen hundreds of gigabytes of data and more than half a million accounts. How Trivy Was Attacked To compromise Trivy, the attackers used credentials stolen in a previous incident. The previous Trivy compromise, which occurred in late February, was likely not fully contained, and the attackers — the same TeamPCP group — returned with a new attack. Trivy’s developers, Aqua Security, speculate that because credentials were being phased out gradually following the previous incident, the attackers were able to generate new access tokens for themselves before compromised old ones had been revoked. As a result, TeamPCP was able to compromise GitHub Actions used in CI/CD pipelines. Using credentials with tag-writing privileges, the attackers forcibly overrode 76 out of 77 version tags in aquasecurity/trivy-action, and all seven tags in aquasecurity/setup-trivy, redirecting existing trusted versions to malicious commits. This resembles tactics observed in the Shai-Hulud 2.0 campaign. As a result, workflows throughout the pipeline began executing the attackers’ code, while the release metadata showed no visible changes. At the same time, the attackers published an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries. LiteLLM Compromise The compromise of the popular language-model access tool LiteLLM could itself trigger a major wave of attacks across the chain of projects that use it. The attack took place on March 24, 2026, when TeamPCP directly published malicious versions of the library (1.82.7 and 1.82.8) on PyPI. Between 10:39 UTC and 16:00 UTC, these compromised packages contained malware that stole credentials. It was embedded in the proxy_server.py file, and version 1.82.8 also contained a malicious litellm_init file. The stolen data was exfiltrated to the server models.litellm[.]cloud. Customers using LiteLLM Cloud or the official LiteLLM Proxy Docker image were not affected due to strict version locking, whereas developers and downstream projects that installed unpinned versions via pip during the specified time window were compromised. Within three hours, the malicious packages were removed from the PyPI repository, and the LiteLLM team suspended new releases, rotated credentials, and engaged an external incident response process. Teams that use LiteLLM in their projects are advised to immediately check for the litellm_init.pth compromise indicator, and routinely rotate all potentially compromised secrets. Features of the TeamPCP Cloud Stealer malware Attackers added new logic to GitHub Actions and the Trivy executable while preserving the original functionality. Vulnerability scan results via Trivy appeared normal, but at the same time valuable data was being searched for and extracted. Malicious code was doing the following: performing reconnaissance (collecting network data and environment variables); searching for tokens and credentials to access AWS and GCP cloud environments; scanning memory (/proc/*/mem) to extract secrets stored in the memory of Runner.Worker and Runner.Listener processes; extracting Kubernetes secrets (/run/secrets/kubernetes.io/serviceaccount); collecting data for connecting to database servers (MySQL, PostgreSQL, MongoDB, Redis, Vault); collecting any other API keys and secrets from environment files and CI/CD configuration files (.env, .json, .yml); searching for webhooks for Slack and Discord channels; searching for data related to crypto wallets (variables related to the Solana blockchain, as well as rpcuser and rpcpassword data). The collected data was encrypted and uploaded to a server with a name similar to the that of the Trivy’s developers (scan.aquasecurtiy[.]org). As a backup mechanism, the attackers provided a method for uploading data to a repository named docs-tpcp. The attack on CheckMarx and LiteLLM used a similar tactic with other typosquatting domains: models.litellm[.]cloud and checkmarx[.]zone. A detailed technical analysis of the malware, along with indicators of compromise, can be found in our expert’s article on the Securelist blog. Response and Defense Strategies for CVE-2026-33634 Existing signature-based checks and dependency scanning in public registries are no longer sufficient, as the malicious code was injected directly into trusted, signed actions, and evaded detection until behavioral monitoring was applied. CI/CD pipelines have become the “new perimeter” of security. Immediate Actions. Ensure that all workflows use secure versions (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6). CI/CD pipeline administrators and security teams should immediately review their dependances to Checkmarx (kics-github-action, ast-github-action) and Trivy (setup-trivy and trivy-action) solutions. If workflows referenced a version tag rather than a specific SHA hash, carefully review your workflow execution logs for the duration of the active supply chain attack. You should also check your network logs for traffic to the domains scan.aquasecurtiy[.]org, checkmarx[.]zone, and models.litellm[.]cloud. The presence of such traffic indicates that sensitive data has been successfully exfiltrated. If a repository named docs-tpcp has appeared on organization’s GitHub, this may also indicate a successful data breach. In any case, a proactive threat hunt should be conducted, assuming that the systems have been successfully compromised and that the attackers have rapidly advanced within the affected systems. It’s recommended to restore the affected environments from verified backups. Check hosts and clusters for signs of compromise – the presence of ~/.config/sysmon/sysmon.py files, suspicious pods in Kubernetes. Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions. Dependency pinning and secret management. Ensure that exact dependency versions are pinned using cryptographic hashes in all pipelines and Dockerfiles. We advise transitioning from long-lived tokens to short-lived credentials by using a secrets manager tool, and implementing OIDC integrations where supported. Minimize the injection of secrets into the runtime environment — do so only when it’s absolutely necessary. Ensure that secrets are not stored on disk or in temporary files, and are not reused across different processes. Rotate all potentially compromised credentials – API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets. Other security measures. Allow only GitHub Actions from a list approved by the organization; block new and unverified processes. Configure GITHUB_TOKEN and other access keys in accordance with the principle of least privilege. Don’t grant write permissions unless absolutely necessary. To enhance the security of GitHub Actions, there are several open-source tools available: zizmor — a tool for static analysis and detection of configuration errors in GitHub Actions; gato and Gato-X — two versions of a tool that helps identify structurally vulnerable pipelines; allstar — a GitHub application, developed by OpenSSF, to configure and enforce security policies in GitHub organizations and repositories. If you want to learn more about supply chain attacks, we invite you to look at our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts, and reveals how often organizations face supply chain and trusted relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against these kinds of threats.
kaspersky.comMar 25, 2026extracted