Message deserialization XSS in lollms enables session hijack

TL;DR — A High-severity XSS in parisneo/lollms can let attacker-supplied message content execute as JavaScript in another user’s browser, risking session hijacking and account takeover.

What happened

lollms is a multi-user web application (FastAPI backend + Vue frontend) that provides a chat interface to LLM backends and related features like RAG, user management, and sharing.

CVE-2026-1116 describes a Cross-Site Scripting vulnerability in the from_dict method of the AppLollmsMessage class. The CVE record states the issue is caused by missing sanitization / HTML encoding of the content field when deserializing user-provided data, allowing an attacker to inject HTML/JavaScript that can execute in the context of another user’s browser.

XSS remains especially high-leverage in multi-user AI/web tooling because it targets identity-bearing browser sessions (tokens, admin panels, sharing features). The CVE record also calls out the potential for “wormable attacks,” which can rapidly amplify impact in collaborative apps.

Who is impacted

• Deployments running parisneo/lollms where the deployed version falls into the CVE record’s affected range (versions less than 2.2.0).
• Multi-user or shared instances where one user’s content can be rendered in other users’ sessions (e.g., shared chats, admin review workflows, moderation, or collaboration features).
• Higher-risk environments where lollms is exposed to untrusted users or content sources (public sign-ups, partner access, or internet-reachable deployments).

What to do now

• Follow vendor remediation guidance and apply a release that is not in the CVE record’s affected range (the CVE lists versions less than 2.2.0 as affected).
• Inventory where lollms is deployed (VMs, containers, and packaged artifacts) and confirm the exact running version.
• Use the CVE record’s patch reference to validate that your deployed build includes the fix (commit 9767b882dbc893c388a286856beeaead69b8292a) if you maintain forks or custom builds.
• If compromise is suspected, treat this as potential session exposure: rotate credentials/tokens accessible to impacted user sessions and review for unexpected administrative actions or new/modified content that could be carrying payloads.