CVE-2024-5482 is a critical severity (CVSS 9.8) server side request forgery in the add_webpage endpoint of parisneo's lollms-webui. The application does not validate URLs, so requests can target localhost and other internal resources. The record names no fixed version, so check the project releases.
What's affected
The NVD record says the issue affects the latest version of lollms-webui at the time of the report, and it lists the product without version bounds. The only reference is a public bug bounty report, which I could not load, so no fixed version is confirmed here. Check the project's GitHub releases and commit history for a change to add_webpage URL handling before you assume you are safe.
The score is 9.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No account is needed in that vector, and the description lists data access, service disruption, network integrity, business logic manipulation and abuse of third party resources as possible effects. The record does not list a KEV entry.
The critical rating depends on the app being reachable by an attacker. A copy that runs only on a laptop and listens on the loopback address is far less exposed than one placed on a shared network.
How to check if you're exposed
lollms-webui is usually installed by cloning the repository, so ask git which commit you run:
git -C /path/to/lollms-webui log -1 --format=%H%n%cd
Compare the date with the project's release list and look for newer commits that touch the add_webpage code path.
Then see how it is exposed. Check the listening address and port:
ss -ltnp | grep -i python
If it listens on all interfaces, or sits behind a reverse proxy that reaches the internet, it can be probed. A listener on 127.0.0.1 only reduces the reach to the local machine.
What to do now
- Stop exposing lollms-webui to shared networks or the internet until a fix is confirmed.
- Bind it to the loopback address or put it behind authentication and a firewall.
- Block egress from the host to internal ranges and metadata endpoints it does not need.
- Watch the project releases and pull the first version that changes URL validation in add_webpage.
- Record the commit you run so you can show when you moved to the fixed code.
Why it matters
CWE-918, server side request forgery, happens when an application fetches a URL a user supplies without checking where it points. The server then acts as a proxy into places the user could not reach directly, such as services bound to localhost.
This one matters more because local AI front ends tend to run next to other tools, databases and sometimes cloud credentials on the same machine. A fetch feature that adds a webpage to a knowledge base is useful, and also exactly the shape SSRF takes. The lesson is general: any feature that retrieves a URL needs an allow list or a block on private ranges.
Try it yourself
With no fix named yet, exposure is the deciding factor. This demo shows how to weigh it.
Click through it at your own pace, or open it full screen.
Quick check
Is there a patched version of lollms-webui?
The record does not name one, and the only reference could not be loaded. Check the project's releases for a change to URL validation.
Is running it on localhost enough?
It reduces exposure a lot, because outsiders cannot reach the endpoint. Other software on the same machine and any browser based route to the local port can still matter, so keep it updated.
Sources
Last reviewed: 19 October 2026.
