TeamPCP deploys Iran-targeted wiper in Kubernetes attacks

This is the third update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 002 covered developments through March 27, including the Telnyx PyPI compromise and Vect ransomware partnership. This update covers developments from March 27-28, 2026. HIGH: First 48-Hour Window Without a New Supply Chain Compromise The most operationally significant development in the last 24 hours is what did not happen: no new package compromises have been confirmed since the Telnyx disclosure on March 27. This is the first 48-hour window without a new ecosystem compromise since TeamPCP began active operations on March 19. The prior operational cadence was aggressive -- a new target every 1-3 days (Trivy March 19, CanisterWorm March 20-22, Checkmarx March 23, LiteLLM March 24, Telnyx March 27). The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests. Analysts assess this pause should not be interpreted as the end of supply chain operations. TeamPCP explicitly stated they intend to be "around for a long time," and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries -- PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker's cost of operations on that platform. Recommended action: Maintain heightened monitoring posture. Use this operational window to complete credential rotations and IOC sweeps if not already done. The CISA KEV remediation deadline for CVE-2026-33634 is now 11 days away (April 8, 2026). HIGH: Palo Alto Networks Publishes Behavioral Detection Rules for CI/CD Pipeline Attacks Palo Alto Networks has published detection rules specifically designed to identify TeamPCP-style CI/CD pipeline attacks at the behavioral level rather than relying solely on IOC matching. This is significant because TeamPCP has demonstrated the ability to rotate infrastructure across each new compromise wave -- each phase used different C2 domains, different exfiltration endpoints, and different packaging techniques (raw scripts, npm worm, .pth exploitation, WAV steganography). Behavioral detection approaches focus on anomalous CI/CD runner behavior: unexpected credential directory enumeration, bulk secret reads from /proc/ /mem, large encrypted archive creation, and outbound data transfers to newly registered domains during workflow execution. These patterns have been consistent across all five TeamPCP compromise phases even as specific IOCs changed. Recommended action: Organizations with Palo Alto Networks security products should review and deploy the published detection rules. All organizations should evaluate whether their CI/CD monitoring can detect the behavioral patterns described -- process memory reads of Runner.Worker, creation of tpcp.tar.gz or similarly named archives, and outbound HTTPS to domains registered within the past 30 days. MEDIUM: Cloud Security Alliance Publishes Kubernetes Wiper Lab Analysis The Cloud Security Alliance has published a detailed lab analysis of TeamPCP's Kubernetes wiper component -- the Iran-targeted DaemonSet that deletes all host filesystem contents when Farsi language settings are detected. The analysis reconstructs the wiper's deployment mechanism and provides detection queries for Kubernetes audit logs. This component was mentioned in the parent report but has received less attention than the credential-stealing payloads. The CSA analysis provides the first detailed defensive playbook specifically for the wiper TTP, including Kubernetes admission controller policies that would block the privileged DaemonSet deployment pattern. Recommended action: Kubernetes operators should review the CSA analysis and implement admission controller policies that prevent privileged DaemonSets from mounting hostPath / with write access. This is good hygiene regardless of TeamPCP exposure. MEDIUM: GitGuardian Quantitative Analysis Maps Credential Exposure Blast Radius GitGuardian has published a quantitative "snowball effect" analysis tracing how a single compromised token cascaded across ecosystems. The analysis maps the amplification factor at each stage: one stolen PAT led to 76+ poisoned GitHub Action tags, which harvested credentials from hundreds of CI/CD pipelines, which enabled compromise of packages with a combined 100+ million monthly downloads. The analysis introduces a metric they call "credential fan-out" -- the ratio of credentials stolen to credentials used for initial access. For TeamPCP, this ratio is estimated at greater than 10,000:1, meaning each compromised credential potentially exposed thousands of downstream secrets. This quantitative framing is useful for communicating risk to executive stakeholders who need to understand why a single supply chain compromise requires organization-wide credential rotation. INFO: Deep Analysis of GitHub Repository-Based Exfiltration Technique Published I have published a detailed analysis of TeamPCP's novel GitHub repository-based data exfiltration technique. The post examines how the campaign used the GitHub Releases API as a fallback exfiltration channel -- programmatically creating repositories on the victim's own account and uploading stolen data as release assets. This technique is significant because corporate firewalls and DLP solutions that whitelist api.github.com traffic cannot distinguish this exfiltration from legitimate GitHub API usage. The analysis includes organizational controls, alternative attack permutations, and threat hunting queries. INFO: AstraZeneca Breach Claim Remains Unconfirmed at 48 Hours LAPSUS$'s claimed 3GB AstraZeneca breach (reported in Update 002) remains unconfirmed. Security Affairs characterized the claim as "potentially one of the most serious healthcare cyber incidents this year" if verified. AstraZeneca has not issued a public statement confirming or denying the breach as of March 28, 2026. No additional named victim claims have been disclosed in the past 24 hours, though the Vect affiliate program distribution may shift the extortion model from centralized TeamPCP/LAPSUS$ operations to distributed affiliate-driven campaigns that are harder to track. Watch Item Status Updated Watch Items First confirmed Vect ransomware deployment using TeamPCP-sourced credentials -- this is the highest-priority indicator of the campaign's next phase Additional named victim disclosures beyond AstraZeneca -- distributed affiliate model may produce claims from multiple actors simultaneously Law enforcement action -- 10 days into an active campaign affecting federal systems with no public enforcement response PyPI and npm registry-level proactive scanning -- both registries have only responded reactively (quarantining packages after disclosure); an announcement of proactive malicious package scanning or signing requirements would signal a meaningful shift in supply chain defense posture CISA KEV deadline compliance (April 8, 2026) -- 11 days remaining 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.

