A supply-chain attack involving the open-source LiteLLM framework potentially exposed more than 2,500 organizations worldwide, according to research from cybersecurity firm CloudSEK.
CloudSEK described the incident as the largest supply-chain attack targeting AI infrastructure identified so far in 2026. Orchestrated by the Team PCP threat actor group in March 2026, the attack affected approximately 434,000 CI/CD pipelines, which are automated workflows that build, test and deploy software code.
The affected software packages were reportedly available for approximately 40 minutes, but the potential consequences extend well beyond that window.
CloudSEK warned:
“The threat is still live: the FBI’s July 2026 FLASH advisory (FLASH-20260702-01) warns that affiliated actors are likely to weaponize the harvested credentials long after the original intrusion, which means further supply chain attacks remain a real possibility.”
The attack “highlights how compromised AI dependencies can create enterprise-wide security exposure,” the company added.
Malicious Packages Expose Cloud and AI Credentials
CloudSEK found that the compromised packages could expose AWS, Google Cloud and Azure credentials, SSH keys, Kubernetes tokens, CI/CD secrets, package publishing credentials and environment variables.
The researchers also identified potential access to large language model API keys and gateway configurations for AI workloads.
Where the attack failed to extract data, CloudSEK said:
“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.”
CloudSEK also warned that removing the malicious packages does not necessarily end the incident.
“Removal does not end the incident,” the company noted, adding that “a package can disappear in minutes while copied credentials remain usable for weeks or months unless they are rotated and downstream activity is investigated.”
That makes the breach less a one-off package compromise and more a long-tail credential exposure event. Even if the malicious dependency was removed quickly, any secrets harvested during the exposure window may remain usable unless organizations rotate credentials and investigate downstream activity.
Major Enterprises Appear in CloudSEK’s Exposure Dataset
CloudSEK’s reconstructed exposure dataset includes high-confidence matches associated with major organizations including NVIDIA, AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, S&P Global, Deloitte, Vodafone, BT, Zscaler and X.
However, the company stressed that a high-confidence match does not establish that an organization was successfully compromised or that an attacker used the exposed credentials.
Instead, it indicates a strong link between an organization or pipeline and the affected supply-chain exposure, requiring further private validation and investigation.
The scale of the potential exposure shows how quickly a compromise in an AI-adjacent development component can create a security investigation spanning cloud infrastructure, software repositories, Kubernetes environments, third-party services and AI systems.
Why the LiteLLM Breach Matters for CX Leaders
The impact of the incident reaches beyond developer tooling.
AI infrastructure increasingly sits between customer data, business applications and systems capable of taking action. AI gateways, model endpoints, agents, vector databases and related services can hold or access credentials for cloud platforms, databases, internal applications and third-party services.
That makes an AI dependency a potential route into a much wider enterprise environment.
CloudSEK stated:
“AI infrastructure is becoming a strategic target. Gateways, agents, vector stores, model endpoints, and MCP servers sit between sensitive data and systems capable of taking action.”
That has implications for customer-facing AI systems that may connect to CRM platforms, knowledge bases, contact center applications, customer records, commerce systems and internal tools.
If credentials available to an AI build or runtime environment are compromised, the potential impact can extend into systems supporting customer interactions, service workflows, customer records and personalized engagement.
CloudSEK pointed to the growing complexity of enterprise AI environments, which can include open-source packages, hosted models, SDKs, connectors, vector databases and third-party services, which creates a broader security problem than a conventional application dependency. A compromised AI infrastructure component may expose not only application secrets, but also model API keys, agent credentials, gateway configurations and access paths into adjacent systems.
CloudSEK identified AI provider access as one potential exposure category, with stolen model API keys and gateway credentials potentially enabling model abuse, prompt or data exposure and unauthorized costs.
In customer-facing environments, those risks can become operational. If an attacker gains access to credentials used by a customer service AI agent, the exposure may touch CRM data, service histories, account details or other sensitive information used to personalize support.
The Credential Problem Is Bigger Than LiteLLM
CloudSEK said credentials accessible to the compromised process should be treated as potentially exposed, including credentials held in process memory, injected into CI/CD jobs, stored on disk or accessible through cloud instance metadata services.
The firm recommends that potentially exposed enterprises rotate cloud, source-control, registry, Kubernetes, SaaS, database and AI credentials. It also advises rebuilding affected environments from known-clean sources and investigating cloud, source-control, package registry and cluster logs.
The company also recommends pinning dependencies and GitHub Actions to verified hashes, reducing credential lifetime and scope, and favoring workload identity over static credentials.
This is particularly important for organizations with large development estates. A dependency that appears in one application can also exist in build caches, scheduled jobs, ephemeral runners and developer environments, creating multiple potential paths through which malicious code can spread.
Removing the Package Is Not Enough
The short exposure window may create a false sense of containment.
CloudSEK’s warning is that malicious packages can disappear quickly while stolen credentials remain valid. That means the response cannot stop at removing LiteLLM-related packages or rebuilding the immediate affected pipeline.
Organizations need to understand what credentials were accessible, where those credentials could be used, whether they were copied, and whether downstream activity occurred after the original package was removed. This can be especially challenging in AI environments because credentials may reach across several layers: cloud infrastructure, model providers, vector stores, CI/CD systems, API gateways and customer-facing applications.
In practice, enterprises may need to treat the incident as both a software supply-chain event and an identity exposure event.
Enterprises Need Visibility Across the AI Supply Chain
The LiteLLM incident highlights a broader challenge for enterprises adopting AI.
Security teams need visibility into the components and credentials supporting AI workloads, rather than treating the model or application as the complete security boundary.
CloudSEK warned that the next wave of supply-chain attacks will target AI infrastructure:
“AI systems are becoming high-value junctions between data, identity, compute, and autonomous action.”
The company drew a parallel with railway junctions in the industrial era, which became strategic targets as multiple supply routes converged.
“AI gateways, agent runtimes, MCP servers, and vector stores are becoming the junctions of digital operations,” CloudSEK said.
Traditional attack-surface monitoring can miss AI-specific assets and relationships, including model endpoints, agents, MCP servers, vector stores and AI workflows.
That means AI governance needs to extend into the software supply chain supporting customer-facing systems.
Questions Enterprises Should Be Asking
Compromising an AI control point can expose the identities and systems around it. Future attacks are likely to target the AI layer precisely because it is connected to so many other parts of the enterprise.
Organizations should be able to answer basic questions about their AI deployments, including:
- Which open-source dependencies are being used?
- Where are those dependencies deployed?
- Which CI/CD pipelines include AI-related packages?
- Which credentials can those workloads access?
- Are model API keys, gateway credentials or agent tokens exposed to build environments?
- Which customer or business systems can those credentials reach?
- Are credentials short-lived and narrowly scoped?
- Can credentials be rotated quickly after a supply-chain incident?
- Are AI gateways, MCP servers, vector stores and agent runtimes included in attack-surface monitoring?
- Is there logging to show whether exposed credentials were used after the package was removed?
Those questions are increasingly relevant for CX teams because AI agents and gateways often sit close to customer data and business workflows.
A service agent may need access to order status, product information or a knowledge base. It does not necessarily need broad access to payment systems, internal notes, customer history, or unrelated CRM fields.
The principle is simple: AI systems should not inherit more access than their specific task requires.
Third-Party AI Tools Do Not Remove Enterprise Responsibility
The LiteLLM case also reinforces the shared responsibility problem around AI supply-chain security.
Enterprises may rely on open-source packages, hosted model providers, AI gateways, SDKs, connectors and third-party services. But if exposed credentials lead into their own systems, they cannot treat the issue as only a vendor or open-source problem.
Kristina Holt, Managing Associate at Foot Anstey, warned in a recent CX Today interview that organizations still retain responsibility when they deploy third-party AI tools.
“You can’t get rid of your responsibility, but you could say, ‘I know that some of that responsibility is being handled by my third party.’ If you are confident that they are in fact handling it.”
That distinction matters in AI infrastructure. A vendor may be responsible for its own platform security, but the enterprise still needs to understand how credentials are scoped, where dependencies run, what systems are connected and how quickly access can be revoked.
AI Supply-Chain Risk Is Becoming Operational Risk
The March attack demonstrates the potential consequences of failing to make those connections.
As enterprises increase their reliance on AI across customer service and other business processes, supply-chain exposure becomes part of the wider operational risk of deploying AI.
The lesson is not that organizations should avoid open-source AI tools. It is that AI infrastructure now needs the same level of dependency governance, credential hygiene, runtime monitoring and incident response planning as other critical enterprise systems.
For CX and business leaders, the risk is no longer confined to the development environment. AI infrastructure increasingly connects customer data, identity, compute and automated action. That makes supply-chain security a customer trust issue, not just a software engineering concern.
