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.”
Encrypted Reasoning Cracked Across Anthropic, OpenAI & Google
Posted in Commentary with tags Anthropic, Google, OpenAI on August 11, 2026 by itnerdResearchers from MATS Research, the Max Planck Institute for Intelligent Systems, the ELLIS Institute Tübingen, Snyk, and the University of Tübingen have found a way to crack encrypted reasoning logs across all three major AI providers.
The researchers found that encrypted reasoning blocks can be passed between compatible models within the same provider’s ecosystem. By feeding an encrypted reasoning block generated by a more capable, heavily safeguarded model into a weaker, less restricted one, they were able to force the weaker model to decode and reproduce the previously hidden reasoning in plain text, without ever directly attacking the more capable model.
“By porting a valid authenticated encrypted reasoning blob across this security gap, an attacker circumvents the frontier model’s alignment entirely, using the weaker, more compliant model as an unwitting decryption oracle,” researchers explain.
The root cause is an architectural design choice: all three providers appear to use a single global encryption key shared across their entire model family. This means encrypted reasoning blocks are not tied to the session, account, or model that created them. A reasoning block generated by one user, on one model, in one session, can be picked up and decoded by a completely different user using a different model in a different session entirely.
This vulnerability was present in the latest AI models from Anthropic, OpenAI, and Google.
This vulnerability was tested in the real world as well. Researchers scraped 315,320 encrypted reasoning blocks from publicly available repositories and decrypted:
They also demonstrate cases where information hidden in the model’s reasoning was significantly more sensitive than what appeared in the model’s final, visible response, including potentially harmful information that the model had refused to provide in its final answer.
You can find the full research paper here: https://arxiv.org/pdf/2608.09867
Voldemaras Kadys (https://www.linkedin.com/in/voldemaras-kadys/), the Head of Security at Cybernews, with over 15 years of experience in cybersecurity and IT infrastructure, comments:
“The most interesting part of this research is that the researchers didn’t need to ‘break’ the encryption in the traditional sense. They found that encrypted reasoning traces could be passed between compatible models within the same provider’s ecosystem, effectively turning a weaker model into a master decryption key.
The main lesson here for users and organizations is this: if you’re using AI with sensitive inputs or outputs, treat chat logs as sensitive data, even when they look like meaningless encrypted text.
Those encrypted blocks can contain credentials, personal information, and other sensitive data that isn’t visible to the person sharing the log.
As this research demonstrates, encryption doesn’t necessarily make that information inaccessible, and the barrier to decrypt it may be much lower than users expect.”
This further dents the reputation of AI. Thus it might be worth a look at your use of AI to see if anything sensitive is making its way into the public domain.
Leave a comment »