devopsy.kinsta.cloud

Tag: AI supply chain attacks

LiteLLM Attack Affected 2,500 Companies, 434,000 CI/CD Pipelines: CloudSEK

The massive supply-chain attack that compromised LiteLLM in the spring affected more than 2,500 companies and exposed about 434,000 CI/CD pipelines, with victims ranging from top-tier IT and AI companies to cybersecurity firms, SaaS, and enterprises.

It rolled up a lot of victims, but also was a high-profile example of the growing trend of threat actors targeting companies’ AI infrastructure layer that is increasingly becoming connected to everything within their environments, according to CloudSEK threat researchers.

The March attack on LiteLLM, a gateway and toolkit that lets developers call more than 100 large language model (LLM) providers – including Anthropic, Google’s Gemini, and Amazon Web Services’ (AWS’) Bedrock – was the result of the threat group TeamPCP earlier that month compromising Aqua Security’s Trivy open source security vulnerability scanner and its associated GitHub Actions.

LiteLLM was compromised by TeamPCP but never directly attacked, according to CloudSEK’s researchers. Instead, LiteLLM became part of a much broader campaign by the threat group after its CI pipeline installed the compromised Trivy scanner, leading to the publishing of releases 1.82.7 and 1.82.8 that included malicious code to the Python Package Index (PyPI) repository.

“Trivy, then the build system, then the LiteLLM release: one un-revoked token, three tools deep,” the CloudSEK researchers wrote in a report. “That chain is what turns a single credential leak into ecosystem-wide exposure.”

Only 40 Minutes Were Needed

The two malicious LiteLLM packages remained on PyPI for about 40 minutes, but within that time, the damage was done. The researchers noted that automated build systems can compress time and that once an artifact containing malicious code gets into a registry, it can get copied quickly in scheduled jobs, dependency resolvers, developer laptops, and other tools.

Given that, the threat remains even after the packages are removed, a key reason behind CloudSEK publishing the lists of compromised companies and affected pipelines.

“We are sharing this openly so that every affected organization can act proactively,” they wrote, adding that the “threat is still live. … Early awareness is the strongest defense; knowing you were impacted lets you rotate credentials, close the exposure, and harden before the next campaign hits.”

Widespread Compromise

The warning echoes an advisory issued by the FBI in July, which pointed to the TeamPCP’s compromise of “supply chain entry points” that not only included Trivy and LiteLLM, but also KICS – an open source code analysis tool created by Checkmarx – and the Telnyx Python SDK.

“These tools are commonly integrated into enterprise development continuous integration (CI)/continuous delivery (CD) pipelines, cloud infrastructure, and security workflows,” the FBI wrote. “By weaponizing these supply chain entry points, the threat actors were able to introduce malicious code into victim environments at scale.”

The agency also wrote that TeamPCP has collaborated with other threat groups and run extortion campaigns – publishing victim names on leak sites and threatening to disclose stolen data – and urged victim organizations to “treat exfiltrated data and credentials as a persistent risk, as affiliated threat actors are likely to weaponize them long after the initial compromise.”

Stealing Credentials, API Keys, and Other Info

The malware distributed by TeamPCP included CanisterWorm, which harvests such sensitive information as cloud access tokens, credentials, API keys, and similar authentication material for cloud services like AWS, Google Cloud Platform, and Microsoft Azure, and SandClock, another info-stealer that targets AWS credentials, Kubernetes service account tokens, and cryptocurrency wallet data.

There’s also Mini Shai-Hulud, a self-replicating worm that targets npm and PyPI repositories for supply chain attacks, and Miasma, a Shai-Hulud variant that also self-propagates across npm and PyPI stealing credentials and damaging configuration files.

“The loot was encrypted and shipped to a typosquatted domain,” the researchers wrote. “Where exfiltration failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the stolen data there as a release asset, meaning some organizations were leaking their own secrets into public view without knowing it.”

