Shadow AI: Scanning Exposed Self-Hosted AI Tools (Ollama, Langflow, ComfyUI) with Nuclei

CISOs rarely find these stacks through a planned audit. They stumble on them by accident: a routine scan flags port 11434 open on a public IP, or a developer casually mentions in a meeting that they "spun up a quick image generation tool for the marketing team." Dig a little and there it is, a ComfyUI instance reachable from the internet, no password, full generation history, and sometimes the cloud account credentials used for GPU billing sitting right there. This is shadow AI: self-hosted AI stacks stood up by engineering teams outside any inventory, frequently exposed with no authentication by default.

The problem: AI panels that are open by default

Most of the popular open source AI tools in 2026 share the same design flaw: authentication is not enabled by default, it has to be configured explicitly. On a developer's laptop that is a non-issue. The day the same container gets deployed on a cloud VM with an overly permissive firewall rule (or none at all), it becomes a public panel.

The most common targets:

• Ollama (default port 11434): a local inference server for language models. Its REST API (/api/tags, /api/generate) requires no authentication out of the box. An open instance lets anyone list the loaded models, generate content under the organization's name, and burn through GPU and CPU resources at will.
• ComfyUI: a workflow-based image generation interface. Its API exposes graph execution, including custom nodes capable of running arbitrary code.
• Langflow: a visual builder for LLM agents. Several versions have shipped code-validation endpoints reachable without authentication, enabling remote code execution.
• AnythingLLM: a self-hosted retrieval augmented generation (RAG) platform. An open instance exposes indexed documents, often sensitive internal ones, along with the API keys configured for the model providers behind it.
• LiteLLM: a routing proxy in front of multiple model providers. A poorly protected instance leaks upstream API keys or allows quota abuse billed straight to the company.
• Gradio: the widely used library for prototyping AI demos. Many instances run in debug mode, which allows server-side Python execution.

None of these tools were built to be dangerous. They were built for local use or demoing, then pushed into production by teams that never applied the hardening reflexes they would apply to a regular web server.

Cataloguing the April 2026 template wave

The detection community tracked this shift closely: a wave of Nuclei templates tagged exposure, llm, and ai landed through the first half of 2026, covering exactly these panels. Before writing anything yourself, the first move is to catalogue what already exists:

nuclei -tags exposure,llm,ai -tl

This lists every matching template without running a single scan. Typical entries cover:

• unauthenticated Ollama interfaces (the /api/tags endpoint returning the loaded model list);
• ComfyUI instances exposing the workflow submission API;
• Langflow panels reachable without a valid session;
• AnythingLLM, LiteLLM, and Gradio dashboards left in open mode.

This list keeps growing: the wave is ongoing because new AI tools ship every month and tend to follow the same exposure pattern. One caution worth repeating: never mix community-sourced cataloguing with directly reusing unlicensed proof-of-concept code pulled from a repository. The same licensing rigor that applies to classic CVE detection applies here too.

Example scan

On a perimeter to audit, the baseline command looks like this:

nuclei -u https://target.example.com -t http/exposed-panels/ -tags llm

It runs every template in the exposed-panels folder filtered on the llm tag. To target a specific Ollama exposure on a given host:

nuclei -u http://target.example.com:11434 -t http/exposed-panels/ollama-api-exposure.yaml

A positive hit typically looks like this:

[ollama-api-exposure] [http] [high] http://target.example.com:11434/api/tags

That result is only useful if it reflects a real leak, which brings us to the most common trap with this class of scan.

The false-positive trap: presence is not exposure

An Ollama panel answering on port 11434 is not automatically an incident. Three very different scenarios can produce the same raw signal:

1. The real leak: the port is open to the internet, no authentication is requested, and the /api/tags endpoint genuinely returns the model list in plain view. That is a real exposure.
2. The scan-path false positive: the scanner reaches the port, but a reverse proxy in front enforces basic auth or a client certificate on the actual production path. Scanning the container's raw port directly (an internal scan aimed at the wrong hop) bypasses that proxy artificially and does not reflect what an external attacker would actually see.
3. The legitimately gated panel: the endpoint exists and answers an unauthenticated request with a 401 or a redirect to a login form. The mere presence of the service must never be confused with actual exposure.

The rule to apply every time: a good matcher never settles for "the port responds" or "the banner contains a product name." It has to match on the real unauthenticated behavior: a 200 response carrying the actual business payload (the model list, the indexed documents, the executable workflow), not a bare status code or a bare service presence. That is the exact same discipline as writing a template for a classic CVE: the proof has to be empirical, not declarative.

Industrializing instead of scanning once

Shadow AI is not a problem that gets solved by a one-off audit. New stacks appear sprint after sprint, frequently bypassing any IT validation. Treating this risk as a bug-bounty-style one-shot (scan once, produce a report, move on) guarantees missing the next instance spun up three weeks later.

The approach that actually holds up over time:

• Recurring scans across the full known attack surface, not just declared assets. AI stacks tend to show up on subdomains or IPs that were never formally inventoried.
• Severity and tag filtering inside the processing pipeline: an exposed LiteLLM instance leaking API keys does not carry the same urgency as a Gradio instance in debug mode on an isolated test environment. Automated severity triage keeps the security team from drowning in alerts of unequal weight treated as if they were equal.
• Continuous integration of new templates: every fresh addition to the llm/ai wave should flow into the pipeline without manual work, otherwise you reproduce the same lag seen with classic CVEs, where the gap between publication and detection is the exposure window itself.

In summary

Shadow AI is not an exotic risk category, it is a familiar problem (unauthenticated admin panels exposed to the internet) reapplied to a new generation of tools growing faster than the hardening habits of the teams deploying them. Nuclei, through its exposure, llm, and ai tags, provides the means to detect this at scale, provided the matchers check real behavior and the scan runs as a recurring process rather than a one-time audit.

That is the discipline built into the ThreatClaw Nuclei feed: continuous coverage of the AI and shadow AI attack surface, prioritized by severity, with matchers validated to tell a genuinely open panel apart from a cosmetic false positive.