Model or dataset
CyberSunil/LLMVault avatar
CyberSunil/LLMVault

LLMVault: a deliberately vulnerable OWASP LLM Top 10 training range

An intentionally vulnerable OWASP LLM Top 10 training platform for AI Security, Prompt Injection, RAG Security, Agent Security, and GenAI penetration testing.

313 stars75 forksPythonMIT

At a glance

What is it?
LLMVault is an MIT-licensed Python lab that pairs 25 scripted LLM attack challenges with a Live Mode aimed at a real local Ollama model. The scripted tiers are reproducible teaching material; the Live Mode is the part that can actually surprise you, and the part with the least documentation.
Who is it for?
Adopt LLMVault if you are teaching or learning LLM attack classes and want a self-hosted range where flags reproduce on demand, and if you accept that the expert tier stays locked until the maintainer hands you a key. Do not adopt it as a production component or as a scanner for your own systems; it is a target, not a tool, and the README warns against exposing it or reusing its code.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 36 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap LLMVault is trying to fill

Most teams learning LLM security read the OWASP Top 10 for LLM Applications and then have nowhere to practise. The categories are described in prose, the payloads circulate in blog posts, and the only place to try them is a system you are not allowed to break. LLMVault's answer is a deliberately vulnerable application in the WebGoat tradition: the README describes it as "WebGoat / KubeGoat, but for AI", and the repository topics include ctf, docker and vulnerable-lab. The intended audience is narrow and identifiable. It is for red teamers who want repetitions against known attack shapes, for application security engineers who need to see how a RAG retrieval bug or an over-permissioned tool actually behaves, and for trainers who need a lab that produces the same flag every time a class runs it. The README repeats the warning that everything inside is intentionally insecure and should be self-hosted for authorised education only, not exposed to the internet and not reused in production. That constraint is the whole premise, not a disclaimer bolted on at the end.

Play Mode: 25 labs, three tiers, scripted assistants

The scored range is called Play Mode and it contains 25 labs in three tiers. The core tier maps one lab to each of the ten OWASP LLM Top 10 (2025) categories, from LLM01 Prompt Injection (a lab called The Obedient Assistant, using direct instruction override) through LLM10 Unbounded Consumption (Denial of Wallet, described as runaway generation plus a leaky error). The advanced tier adds ten multi-turn challenges that unlock only after all ten core labs are solved, and the README is explicit that these are conversational: "no single message wins". Examples include Roleplay Unchained for persona-escalation jailbreaking, The Note Keeper for stored or second-order injection, Confused Deputy for agent tool-chaining toward internal metadata, and The Oracle for query-based model extraction. The expert tier holds five labs that model real-world disclosed vulnerability classes, and the README states plainly that these are simulated: the application recognises a known payload and returns a flag, and no real RCE, SSRF or SQL execution occurs. The mechanism that makes this teachable is scripting. Because the assistants are scripted, flags reproduce every time, which is what lets a learner repeat a technique until it sticks. The trade-off is that a scripted bot cannot teach you to read an unfamiliar model's behaviour; it teaches you the shape of the attack and nothing about variance.

Live Mode and the local Ollama dependency

Version 2.0.0, released 2026-08-10 and titled Live Mode and Mission Command, adds the part that is not scripted. Live Mode points the same attacks at a real model running on the operator's machine. The README names Ollama as the runtime, gives roughly 2 GB as the model size, and states that CPU is fine. The secret is minted fresh per session, there is no flag to look up, and the README says there is no score and no penalties, with unlimited hints. Three scenarios are listed: prompt injection, indirect injection via an image, and downstream output handling. The honest framing in the README is that a real local model is "genuinely unpredictable, so yesterday's payload may die today". That sentence is the strongest argument for the mode and also the strongest warning about it. A scripted lab gives you a stable target and a stable lesson. A live model gives you a result that depends on the model, its version, its sampling settings and the day. If you are teaching a cohort and need every student to reach the same conclusion, Live Mode is the wrong instrument. If you want to find out whether a payload generalises past the bot you trained against, it is the right one. Note that the supplied material does not document which Ollama model tag is pulled, what generation parameters are used, or how the per-session secret is generated, so those are things to read in the code before you rely on them.

The expert tier ships as ciphertext, and that has consequences

The five expert labs are not in the repository in readable form. The README states they are AES-encrypted with Fernet into challenges/expert.enc, using a key derived from an Expert Access Key that is not in the repo. Cloning gives you ciphertext only. To unlock the tier a player must finish all core and advanced labs and then enter the key, which the maintainer hands out manually after the player shares their completion card. A wrong key fails authenticated decryption and reveals nothing. This is a deliberate design decision and it is worth being clear about what it does to the product. It converts the expert tier from software into a gated service. You cannot audit those five challenges before adopting the platform, you cannot run them offline in an air-gapped classroom without first obtaining the key, and you cannot fork the repository and expect the tier to work. It also means the tier's content is not covered by the MIT licence in any practical sense until you hold the key, because you do not possess the material. Whether that matters depends on your use case. For an individual learner chasing a challenge, the gate is the point. For an organisation that needs a repeatable internal curriculum with no external dependency on one person's availability, it is a real operational constraint.

Getting it running and what the material does not say

The repository is Python and the README advertises Python 3.10+ and Docker readiness, so the expected path is a container: build the image from the repository and run it locally, then open the dashboard and choose Play Mode or Live Mode. Live Mode additionally requires Ollama running locally with a model of roughly 2 GB. The supplied material stops short of listing the exact docker build and docker run invocations, the compose file name, the port the dashboard binds to, or the environment variables that point the application at Ollama. It also does not name a configuration file or a set of config keys. That is a documentation gap, not a hidden feature: the README is organised around the lab catalogue, the two modes and the v2.0.0 changes, and the operational detail lives in the repository rather than in the README text. Before you plan a workshop around this, read the Dockerfile and any compose file in the repository and confirm the bind address, because the README's warning about not exposing the application to the internet only holds if the default port is bound to localhost. The release history is short and easy to read: v1.0.0 on 2026-07-15, v1.1.0 on 2026-08-02 adding OWASP reference panels, a refreshed Labs page and hash-based flag verification instead of a stored plaintext match, then v2.0.0 on 2026-08-10 adding Live Mode, the dashboard, themes and milestone cards.

Where LLMVault is the wrong tool

Three cases stand out. First, do not treat it as an assessment tool for your own LLM application. It is a target range with its own scripted and simulated vulnerabilities; nothing in the repository material suggests it probes an external endpoint or produces findings about your system. Second, do not use the expert tier as the basis of a curriculum you need to reproduce on your own schedule. The manual key handoff and the maintainer's availability sit between you and five of the twenty-five labs. Third, be careful with the scripted tiers as evidence of anything. A lab that returns a flag whenever a known payload is recognised, as the README describes for the expert tier, teaches recognition rather than exploitation. A learner can finish those challenges without understanding why the payload works. The README's own mitigation is the paired defense: every lab shows the attack and then what would have stopped it, and v1.1.0 added per-category reference panels so you read the issue, its cause and what to watch for before attacking. That pairing is the part that carries the educational weight, and it is the part a learner can skip. If your goal is a credential or a score, LLMVault will give you one. If your goal is judgement about unfamiliar systems, the scripted tiers will not get you there on their own.

Alternatives and the difference in approach

The obvious comparison is the family the README itself invokes. WebGoat is a deliberately vulnerable Java web application for the OWASP Top 10 for web applications, and KubeGoat is a deliberately vulnerable Kubernetes cluster. Both are targets you attack to learn a class of bug, and LLMVault copies that model for LLM applications. The difference is the substrate. WebGoat's vulnerabilities are in code you can read and patch; LLMVault's are in prompt handling, retrieval, tool permissions and output rendering, so the same lab structure has to cover a system prompt leak and a vector-store ACL bypass in the same interface. The second comparison is a general-purpose LLM red-teaming framework, which takes the opposite approach: instead of hosting a vulnerable target, it sends generated probes at a model or application you supply and reports what came back. Those frameworks scale across targets and produce findings; LLMVault produces understanding of a fixed set of attack classes against a target it controls. If you need to test a specific deployed assistant, a probing framework is the right shape and LLMVault is not. If you need somewhere safe to learn what LLM08 vector and embedding weaknesses look like when retrieval ignores ACLs, a probing framework will not show you that, because it has no vulnerable retrieval layer to show you.

Licence, maintenance and what to check first

The repository is MIT licensed. That permits reuse and modification with the licence and copyright notice retained, but it does not change the security posture of the code itself: the README states that none of it should be reused in production, and an MIT grant on intentionally vulnerable code is exactly the situation where the licence and the advice point in different directions. Nothing here is legal advice, and if you plan to redistribute a modified copy, read the licence text and the README warning together. On maintenance, the observable facts are a first release in mid-July 2026, a second three weeks later, and v2.0.0 in early August 2026. Three releases in under a month is a fast-moving project, which cuts both ways: the lab catalogue is expanding, and the interfaces you script against may move with it. The cost of upgrading is mostly in Live Mode, because a new model tag or a changed prompt harness can invalidate payloads you have already tuned, while Play Mode is described as untouched between versions. The first thing to verify is the container build on your own host and the default bind address, since the entire safety argument rests on the range staying local. The second is whether Ollama is already available to you and whether a roughly 2 GB model download is acceptable on the machines you plan to use. The third is whether you can obtain the Expert Access Key, because if you cannot, you are adopting a twenty-lab platform with five labs you will never see.

Editorial conclusion

Adopt LLMVault if you are teaching or learning LLM attack classes and want a self-hosted range where flags reproduce on demand, and if you accept that the expert tier stays locked until the maintainer hands you a key. Do not adopt it as a production component or as a scanner for your own systems; it is a target, not a tool, and the README warns against exposing it or reusing its code. Before committing, verify the Docker setup on your host, confirm the Python version satisfies the stated 3.10+ requirement, and check whether the Live Mode model download fits your disk and network budget.

Official sources

  1. CyberSunil/LLMVault on GitHub
  2. Issues
  3. License: MIT
  4. README
  5. Releases
Community notes

Community notes