High-Profile Victims

The CloudSEK Threat Intelligence unit was able to access a dataset holding the information of victims, according to the researchers. The list includes a large number of well-known companies, including such tech, cloud, and SaaS companies as Nvidia, Intel, Zscaler, AWS, Cisco Systems, Salesforce, and ServiceNow.

There also are numerous enterprises outside of IT, from John Deere and Airbus U.S. to FedEx, Volkswagen, Bayer, and Deloitte.

The researchers cautioned that the company and pipeline numbers just refer to exposure to the threat, not necessarily that they’ve been compromised.

Targeting AI Infrastructure

They also expect that AI infrastructure will increasingly become a target of cybercriminals, noting that such systems are becoming key junctions between data, identity, compute, and autonomous action. This trend would echo what’s happened in the past.

“In the industrial age, rail junctions became strategic targets because many supply routes met at one point,” the researchers wrote. “AI gateways, agent runtimes, MCP servers, and vector stores are becoming the junctions of digital operations. The [LiteLLM] incident was not only a software supply chain breach that happened to involve an AI product. It demonstrated that compromising an AI control point can expose the identities and systems around it.”

August 12, 2026
North Korea Expands the Reach of PolinRider Supply Chain Attack Campaign

The North Korean-sponsored threat groups behind the long-running fake interview scams targeting developers are expanding the PolinRider supply chain campaign that has escalated over the past several months.

Reports from cybersecurity vendors Socket and Rescana found that two groups linked to the Democratic People’s Republic of Korea (DPRK) have published at least 108 malicious packages and browser extensions across a range of open source ecosystems, from npm and Packagist to Go modules and Google’s Chrome Store.

The attackers aim to compromise legitimate developer accounts and repositories by placing malware loaders into popular packages that establish command-and-control (C2) systems and then deploy payloads designed to steal credentials and exfiltrate source code, as well as move laterally throughout a developer’s environment, according to Rescana researchers.

“The campaign is ongoing, with new malicious artifacts surfacing regularly, posing a critical risk to organizations and individuals relying on open-source software for development and production environments,” the researchers wrote.

Famous Chollima and APT37

The PolinRider campaign is attributed to Famous Chollima – the North Korean nation-state actor that appears to be a subset of the DPRK’s high-profile Lazarus Group and is linked to the complex Contagious Interview scam – and APT37, also known as Reaper or ScarCruft.

In the Contagious Interview campaign – which dates back at least three years – Famous Chollima targets software developers and those working in crypto by using fake job advertisements on sites like LinkedIn and GitHub and interviews to trick victims into installing malware onto their systems and running malicious code. The malware variants used in the campaign include BeaverTail, InvisibleFerret, and OtterCookie.

In the ongoing PolinRider campaign, the steps the groups take is consistent, according to Socket security researcher Karlo Zanki. The bad actors drop highly obfuscated JavaScript loaders into repositories and hide the code through various means, including whitespace padding – where attackers add hundreds or thousands of black spaces to push malicious payloads off-screen – or fake .woff2 font files, deceptive files that masquerade as legitimate Web Open Font Format (WOFF2) web assets that hide loaders or encrypted data.

They use developer tools like VS Code task files to trigger the execution of the malware and Git history rewriting to make malicious changes to code seem older and, therefore, less suspicious.

“This makes the GitHub landing page and visible commit history unreliable indicators of compromise; defenders should review repository activity logs, package release metadata, VS Code task configuration, and suspicious changes to configuration files,” Zanki wrote in a report.

Second-Stage Payloads

The malware loader grabs next-stage payloads from blockchain and public Remote Procedure Call (RPC) infrastructure like TRON, Aptos, and BNB Smart Chain services. The payload, such as DEV#POPPER remote access trojan (RAT) and Python-based OmniStealer, is decrypted with embedded XOR keys and executed.

Zanki warned that because the malware is loader-based, the bad actors could use it to deliver other malicious code.

