CVE-2024-6674: Lollms Web UI Auth Bypass Vulnerability

CVE-2024-6674 Overview

CVE-2024-6674 is a Cross-Origin Resource Sharing (CORS) misconfiguration in parisneo/lollms-webui affecting all versions prior to 10. The flaw permits malicious origins to issue cross-origin requests against the application and read responses containing logs, browser session data, and configuration settings that may include private API keys for third-party services. Attackers can also leverage the misconfiguration to perform state-changing actions on behalf of an authenticated user, including deleting projects or sending messages. The vulnerability is tracked under CWE-346: Origin Validation Error and impacts both confidentiality and integrity of the affected instance.

Critical Impact
Attackers who lure an authenticated lollms-webui user to a malicious page can exfiltrate API keys, session data, and logs, and execute privileged actions in the user's context.

Affected Products

parisneo/lollms-webui versions prior to 10
Deployments exposing the lollms-webui HTTP interface to authenticated users
Instances storing third-party API keys in lollms-webui settings

Discovery Timeline

2024-10-29 - CVE-2024-6674 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-6674

Vulnerability Analysis

The lollms-webui application implements an overly permissive CORS policy on its HTTP API. The server reflects or accepts arbitrary Origin header values and returns Access-Control-Allow-Credentials: true, which instructs browsers to include the user's session cookies on cross-origin requests. As a result, any third-party site can issue authenticated requests against a victim's local or remote lollms-webui instance and read the responses.

Because lollms-webui stores configuration data — including API keys for external large language model providers — and exposes endpoints for log retrieval and user actions, the impact extends beyond information disclosure. Attackers can also send POST or DELETE requests that mutate state, such as deleting projects or sending chat messages, because the browser attaches authentication automatically.

The attack requires user interaction (UI:R): the victim must visit an attacker-controlled web page while authenticated to lollms-webui.

Root Cause

The root cause is improper origin validation in the application's CORS handling. Rather than maintaining an allowlist of trusted origins, the server treats requests from any origin as legitimate while still permitting credentialed responses. This violates the browser's same-origin protections that normally isolate sensitive data from untrusted sites.

Attack Vector

Exploitation proceeds entirely over the network through the browser. The attacker hosts a page containing JavaScript that issues fetch() calls with credentials: 'include' to the victim's lollms-webui endpoint. When a logged-in victim loads the page, the browser sends authenticated requests, the server returns sensitive data with permissive CORS headers, and the attacker's script reads the response and exfiltrates it. The fix in commit c1bb1ad19752aa7541675b398495eaf98fd589f1 restricts the allowed origins. Technical details are documented in the Huntr bounty record.

Detection Methods for CVE-2024-6674

Indicators of Compromise

Unexpected outbound requests from user browsers to lollms-webui endpoints containing Origin headers that do not match deployed hostnames
HTTP responses from lollms-webui containing Access-Control-Allow-Origin values that reflect arbitrary attacker-controlled origins paired with Access-Control-Allow-Credentials: true
Unexplained log retrievals, settings reads, or project deletions in lollms-webui audit trails
Use of exfiltrated third-party API keys from unfamiliar source IPs against external LLM providers

Detection Strategies

Inspect lollms-webui access logs for cross-origin requests where the Origin header does not match the deployment's canonical URL
Correlate authenticated API calls with the Referer header to identify requests initiated from unrelated web pages
Monitor third-party LLM provider dashboards for anomalous API key usage that may indicate stolen credentials

Monitoring Recommendations

Capture full HTTP request and response headers for lollms-webui traffic and alert on permissive CORS reflections
Track configuration read endpoints and settings-export endpoints for access volume outside normal user behavior
Forward webui application logs to a centralized analytics pipeline to enable cross-session correlation and retention

How to Mitigate CVE-2024-6674

Immediate Actions Required

Upgrade parisneo/lollms-webui to version 10 or later, which contains the fix from commit c1bb1ad19752aa7541675b398495eaf98fd589f1
Rotate all third-party API keys stored in lollms-webui settings under the assumption they may have been exposed
Restrict network access to lollms-webui instances so they are not reachable from arbitrary browser sessions on the public internet
Invalidate active user sessions after upgrading to force re-authentication

Patch Information

The maintainers fixed the issue in version 10 via the GitHub commit c1bb1ad, which tightens the CORS configuration to validate request origins against an allowlist rather than accepting arbitrary values.

Workarounds

Place lollms-webui behind a reverse proxy that strips or validates the Origin header and enforces a strict allowlist
Bind the lollms-webui service to localhost and require users to reach it through an authenticated tunnel or VPN
Remove sensitive third-party API keys from lollms-webui settings until the upgrade is applied and rely on environment-scoped secrets instead

bash

# Example nginx reverse-proxy snippet enforcing a CORS allowlist
map $http_origin $cors_ok {
    default "";
    "https://lollms.internal.example.com" $http_origin;
}

server {
    listen 443 ssl;
    server_name lollms.internal.example.com;

    location / {
        if ($cors_ok = "") { return 403; }
        add_header Access-Control-Allow-Origin $cors_ok always;
        add_header Access-Control-Allow-Credentials "true" always;
        add_header Vary "Origin" always;
        proxy_pass http://127.0.0.1:9600;
    }
}