CVE-2026-1116: parisneo/lollms XSS Vulnerability

CVE-2026-1116 Overview

A Cross-site Scripting (XSS) vulnerability was identified in the from_dict method of the AppLollmsMessage class in parisneo/lollms prior to version 2.2.0. The vulnerability arises from the lack of sanitization or HTML encoding of the content field when deserializing user-provided data. This allows an attacker to inject malicious HTML or JavaScript payloads, which can be executed in the context of another user's browser. Exploitation of this vulnerability can lead to account takeover, session hijacking, or wormable attacks.

Critical Impact

Attackers can inject malicious scripts that execute in victim browsers, potentially leading to account takeover, session hijacking, and wormable attacks that could spread across the platform.

Affected Products

• parisneo/lollms versions prior to 2.2.0
• AppLollmsMessage class from_dict method
• Social and direct messaging components in lollms backend

Discovery Timeline

• 2026-04-12 - CVE-2026-1116 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-1116

Vulnerability Analysis

This XSS vulnerability exists in the deserialization process of the AppLollmsMessage class. When user-provided data is processed through the from_dict method, the content field is not properly sanitized or HTML-encoded before being rendered in the browser. This missing input sanitization creates a stored XSS attack surface where malicious payloads persist and execute whenever other users view the affected content.

The attack requires no authentication from the attacker's perspective, though it does require user interaction from the victim to trigger the payload. The scope is changed, meaning the vulnerability impacts resources beyond its security scope, affecting other users' sessions and browser contexts. This characteristic makes it particularly dangerous as it enables wormable attacks where compromised sessions can automatically propagate the malicious payload to additional victims.

Root Cause

The root cause is a missing input sanitization vulnerability (CWE-79) in the deserialization logic. The from_dict method directly accepts and processes user-controlled data in the content field without applying any HTML encoding, escaping, or sanitization. This allows raw HTML and JavaScript to be stored and later rendered in other users' browsers when viewing messages.

Attack Vector

The attack vector is network-based, allowing remote exploitation. An attacker can craft a malicious message containing JavaScript payloads in the content field. When this message is deserialized and rendered for other users, the embedded script executes in their browser context. The attack requires user interaction (the victim must view the malicious content) but requires no privileges from the attacker.

Potential attack scenarios include:

• Injecting scripts that steal session cookies or authentication tokens
• Creating self-propagating worm payloads that spread through the messaging system
• Phishing attacks by manipulating the page content to capture credentials
• Redirecting users to malicious external sites

The security patch demonstrates the fix by implementing bleach library for input sanitization:

 from fastapi import APIRouter, Depends, HTTPException, status
 from ascii_colors import trace_exception
 import re
+import bleach
 from backend.settings import settings
 from backend.task_manager import task_manager
 from backend.tasks.social_tasks import _respond_to_mention_task, _moderate_content_task

Source: GitHub Commit Update

The patch also applies sanitization to the direct messaging component:

 from werkzeug.utils import secure_filename
 from datetime import datetime
 from pydantic import BaseModel, Field
+import bleach

 from backend.db import get_db
 from backend.db.models.user import DBUser as User

Source: GitHub Commit Update

Detection Methods for CVE-2026-1116

Indicators of Compromise

• Unusual JavaScript patterns in stored messages, particularly <script> tags or event handlers like onerror, onload, onclick
• Messages containing encoded JavaScript payloads (Base64, URL encoding, Unicode escaping)
• Unexpected outbound network requests from user browsers to unknown domains
• Session anomalies such as concurrent sessions from different geographic locations

Detection Strategies

• Implement web application firewall (WAF) rules to detect XSS patterns in message content
• Monitor application logs for messages containing HTML tags or JavaScript event handlers
• Deploy browser-based security monitoring to detect anomalous script execution
• Review stored message content for suspicious patterns matching known XSS vectors

Monitoring Recommendations

• Enable Content Security Policy (CSP) headers with violation reporting to detect XSS attempts
• Monitor for unusual authentication patterns that may indicate session hijacking
• Track changes in user account settings or profile data that could indicate compromise
• Implement real-time alerting for messages containing known XSS payload signatures

How to Mitigate CVE-2026-1116

Immediate Actions Required

• Upgrade parisneo/lollms to version 2.2.0 or later immediately
• Review stored message data for potential malicious payloads and sanitize existing content
• Implement Content Security Policy (CSP) headers to restrict inline script execution
• Force session invalidation for all users to mitigate potential ongoing session hijacking

Patch Information

The vulnerability has been addressed in parisneo/lollms version 2.2.0. The fix implements input sanitization using the bleach library to properly sanitize user-provided content before storage and rendering. The security patch is available in commit 9767b882dbc893c388a286856beeaead69b8292a.

Additional details about this vulnerability can be found in the Huntr Bug Bounty Listing.

Workarounds

• Deploy a reverse proxy or WAF to filter XSS patterns before they reach the application
• Implement server-side content sanitization at the API gateway level
• Restrict access to social and direct messaging features until patching is complete
• Enable strict Content Security Policy headers with script-src 'self' directive

# Example nginx configuration for CSP headers
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';" always;

# WAF rule to block common XSS patterns (example for ModSecurity)
SecRule ARGS "@rx <script[^>]*>" "id:1001,phase:2,deny,status:403,msg:'XSS Attack Detected'"