The campaign is having far-reaching effects, according to Rescana. Malicious packages not only have been published, but some also have been integrated into legitimate projects that have led to infections downstream, a key goal of any supply chain attack. The researchers pointed to some npm packages – including tailwindcss-style-animate, tailwind-mainanimation, and tailwind-autoanimation – Go modules, and PHP packages within the sevenspan namespace on Packagist.

Socket’s Zanki pointed to the Xpos587 GitHub account as another example. Several repositories that are maintained by the account were modified at the same time on June 23, with the researcher noting that such a “synchronized update pattern is unlikely to reflect normal maintainer activity and is consistent with account-level compromise followed by bulk repository modification.”

Downstream Impacts

There have been a range of victims, including developers, open source projects, and companies with automated CI/CD pipelines that use dependencies from public registries, with the damage being stolen credentials and other sensitive data and unauthorized access to source code repositories, according to Rescana.

It’s clear that the North Korean groups are aiming for their campaigns to reach deep downstream, hoping to rack up more victims via transitive dependencies and automated builds. Rescana researchers also noted that CI/CD environments – which have become attractive targets of threat actors – are at a high risk from PolinRider because they rely so much on automated dependency resolution and given the level of lateral movement the bad actors can gain within an organization’s networks.

New malicious packages and extensions are emerging every week, illustrating the persistent threat PolinRider represents, Rescana wrote.

July 8, 2026
Widespread Mini Shai-Hulud Campaign Is a Matter of Trust

The latest series of attacks using the notorious Shai-Hulud worm puts into sharp focus the threats facing software developers and their CI/CD pipelines, an issue that has been raised in recent months as bad actors increasingly turn their attention to DevOps environments.

That said, these most recent Shai-Hulud incidents attributed to the TeamPCP group also reflect the trend toward abusing trust, a key point given the extensive connectivity between corporate ecosystems and development platforms.

“Shai-Hulud should be understood less as a one-off package compromise and more as an evolving supply-chain playbook,” said Jonathan Stross, SAP security analyst at Pathlock.

Earlier waves of Shai-Hulud attacks in 2025 and this year focused on stealing developer and maintainer credentials and using them to publish more malicious packages. In the latest incidents – referred to as “Mini Shai-Hulud” – the threat group abused trusted CI/CD publishing paths and OpenID Connect (OIDC) tokens, meaning that malicious package versions still carried valid provenance attestations.

“In other words, some of the signals defenders increasingly rely on to establish trust were present, even though the package content was malicious,” Stross said.

Chuck Randolph, senior vice president for strategic intelligence and security at 360 Privacy, said organizations, their development teams, and code repositories need to recognize and prepare for such campaigns, which build on the trend over the past several years to abuse identities.

“Modern attacks increasingly exploit trust rather than simply targeting vulnerabilities,” Randolph said. “Whether it is software ecosystems, digital identities, or interconnected platforms, adversaries are learning to weaponize trusted relationships to gain speed, scale, and operational access.”

Broad Exposure

What organizations need to take away from all this is that “the attack surface is no longer limited to a single system or user,” he added. “Exposure now exists across entire ecosystems, where one compromised relationship, credential, or trusted platform can create cascading downstream effects. The broader lesson is that digital exposure and operational risk are becoming increasingly interconnected.”

Researchers with a number of security firms, including Endor Labs, Aikido, Socket, and StepSecurity, wrote reports in recent days outlining the latest round of attacks that involve compromised npm and PyPI packages from a range of companies, including Mistral AI, Guardrails AI, TanStack, and UiPath.

TeamPCP emerged last year, targeting cloud-native environments with automated supply-chain attacks that plant malware into software updates that infect organizations that download them. In this campaign, the threat actors acquired broad permission in GitHub Actions workflows and made their payload appear to be an initialization module.

Stealing Credentials and Secrets