TeamPCP, the threat actor behind the supply chain attack targeting Trivy, KICS, and litellm, has now compromised the telnyx Python package by pushing two malicious versions to steal sensitive data. The two versions, 4.87.1 and 4.87.2, published to the Python Package Index (PyPI) repository on March 27, 2026, concealed their credential harvesting capabilities within a .WAV file. Users are recommended to downgrade to version 4.87.0 immediately. The PyPI project is currently quarantined. Various reports from Aikido, Endor Labs, JFrog, Ossprey Security, SafeDep, Socket, and StepSecurity indicate the malicious code is injected into "telnyx/_client.py," causing it to be invoked when the package is imported into a Python application. The malware is designed to target Windows, Linux, and macOS systems. "Our analysis reveals a three-stage runtime attack chain on Linux/macOS consisting of delivery via audio steganography, in-memory execution of a data harvester, and encrypted exfiltration," Socket said. "The entire chain is designed to operate within a self-destructing temporary directory and leave near-zero forensic artifacts on the host." On Windows, the malware downloads a file named "hangup.wav" from a command-and-control (C2) server and extracts from the audio data an executable that's then dropped into the Startup folder as "msbuild.exe." This allows it to persist across system reboots and automatically run every time a user logs in to the system. In case the compromised host runs on Linux or macOS, it fetches a different .WAV file ("ringtone.wav") from the same server to extract a third-stage collector script and run. The credential harvester is designed to capture a wide range of sensitive data and exfiltrate the data in the form of "tpcp.tar.gz" via an HTTP POST request to "83.142.209[.]203:8080." "The standout technique in this sample - and the reason for the post title - is the use of audio steganography to deliver the final payload," Ossprey Security said. "Rather than hosting a raw executable or a base64 blob on the C2 (both of which are trivially flagged by network inspection and EDR), the attacker wraps the payload inside a .WAV file." "This is almost identical to the sample observed in the LiteLLM malware, with one key difference: instead of embedding the malicious code as Base64, they now download it from a remote server," OX Security's Moshe Siman Tov Bustan said. "The malware downloads an XOR-obfuscated WAV file from a remote C2 server, decodes it, and then executes it on the target machine." It's worth noting that the .WAV trick isn't new to TeamPCP. The same methodology was previously used to conceal the malicious payload in the "kamikaze" wiper malware distributed via CanisterWorm and exposed Docker instances. In addition, the malware features a Kubernetes lateral movement component that abuses Kubernetes service account tokens to deploy a privileged pod to every node and deploy a persistence mechanism. It's currently not known how the package's PYPI_TOKEN was obtained by TeamPCP, but it's likely that it was through a prior credential harvesting operation. "We believe the most likely vector is the litellm compromise itself," Endor Labs researchers Kiran Raj and Rachana Misal said. "TeamPCP's harvester swept environment variables, .env files, and shell histories from every system that imported litellm. If any developer or CI pipeline had both litellm installed and access to the telnyx PyPI token, that token was already in TeamPCP's hands." In a security notice shared on its website, the maintainers of the Python package said both unauthorized versions have been removed from PyPI and that users are likely to be affected if they installed or upgraded the library between 03:51 UTC and 10:13 UTC on March 27, 2026. Telnyx said it's also investigating how the publishing credentials were obtained by the threat actors. What's notable about the attack is the absence of a persistence mechanism in Linux and macOS and the use of a temporary directory to conduct the malicious actions and recursively delete all its contents once everything is complete. "The strategic split is clear. Windows gets persistence: a binary in the Startup folder that survives reboots, providing the threat actor with long-term, repeatable access," Socket explained. "Linux/macOS gets smash-and-grab: a single, high-speed data harvesting operation that collects everything of value and exfiltrates it immediately, then vanishes." The development comes a few days after the threat actor distributed trojanized versions of the popular litellm Python package to exfiltrate cloud credentials, CI/CD secrets, and keys to a domain under its control. The supply chain incident also reflects a new-found maturation, where the threat actor has consistently infected legitimate, trusted packages with massive user bases to distribute malware to downstream users and widen blast radius, rather than directly publishing malicious typosquats to open-source package repositories. "The target selection across this campaign focuses on tools with elevated access to automated pipelines: a container scanner (Trivy), an infrastructure scanning tool (KICS), and an AI model routing library (litellm)," Snyk said. "Each of these tools requires broad read access to the systems it operates on (credentials, configs, environment variables) by design." To mitigate the threat, developers are advised to perform the following actions - Audit Python environments and requirements.txt files for telnyx==4.87.1 or telnyx==4.87.2. If found, replace them with a clean version. Assume compromise and rotate all secrets. Look for a file named "msbuild.exe" in the Windows Startup folder. Block the C2 and exfiltration domain ("83.142.209[.]203"). The compromise is part of a broader, ongoing campaign undertaken by TeamPCP spanning multiple ecosystems, with the threat actor announcing collaborations with other cybercriminal groups like LAPSUS$ and an emerging ransomware group called Vect to conduct extortion and ransomware operations. "Supposedly, the group harvested a ton of credentials over the course of the last few attacks, and teaming up allows scaling/accelerating their (ab)use before all the victims completed remediation," Henrik Plate, head of security research at Endor Labs, told The Hacker news. "Depending on the credentials, 'downstream threat actors' will continue according to their focus, e.g., ransomware attacks." This also signals a shift where ransomware gangs, which have historically focused on initial access methods like phishing and exploitation of security flaws, are now weaponizing supply chain attacks targeting the open source infrastructure as an entry point for follow-on attacks. "This puts a spotlight on anything in CI/CD environments that isn’t locked down," Socket said. "Security scanners, IDE extensions, build tooling, and execution environments are granted broad access because they’re expected to need it. When attackers are targeting the tools themselves, anything running in the pipeline has to be treated as a potential entry point."

TeamPCP has again expanded its supply chain attacks on open-source repositories by targeting Telnyx, according to security researchers. The cyber threat group recently rose to notoriety by uploading malicious packages to Python Package Index (PyPI), the official online repository where developers share and download Python software packages. The group typically uses typosquatting to trick developers into downloading them. In one campaign, the group targeted Trivy, a widely used open-source vulnerability scanner owned by Aqua Security, by injecting credential-stealing malware into official releases and GitHub Actions. A few days later, researchers discovered TeamPCP targeted LiteLLM AI Gateway, a popular Python library for AI model integration. Now, a third TeamPCP campaign has been identified which affects the Telnyx Python package on PyPI and leads to the delivery of credential-stealing malware. Telnyx is a cloud communications platform that provides application programming interfaces (APIs) for phone calls, SMS, MMS and other telecom services. TeamPCP’s Telnyx Compromise Campaign Explained On March 27, researchers from both Socket and Endor Labs published findings revealing that the official Telnyx Python software development kit (SDK) had been compromised in a software supply chain attack. Socket researchers identified that the telnyx package, a legitimate and widely used Python SDK for the Telnyx communications platform, had been tampered with. The malicious versions published to PyPI – versions 4.87.1 and 4.87.2 – contained code designed to exfiltrate sensitive information from victim environments. “They should not be used,” warned the Socket Research Team, whose members confirmed that researchers at Aikido Security and Wiz, now part of Google Cloud, independently came to the same conclusions. Socket found that the attacker had injected functionality to steal SSH private keys and bash history files from compromised systems, sending that data to an attacker-controlled remote server. The malicious payload was designed to execute at install time, meaning a developer or automated pipeline simply installing or updating the package would trigger the attack without needing to import or run any of the package's actual functionality. Endor Labs researchers confirmed Socket’s findings and further explained that the threat actor gained the ability to publish malicious versions of the telnyx package by compromising the credentials of a maintainer account. This is a particularly dangerous attack vector because it does not require vulnerabilities in PyPI's infrastructure itself to be exploited. Instead, the attacker leveraged legitimate publishing access to push trojanized versions that would appear authentic to any automated or manual dependency resolution process. Because the package retained its legitimate name and continued to function as expected for its intended purpose, detection through casual inspection or functional testing would be extremely difficult. Socket researchers noted that the injected payload specifically targeted files that would be of high value in a lateral movement or credential harvesting context. SSH private keys would allow an attacker to pivot to other systems the victim has access to, while bash history files could expose commands containing credentials, server addresses, internal tooling or other sensitive operational information. The data exfiltration was performed over HTTP to an external endpoint controlled by the attacker. Telnyx Campaign Reflects TeamPCP's Growing Sophistication Endor Labs researchers emphasized that the pattern exhibited by TeamPCP reflects a maturation in supply chain attack methodology. Rather than relying solely on typosquatting, which depends on a developer making a naming mistake, this actor has demonstrated the capability and willingness to directly compromise legitimate, trusted packages with real user bases. Endor Labs researchers argued that this significantly raises the risk profile because developers and security teams who explicitly trust a known package and pin to it by name are not protected against this class of attack. Additionally, the three-day interval between the LiteLLM and Telnyx compromises further suggested that the actor was actively iterating and moving quickly across targets rather than executing a single opportunistic event. According to Socket, TeamPCP has recently started partnering with the Vect ransomware group to turn supply chain compromises into large-scale ransomware operations. Socket and Endor Labs researchers recommended that organizations audit their environments for the presence of the malicious versions and rotate any credentials or keys that may have been exposed on systems where the compromised package was installed.

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.

