A community threat catalog for LLM apps, mapped for the classroom.

Crafted input that manipulates an LLM into ignoring its intended instructions or safety constraints. Direct injection comes straight from the user; indirect injection is hidden in content the model reads later — a webpage, a document, a tool's returned data.

It's the entry point for most other LLM-specific attacks: a successful injection can be the first step toward triggering excessive agency, leaking a system prompt, or exfiltrating sensitive data.

Vulnerabilities introduced through third-party components — pretrained base models, fine-tuning datasets, LoRA adapters, plugins, or hosting/serving infrastructure — rather than code the organization wrote itself.

An LLM application often inherits risk from a dozen upstream parties it never directly vetted; a compromised or poisoned upstream artifact can propagate silently downstream.

Deliberate manipulation of training, fine-tuning, or embedding data to introduce vulnerabilities, biases, or backdoors that later affect the model's behavior, security, or ethical performance.

Unlike a runtime attack, poisoning happens upstream and can be extremely difficult to detect after the fact — the model simply behaves as it was (mis)trained to.

Insufficient validation, sanitization, or escaping of LLM-generated output before it's passed to a downstream component — a browser, a shell, a database query, another service.

This turns an LLM into an attacker-controlled input source for the rest of the system — the same class of bug as classic XSS or SQL injection, just with the model as the delivery mechanism.

An LLM-based system granted more autonomy, permissions, or tool access than its actual task requires — so a manipulated or simply mistaken output can trigger a damaging real-world action.

The blast radius of a bad output scales with what the system is allowed to do. A chatbot that can only draft text is low-risk; one that can also send emails, execute code, or move funds is a very different system.

Confidently stated, false or misleading output — including hallucinated facts, citations, or code — combined with users' tendency to over-trust fluent-sounding answers.

Unlike a crashed system, a confidently wrong answer often isn't flagged as a failure at all — it's the risk that looks least like a security incident and is easiest to overlook.

The model reveals personal data, proprietary business information, or credentials — whether memorized from training data, present in the current conversation context, or accessible through a connected system.

Disclosure can happen even without an attack — through ordinary over-sharing in a poorly scoped prompt or a model that memorized more of its training data than intended.

The hidden instructions that configure an LLM application's behavior (its "system prompt") are unintentionally revealed to a user — exposing internal logic, business rules, or occasionally embedded secrets.

A leaked system prompt hands an attacker a map of the application's guardrails, making every other attack on the list easier to aim.

Security gaps in how vectors and embeddings are generated, stored, and retrieved in retrieval-augmented generation (RAG) systems — including insufficient access control on a shared vector database or poisoned documents entering the retrieval index.

RAG is meant to ground a model in trustworthy data; if the retrieval layer itself is compromised or under-permissioned, it becomes a new way to feed the model bad or unauthorized information.

Insufficient limits on how much a user (or an automated agent) can make an LLM system compute or spend — covering both denial-of-service (resource exhaustion) and "denial-of-wallet" (runaway API cost) attacks.

LLM inference is expensive per-request in a way traditional web requests usually aren't, so a lack of rate-limiting can be a direct, fast-moving financial risk, not just an availability one.