Loading vulnerability…
Unauthenticated SSRF in LoLLMs WEBUI /api/proxy
CVE-2026-33340 is a critical server-side request forgery vulnerability in LoLLMs WEBUI, affecting all known existing versions at the time of publication. The flaw is in the unauthenticated POST /api/proxy endpoint, referenced in lollms/server/endpoints/lollms_apps.py (lines 443-450 in the cited repository context). The endpoint accepts a user-supplied URL and causes the server to perform an arbitrary outbound GET request to that destination. Proof-of-concept material shows that sending JSON such as {"url":"http://<attacker-controlled-host>"} to /api/proxy results in the server fetching the remote resource and returning the fetched content, confirming SSRF behavior. Because the request is made by the server, an attacker can abuse the application as a proxy to reach resources not directly accessible from the Internet.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows a remote, unauthenticated attacker to induce the vulnerable server to make arbitrary outbound HTTP GET requests. This can be used to access internal-only services, enumerate or scan local and adjacent networks from the server's vantage point, and retrieve sensitive metadata from cloud environments, including AWS or GCP IAM-related metadata endpoints and tokens. The provided CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) indicates high confidentiality and integrity impact, with no user interaction or prior authentication required.
If you can’t patch tonight, do this now.
Until an official fix is available, disable or restrict access to the /api/proxy endpoint, preferably removing public exposure entirely. Place the application behind an authentication gate or reverse proxy ACLs so unauthenticated users cannot reach the endpoint. Apply egress filtering at the host, container, VPC, or firewall level to prevent the application from reaching internal networks, localhost, link-local ranges, and cloud metadata services such as 169.254.169.254. Where possible, isolate the service in a network segment with minimal outbound access and monitor for anomalous outbound requests originating from the application.
Patch, then assume compromise.
No known patched version was available at the time of publication according to the provided content. Remediation should therefore consist of updating to a vendor-fixed release once available and removing or redesigning the vulnerable proxy behavior. The /api/proxy endpoint should require authentication and authorization, and it should not permit arbitrary user-controlled destinations. Implement strict allowlisting of permitted upstream hosts, schemes, ports, and paths; block access to loopback, link-local, RFC1918, and cloud metadata address space; and validate and canonicalize URLs before any outbound request is issued.
No validated public exploits yet. Hidden: 1 rejected by Mallory's analysis as not a working exploit.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.