TeamPCP strikes again: Backdoored Telnyx PyPI package delivers malware TeamPCP continues is supply chain compromise rampage, with telnyx on PyPI being the latest maliciously modified package. What happened? Telnyx is a widely used software development kit (SDK) for the Telnyx AI Voice Agent service. According to Endor Labs researchers, attackers backdoored the legitimate SDK code and published versions 4.87.1 and 4.87.2 of the package on the Python Package Index (PyPI), one shortly after the other. The malicious code wasn’t functional in the first version due to a typo, so a second version had to be published. The malicious releases were published on 27 March 2026, between 03:51 UTC and 04:07 UTC on 27 March 2026, “without corresponding GitHub releases or tags, indicating the PyPI publishing credentials were compromised,” Endor Labs’ Kiran Raj explained. “We believe the most likely vector is the litellm compromise itself,” he added. “TeamPCP’s harvester swept environment variables, .env files, and shell histories from every system that imported litellm. If any developer or CI pipeline had both litellm installed and access to the telnyx PyPI token, that token was already in TeamPCP’s hands. The three-day gap fits the time needed to sift through stolen credentials and pick the next target.” The telnyx PyPI project has since been quarantined. A new malware delivery mechanism Between the LiteLLM and the Telnyx compromises, the group changed some things. For one, the malicious package delivered the encoded malicious payload in the audio frame data of a valid WAV file. Secondly, the malicious packages were smaller than in previous attacks, as the real payload was fetched at runtime from the C2 (which is a “raw” IP address instead of an impersonated domain such as models.litellm.cloud in the LiteLLM attack). When a malicious telnyx package is imported, it executes immediately and retrieves and drops a persistent executable on Windows systems or an information stealer on Linux/macOS systems. The latter is designed to exfiltrate a wide range of sensitive data across systems: SSH keys and configurations; cloud credentials; authentication data from developer tools like Docker, npm, Git, and Vault; database credentials; environment configuration files (to extract embedded secrets like API keys and tokens); shell and database histories; and cryptocurrency wallet data. “If a Kubernetes service account token exists, the malware goes after the entire cluster,” Endor Labs researchers noted. “[It] deploys a privileged pod to every node in kube-system, each mounting the host root filesystem at /host with hostPID, hostNetwork, and privileged: True. The pods chroot into the host to install the persistence implant directly on the node.” Finally, the stolen sensitive data is encrypted and exfiltrated. TeamPCP signatures Analyses of the incident have revealed undisputable links to TeamPCP, who compromised Trivy, LiteLLM, and CheckMarx’s IDE extensions and GitHub Actions in the past week or so. Endor Labs says its attribution is based on multiple overlapping indicators: the use of an RSA-4096 public key previously observed in the LiteLLM PyPI compromise, the use of the same AES-256-CBC + RSA OAEP encryption scheme for data exfiltration, and the presence of specific archive files and headers during data exfiltration that are a TeamPCP signature. The researcher shared indicators of compromise and advised on how to check systems nad logs for them. “Treat any match as a full-environment compromise — rotate all credentials,” they advised. SafeDep and Aikido researchers’ write-ups are also a good source of advice. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

This is the first update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). That report covers the full campaign from the February 28 initial access through the March 24 LiteLLM PyPI compromise. This update covers developments since publication. Checkmarx ast-github-action: All 91 Tags Were Compromised, Not Just v2.3.28 The most significant new finding since the report's publication: the scope of the Checkmarx ast-github-action compromise was substantially larger than publicly reported. Checkmarx's official security advisory stated that "all older versions have been permanently deleted" but did not quantify how many tags were affected. This ambiguity allowed the security community to anchor on a single confirmed version — v2.3.28 — as the extent of the compromise. Sysdig's analysis characterized it as "Checkmarx/ast-github-action/2.3.28: (possibly more)." Even Wiz, which assessed that "it is likely all tags were impacted," only observed the single tag directly. An independent security researcher who was working this incident firsthand at a Checkmarx customer has now provided primary evidence that all 91 published tags were overwritten — every version from v0.1-alpha through v2.3.32. The evidence is publicly visible in the GitHub activity log, which shows 91 tag deletions performed during Checkmarx's remediation between 19:09 and 19:16 UTC on March 23, 2026. Three of the malicious commits are still visible on GitHub: Each malicious commit follows an identical pattern: the legitimate Docker-based action.yml was replaced with a composite action that executes a credential-stealing setup.sh before delegating to the legitimate Checkmarx action at pinned SHA 327efb5d. Each commit was individually crafted with a version-appropriate backdated timestamp and fake commit message (e.g., "2.0.30: PR #"). The attacker did not reuse a single malicious commit across multiple tags — they created individual poisoned commits for individual versions. The impact of this under-reporting is material. Organizations that searched their CI/CD logs only for [email protected] would have missed compromised runs referencing any of the other 90 poisoned tags. The credential stealer executed regardless of which tag version was referenced. Recommended action: Search your CI/CD workflow logs for ANY reference to checkmarx/ast-github-action that executed between 12:58 and 19:16 UTC on March 23, 2026. If found, treat all secrets accessible to that workflow as compromised and rotate immediately. The only safe version is v2.3.33, released during remediation. For comparison, the companion kics-github-action received accurate "all 35 tags" reporting from the outset, largely because GitHub Issue #152 was filed publicly with the title "Malware injected in all Git Tags." No equivalent public issue was filed for ast-github-action. CISA Adds CVE-2026-33634 to Known Exploited Vulnerabilities Catalog CISA has added CVE-2026-33634 (CVSS 9.4) to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation. Federal agencies are required to remediate by April 3, 2026. All organizations using Trivy, trivy-action, or setup-trivy should verify they are running safe versions: Trivy binary: ≥ v0.69.2 trivy-action: v0.35.0 (or pin to SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 ) setup-trivy: v0.2.6 (re-released clean) PyPI Quarantine Lifted; LiteLLM Freezes All Releases PyPI lifted its quarantine of the LiteLLM package on March 25 at 20:15 UTC. Malicious versions 1.82.7 and 1.82.8 have been yanked. However, BerriAI has announced they are pausing all new LiteLLM releases pending a complete supply chain security review. Google's Mandiant has been engaged for forensic analysis. The last known-safe version is v1.82.6.rc.2. Any installation of LiteLLM v1.82.7 or v1.82.8 should be treated as compromised — rotate all credentials that were present as environment variables, in configuration files, or in Kubernetes secrets on the affected system. Community Detection Tools Now Available Two community-developed detection tools are now available: jthack/litellm-vuln-detector — Scans for malicious .pth files, persistence backdoors (~/.config/sysmon/sysmon.py , systemd user services), exfiltration domains (models.litellm.cloud ), and attacker Kubernetes pods (node-setup-* inkube-system ). Community detection gist — Checks for compromised LiteLLM versions and TeamPCP indicators. Run these against your CI/CD runners, developer workstations, and any systems where LiteLLM was installed during the March 24 exposure window. Additional Intelligence TeamPCP Telegram statement: The threat actor posted to their Telegram channel: "These companies were built to protect your supply chains yet they can't even protect their own... we're gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners." Socket.dev characterizes this as confirmation that TeamPCP is deliberately and systematically targeting security tools as a strategy. Wiz publishes third analysis: Wiz Research published "Three's a Crowd: TeamPCP Trojanizes LiteLLM", confirming LiteLLM is present in 36% of cloud environments they monitor. This is the third Wiz blog post covering the campaign arc (Trivy, KICS, LiteLLM). RSA Conference timing: Analysts assess that TeamPCP may have deliberately timed the LiteLLM attack to coincide with RSA Conference, when many security teams had reduced staffing. This assessment, reported by CSO Online, is based on temporal correlation and has not been confirmed by the threat actor or forensic evidence. Parallel campaign — ForceMemo: SecurityWeek reports a separate campaign ("ForceMemo") using credentials stolen via GlassWorm VS Code extensions to force-push malicious code into approximately 150 GitHub Python repositories. This is NOT TeamPCP but demonstrates the breadth of the current supply chain threat landscape. Watch Items Named victim breach disclosures — expected imminently given active extortion Expansion to RubyGems, crates.io, or Maven Central — predicted by Endor Labs but not yet confirmed Aqua Security promised additional findings by end of day March 26 CISA standalone advisory — KEV entry issued, but no dedicated advisory document yet The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast is scheduled at sans.org/webcasts/when-security-scanner-became-weapon.

Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione. Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica. C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale. Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/

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.

