CVE-2024-0759 is a high severity server side request forgery in AnythingLLM, scored 7.5 by NVD. A privileged user can make the link collector fetch internal addresses. The project fixed it with a commit that rejects private and loopback IP ranges, so update to a release that contains that change.
What's affected
The record covers the AnythingLLM product from Mintplex Labs with no version bound. The description says the risk applies when an instance is hosted on an internal network and the attacker has been explicitly granted a manager or admin permission level. They could then use link scraping to reach internally resolving IPs of other services on that network. The attacker would need to guess those addresses, since range wildcards are not possible, though guessing could be brute forced.
The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which says no privileges are required. That differs from the prose, which says manager or admin rights are needed. Both are in the record, so read the 7.5 score as an upper estimate. The weakness is CWE-918, server side request forgery.
The fix commit, per the GitHub page, adds a check in the collector's URL validation. If the hostname is an IPv4 address whose first octet is 10, 127, 172 or 192, the URL is rejected. I could not confirm which tagged release first contained the commit, so check the project's release notes.
How to check if you're exposed
Find where AnythingLLM runs and how it is deployed. If you use Docker, list the image tag:
docker ps --format "table #{{.Names}}\t#{{.Image}}"
Then compare against the project's releases and confirm the commit 0db6c3b is included. If you build from source, check that collector/utils/url/index.js includes the private IP check.
Also note which users hold the manager or admin role, and which internal services the host can reach.
What to do now
- Update AnythingLLM to a release that includes the private IP check.
- Review who holds manager and admin roles and remove roles that are not needed.
- Place the instance in a network segment that cannot reach sensitive internal services.
- Make sure internal services require authentication, as the record notes a duty of care that they not be open to a plain request with no credentials.
- Note that the validation described covers literal IPv4 hostnames, so also restrict outbound traffic from the host at the network level.
Why it matters
Server side request forgery turns an application into a proxy. The user supplies a URL, and the server fetches it from inside the network where it sits. Anything the server can reach, including services that trust the internal network, becomes reachable by proxy.
The impact here is data disclosure only. Even so, internal metadata services and admin panels are common targets for this class of bug. A host name check on the first octet is a reasonable step, but defenders usually add network egress rules because host names, redirects and alternative address formats can bypass simple checks. The record does not flag this CVE as known exploited.
If the affected component is something your own code pulls in as a dependency, the free in-browser dependency scan at gold.safeguard.sh/scan will tell you whether it appears in your manifests. Reachability analysis then helps you separate the copies that your code actually exercises from the ones that only sit in the tree.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need admin rights to abuse this?
The description says an attacker would be granted manager or admin permission, while the CVSS vector says no privileges. Plan as though low effort is enough.
Is there a confirmed fixed version?
Not in the pages I read. The fix commit is public, but check the project's release notes for the first release containing it.
Sources
Last reviewed: 19 October 2026.