An obfuscated JavaScript file planted in the npm packages looks for secret files and SSH keys and steals credentials – including security keys and passwords – and targets high-profile cloud players like Google Cloud Platform, Amazon Web Services, HashiCorp Vault, and Kubernetes, as well as AI tools, messaging apps, and cryptocurrency wallets.

In line with other TeamPCP attacks, the malware creates a ransom note and threatens to wipe the computer of its data if the victim tries to revoke the compromised access.

Jason Soroko, Senior Fellow at Sectigo, noted that the “latest wave adopts a stealthier execution model. By bundling a JavaScript payload within the package tarball and utilizing an optional GitHub dependency to trigger execution via the Bun runtime, the attackers bypass traditional static scanning.”

Same Goals, Bigger Scale

Aikido security researcher Raphael Silva wrote in a report that the vendor’s malware team detected 737 malicious package-version entries across 169 npm package names. The campaign echoes another one involving Shai-Hulud last month that targeted SAP packages.

“The basic goal is still the same: steal credentials from developer machines and CI/CD runners, then use those credentials to reach more packages,” Silva wrote. “What changed is the scale and the release path. This wave does not just look like someone manually publishing bad versions. The malware is built to run inside build systems, steal npm and GitHub access, and abuse trusted publishing paths to push new compromised packages. … This is the follow-up: the same idea, but with a much bigger blast radius.”

‘The Worm is Iterating’

Peyton Kennedy, security researcher with Endor Labs, wrote that Mini Shai-Hulud is not only getting larger, but also more technically sophisticated with each campaign. For example, the four SAP packages in two weeks became 84 TanStack packages and the static-token and OIDC branch-push vectors in the SAP campaign now include “a new orphaned-commit-through-a-fork technique that bypasses branch protection rules while still yielding a legitimate OIDC-derived publish token,” Kennedy wrote.

“The underlying truth of this campaign arc remains unchanged: provenance tells you where a package was built, not whether the build was authorized,” he wrote. “OIDC trusted publishing removes the need for long-lived tokens, but introduces a new trust surface — the scope of what workflows and commits can request those tokens. Narrowing that scope to the minimum required is the control that closes this class of attack.”

“The worm is iterating. Defenders need to as well,” Kennedy wrote.

May 15, 2026
Sophisticated Supply Chain Attack Targeting Trivy Expands to Checkmarx, LiteLLM

The supply chain attack that compromised Aqua Security’s Trivy open source security vulnerability scanner and its associated GitHub Actions earlier this month continues to expand, with software development tools from Checkmarx and LiteLLM being the latest victims of the sophisticated campaign.

The threat group behind it, TeamPCP, is using the attacks to create persistence and to steal credentials and sensitive digital keys from organizations.

“The TeamPCP stealer’s primary function is harvesting credentials from CI runner memory,” Sysdig threat researchers wrote. “When a compromised Trivy action executes in a workflow, it extracts GitHub personal access tokens (PATs) and other secrets from the Runner.Worker process memory. If those tokens have write access to repositories that also use Checkmarx actions, the attacker can use them to push malicious code to additional action dependencies.”

The researchers added that such action “creates a cascading supply chain compromise: One poisoned action harvests credentials that enable poisoning of additional actions, each using a different typosquat domain to avoid pattern-based detection.”

A Moving Target

Damon Small, a board member with security firm Xcape, said that “the risk here is a ‘wormable’ supply chain: the malware scrapes runner memory for GitHub PATs and cloud keys, which it then uses to compromise any other repositories that the infected pipeline has write access to. For defenders, the priority isn’t just updating Trivy; it is a scorched-earth credential rotation.”

Small added that “it takes a special kind of irony for a vulnerability scanner to become the primary infection vector for your entire cloud environment.”

Organizations with pipelines that ran a Trivy scan between March 19 and 23 need to assume that every secret that was accessible through the scans – from Amazon Web Services (AWS) keys to npm tokens to SSH keys – has been stolen, Small said.

