Layer 2: The components
Behind Every AI Supplier Is a Supply Chain of Its Own
An AI product is assembled largely from parts the vendor did not build: workflow platforms, model-routing tools, databases, software libraries, and pre-trained models. NIST’s generative AI profile describes value chains that “involve many third-party components such as procured datasets, pre-trained models, and software libraries”. Each of those components is a supplier of the vendor, and through the vendor a supplier of its customers. Even a model file is a security object: in common machine learning formats, loading a model can execute code it carries, which is why joint guidance from the cybersecurity agencies of seven countries treats serialized model files as a supply-chain risk.
This supply chain exposure is not just a theoretical concern. Black Kite's research identified security findings associated with AI workflow platforms and model-routing tools across multiple companies.
The examples below connect these findings with vulnerabilities documented by CISA and a real-world software supply chain attack. Together, they show why assessing an AI supplier requires looking beyond the company's own infrastructure to the technologies its products depend on.
When Common AI Tools Become Shared Security Weaknesses
CISA’s KEV catalog also lists flaws in software built for AI work, and those flaws sit at AI companies in this population. They are recent, and the tools they affect hold the connections an AI product uses to reach other systems.
The largest group concerns n8n, a workflow automation platform widely used to build AI agents and to connect models to business systems. Black Kite identified CVE-2025-68613 at 93 AI companies. The vulnerability affects n8n’s workflow expression evaluation and can allow unauthorized code execution.
What makes n8n relevant to a customer is what it holds. A workflow platform stores the credentials its workflows use to reach other services, so control of the platform reaches those services as well. In January 2026, Endor Labs found malicious packages posing as n8n integrations that used this position to steal stored OAuth tokens, and its researchers noted that such add-ons run “with the same level of access as n8n itself”.
Langflow, a visual builder for AI agents and retrieval workflows, shows how such a tool accumulates exposure when it falls behind. CISA’s catalog lists Langflow vulnerabilities as exploited and records the first of them as used in ransomware campaigns. Langflow-related findings appeared at five AI companies, four of which carry both KEV-listed Langflow vulnerabilities, CVE-2025-3248 and CVE-2025-34291.
LiteLLM-related FocusTags® appeared at seven AI companies. The open-source model-routing tool became the source of a supply-chain incident when malicious releases in March 2026 introduced credential-harvesting code into environments that installed them.
Across n8n, Langflow, and LiteLLM, Black Kite identified 105 distinct AI companies with related findings. Their importance lies in the role these components can play: connecting AI applications to workflows, credentials, and other services.
These technologies serve different purposes, but they share an important characteristic: they can sit between AI applications and other software services, often handling credentials, workflows, or access to external systems.
This creates a security consideration that goes beyond the supplier's own infrastructure. The components used to build an AI product can introduce risks that are difficult to recognize by assessing the supplier's internet-facing systems alone.
Reuse makes one component everybody’s component
The parts are drawn from a shallow pool. A 2025 study traced the components behind 3,859 AI applications and found that of the 109,211 models involved, 98,436, or 90.1%, could be traced back to just 161 core models. The software beneath the applications showed the same concentration, with 49% of them depending on libraries that carry known vulnerabilities.
Of the 109,211 models behind 3,859 AI applications, 90.1% traced back to just 161 core models. 2025 study of AI application supply chains, arXiv
A related pattern of recurring exposure appears in Black Kite’s findings. The AI-tool examples show how a component-level weakness can recur across suppliers. At the general infrastructure layer, HTTP/2 Rapid Reset was confirmed at 963 AI companies, 5.3% of the study, after a direct check of the affected systems.
The PHP2Shell flaws disclosed as this report went to press, found at 939 AI companies within a week, are the latest example.
That concentration is what turns a component problem into a supply chain problem. Five AI companies in a supplier register may look independent while resting on the same few base models and the same handful of packages. If a shared component is compromised, several otherwise independent suppliers may be exposed to the same incident, potentially creating a common point of failure across AI products that customers purchased and assessed separately.
Third-party cyber risk programs already have a name for this. Concentration risk is what a program is managing when many of its suppliers run on one cloud platform or clear through one payment processor, and it is managed by knowing where the concentration sits. In an AI supply chain it sits in components, one level below what a supplier register records, which is why a program can hold an accurate vendor inventory and still not know that several of its tools fail together. The case below follows that sequence from one compromised package to an AI vendor and on to that vendor’s customers, in the space of days.
Case Study
LiteLLM and Mercor: Forty minutes on a package repository
In March 2026, attackers published malicious versions of LiteLLM, an open source tool widely used to route application requests to different language models, to PyPI, the Python package repository. The malicious code harvested credentials from the environments that installed it.
One of those environments belonged to Mercor, a company that supplies AI training data and handles the data sets and workflows of model developers. Mercor disclosed the breach on March 31 and said it was “the result of a hack of the open source tool LiteLLM”, which had “harbored credential harvesting malware” for 40 minutes. That figure is how long the compromised package was available for download, not the length of the intrusion: the credentials taken in that window were then used to reach further systems and accounts.
Mercor’s investigation, conducted with Google’s Mandiant and Latacora, concluded in June 2026. The company reported that sensitive information belonging to “a very limited subset” of its nearly five million experts was affected, that the impact on customer information was limited because many customers operate on their own platforms, and that no employee data was affected. Its remediation included auditing all third-party dependencies, rotating credentials across cloud, GitHub, and SaaS systems, and adding managed detection and response: the controls a customer should ask an AI supplier about before an incident rather than after one.
The important lesson is how the incident moved through the supply chain. Mercor's customers did not choose the compromised LiteLLM package themselves. The security risk entered through software used by their supplier.
This raises a practical question for organizations adopting AI services: does the supplier know which software components its product depends on, and can it respond quickly when one of those components becomes a security problem?
1. The component
Malicious LiteLLM package on PyPI
March 2026. Downloadable for 40 minutes.
2. The supplier
Mercor installs it. Credentials harvested and used to reach further systems.
Disclosed March 31.
3. The customers
Data belonging to a limited subset of Mercor’s experts affected.
Investigation closed June 25.
Mercor’s customers did not choose the compromised package. The risk arrived through software their supplier used.
Next: Components determine what a supplier is built from.
Integrations determine what it can reach. When an AI product connects to your systems, the access it holds becomes part of your attack surface.