More than 2,500 companies and approximately 434,000 CI/CD pipelines worldwide were potentially exposed in what is believed to be the largest supply-chain attack targeting AI infrastructure in 2026.
In March 2026, threat actor group Team PCP compromised LiteLLM, a widely used open-source AI gateway. CloudSEK Threat Intelligence subsequently reconstructed the victim exposure and is now sharing details of impacted organisations to help security teams identify potential exposure and take remedial action.
The affected LiteLLM packages were reportedly available through PyPI for only around 40 minutes. However, automated CI/CD environments can download and execute dependencies rapidly, allowing even a short-lived compromise to create prolonged security risk.
Among the information potentially accessible from affected environments were AWS, Google Cloud and Microsoft Azure credentials, SSH keys, Kubernetes tokens, CI/CD secrets, repository credentials, environment variables and LLM/API keys.
CloudSEK’s exposure dataset includes high-confidence matches associated with major global organisations including NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales and London Stock Exchange Group, among others.
CloudSEK stresses that an exposure match does not automatically confirm successful compromise, data theft or malicious use of credentials. Organisations identified in the dataset should validate their exposure and investigate relevant systems.
The Threat May Outlive the Original Attack
The significance of the incident extends beyond the malicious package itself.
Once credentials are copied from an affected environment, removing the compromised software does not invalidate those credentials. According to CloudSEK’s analysis, stolen access can potentially be reused, sold or weaponized even after the malicious package has been removed, creating the possibility of downstream attacks weeks or months later.
The FBI also issued FLASH-20260702-01 on July 2, 2026, covering cybercriminal group TeamPCP, further highlighting the continuing security concern surrounding the campaign.
CloudSEK is sharing the exposure research openly so affected organisations can identify possible exposure, rotate credentials, investigate suspicious activity and harden their environments before compromised access is reused.
AI Infrastructure Is Becoming a High-Value Target
The LiteLLM incident also reflects a broader shift in cyberattacks.
AI gateways, MCP servers, agentic systems, vector databases and other AI infrastructure increasingly sit between sensitive corporate data, identities, cloud services and systems capable of taking action.
This makes AI infrastructure an attractive target for attackers seeking access beyond a single application. CloudSEK assesses that future attacks are increasingly likely to target the AI layer precisely because of how deeply it is connected to enterprise environments.
CloudSEK AIVigil: Continuous AI Attack Surface Monitoring
The growing attack surface around enterprise AI is the security problem CloudSEK AIVigil is designed to address.
AIVigil continuously discovers and monitors exposed AI infrastructure, MCP servers, leaked AI credentials, vector databases, agentic workflows and shadow AI. It combines CloudSEK’s cyber threat intelligence with AI exposure monitoring to help security teams identify exposed assets, credentials and attack paths before they develop into wider enterprise incidents.
Check Your Exposure
Organisations can use CloudSEK’s free exposure-checking tool to determine whether credentials associated with their environment appear in the identified dataset:
Free Exposure Checker: https://exposure.cloudsek.com/ai-supply-chain-incident
Full Research Report: https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
Full List Of Exposed Companies: TeamPCP CI/CD Secret Exposure — Check if your organisation is affected | CloudSEK
UPDATE: Rohit Valia, CEO of cybersecurity company Tumeryk, provided the following comments:
“Incidents like the recent LiteLLM supply chain compromise show that a single unrevoked token in an open source build chain can result in an ecosystem-wide exposure. Open source innovation is essential to the pace of AI development, but enterprises need more than the raw project — they need it hardened, tested, and accountable. It also needs to be put through rigorous security validation before it reaches production. Sanctioned shouldn’t just mean ‘permitted’ — it should mean proven.”
UPDATE #2: Seemant Sehgal, Founder & CEO, BreachLock adds this:
“The malicious packages were live for 40 minutes, but the window mattered to defenders long after it mattered to the attacker. Any system that pulled 1.82.7 or 1.82.8 during those 40 minutes ran malware on every subsequent Python startup, meaning credentials harvested from those environments have been sitting in attacker hands since before most teams knew there was an incident.
“Cloud keys, SSH keys, AI provider tokens, and package-publishing credentials from 434,000 CI/CD pipelines enable access, and access can be used quietly for a long time before anyone sees the effect. The initial scanner compromise fed LiteLLM’s CI pipeline, which pushed malware to PyPI. The affected organizations were two steps removed from the original breach, with every link in the chain working exactly as designed.”
John Strand, Owner, Black Hills Information Security, Inc.:
“One of the biggest takeaways from this latest LLM attack, especially when viewed alongside the recent wave of malicious NPM packages, is that sophisticated attackers are increasingly focused on the software supply chain. They’re looking for opportunities to compromise the tools and components that everyone trusts because that gives them an enormous amount of reach.
“What concerns me most about this attack isn’t just its scope, although the scope is certainly significant. It’s how difficult it would be for many organizations to detect. These attacks often operate outside the visibility of traditional security controls.
“In many ways, this reminds me of the early days of internet worms like Conficker, SQL Slammer, Blaster, and Nachi. Those threats spread incredibly fast, and because they were so loud, the entire security industry mobilized to detect them, contain them, and ultimately build better defenses.
“I think we’re seeing something similar with supply chain attacks today. Right now, attackers are going big. They’re compromising widely used packages and trying to maximize their impact. My concern is what happens after this phase. History tells us that attackers eventually become more disciplined. Instead of going after everything, they’ll become more selective, targeting the specific packages, libraries, and dependencies that give them access to the organizations they actually want to compromise.
“That’s why I see these attacks as a harbinger of what’s coming next. They’re already difficult to detect because they exist outside the normal visibility of EDR platforms, firewalls, and traditional intrusion detection and prevention systems. As attackers become more targeted and more subtle, that detection problem is only going to get harder for defenders.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Forty minutes was the theft. Five months later, the FBI is still warning that the stolen credentials will be weaponized.
“I’ve been tracking TeamPCP’s campaign since they hit Aqua Security’s Trivy scanner in March. LiteLLM’s CI pipeline pulled Trivy from apt without pinning a version. One poisoned build later, the attackers had LiteLLM’s PyPI publishing credentials and pushed two malicious versions that ran code at Python startup, no import needed, bypassing the install-script protections most teams count on.
“2,500 organizations and 434,000 pipelines from that window. Automated build systems explain the math. They pull dependencies in seconds, cached layers spread them further, and a poisoned package rides the distribution network into every downstream consumer before anyone notices.
“TeamPCP has used this playbook all year. Trivy, LiteLLM, Microsoft’s durabletask-python twice, always re-entering through credentials that survived the previous cleanup. SANDCLOCK grabbed cloud keys, Kubernetes tokens, SSH keys, AI provider credentials, everything the runner could reach. Those stolen credentials often valid until someone actively revokes them.
“Organizations with a Software Bill of Materials (SBOM) knew within hours whether LiteLLM 1.82.7 or 1.82.8 was anywhere in their stack. A mandated delay on dependency updates, even an hour, would have cleared the entire 40-minute window before either version installed. Pin CI dependencies to verified hashes, scope runner credentials to the minimum each job needs, and if you ran either version, rotate every secret that runner could reach.”
Hackers breach Polish power plant through private cellular network
Posted in Commentary with tags Hacked on August 11, 2026 by itnerdPoland’s CERT has disclosed a cyberattack that shut down a steam turbine and process-water treatment system at a combined heat and powerplant supplying roughly 50,000 residents. The December 2025 attack caused a short-lived operational disruption, but customers did not lose heat or electricity.
Investigators found the attackers initially compromised a FortiGate VPN/firewall at a separate wind farm, then used a cellular router to enter a private APN connecting remote infrastructure. Because the network lacked client isolation, the attackers reached a WAGO industrial controller using default administrator credentials, pivoted into the plant’s OT network and ultimately accessed its SCADA system and Siemens PLCs. CERT Polska said it believes this is the first known real-world cyberattack to gain access to an OT network by moving laterally through a private APN.
Waseem Ahmed, Head of Engineering, Secure.com:
“Breaches like this do not start with anything fancy. They start with a device someone forgot about. Attackers got into a wind farm firewall, then rode a private cellular network into a power plant that had nothing to do with it. The controller they landed on still had its default password. From there they reached the plant floor and stopped a turbine.
“CERT Polska assessed this as the first confirmed case of an attacker using a private cellular APN as a lateral movement path into OT infrastructure, which matters because operators often treat private APNs as inherently safe without applying the same segmentation controls they would to any other network connection.
“A private network is not the same as an isolated one. Client isolation, replacing default credentials, and treating every remote link as untrusted stops most of this. When offense maps these paths first, defense knows which door to close.”
Denis Calderone, CTO, Suzu Labs:
“Private cellular networks are a good idea for OT connectivity, but they only solve one problem: keeping traffic off the public internet. What they don’t solve is what happens when one device on that network gets compromised. In this case, a single insecure controller on the operator’s private APN gave the attacker vertical exposure all the way down to the SCADA system and Siemens PLCs at a completely separate facility. The APN kept the outside world out, but nobody considered the trust boundaries between devices inside it. Without client isolation, a private APN is just a flat shared network where any compromised node can reach everything else.
“The private APN in this case was set up by the distribution system operator, the entity that runs the local electricity grid, to communicate with distributed generation sites. Wind farms, CHP plants, substations, all connected to the same carrier-managed cellular network for SCADA communication. This makes perfect sense architecturally, but the problem is that the DSO architected it as a flat mesh. Every site could reach every other site. Think of it like an MPLS network where multiple customers are in the same VRF with no route filtering between spokes.
“The wind farm had zero operational reason to communicate with the CHP plant’s controllers. Both sites needed to talk to the DSO’s central SCADA, and that’s it. But because there was no hub-and-spoke enforcement and no spoke-to-spoke restriction, an attacker who compromised a Teltonika router at one wind farm could scan the entire APN, find a WAGO PLC at an unrelated facility still running default credentials, and use it as a bridge into that plant’s OT environment. One compromised site gave them the run of the entire network.
“CERT Polska says this APN misconfiguration was common across Poland at the time of the attack and is believed to be widespread internationally. That tracks. Back in May there were the Polish water treatment attacks where operators were running passwords like ‘111111’ on internet-exposed HMIs and mistaking active intrusions for equipment glitches. Same pattern here. The CHP plant operators initially thought the shutdown was a contractor error during routine maintenance. CERT Polska only investigated because the timing coincided with the larger coordinated attack on 30 other energy sites that same day. Without that coincidence, this might still be filed as an unexplained equipment failure.
“The prescriptive side here starts with the APN specifically. Contact your carrier and confirm that client isolation is enabled. If it’s not, or if you must run a flat APN mesh between every site, make sure to enforce your own site-to-site edge controls. Where possible, the default configuration should be to enforce hub-and-spoke so each site can reach the central SCADA gateway and nothing else. And beyond the cellular network, this is the same OT security discipline we preach on every engagement. Industrial controllers and SCADA interfaces should never have their administrative interfaces exposed on any network they don’t absolutely need to be on. Default credentials on PLCs need to be treated with the same urgency as a default password on a domain admin account. Segment OT environments from IT with monitored firewall boundaries. And include your cellular connectivity in your security testing program.”
John Strand, Owner, Black Hills Information Security, Inc.:
“This is the problem with unseen IT, OT, and legacy technology. Anything that falls outside of mainstream server and endpoint infrastructure tends to get neglected by organizations. That doesn’t necessarily mean those organizations are incompetent or negligent. The reality is that there simply aren’t as many security products and services available to protect these environments, and a lot of that comes down to market share.
“We are starting to see improvements, but it’s still very easy for organizations to ignore these technologies or even create exceptions for them within their compliance frameworks. Attackers understand this. If they can move away from environments protected by mainstream EDR and other widely deployed security technologies, they can start targeting unseen, out-of-the-way, and lesser-known systems where they have a much higher probability of success. That’s the attack surface we need to start paying a lot more attention to.”
This is an epic fail. But at least they were honest enough to put what happened down on paper. But how about stopping this from happening in the first place? That’s real progress.
Leave a comment »