“Moving forward, security teams must enforce the pinning of all third-party GitHub Actions to full 40-character commit hashes to prevent this ‘silent’ tag-swapping from recurring,” he said.

Incomplete Containment an Issue

According to Wiz researchers, TeamPCP actors were able to launch the multi-faceted attack through access gained via the “incomplete containment of an earlier incident,” pushing credential stealer code from a typosquatted domain into Trivy and publishing “backdoored binaries … to GitHub Releases, Docker Hub, GHCR, and ECR. The maintainers have since removed these malicious artifacts.”

Palo Alto Networks researchers noted that “incomplete containment is a recurring issue in incident response. When breaches are not fully addressed, they create the conditions for the next attack.” That was the case with Trivy.

The Python-based payload harvested not only credentials from cloud providers AWS, Google Cloud Platform, and Microsoft Azure, but also Kubernetes secrets, CI/CD and application secrets, infrastructure and access information, and cryptocurrency, according to Microsoft’s Defender Security Research Team.

Keeping Under the Radar

The attackers were able to pose as legitimate developers, and according to Microsoft, “after exfiltration, the malware cleaned up all temporary files and launched the legitimate Trivy scan. The workflow completed successfully with expected output, masking the compromise from pipeline operators.”

The persona impersonation tactics used by the TeamPCP attackers were similar to what Microsoft researchers saw in the Shai-Hulud 2.0 campaign.

Suzu Labs CTO Denis Calderone said security teams need to pay attention to TeamPCP’s technical execution.

“Stolen credentials from a misconfigured GitHub Actions workflow gave the attackers access to push malicious code into 75 of 76 version tags,” Calderone said. “The payload ran inside CI/CD pipelines, silently collecting GitHub tokens, cloud credentials, SSH keys, Kubernetes tokens, database passwords, and crypto wallets from every pipeline that pulled the compromised version. CI/CD runners hold the keys to everything, so compromising the pipeline is effectively compromising every environment that pipeline touches.”

After the Trivy compromise, TeamPCP was able to expand its reach into Checkmarx’s KICS open static code analysis tool and LiteLLM, an open source AI gateway that offers a unified API that is compatible with OpenAI and use to call more than 100 large language model (LLM) provides, including OpenAI, Azure, AWS’s Bedrock, and Google Cloud Platform.

TeamPCP Worms Its Way In

The expansion to other victims was accomplished through CanisterWorm, which TeamPCP launched by using stolen credentials, according to Palo Alto researchers. The worm compromised more than 45 npm packages across various scopes.

“Later variants added token theft and malicious publishing in the postinstall hook, making every developer or CI pipeline that installed an affected package an unwitting propagation vector,” they wrote. “Twenty-eight packages were compromised in under 60 seconds.”

The CanisterWorm component caught the attention of Suzu Labs’ Calderone.

“This is the first documented malware to use blockchain for command and control,” Calderone said. “Instead of traditional C2 servers that can be seized or sinkholed, the attackers are using smart contracts as a decentralized dead-drop. There’s no single server to take down, no domain to block. The operator can rotate payloads on-chain without ever touching an infected host.”

He called it “a fundamental shift in how attackers maintain persistence and control, and if this model proves out, it’s going to change how we think about disrupting campaigns.”

Targeting Open Source, AI Development

Sonatype researchers noted the targeting of LiteLLM, writing that the attackers 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.”

Kubernetes environments are getting attention from the bad actors, but the data being collected is intentionally expansive, targeting any system that can store credentials or interact with cloud services.

“This makes the software supply chain attack especially dangerous in environments where developers, CI/CD systems, and production infrastructure share access to sensitive credentials, as compromise in one layer can quickly cascade into others,” they wrote.

March 25, 2026
Three Encryption Resolutions for DevSecOps in 2026

It’s almost the New Year, and naturally, many people are looking to make their resolutions to improve their processes as we advance.