A widely used Python package with more than 95 million monthly downloads has been compromised with credential-stealing malware, expanding the ongoing supply chain campaign linked to the TeamPCP threat group. The newly discovered compromise affects the LiteLLM package on PyPI and follows earlier incidents involving the Trivy vulnerability scanner and malicious Docker images distributed through Docker Hub. The compromised LiteLLM versions, 1.82.7 and 1.82.8, were uploaded on March 24, 2026, and contained hidden malware designed to harvest credentials, move laterally across Kubernetes environments and install persistent backdoors. Both malicious versions have since been removed from PyPI, and version 1.82.6 is currently considered the last clean release. Security researchers from Endor Labs said the malicious code executed automatically when certain package components were imported, while the later version introduced a more aggressive mechanism that executed whenever any Python process started in an affected environment. This meant the malware could run silently in the background even if the package was not actively used. Malware Designed For Credential Theft and Persistence Analysis by Jfrog researchers showed the malware operated in three stages, beginning with a hidden payload embedded inside package files. Once triggered, the malware collected sensitive information from the system and attempted to spread across Kubernetes clusters before installing a persistent system service backdoor. The malware collected a wide range of sensitive data, including: SSH keys and configuration files Cloud credentials from AWS, GCP and Azure Kubernetes secrets and configuration files Database credentials and environment files Cryptocurrency wallets TLS and SSL private keys Shell histories and system authentication files The stolen data was encrypted and transmitted to attacker-controlled infrastructure, making detection more difficult and allowing attackers to access compromised environments later through persistent backdoors. Linked to Ongoing TeamPCP Supply Chain Attacks Researchers attributed the compromise to TeamPCP, the same threat group linked to the aforementioned Trivy compromise and subsequent malicious Docker images. The group has been observed running a multi-stage supply chain campaign across several developer ecosystems, including GitHub Actions, Docker Hub, npm, OpenVSX and PyPI. "Given the volume of stolen credentials across likely thousands of downstream environments, expect an increase in breach disclosures, follow-on intrusions, and extortion attempts in the coming weeks," Brett Leatherman, FBI Assistant Director of Cyber Division wrote on LinkedIn earlier today. Investigators believe the attackers are deliberately targeting developer and security tools because they often run with elevated privileges and have access to sensitive credentials and infrastructure. Security experts warned that organizations that installed the affected LiteLLM versions should assume credentials were exposed and rotate all secrets and review systems for signs of compromise.

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

LiteLLM PyPI packages compromised in expanding TeamPCP supply chain attacks A slew of supply chain attacks against popular open source tools and packages appears to have been orchestrated by TeamPCP, a cybercriminal group that rose to prominence in late 2025. The latest victim of the group is BerryAI’s popular LiteLLM library, a unified interface that makes it easier for apps to switch between various LLMs: on March 24, TeamPCP uploaded two compromised versions (1.82.7 and 1.82.8) on PyPI that included a credential stealer and a malware dropper. Callum McMahon, a research scientist at FutureSearch, was the first to raise the alarm, after he loaded the malicious payload and it caused havoc on his local machine. “Because LiteLLM typically sits directly between applications and multiple AI service providers, it often has access to API keys, environment variables, and other sensitive configuration data. Compromising a package in this position allows attackers to intercept and exfiltrate valuable secrets without needing to directly breach upstream systems,” Sonatype researchers noted. “Given the package’s place in the AI stack, cybercriminals are looking to take advantage of enterprises leveraging open source to rapidly develop and deploy AI applications. The design of the malware suggests a broad targeting strategy aimed at developers, cloud environments, and modern application infrastructure.” The malicious LiteLLM versions have since been removed from PyPI. Sonatype advises organizations that installed or executed them to identify and remove the malicious package from affected systems, rotate all potentially exposed credentials (SSH keys, cloud tokens, CI/CD secrets, crypto wallets, etc.), and conduct a thorough investigation to unearth persistence mechanisms and additional payloads dropped during the compromise. “In many cases, rebuilding affected systems from a known clean state may be the safest course of action,” they added. A series of supply chain attacks The compromise of LiteLLM on PyPI was subsequently tied to a compromised maintainer account and malicious workflows pushed by the attackers. The attack followed the same playbook that TeamPCP used to compromise Aqua’s Trivy security scanner and related GitHub Actions (automated tasks) on March 19, and CheckMarx’s VS Code extensions/plugins and GitHub Actions on March 23. Both companies have outlined actions that affected organizations should take and Aqua has confirmed that the compromise happened due to an incomplete containment/remediation of an earlier supply chain attack. “Following the initial disclosure on March 1, credential rotation was performed but was not atomic (not all credentials were revoked simultaneously). The attacker could have used a valid token to exfiltrate newly rotated secrets during the rotation window (which lasted a few days). This could have allowed the attacker to retain access and execute the March 19 attack,” the company explained. Finally, TeamPCP is also believed to have compromised a number of NPM packages, which were equipped with a Python backdoor that downloads and executes “whatever it’s told to”, and a self-propagation tool (worm) for spreading the backdoor further to other NPM packages. And, according to Aikido researchers, they also deployed a Kubernetes node or local machine wiper when the target is (geo)located in Iran. Rami McCarthy, Principal Security Researcher at Wiz, has compiled a timeline of the attacks, which is likely to expand in the coming days. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

