Initially published by the Open Worldwide Application Security Project (OWASP) in 2023, the Top 10 for LLM Application Security list seeks to bridge the gap between traditional application security and the unique threats related to large language models (LLMs). Even where the vulnerabilities listed have the same names, the Top 10 for LLM Application Security focuses on how threat actors can exploit LLMs in new ways and potential remediation strategies that developers can implement.
While the original list raised awareness, Version 2025 responds to changes in how people use LLMS and includes insights from more experts, including professionals focused on LLM application security. The updates reflect a better understanding of how people use LLMs in real-world applications.
For organizations implementing LLMs as part of internally built applications or when reviewing embedded LLMs, understanding the top 10 threats can improve overall security posture.
LLM01:2025 Prompt Injection
A prompt injection vulnerability exists when a user prompt changes the LLM’s behavior or output in unintended ways, even if the injections are not human readable. The vulnerability relies on how the model processes the prompt, leading the input to force the model to incorrectly pass prompt data to other parts of the model that can:
- Violate guidelines.
- Generate harmful content.
- Enable unauthorized access.
- Influence decisions.
The two types of prompt injection vulnerabilities are:
- Direct prompt injection: The prompt directly alters the model’s behavior either intentionally or unintentionally.
- Indirect prompt injection: The LLM accepts inputs from external sources that the model may interpret in ways that change its behavior.
LLM02:2025 Sensitive Information Disclosure
Sensitive information disclosure includes the LLM or its application leaking:
- Personally identifiable information (PII).
- Financial details.
- Health records.
- Confidential business data.
- Security credentials,
- Legal documents.
- Proprietary algorithms.
When built into applications, LLMs risk exposing sensitive information so organizations need to understand the risks of unintentionally providing sensitive data that the model’s output could later disclose.
Common examples of this vulnerability include:
- PII leakage: PII disclosures during LLM interactions.
- Proprietary algorithm exposure: Output revealing proprietary algorithms or date, like revealing training data that attackers can exploit to extract sensitive information or reconstruct inputs.
- Sensitive business data disclosure: Responses accidentally including confidential business information.
LLM03:2025 Supply Chain
Vulnerabilities across the LLM Supply chain can affect training data, model, and deployment platform integrity resulting in:
- Biased outputs.
- Security breaches.
- System failures.
Unlike traditional code- and dependency-based vulnerabilities, machine learning (ML) risks include third-party pre-trained models and data.
Common examples of risks include:
- Traditional third-party package vulnerabilities: Attackers can exploit outdated or deprecated components.
- Licensing risks: Open-source, proprietary, and dataset licenses can impact legal liability, usage, distribution, or commercialization.
- Outdated or deprecated models: Unmaintained models can create security issues.
- Vulnerable pre-trained model: Poisoned datasets and direct model tampering can lead to hidden biases, backdoors, or other malicious features.
- Weak model provenance: Current documentation provides no guarantees around the model’s origin so attackers can compromise a supplier account that impacts the LLM’s applications entire supply chain.
- Vulnerable Low-Rank Adaptation (LoRA): A malicious LoRA adapter compromises the pre-trained base model’s integrity and security, like when downloading and applying adapters to a deployed model.
- Exploit collaborative development processes: When hosted in shared environments, attackers can exploit collaborative model merge and model handling services to introduce vulnerabilities.
- LLM model on device supply-chain vulnerabilities: When running AI models on a device, operating system and software vulnerabilities can allow attackers a way to steal, alter, or misuse the AI model or its data.
- Unclear data privacy policies or terms and conditions: When model operators use vague terms and privacy policies, the application may use sensitive data for model training which can lead to sensitive data exposure.
LLM04: Data and Model Poisoning
Data poisoning is when someone manipulates pre-training, fine-tuning, or embedding data to introduce vulnerabilities, backdoors, or biases that can compromise security, performance, or ethical behavior leading to issues like:
- Degraded model performance.
- Biased or toxic content.
- Downstream system exploitation.
Some common examples of this vulnerability include:
- Introducing harmful data during training that leads to biased outputs.
- Injecting harmful content into the training process to compromise output quality.
- Accidentally injecting sensitive or proprietary information during interactions.
- Unverified training data leading to biased or wrong outputs.
- Ingesting unsafe data when no resource access restrictions exist.
LLM05:2025 Improper Output Handling
An improper output handling vulnerability exists when an application fails to validate, sanitize, or securely process LLM-generated content before passing it to downstream systems. User input influences LLM output, so attackers can craft prompts that indirectly manipulate system behavior to produce malicious outputs.
Unlike overreliance on LLM accuracy, this vulnerability focuses on what happens after the model generates content. If applications treat model output as trusted input, attackers can trigger:
- Cross-site scripting (XSS).
- Cross-site request forgery (CSRF).
- Server-side request forgery (SSRF).
- Privilege escalation.
- Remote code execution.
Common examples of this vulnerability include:
- Direct execution of model output: Passing LLM output into system shell commands (e.g., exec or eval) without validation.
- Browser-interpreted script generation: Rendering LLM-generated JavaScript or Markdown in a browser without proper encoding, leading to XSS.
- SQL injection using generated queries: Executing LLM-generated SQL statements without parameterization.
- Path traversal: Using model output to construct file paths without sanitization.
- Unsafe email or template rendering: Embedding unescaped LLM content into communications, enabling phishing or content injection.
LLM06:2025 Excessive Agency
An excessive agency vulnerability exists when an application grants an LLM more autonomy, permissions, or system access than necessary. Attackers can manipulate prompts to perform unauthorized operations when LLMs can:
- Call tools.
- Access APIs.
- Execute code.
- Act on a user’s behalf.
Typically, an excessive agency vulnerability arises from one or more of the following:
- excessive functionality.
- excessive permissions.
- excessive autonomy.
Common examples of risks include:
- Excessive functionality through extensions: Granting an LLM agent access to third-party tools that include unnecessary capabilities, such as modify or delete permissions when the application only requires read access.
- Excessive functionality during development: Leaving previously tested or deprecated extensions available to the LLM agent, even after selecting alternative tools.
- Excessive functionality of plugin: Using open-ended plugins that fail to properly filter instructions, allowing execution of commands beyond the intended scope (e.g., permitting arbitrary shell commands instead of a single approved command).
- Excessive permissions for service accounts: Connecting extensions to downstream systems with identities that have broader permissions than required, such as SELECT, UPDATE, INSERT, and DELETE access when only read access is necessary.
- Excessive permissions from user’s access permissions: Allowing extensions operating on behalf of individual users to authenticate with generic privileged accounts that can access all users’ data.
- Excessive autonomy from unverified high-impact actions: Permitting LLM-driven extensions to execute sensitive operations, such as deleting documents, without independent validation or explicit user confirmation.
LLM07:2025 System Prompt Leakage
A system prompt leakage vulnerability exists when attackers can extract an LLM application’s hidden system instructions, policies, or guardrails by using prompts that contain:
- Operational logic.
- Security constraints.
- Proprietary information.
If attackers successfully retrieve system-level instructions, they can:
- Reverse engineer security controls.
- Craft more effective prompt injection attacks.
- Discover internal policies or logic.
- Expose proprietary business processes.
Common examples of this vulnerability include:
- Exposure of sensitive functionality: Revealing confidential system details within the system prompt allowing attackers to extract data so they can gain unauthorized access or craft targeted attacks.
- Exposure of internal rules: Disclosing business logic or decision-making thresholds embedded in the system prompt to bypass safeguards, manipulate workflows, or evade fraud controls.
- Revealing filtering criteria: Exposing explicit content moderation or rejection rules within the system prompt allowing attackers to use this information to rephrase inputs and circumvent protective controls.
- Disclosure of permissions and user roles: Leaking details about internal role structures or privilege levels allowing attackers to use this information when attempting privilege escalation or targeting high-value accounts.
LLM08:2025 Vector and Embedding Weaknesses
Vector and embedding weaknesses occur when attackers manipulate retrieval-augmented generation (RAG) systems or embedding pipelines to influence model output when relying on:
- External data stores for context.
- Insecure vector databases.
- Poorly validated embeddings.
Common examples of this vulnerability include:
- Unauthorized access and data leakage: Failing to enforce proper access controls on vector databases or embedding stores which allows the model to retrieve and disclose sensitive data.
- Cross-context information leakage: Allowing multiple user classes or applications within a multi-tenant system to share the same vector database without strict segmentation, leading to data leakage across contexts.
- Embedding inversion attacks: Exploiting weaknesses in embedding storage or exposure to reconstruct source content from vector representations, compromising data confidentiality.
- Data poisoning attacks: Introducing malicious or unverified data into retrieval pipelines through insider actions, prompt injection, seeded documents, or untrusted providers that can result in manipulated or biased outputs.
- Behavior alteration: Inadvertently changing model behavior through retrieval augmentation in ways that undermine emotional intelligence or empathy.
LLM09:2025 Misinformation and Hallucination
A misinformation and hallucination vulnerability exists when an LLM generates incorrect, misleading, or fabricated information that users or downstream systems treat as authoritative. When the LLM uses statistical patterns to fill a training data gap, it can produce false answers since it lacks contextual understanding.
Common examples of this vulnerability include:
- Factual inaccuracies: Generating incorrect statements that people use to make decisions.
- Unsupported claims: Producing baseless assertions that can be particularly harmful in sensitive contexts.
- Misrepresentation of expertise: Presenting responses with a level of confidence or authority that exceeds the model’s actual capabilities.
- Unsafe code generation: Suggesting insecure, outdated, or non-existent libraries and coding practices that can introduce vulnerabilities.
LLM10:2025 Unbounded Consumption
An unbounded consumption vulnerability exists when the LLM application allows users to conduct too many inferences. Attackers can use this vulnerability to:
- Disrupt service.
- Deplete financial resources.
- Steal intellectual property.
Common examples of this vulnerability include:
- Variable-length input flooding: Overloading the LLM with prompts of different lengths to overwhelm the system and disrupt availability.
- Denial of wallet (DoW): Exploiting the cost-per-use cloud-based AI service model by initiating high volumes of operations to make operation too expensive.
- Continuous input overflow: Repeatedly sending prompts that exceed the model’s context window to use compute power and disrupt operations.
- Resource-intensive queries: Crafting complex, computation-heavy prompts that strain system capacity and reduce processing speed.
- Model extraction via API: Querying the model with carefully designed inputs so output data enables underlying model approximation, replication, or reverse engineering.
- Functional model replication: Using outputs to generate synthetic training data that fine-tunes another model into a functional equivalent.
- Side-channel attacks: Exploiting input filtering techniques to infer model architecture, weights, or architecture information.
Graylog: Modern Security Monitoring for Modern Security Threats
Graylog enables organizations to centralize, secure, and analyze machine data at scale so teams can detect threats faster, investigate smarter, and maintain operational visibility across complex environments. Whether deployed on-premises, in the cloud, or in hybrid architectures, Graylog SIEM and log management unifies logs and event data from diverse sources, enriches them with context, and surfaces meaningful insights through real-time search, alerts, dashboards, and automated workflows.
With Graylog, built-in analytics, AI-assisted workflows, contextual risk scoring, and centralized visibility, security, IT operations, and compliance teams can focus on real risks, streamline investigations, and fulfill audit requirements without expensive add-ons or surprise charges.
For more information about how Graylog Security can help you comply with NIS2, contact us today.
