CVE-2026-1163: Lollms Session Expiration Bypass Vulnerability

CVE-2026-1163 Overview

An insufficient session expiration vulnerability exists in parisneo/lollms, a popular Large Language Model (LLM) framework. The application fails to invalidate active sessions after a password reset, allowing an attacker to continue using an old session token. This issue arises due to the absence of logic to reject requests after a period of inactivity and the excessively long default session duration of 31 days. The vulnerability enables an attacker to maintain persistent access to a compromised account, even after the victim resets their password.

Critical Impact

Attackers who have compromised session tokens can maintain unauthorized access to user accounts indefinitely, even after victims perform password resets, undermining fundamental account recovery security controls.

Affected Products

• parisneo/lollms (latest version at time of disclosure)

Discovery Timeline

• 2026-04-08 - CVE CVE-2026-1163 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-1163

Vulnerability Analysis

This vulnerability is classified under CWE-613 (Insufficient Session Expiration), which occurs when a web application permits an attacker to reuse old session credentials or session IDs for authorization. In parisneo/lollms, the session management implementation contains two critical flaws that compound to create a significant security weakness.

First, the application does not implement any session invalidation mechanism when a user performs a password reset operation. This means that any existing authenticated sessions remain valid and functional even after the account password has been changed. Second, the default session duration is configured to an excessive 31 days, providing attackers with an extended window of opportunity to exploit compromised session tokens.

The combination of these factors creates a scenario where standard account recovery procedures—such as resetting a password after discovering unauthorized access—fail to protect the user. An attacker who has obtained a valid session token through any means (such as session hijacking, XSS attacks, or network interception) can continue to access the victim's account unimpeded.

Root Cause

The root cause of this vulnerability stems from missing session lifecycle management in the authentication subsystem. The password reset functionality does not include logic to enumerate and invalidate all existing sessions associated with the user account. Additionally, there is no inactivity timeout mechanism to automatically expire sessions that have been idle, and the default session lifetime of 31 days is far longer than security best practices recommend for sensitive applications.

Attack Vector

The attack vector is network-based and requires the attacker to first obtain a valid session token for the target account. This could be achieved through various methods such as cross-site scripting (XSS) attacks, man-in-the-middle attacks on unencrypted connections, or physical access to the victim's device.

Once an attacker has obtained a valid session token, the following attack scenario becomes possible:

1. The attacker gains access to the victim's lollms account using the stolen session token
2. The victim notices suspicious activity and performs a password reset
3. Despite the password change, the attacker's session token remains valid
4. The attacker continues to have full access to the victim's account for up to 31 days
5. The victim believes their account is secured, unaware that unauthorized access persists

For technical details on this vulnerability, refer to the Huntr Bug Bounty Report.

Detection Methods for CVE-2026-1163

Indicators of Compromise

• Multiple active sessions for a single user account originating from different IP addresses or geographic locations
• Session activity continuing after a password reset event was logged
• Unusual API calls or data access patterns associated with long-lived session tokens
• Authentication logs showing session tokens created before the most recent password change still being used

Detection Strategies

• Implement logging that correlates session creation timestamps with password reset events to identify sessions that should have been invalidated
• Monitor for concurrent sessions from disparate locations or user agents that may indicate token theft
• Create alerts for sessions that exceed typical duration thresholds or show activity patterns inconsistent with normal user behavior
• Deploy application-level monitoring to detect API calls made with session tokens that predate credential changes

Monitoring Recommendations

• Enable verbose session logging including creation time, last activity time, and source IP addresses
• Implement real-time alerting on password reset events to trigger session audit reviews
• Establish baseline metrics for typical session durations and alert on outliers
• Consider implementing user-visible session management features that allow users to view and terminate active sessions

How to Mitigate CVE-2026-1163

Immediate Actions Required

• Review all active sessions in your lollms deployment and manually invalidate any suspicious or overly long-lived sessions
• Reduce the default session timeout from 31 days to a more reasonable value (typically 24 hours or less for sensitive applications)
• Implement additional authentication checks for sensitive operations until a patch is available
• Educate users about the limitation and advise them to manually log out of all devices if they suspect account compromise

Patch Information

Monitor the Huntr Bug Bounty Report and the official parisneo/lollms repository for patch releases. When a fix becomes available, update to the patched version immediately and invalidate all existing sessions to ensure any potentially compromised tokens are no longer functional.

Workarounds

• Configure a reverse proxy or web application firewall to enforce shorter session timeouts at the network layer
• Implement an external session management solution that can track and invalidate sessions based on password change events
• Deploy IP-based session binding to limit the effectiveness of stolen session tokens from different network locations
• Consider requiring re-authentication for sensitive operations regardless of session status

# Example: Reduce session timeout in web server configuration
# For nginx reverse proxy, add session timeout headers
location /lollms/ {
    proxy_pass http://localhost:9600/;
    proxy_set_header X-Session-Timeout "3600";
    proxy_cookie_flags ~ httponly secure samesite=strict;
}