The TeamPCP hacking group continues its supply-chain rampage, now compromising the massively popular "LiteLLM" Python package on PyPI and claiming to have stolen data from hundreds of thousands of devices during the attack. LiteLLM is an open-source Python library that serves as a gateway to multiple large language model (LLM) providers via a single API. The package is very popular, with over 3.4 million downloads a day and over 95 million in the past month. According to research by Endor Labs, threat actors compromised the project and published malicious versions of LiteLLM 1.82.7 and 1.82.8 to PyPI today that deploy an infostealer that harvests a wide range of sensitive data. The attack has been claimed by TeamPCP, a hacking group that was behind the recent high-profile breach of Aqua Security's Trivy vulnerability scanner. That breach is believed to have led to cascading compromises that impacted Aqua Security Docker images, Checkmarx KICS project, and now LiteLLM. The group has also been found targeting Kubernetes clusters with a malicious script that wipes all machines when it detects systems configured for Iran. Otherwise, it installs a new CanisterWorm backdoor on devices in other regions. Sources have told BleepingComputer the number of data exfils is approximately 500,000, with many being duplicates. VX-Underground reports a similar number of 'infected devices." However, BleepingComputer has not been able to confirm those numbers independently. LiteLLM supply chain attack Endor Labs reports that threat actors pushed out two malicious versions of LiteLLM today, each containing a hidden payload that executes when the package is imported. The malicious code was injected into 'litellm/proxy/proxy_server.py' [VirusTotal] as a base64 encoded payload, which is decoded and executed whenever the module is imported. Version 1.82.8 introduces a more aggressive feature that installs a '.pth' file named 'litellm_init.pth' [VirusTotal] to the Python environment. Because Python automatically processes all '.pth' files when the interpreter starts, the malicious code would be executed whenever Python is run, even if LiteLLM is not specifically used. Once executed, the payload ultimately deploys a variant of the hacker's "TeamPCP Cloud Stealer" and a persistence script. Analysis by BleepingComputer shows the payload contains virtually the same credential-stealing logic used in the Trivy supply chain attack. "Once triggered, the payload runs a three-stage attack: it harvests credentials (SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and .env files), attempts lateral movement across Kubernetes clusters by deploying privileged pods to every node, and installs a persistent systemd backdoor that polls for additional binaries," explains Endor Labs. "Exfiltrated data is encrypted and sent to an attacker-controlled domain." The stealer harvests a wide range of credentials and authentication secrets, including: System reconnaissance by running the hostname, pwd, whoami, uname -a, ip addr, and printenv commands. SSH keys and configuration files Cloud credentials for AWS, GCP, and Azure Kubernetes service account tokens and cluster secrets Environment files such as .env variants Database credentials and configuration files TLS private keys and CI/CD secrets Cryptocurrency wallet data The cloud stealer payload also includes an additional base64 encoded script that is installed as a systemd user service disguised as a "System Telemetry Service," which periodically contacts a remote server at checkmarx[.]zone to download and execute additional payloads. Stolen data is bundled into an encrypted archive named tpcp.tar.gz and sent to attacker-controlled infrastructure at models.litellm[.]cloud, where the threat actors can access it. Rotate exposed credentials! Both malicious LiteLLM versions have been removed from PyPI, with version 1.82.6 now the latest clean release. Organizations that use LiteLLM are strongly advised to immediately: Check for installations of versions 1.82.7 or 1.82.8 Immediately rotate all secrets, tokens, and credentials used on or found within code on impacted devices. Search for persistence artifacts such as '~/.config/sysmon/sysmon.py' and related systemd services Inspect systems for suspicious files like '/tmp/pglog' and '/tmp/.pg_state' Review Kubernetes clusters for unauthorized pods in the 'kube-system' namespace Monitor outbound traffic to known attacker domains If compromise is suspected, all credentials on affected systems should be treated as exposed and rotated immediately. BleepingComputer has repeatedly covered breaches that stemmed from companies not rotating credentials, secrets, and authentication tokens found in previous breaches. Both researchers and threat actors have told BleepingComputer that while rotating secrets is difficult, it is one of the best ways to prevent cascading supply chain attacks. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

TeamPCP, the threat actor behind the recent compromises of Trivy and KICS, has now compromised a popular Python package named litellm, pushing two malicious versions containing a credential harvester, a Kubernetes lateral movement toolkit, and a persistent backdoor. Multiple security vendors, including Endor Labs and JFrog, revealed that litellm versions 1.82.7 and 1.82.8 were published on March 24, 2026, likely stemming from the package's use of Trivy in their CI/CD workflow. Both the backdoored versions have since been removed from PyPI. "The payload is a three-stage attack: a credential harvester sweeping SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files; a Kubernetes lateral movement toolkit deploying privileged pods to every node; and a persistent systemd backdoor (sysmon.service) polling 'checkmarx[.]zone/raw' for additional binaries," Endor Labs researcher Kiran Raj said. As observed in previous cases, the harvested data is exfiltrated as an encrypted archive ("tpcp.tar.gz") to a command-and-control domain named "models.litellm[.]cloud" via an HTTPS POST request. In the case of 1.82.7, the malicious code is embedded in the "litellm/proxy/proxy_server.py" file, with the injection performed during or after the wheel build process. The code is engineered to be executed at module import time, such that any process that imports "litellm.proxy.proxy_server" triggers the payload without requiring any user interaction. The next iteration of the package adds a "more aggressive vector" by incorporating a malicious "litellm_init.pth" at the wheel root, causing the logic to be executed automatically on every Python process startup in the environment, not just when litellm is imported. Another aspect that makes 1.82.8 more dangerous is the fact that the .pth launcher spawns a child Python process via subprocess.Popen, which allows the payload to be run in the background. "Python .pth files placed in site-packages are processed automatically by site.py at interpreter startup," Endor Labs said. "The file contains a single line that imports a subprocess and launches a detached Python process to decode and execute the same Base64 payload." The payload decodes to an orchestrator that unpacks a credential harvester and a persistence dropper. The harvester also leverages the Kubernetes service account token (if present) to enumerate all nodes in the cluster and deploy a privileged pod to each one of them. The pod then chroots into the host file system and installs the persistence dropper as a systemd user service on every node. The systemd service is configured to launch a Python script ("~/.config/sysmon/sysmon.py") – the same name used in the Trivy compromise – that reaches out to "checkmarx[.]zone/raw" every 50 minutes to fetch a URL pointing to the next-stage payload. If the URL contains youtube[.]com, the script aborts execution – a kill switch pattern common to all the incidents observed so far. "This campaign is almost certainly not over," Endor Labs said. "TeamPCP has demonstrated a consistent pattern: each compromised environment yields credentials that unlock the next target. The pivot from CI/CD (GitHub Actions runners) to production (PyPI packages running in Kubernetes clusters) is a deliberate escalation." With the latest development, TeamPCP has waged a relentless supply chain attack campaign that has spawned five ecosystems, including GitHub Actions, Docker Hub, npm, Open VSX, and PyPI, to expand its targeting footprint and bring more and more systems into its control. "TeamPCP is escalating a coordinated campaign targeting security tools and open source developer infrastructure, and is now openly taking credit for multiple follow-on attacks across ecosystems," Socket said. "This is a sustained operation targeting high-leverage points in the software supply chain." In a message posted on their Telegram channel, TeamPCP said: "These companies were built to protect your supply chains yet they can't even protect their own, the state of modern security research is a joke, as a result we're gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners." "The snowball effect from this will be massive, we are already partnering with other teams to perpetuate the chaos, many of your favourite security tools and open-source projects will be targeted in the months to come so stay tuned," the threat actor added. Users are advised to perform the following actions to contain the threat - Audit all environments for litellm versions 1.82.7 or 1.82.8, and if found, revert to a clean version Isolate affected hosts Check for the presence of rogue pods in Kubernetes clusters Review network logs for egress traffic to "models.litellm[.]cloud" and "checkmarx[.]zone" Remove the persistence mechanisms Audit CI/CD pipelines for usage of tools like Trivy and KICS during the compromise windows Revoke and rotate all exposed credentials "The open source supply chain is collapsing in on itself," Gal Nagli, head of threat exposure at Google-owned Wiz, said in a post on X. "Trivy gets compromised → LiteLLM gets compromised → credentials from tens of thousands of environments end up in attacker hands → and those credentials lead to the next compromise. We are stuck in a loop." Update In a post shared on GitHub and Y Combinator's Hacker News, Berri AI, which maintains litellm, confirmed that the compromise came from a Trivy security scan dependency, urging users to "rotate ALL credentials that were present as environment variables or config files on any system where litellm 1.82.7+ was installed." The Python Packaging Authority (PyPA) has also issued an advisory warning that the malicious versions harvest sensitive credentials and files, and exfiltrate them to a remote server. "Anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate them accordingly," PyPA said. "The affected environment should be isolated and carefully reviewed against any unexpected modifications and network traffic." In what appears to be a further escalation of the campaign, TeamPCP is said to be collaborating with the notorious extortion group LAPSUS$, with Wiz pointing out that the compromise of litellm represents an ecosystem-wide cascade targeting the modern cloud-native and AI stack. Litellm, per the cloud security vendor, is present in 36% of all cloud environments. "We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like LAPSUS$," Ben Read, a lead researcher at Wiz, said in a statement shared with The Hacker News. "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." GitGuardian said the campaign highlights how incomplete cleanup can turn a breach into a wide-ranging campaign impacting multiple ecosystems, underscoring the need for monitoring public GitHub repositories, early alerting, and auditing non-human identities to contain the blast radius. "Teams need to detect exposed credentials quickly, but detection is only the start," GitGuardian researcher Guillaume Valadon said. "They also need to know which machine identities were reachable from that workflow, which of those secrets are still active, what each credential unlocks, and which ones must be rotated first to cut off attacker movement." The development comes as the leader of the group, who went by the alias "DMT," called it quits, stating their work is "largely done" and that they have been "doing this in the midst of a burnout is perpetually making me very mentally unwell which I can't afford right now." They also noted, "This doesn't mean the group is done in any way, they are all very capable, I am just no longer involved." TeamPCP has since also launched an account on X under the handle @pcpcats. "DMT is retiring but the group will continue on strong, we are here to stay,” the group said in an X post. (The story was updated after publication to reflect the latest developments.)

