When LLMs Inherit Vulnerabilities… Through the Supply Chain

Author(s): Rabia AMAAOUCH

Originally published on Towards AI.

OWASP Top 3 Vulnerabilities for Large Language Models

Large Language Models (LLMs) rely on a complex supply chain: training data, third-party libraries, pre-trained models, APIs, and more. A single compromised component can jeopardize the entire system. OWASP LLM03:2025 highlights these often-overlooked risks.

How it works

Think of an LLM that uses an open-source library to process inputs or is fine-tuned on external datasets. If these sources are malicious or corrupted, the model can inherit dangerous behaviors: bias, data leakage, backdoors, and more.

Risks

1. Malicious Dependencies

• Illustration:
  LLMs often rely on third-party libraries or pre-trained models. If one of these contains hidden malicious code (e.g., a backdoor), it can silently compromise the entire system.
• Impact:
  Unauthorized access to internal systems, Data leakage or manipulation
  or Loss of control over model behavior.
• Real-world case: LoRA adapter vulnerability
  In 2024, a rogue LoRA adapter uploaded to Hugging Face introduced obfuscated code that leaked API keys and user credentials from downstream applications.

2. Poisoned Pre-Trained Models

• Illustration:
  Attackers inject biased or malicious data into training sets or fine-tuning pipelines. The model then learns harmful behaviors or hidden triggers.
• Impact:
  Biased or misleading outputs, Activation of hidden behaviors via specific prompts or Legal and reputational risks.
• Real-world case:
  Researchers from Carnegie Mellon and Google DeepMind demonstrated that poisoning just 0.1% of a model’s pre-training data could cause persistent unsafe behavior — even after alignment. They simulated attacks like denial-of-service and belief manipulation.

3. Outdated or Vulnerable Dependencies

• Illustration:
  LLMs often use legacy libraries or models. If these components are outdated and unpatched, attackers can exploit known vulnerabilities.
• Impact:
  Remote code execution, System instability or Compliance failures
• Real-world case: CVE-2025–53773
  This CVE affected Microsoft Copilot and Visual Studio, allowing malicious source code to hijack AI coding assistants. This vulnerability turned trusted AI tools into attack vectors.

4. Licensing Risks

• Illustration:
  Many LLMs and datasets are released under open-source or research-only licenses. Using them in commercial products without proper review can lead to legal violations.
• Impact:
  Intellectual property infringement, Legal action or takedown requests or Financial penalties and reputational damage
• Real-world case:
  In 2023, Stability AI faced legal threats for using copyrighted training data without proper licensing in its image generation models. Similarly, several startups using LLaMA (Meta’s model under a non-commercial license) in commercial products received takedown notices and had to pivot or pay licensing fees.

5. Third-Party Model

• Illustration:
  LLM platforms integrate third-party plugins or models without verifying their integrity.
• Impact:
  Credential theft, Prompt hijacking or Platform compromise
• Real-world case: Empirical Study
  A plugin on an LLM platform was designed to intercept login credentials and manipulate user prompts, leading to phishing and data theft. The plugin mimicked a legitimate grammar-check tool.

6. Tampered LoRA/PEFT Adapters

• Illustration:
  Attackers inject backdoors into LoRA adapters and distribute them via open platforms.
• Impact:
  Trigger-based malicious behavior, Scalable backdoor propagation or Difficult detection due to modularity
• Real-world case:
  In the “LoRA Once, Backdoor Everywhere” attack, researchers showed how a single tampered LoRA adapter could be merged with others and distributed at scale, retaining both benign and malicious capabilities.

Risks mitigations

Each risk in the LLM supply chain can be addressed with practical safeguards. Whether you’re publishing models or integrating them into your systems, the following mitigations help reduce exposure to malicious code, legal issues, and hidden vulnerabilities.

1. Protect from the Inside — LLM Publisher Perspective

• Verify Dependencies
  Use Software Composition Analysis (SCA) tools to detect vulnerabilities and malicious code. Verify third-party libraries and models via code audits and source reputation checks. Sign and hash all distributed components to ensure integrity.
• Test for Poisoning and Backdoors
  Apply data sanitization and curation during pre-training and fine-tuning. Conduct adversarial testing and red teaming to uncover hidden triggers. Use differential testing to detect biased or anomalous outputs.
• Maintain Secure Update Pipelines
  Automate patching and updates through CI/CD pipelines.
  Monitor CVEs and subscribe to security advisories for all dependencies.
• Manage Licensing Compliance
  Maintain a license inventory for all datasets, models, and code.
  Use automated license scanners to detect incompatible or restricted licenses. Involve legal teams in reviewing third-party assets before integration.
• Secure Plugin and Adapter Ecosystem
  Vet plugins and models via static and dynamic analysis.
  Enforce sandboxing and least privilege access for third-party integrations.
  Maintain a verified registry of trusted contributors and plugins.
  Sign LoRA/PEFT adapters and educate users on safe merging practices.

2. Protect from the Outside — LLM Consumer Perspective (Black Box)

These apply to teams or individuals who use, deploy, or integrate LLMs into applications or workflows.

• Use Trusted Sources
  Prefer models and adapters from verified repositories.
  Validate adapter integrity using hash checks and source verification.
  Avoid merging components from unknown or unverified sources.
• Validate Model Behavior
  Even when using LLMs as SaaS, consumers can test model behavior by running representative prompts, monitoring outputs in their own context, and using moderation tools or safety filters provided by the platform.
  Reinforcement Learning from Human Feedback (RLHF)
  RLHF is a technique used to align LLMs with human expectations by training them to prefer helpful and safe responses. While consumers can’t apply RLHF directly, they can choose models that have been fine-tuned using RLHF and review provider documentation to ensure alignment efforts are in place.
• Keep Dependencies Updated
  Regularly audit and update LLM-related packages and plugins: SDKs and plugins used to access the LLM, and follow provider changelogs to stay informed about security fixes.
  Use runtime protection tools (e.g., WAFs, EDRs) to detect exploitation attempts.
• Respect Licensing Terms
  Review license terms before deploying models commercially.
  Avoid using models labeled “research-only” or “non-commercial” in production.
  Prefer models with permissive licenses (e.g., Apache 2.0, MIT) since they allow modification, redistribution, and integration without complex legal restrictions or risk of infringement
• Control Plugin Behavior
  Disable or restrict plugins by default; enable only trusted ones.
  Monitor plugin behavior for prompt injection or credential access.
  Use audit logs to trace plugin activity and detect anomalies.

Risks & Remedies Table

Tech it to the end

Supply chain risks in LLMs aren’t just theoretical — they’re already shaping the threat landscape. Whether you’re building or integrating models, securing every layer matters: from dependencies to licensing, from plugins to adapters. Awareness is the first step, action is the next.

Stay tuned — same AI time, same AI channel.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI