LLaMA-Factory RCE Flaw (CVE-2026-58116): An Exposed Web UI Lets Anyone Hijack the Server

A critical flaw has been found in LLaMA-Factory, a popular tool for training and fine-tuning AI models for your own needs. If its control screen (the WebUI) is reachable from outside, an attacker can simply make it load a malicious model and take over the server. The flaw is tracked as CVE-2026-58116, and its severity is rated 9.8 out of 10 (CVSS v3.1), among the highest possible. It was published on June 30, 2026 by the vulnerability database VulnCheck and the U.S. NVD (National Vulnerability Database). It was found and reported by researcher h3nrrrych4u, who released a write-up with proof-of-concept code the same day.

The troubling part is that no fix is available as of this writing. Every version up to and including the latest 0.9.5 is affected, and the developer has not shipped a patch. LLaMA-Factory is a widely used open-source tool among AI engineers, with more than 50,000 stars on GitHub. For anyone who trains AI themselves, or who runs that training screen on a server, this is not someone else's problem.

* The "WebUI" is LLaMA-Factory's browser-based control screen. If anyone outside can reach this screen, the risk jumps sharply.

Who is at risk, and what is the damage?

The people who go after this hole are attackers scanning the internet for exposed AI training screens. LLaMA-Factory's training screen is easy to spin up, but depending on the settings it can end up reachable from beyond your own machine — your office network or even the open internet. Attackers hunt down these "screens you can touch from outside" automatically and target them the moment they find one. If the screen has no login in front of it, whoever reaches it can operate it freely.

What the attacker does is almost anticlimactically simple. They type the location of a booby-trapped AI model into the "model path" field and press "load" or "start training" (or trick someone into doing so). The attack program bundled with that model then runs in the background, right as the model is being loaded. As proof, the reporter h3nrrrych4u launched the system calculator app on the target server. Being able to pop a calculator means the same method can run any command at all.

Once arbitrary commands can run, that server is effectively taken over. An attacker can steal the valuable training data, grab keys that lead into other internal systems, hijack the compute to mine cryptocurrency, or plant other malware. The targets are the engineers running LLaMA-Factory and the companies or labs operating it. Because AI training tends to gather expensive GPU servers and confidential data in one place, a takeover hurts badly.

What LLaMA-Factory is, and why it concerns so many people

LLaMA-Factory is an open-source tool that lets you train and adapt existing large language models (the engines behind chat AIs like ChatGPT) to your own needs without writing difficult code. This "retraining an AI on your own data" is called fine-tuning, and it is widely used to build an AI that knows your internal documents or is strong in a specific field. A key reason for its popularity is its WebUI (control screen), which lets even non-programmers run training with button clicks in the browser.

The user base is large. The project's GitHub page has over 50,000 stars (the "favorites" users give a project) — among the biggest for an AI tool. It is used broadly wherever people want to grow their own AI: university labs, startups, and enterprise AI teams. In other words, this concerns everyone who trains AI themselves, and teams that put the training screen on a shared server to streamline work are especially exposed to this weakness.

Why does merely loading a model run commands?

At its core, this flaw is a settings problem: it runs the program from an untrusted location without any check. Formally it is classified as code injection (CWE-94) and inclusion of functionality from an untrusted source (CWE-829).

AI models are typically placed on sites like Hugging Face (a model-sharing site, like an App Store for AI models) and loaded by specifying the "name of the location." The popular AI library used here, transformers, has a setting called trust_remote_code that decides whether to run the Python program bundled with a model. By design, you should turn this on yourself only when you trust the model; off is the safe default.

However, according to VulnCheck's analysis, LLaMA-Factory passes the model location a user typed into the screen straight into the loading routines (AutoTokenizer.from_pretrained() and AutoModel.from_pretrained()) without any validation, with trust_remote_code=True (i.e., trust external code = on) hardcoded. As a result, a configuration program bundled with the model (in the proof of concept, a file named configuration_poc.py) runs as part of loading. An attacker places a booby-trapped model on a sharing site in advance and only needs that location typed in to run any command on the victim's server.

The same "trust_remote_code is hardcoded on" weakness has appeared in other AI infrastructure software too. The similar vLLM flaw (CVE-2026-4944) we covered earlier was the same pitfall: external code ran even when the user thought they had turned it off. Knowing this as a weakness common across AI tools makes the right defenses easier to grasp.

Am I at risk? A quick situation chart

Your risk depends heavily on two things: how far you have opened the training screen (WebUI) to the outside, and whether the models you load come from a trusted source. Match your situation against the chart.

* "Exposed to the internet" includes launching the screen on 0.0.0.0 or pushing it out via Gradio's share-link feature. Exposure can happen unintentionally, so check your scope first.

What you should do now

Since no fix is out yet, the available defenses center on closing the attack's entry points. In order of priority:

First and foremost, do not expose the training screen (WebUI) externally. Check whether it is reachable by anyone from the internet or a broad office network, and if you don't need that, run it only on your own machine (localhost). If you truly must share it among several people, you need to wall it off — put a login in front of the screen and limit which devices can connect. Avoid casually using the share-link feature of Gradio (the component behind LLaMA-Factory's screen).

Next, do not load models of unknown origin. Even if someone on social media or a forum recommends "load the model at this location," do not type it in if you can't confirm the provider is trustworthy. The whole problem here is that the program runs on its own even for models you don't trust. This is the same structure as a supply-chain attack (an attack on the supply chain) that hides malicious code in the parts (libraries) a program uses behind the scenes; we lay out the mindset for defending against it in our OSS supply chain scanner.

On top of that, keep a close eye on the official LLaMA-Factory repository and its security advisories page, and update promptly once a fix ships. The reporter points out that trust_remote_code should default to off and be enabled only when the user chooses to, through a safe method. Running training in a dedicated environment separated from your everyday workspace (a container or a throwaway virtual machine) keeps the damage minimal even if a takeover does happen.

Frequently asked questions

Summary

CVE-2026-58116 is a flaw in LLaMA-Factory, a popular tool for fine-tuning AI: it loads the model location a user types in without validation, and its setting to run external code is hardcoded on, so simply loading a malicious model lets an attacker run any command on the server. If the training screen is exposed externally and has no login, anyone can take it over remotely, and the severity is rated at the top tier of 9.8.

No fix is available yet. First, check whether your training screen is exposed externally, and don't load models of unknown origin. Then watch the official security advisories and apply countermeasures as soon as they appear. As more teams grow their own AI in-house, the safety of "the training tools themselves" will be questioned more often.

References

• ・NVD — CVE-2026-58116
• ・VulnCheck — LLaMA-Factory Remote Code Execution via WebUI Model Path
• ・h3nrrrych4u — Proof of concept and write-up (GitHub Gist)
• ・LLaMA-Factory official repository (GitHub)
• ・LLaMA-Factory security advisories
• ・Hugging Face transformers — about trust_remote_code
• ・MITRE — CWE-94 (Code Injection)
• ・MITRE — CWE-829 (Inclusion of Functionality from Untrusted Control Sphere)