Two more GitHub Actions workflows have become the latest to be compromised by credential-stealing malware by a threat actor known as TeamPCP, the cloud-native cybercriminal operation also behind the Trivy supply chain attack. The workflows, both maintained by the supply chain security company Checkmarx, are listed below - Cloud security company Sysdig said it observed an identical credential stealer as the one used in TeamPCP's operations targeting Aqua Security's Trivy vulnerability scanner and its associated GitHub Actions, about four days after the breach on March 19, 2026. The Trivy supply chain compromise is being tracked under the CVE identifier CVE-2026-33634 (CVSS score: 9.4). "This suggests that the stolen credentials from the Trivy compromise were used to poison additional actions in affected repositories," Sysdig said. The stealer, referred to as "TeamPCP Cloud stealer," is designed to siphon credentials and secrets related to SSH keys, Git, Amazon Web Services (AWS), Google Cloud, Microsoft Azure, Kubernetes, Docker, .env files, databases, and VPNs, along with CI/CD configurations, data from cryptocurrency wallets, and Slack and Discord webhook URLs. Like in the case of Trivy, the threat actors have been found to force-push tags to malicious commits containing the stealer payload ("setup.sh"). The stolen data is exfiltrated to the domain "checkmarx[.]zone" (IP address: 83.142.209[.]11:443) in the form of an encrypted archive ("tpcp.tar.gz"). The new version creates a "docs-tpcp" repository using the victim's GITHUB_TOKEN to stage the stolen data as a backup method if the exfiltration to the server fails. In the Trivy incident, the threat actors used the repository name "tpcp-docs" instead. "The use of vendor-specific typosquat domains for each poisoned action is a deliberate deception technique," Sysdig said. "An analyst reviewing CI/CD logs would see curl traffic to what appears to be the action's own vendor domain, reducing the likelihood of manual detection." The fact that the stealer's primary function is to harvest credentials from CI runner memory allows the operators to extract GitHub personal access tokens (PATs) and other secrets from when a compromised Trivy action executes in a workflow. To make matters worse, if those tokens have write access to repositories that also use Checkmarx actions, the attacker can weaponize them to push malicious code. This, in turn, opens the door to a cascading supply chain compromise, where one poisoned action captures secrets that are used to facilitate the poisoning of other actions. "The identical payload, encryption scheme, and tpcp.tar.gz naming convention confirm this is the same threat actor expanding their reach beyond the initial Trivy compromise," Sysdig noted. "Code review and dependency scanning failed here because the malicious code was injected into a trusted action at the source." According to Wiz, the attack appears to have been carried out via the compromise of the "cx-plugins-releases" service account, with the attackers also publishing trojanized versions of the "ast-results" (version 2.53.0) and "cx-dev-assist" (version 1.7.0) Open VSX extensions. The VS Code Marketplace versions are not affected. Once the extension is activated, the malicious payload checks whether the victim has credentials for at least one cloud service provider, such as GitHub, AWS, Google Cloud, and Microsoft Azure. If any credentials are detected, it proceeds to fetch a next-stage payload from the same domain ("checkmarx[.]zone"). "The payload attempts execution via npx, bunx, pnpx, or yarn dlx. This covers major JavaScript package managers," Wiz researchers Rami McCarthy, James Haughom, and Benjamin Read said. "The retrieved package contains a comprehensive credential stealer. Harvested credentials are then encrypted, using the keys as elsewhere in this campaign, and exfiltrated to 'checkmarx[.]zone/vsx' as tpcp.tar.gz." "On non-CI systems, the malware installs persistence via a systemd user service. The persistence script polls https://checkmarx[.]zone/raw every 50 minutes for additional payloads, with a kill switch that aborts if the response contains "youtube". Currently, the link redirects to The Show Must Go On by Queen." To mitigate the threat, users are advised to perform the following actions with immediate effect - Rotate all secrets, tokens, and cloud credentials that were accessible to CI runners during the affected window. Audit GitHub Actions workflow runs for any references to tpcp.tar.gz, scan.aquasecurity[.]org, or checkmarx[.]zone in runner logs. Search GitHub organization for repositories named "tpcp-docs" or "docs-tpcp," which indicate successful exfiltration via the fallback mechanism. Pin GitHub Actions to full commit SHAs rather than version tags, as tags can be force-pushed. Monitor outbound network connections from CI runners to suspicious domains. Restrict the Instance Metadata Service (IMDS) from CI runner containers using IMDSv2. In an alert issued today, Checkmarx said it's "not aware of any impact to customer data or production environments" as a result of the supply chain security incident, adding it has identified and released new versions of the impacted VS Code extensions. "Only organizations that downloaded the following artifacts from OpenVSX today (3/23/2026) between 02:53 UTC and 15:41 UTC and ran it are potentially impacted by this incident," it said. "We recommend that you continue adhering to your organization's standard incident response procedures, including increased monitoring and validation of development and build environments." In the days following the initial breach, TeamPCP actors have pushed malicious Docker images of Trivy containing the same stealer and hijacked the company's "aquasec-com" GitHub organization to tamper with dozens of internal repositories. They have also been observed targeting Kubernetes clusters with a malicious shell script that wipes all machines when it detects systems matching the Iranian time zone and locale, highlighting a newfound escalation of the group's modus operandi.

