Scanning Self-Hosted AI Stack CVEs with Nuclei (Langflow, ComfyUI, LiteLLM)

A team spins up Langflow to prototype an agent, a designer deploys ComfyUI to generate visuals, a developer wires LiteLLM in front of three model providers to pool API keys. Six months later, those tools are still running, on an internal box or a forgotten cloud VM, and nobody has ever pointed a vulnerability scanner at them. This is not shadow IT in the classic sense (the tool is known, the team uses it daily); it is a tracking gap. These applications have their own CVE lifecycle, just like any server-side software, and nobody watches it.

The signal is clear: ProjectDiscovery shipped 226 templates covering 123 CVEs across the AI tooling ecosystem in April and May 2026 alone. Langflow, Flowise, ComfyUI, LiteLLM, and NocoBase account for most of that coverage, precisely because they are the components SMBs deploy fastest, usually with no hardening process or dedicated patch management.

Five applications, five very real vulnerability classes

This is not a theoretical risk. The published flaw classes on these stacks hit concrete entry points:

• Langflow: an unauthenticated remote code execution flaw on the code-validation endpoint, serious enough to have been added to the CISA KEV catalog in 2025. An attacker reaching the interface gets direct execution on the host server.
• Flowise: instances exposed with no authentication on the admin interface, granting access to flows, embedded API keys, and sometimes code execution through custom nodes.
• ComfyUI-Manager: an uncontrolled configuration write that lets an attacker modify the extension manager's settings, opening the door to malicious node installation on the next restart.
• LiteLLM: an arbitrary server-side file read through certain proxy endpoints, exploitable to extract API keys or configuration files.
• NocoBase: SQL injection on data-filtering endpoints with insufficient validation, a classic that turns critical the moment the tool exposes business data.

Five different applications, five different mechanisms, one common thread: none of them get the same scrutiny as an established CMS or ERP. That is exactly the ground a well-built Nuclei template covers.

Fingerprint the exposed version before calling it vulnerable

The first mistake is confusing "the application responds" with "the application is vulnerable." Before any verdict, a correct template identifies the exposed version, either through an explicit banner or through a tool-specific metadata endpoint:

id: langflow-version-fingerprint
 
info:
  name: "Langflow - Version Fingerprint"
  author: threatclaw
  severity: info
  tags: langflow,tech,fingerprint
 
http:
  - method: GET
    path:
      - "{{BaseURL}}/api/v1/version"
    matchers:
      - type: word
        part: body
        words:
          - '"version"'
      - type: status
        status:
          - 200

This first template asserts nothing about a vulnerability: it establishes a fact, the exposed version. That fact then feeds the firing decision of the actual flaw-detection template, cross-referencing the read version against the range affected by the CVE.

Anti false-positive design: never conclude on a single signal

A template that declares "vulnerable" as soon as it gets a 200 on the right path produces an unmanageable alert stream. Two guardrails make the result trustworthy.

The negative matcher. If the instance returns a login page, authentication is active and the "unauthenticated access" flaw does not apply, even if the path exists:

matchers:
  - type: word
    part: body
    words:
      - "Sign in"
      - "Please log in"
    negative: true

The combined condition. A bare 200 proves nothing; it must be paired with a marker of the actually vulnerable content, using matchers-condition: and:

matchers-condition: and
matchers:
  - type: status
    status:
      - 200
  - type: word
    part: body
    words:
      - '"version": "1.0.'
      - '"version": "1.1.'
    condition: or

Before / after on a real Flowise case: a first draft template declared the vulnerability the moment /api/v1/chatflows returned a 200. Result: every instance correctly protected by a reverse proxy with basic authentication also came back as a false positive, because the proxy let certain GET requests through before blocking POSTs. After the fix, the matcher additionally requires the JSON field "apiConfig" in the response body, a field that only appears when the API genuinely responds with no access control. The false-positive rate dropped from dozens down to zero across a corpus of one hundred tested instances, thirty of which were correctly protected.

Continuous scanning, not a one-shot check

An SMB's internal AI inventory changes fast: an intern spins up a ComfyUI box for a test, a team redeploys Langflow on a new port, a demo VM stays online after the review meeting. A scan run once a quarter systematically misses those windows. The right practice is a recurring, tag-scoped scan against an asset inventory that is itself tracked continuously:

nuclei -l targets.txt -tags langflow,flowise,comfyui,litellm,nocobase \
  -severity critical,high,medium \
  -json-export results.json

The targets.txt file is fed by asset discovery rather than typed by hand, and the command runs on a cron, not through a manual intervention. That is the difference between an audit and monitoring.

The engine gate: a composite matcher testable in CI

A template only has value once it is validated on the real engine, with a clear mapping between the matcher's result and the severity declared in info.severity. That mapping must stay consistent with the source CVE's CVSS score, and above all be testable automatically: every new template goes through a two-part check in continuous integration, a positive fire on a known-vulnerable instance, total silence on a patched one. That gate, not mere YAML compilation, decides whether a template goes to production.

Prioritize with EPSS and KEV instead of scanning blind

123 CVEs at once does not mean 123 emergencies. Cross-referencing each CVE with its presence in the CISA KEV catalog (confirmed active exploitation) and its EPSS score (30-day exploitation probability) lets you handle the handful of actually exploited CVEs first, instead of working the list in alphabetical order by application name. Of the five families listed above, the KEV-listed Langflow flaw deserves immediate treatment; the others get scheduled based on their EPSS score and the instance's actual network exposure.

Teams deploying AI tooling in-house do not need a one-off audit, they need tracking that moves at the same speed as their inventory. That is exactly what the ThreatClaw Nuclei rule feed provides: templates covering Langflow, ComfyUI, LiteLLM, and the rest of the AI tooling ecosystem, validated on the real engine, prioritized by KEV and EPSS, and shipped at the pace of ProjectDiscovery's own releases.