For DevSecOps teams, which focus on the software development lifecycle, they will want to take greater steps to significantly improve the security of their pipelines in the wake of the growing number of supply chain attacks.

In June, dark web monitoring company Cyble reported that 79 cyberattacks with “supply chain implications” took place in the first five months of 2025. Of those, at least half targeted IT, technology providers, and Telco providers. Looking back further to the period between September 2024 and February 2025, while there were slightly fewer than 13 attacks each month, just a short time later, in the period between October 2024 and May 2025, the figures grew to 16 per month.

Then you have AI, which is being implemented by cyber criminals to expand operations and better prey on their victims. A recent article in The Hacker News stated that “AI-enabled supply chain attacks are exploding in scale and sophistication – Malicious package uploads to open-source repositories jumped 156% in the past year.”

With these facts in mind, it’s reasonable to assume that the people protecting the supply chain will have to do better next year, or cyber criminals will continue to see rising success.

Reducing Supply Chain Attacks

There are many steps DevSecOps teams could take to reduce the chances of a security incident that may lead to a supply chain attack. This includes utilizing tools for dependency scanning, continuous monitoring, threat detection, and automated security testing.

In addition, DevSecOps must also consider the critical role that Public Key Infrastructure (PKI) plays.

PKI is critical for DevSecOps because it establishes trust and ensures the integrity of the software code throughout the development and deployment pipeline. PKI-based digital certificates – Code Signing Certificates in the case of DevSecOps – enable digital signing of source code; building artifacts and container images, guaranteeing authenticity and preventing tampering. It also secures communication between systems and services through encryption and certificate-based authentication, which reduces the risk of unauthorized access. In addition, by verifying signatures and enforcing trusted identities, PKI helps prevent supply chain attacks and supports compliance with security standards.

DevSecOps Haven’t Always Relied on PKI

The reality is that the DevSecOps process has not always utilized PKI-backed certificates. Instead, they have historically opted for self-signing certificates as they were viewed as still being reliable, while also being more economical and able to be created very quickly.

With the increase in volume and complexity of cyberattacks targeting the software supply chain, there is a high degree of likelihood that organizations will have no choice but to expand their utilization of Trusted Digital Certificates. In fact, Mordor Intelligence predicts that the Code Signing Certificate market could reach $50.3M by 2029.

With that in mind, here are GlobalSign’s top new year resolutions we suggest for DevSecOps teams.

1. I Will End My Reliance on Self-Signed or Unapproved Certificates

Under pressure to meet deadlines, teams sometimes bypass PKI by creating self-signed certificates or using certificates that are not trusted. This creates compliance issues and exposes systems to man-in-the-middle attacks. The negative results of this approach speak for themselves.

2. I Will Stop Using Manual Processes for Certificate Lifecycle Management

Many teams still rely on manual steps to request, issue, and deploy certificates. This slows down CI/CD pipelines and introduces human error. This can result in increased risk of expired certificates, or even outages that make websites unusable, and product use comes to a standstill.  Automating your certificates is the best way forward to successfully manage them.

3. I Will Pay Closer Attention to Certificate Industry Rules & Regulations

On March 1, 2026, per the CA/B Forum – the PKI industry’s main governing organization – Code Signing Certificate validity will be limited to a maximum of 460 days. These changes will impact security strategies, compliance, and operational workflows across industries. If you are using Code Signing Certificates but not taking steps to ensure they meet these new standards, your company could experience numerous issues – and be non-compliant. Why take that risk?

Hopefully, the coming year will bring a reduction in supply chain attacks. This is a goal that’s more than achievable if the proper tools and practices are put in place and maintained by the DevSecOps community to keep code secure. Keeping watch on industry rules and regulations, ending reliance on outdated practices, and automating your tools will be especially important. You can choose from a variety of vendors to get your PKI in place to properly protect your code, to ensure your code security is rock solid, and can keep cyber criminals at bay.

December 19, 2025