The TeamPCP hacking group is targeting Kubernetes clusters with a malicious script that wipes all machines when it detects systems configured for Iran. The threat actor is responsible for the recent supply-chain attack on the Trivy vulnerability scanner, and also an NPM-based campaign dubbed ‘CanisterWorm,’ which started on March 20. Selective destruction payload Researchers at application security company Aikido say that the campaign targeting Kubernetes clusters uses the same command-and-control (C2), backdoor code, and drop path as seen in the CanisterWorm incidents. However, the new campaign differs in that it includes a destructive payload targeting Iranian systems and installs the CanisterWorm backdoor on nodes in other locales. “The script uses the exact same ICP canister (tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io) we documented in the CanisterWorm campaign. Same C2, same backdoor code, same /tmp/pglog drop path,” Aikido says. “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.” According to Aikido researchers, the malware is built to destroy any machine that matches Iran's timezone and locale, regardless if Kuberenetes is present or not. If both conditions are met, the script deploys a DaemonSet named ‘Host-provisioner-iran’ in ‘kube-system’, which uses privileged containers and mounts the host root filesystem into /mnt/host. Each pod runs an Alpine container named ‘kamikaze’ that deletes all top-level directories on the host filesystem, and then forces a reboot on the host. If Kubernetes is present but the system is identified as not Iranian, the malware deploys a DaemonSet named ‘host-provisioner-std’ using privileged containers with the host filesystem mounted. Instead of wiping data, each pod writes a Python backdoor onto the host filesystem and installs it as a systemd service so it persists on every node. On Iranian systems without Kubernetes, the malware deletes every file on the machine, including system data, accessible to the current user by running the rm -rf/ command with the --no-preserve-root flag. If root privileges are not available, it attempts passwordless sudo. On systems where none of the conditions are met, no malicious action is taken, and the malware just exits. Aikido reports that a recent version of the malware, which uses the same ICP canister backdoor, has omitted the Kubernetes-based lateral movement and instead uses SSH propagation, parsing authentication logs for valid credentials, and using stolen private keys. The researchers highlighted some key indicators of this activity, including outbound SSH connections with ‘StrictHostKeyChecking+no’ from compromised hosts, outbound connections to the Docker API on port 2375 across the local subnet, and privileged Alpine containers via an unauthenticated Docker API with / mounted as a hostPath. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

The TeamPCP hackers behind the Trivy supply-chain attack continued to target Aqua Security, pushing malicious Docker images and hijacking the company’s GitHub organization to tamper with dozens of repositories. This follows the threat actor compromising the GitHub build pipeline for Trivy, Aqua Security's scanner, to deliver infostealing malware in a supply-chain attack that extended to Docker Hub over the weekend. Trivy has more than 33,800 stars on GitHub and is widely used for detecting vulnerabilities, misconfigurations, and exposed secrets across software artifacts and infrastructure. Supply-chain security company Socket says in a report on Sunday that it identified compromised Trivy artifacts published to Docker Hub. "New image tags 0.69.5 and 0.69.6 were pushed on March 22 without corresponding GitHub releases or tags," Socket researchers say. According to their analysis, the two images contain indicators of compromise related to the infostealer that TeamPCP pushed after gaining access to Aqua Security's GitHub organization. The researchers note that the last known Trivy release is 0.69.3 and warn that even if they did not see any evidence of older images or binaries being modified after publication, "Docker Hub tags are not immutable, and organizations should not rely solely on tag names for integrity." Breaching AquaSec's GitHub On March 20, Aqua Security said that the threat actor gained access to the company's GitHub organization due to incomplete containment of a previous incident targeting the same tool at the beginning of the month. This allowed the attacker to inject into Trivy credential-harvesting code (TeamPCP Cloud stealer) and publish malicious versions of the tool. Aqua responded to this incident by publishing new, safe versions of Trivy on March 20 and engaging the incident response firm Sygnia to assist them with remediation and forensic investigation. However, via an update published today, Aqua noted that it identified additional suspicious activity on March 22, indicating that the same threat actors have re-established unauthorized access, and performed “unauthorized changes and repository tampering.” The company noted that, despite this new development, Trivy was not impacted at this time. An analysis from OpenSourceMalware, a community-driven malware intelligence platform, explains that TeamPCP gained access to the aquasec-com GitHub organization, where Aqua Security hosts its proprietary code, separate from the company's aquasecurity GitHub organization for public repositories. Using an automation script, it took the hackers about two minutes to add the prefix tpcp-docs- to all 44 repositories available in the company's GitHub organization and change all descriptions to read "TeamPCP Owns Aqua Security." The researchers have high confidence that the attacker gained access by compromising a service account named Argon-DevOps-Mgt, which had access to both of Aqua Security's GitHub organizations. According to OpenSourceMalware, the targeted service account authorized actions based on a Personal Access Token (PAT) of a standard user instead of a GitHub App. The issue is that PAT authentication functions like a password and is valid for a longer period than the token of a GitHub App. Additionally, a service account is typically used for automated tasks and does not have multi-factor authentication (MFA) protection. To test that the account had admin permissions for AquaSec's both public and private GitHub organizations, TeamPCP created a new update-plugin-links-v0.218.2 branch in the public aquasecurity/trivy-plugin-aqua repository, which they then deleted "at the exact same second." The researchers believe that hackers obtained the PAT for the Argon-DevOps-Mgt service account using the TeamPCP Cloud stealer, which collects GitHub tokens, SSH keys, cloud credentials, and environment variables from CI runners. "As a service account that triggers workflows on trivy-plugin-aqua, its token was present in the runner environment," OpenSourceMalware explains. OpenSourceMalware has provided a set of indicators of compromise that can help defenders determine if their environments have been impacted by the supply-chain attack. Aqua Security says that it has no evidence that the Trivy version used in its commercial products has been impacted. "By design, the forked version of Aqua’s commercial platform lags Trivy open source with a controlled integration process." However, the company promised to share updates as new details emerge and publish additional findings on Tuesday, at the end of the day. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A threat actor compromised Aqua Security’s Trivy open source vulnerability scanner in a supply chain attack that started in late February. On March 1, Trivy’s maintainers announced that the scanner’s GitHub repository had been compromised in an attack involving a GitHub Actions workflow issue. Some releases were deleted, and malicious versions of the application’s VS Code extensions were published to the Open VSIX marketplace. The attack was part of a larger, automated attack campaign that hit multiple open source repositories via GitHub Actions workflows and resulted in a large natural-language prompt being injected into two malicious versions of Trivy’s VS Code extension. Credentials exfiltrated during the initial incident were used last week in a new supply chain attack that targeted not only the Trivy package but also trivy-action and setup-trivy, Trivy’s maintainers have confirmed in a March 21 advisory. “Following the initial disclosure on March 1, credential rotation was performed, but was not atomic (not all credentials were revoked simultaneously). The attacker could have used a valid token to exfiltrate newly rotated secrets during the rotation window (which lasted a few days),” the maintainers explain. The attackers used the compromised credentials to push a malicious Trivy release (version v0.69.4) that was distributed across all regular channels, including GitHub Container Registry, Amazon ECR Public, and Docker Hub. They also force-pushed 76 of 77 trivy-action version tags to malicious commits, leading to infections with an information stealer designed to dump the Runner.Worker process memory and extract all secrets from it. The malware was also designed to encrypt the harvested data and send it to a remote server. If the exfiltration failed, it created a public GitHub repository and uploaded the data to it. Additionally, the attackers targeted the setup-trivy releases, force-pushing all tags to malicious commits, leading to the same infostealer. Socket and Wiz published technical details on the attack and the malware. Ongoing attack According to Aqua, none of its commercial products that use Trivy have been affected by the attack, as “the forked version of Aqua’s commercial platform lags Trivy open source with a controlled integration process.” On Monday, the company warned that the attack is ongoing and evolving, with suspicious activity identified on March 22, “involving unauthorized changes and repository tampering”. “Based on our current understanding, this activity is consistent with the attacker’s previously observed behavior. Our investigation is actively focused on validating that all access paths have been identified and fully closed,” Aqua said. Trivy’s maintainers released clean iterations of Trivy (versions v0.69.2 and v0.69.3), trivy-action (v0.35.0), and setup-trivy (v0.2.6). Because the original trivy-action tags were deleted during remediation, new tags with a v prefix were published. They urge all users to rotate all credentials, tokens, and other secrets if a compromised version of Trivy, trivy-action, or setup-trivy ran on their environments. “Check whether your organization pulled or executed Trivy v0.69.4 from any source. Remove any affected artifacts immediately. Look for repositories named tpcp-docs in your GitHub organization. The presence of such a repository may indicate that the fallback exfiltration mechanism was triggered and secrets were successfully stolen,” the maintainers note. TeamPCP’s CanisterWorm campaign The attack has been linked to a threat actor named TeamPCP, which has expanded its activity following the Trivy compromise, targeting the NPM ecosystem with the CanisterWorm malware. Last week, Aikido reported that TeamPCP compromised over 45 NPM packages, injecting them with a post-install loader that fetches a persistent Python backdoor, enabling dynamic payload delivery via an ICP canister used for command-and-control (C&C) dead-drop. CanisterWorm, the security firm says, can extract NPM tokens, resolve usernames, enumerate published packages, create new package versions, and publish the payload across all of them. It also establishes persistence, contains evasion capabilities, masquerades as PostgreSQL tooling, polls the ICP canister every 50 minutes, and can be disarmed by pointing the canister to a YouTube link. “If the attacker updates the canister to point to a new URL, every infected machine picks up the new binary on its next poll. The old binary keeps running in the background since the script never kills previous processes,” Aikido explains. The infected packages contain a standalone self-propagating tool that appears to be entirely vibe-coded and does not use obfuscation, and which uses stolen tokens to spread the malicious payload across packages. Financially motivated, TeamPCP emerged in late 2025, targeting cloud-native infrastructure via exposed CI/CD pipelines, Docker APIs, and Kubernetes clusters. The threat actor is known for mounting supply chain attacks and for leveraging credentials stolen from cloud workloads and GitHub Actions runners via memory scrapers. Related: ForceMemo: Python Repositories Compromised in GlassWorm Aftermath Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea Related: New ‘Sandworm_Mode’ Supply Chain Attack Hits NPM Related: Over 100 GitHub Repositories Distributing BoryptGrab Stealer

Cybersecurity researchers have uncovered malicious artifacts distributed via Docker Hub following the Trivy supply chain attack, highlighting the widening blast radius across developer environments. The last known clean release of Trivy on Docker Hub is 0.69.3. The malicious versions 0.69.4, 0.69.5, and 0.69.6 have since been removed from the container image library. "New image tags 0.69.5 and 0.69.6 were pushed on March 22 without corresponding GitHub releases or tags. Both images contain indicators of compromise associated with the same TeamPCP infostealer observed in earlier stages of this campaign," Socket security researcher Philipp Burckhardt said. The development comes in the wake a supply chain compromise of Trivy, a popular open-source vulnerability scanner maintained by Aqua Security, allowing the threat actors to leverage a compromised credential to push a credential stealer within trojanized versions of the tool and two related GitHub Actions "aquasecurity/trivy-action" and "aquasecurity/setup-trivy." The attack has had downstream impacts, with the attackers leveraging the stolen data to compromise dozens of npm packages to distribute a self-propagating worm known as CanisterWorm. The incident is believed to be the work of a threat actor tracked as TeamPCP. According to the OpenSourceMalware team, the attackers have defaced all 44 internal repositories associated with Aqua Security's "aquasec-com" GitHub organization by renaming each of them with a "tpcp-docs-" prefix, setting all descriptions to "TeamPCP Owns Aqua Security," and exposing them publicly. It's worth noting that the "aquasec-com" account is distinct from the cloud security vendor's other well-known GitHub organization account, "aquasecurity," which hosts the impacted Trivy scanner and GitHub Actions, along with various open-source projects. The newly compromised organization contains proprietary source code, including source code for Tracee, internal Trivy forks, CI/CD pipelines, Kubernetes operators, and team knowledge bases. All the repositories are said to have been modified in a scripted 2-minute burst between 20:31:07 UTC and 20:32:26 UTC on March 22, 2026. It's been assessed with high confidence that the threat actor leveraged a compromised "Argon-DevOps-Mgt" service account for this purpose. "Our forensic analysis of the GitHub Events API points to a compromised service account token — likely stolen during TeamPCP's prior Trivy GitHub Actions compromise — as the attack vector," security researcher Paul McCarty said. "This is a service/bot account (GitHub ID 139343333, created 2023-07-12) with a critical property: it bridges both GitHub orgs." "One compromised token for this account gives the attacker write/admin access to both organizations," McCarty added. The development is the latest escalation from a threat actor that's has built a reputation for targeting cloud infrastructures, while progressively building capabilities to systemically exposed Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers to steal data, deploy ransomware, conduct extortion, and mine cryptocurrency. Their growing sophistication is best exemplified by the emergence of a new wiper malware that spreads through CanisterWorm, as well as by exploiting SSH via stolen keys and exposed Docker APIs on port 2375 across the local subnet. The new "kamikaze" wiper attributed to TeamPCP has been found to go beyond credential theft to wiping entire Kubernetes (K8s) clusters located in Iran. The shell script uses the same ICP canister linked to CanisterWorm and then runs checks to identify Iranian systems. "On Kubernetes: deploys privileged DaemonSets across every node, including control plane," Aikido security researcher Charlie Eriksen said. "Iranian nodes get wiped and force-rebooted via a container named 'kamikaze.' Non-Iranian nodes get the CanisterWorm backdoor installed as a systemd service. Non-K8s Iranian hosts get 'rm -rf / --no-preserve-root.'" Eriksen told The Hacker News it's currently not known if TeamPCP is also behind the "hackerbot-claw" incident that led to the breach of Trivy earlier this month. Given the ongoing nature of the attack, it's imperative that organizations review their use of Trivy in CI/CD pipelines, avoid using affected versions, and treat any recent executions as potentially compromised. "This compromise demonstrates the long tail of supply chain attacks," OpenSourceMalware said. "A credential harvested during the Trivy GitHub Actions compromise months ago was weaponized today to deface an entire internal GitHub organization. The Argon-DevOps-Mgt service account — a single bot account bridging two orgs with a long-lived PAT — was the weak link." "From cloud exploitation to supply chain worms to Kubernetes wipers, they are building capability and targeting the security vendor ecosystem itself. The irony of a cloud security company being compromised by a cloud-native threat actor should not be lost on the industry. Update In a formal update shared on March 23, 2026, Aqua Security said its investigation is "actively focused on validating that all access paths have been identified and fully closed," adding there is no indication its commercial products were impacted by the incident. The attack is now being tracked under the CVE identifier CVE-2026-33634 (CVSS score: 9.4). "The mechanics here weren't novel. The attacker, with write access to the repository, force-pushed tags to a new commit containing a modified entry point and relied on the fact that most workflows reference actions by tag," CrowdStrike said. "For a defender, the takeaway is to pin your actions by committing SHA, monitor your CI/CD runners with the same rigor as production hosts, and treat any code that runs in your pipeline as code that runs in your infrastructure." (The story was updated after publication on March 25, 2026, with additional insights from Aikido.)