CVE-2026-75898 is a server-side request forgery flaw (CWE-918) in the agent Invoke component of RAGFlow. A user who can create or trigger an agent can make the server request internal addresses and read the response. The record rates it High at 8.5. Upgrade to RAGFlow 0.26.3 or later.
What's affected
The record says RAGFlow before 0.26.3 is affected, and the project published a v0.26.3 release. The vulnerable code is in agent/component/invoke.py, which builds an outbound URL from canvas configuration and runtime template variables.
The record says the component does not call the shared assert_url_is_safe validator, which other fetch paths such as the crawler, SearXNG, file upload and RSS use, and that it does not pin the resolved address. It lists loopback, link-local and RFC 1918 destinations, including cloud instance metadata endpoints and services on the deployment network, as reachable, with the response returned to the requester.
The record scores it 8.5 (High) with a changed scope, because the request crosses into other systems. The release notes we fetched did not give a competing score.
How to check if you're exposed
Check the version of RAGFlow you run.
docker ps --format '{{.Image}}' | grep -i ragflow
docker inspect <container> | grep -i version
For source deployments, check the git tag or release you checked out. Then list the people who can create or run agents. The record says anyone with that right can trigger the request, so the exposure is that group. Review cloud settings too: if the host can reach an instance metadata service, assume it is a target.
What to do now
- Upgrade RAGFlow to 0.26.3 or later.
- Limit who can create and run agents until the upgrade is done.
- Where your cloud supports it, require session based, hop limited access to the metadata service, so a simple fetch cannot read credentials.
- Apply egress filtering on the RAGFlow host, allowing only the destinations it needs.
- Review roles attached to the RAGFlow host, and remove any broad permissions.
Why it matters
The weakness is server-side request forgery, CWE-918. The server makes an outbound request on behalf of a user, and the destination comes from user controlled configuration. The record points out the inconsistency that made this one avoidable: other fetch paths in the same product call a shared safety check, and the Invoke component does not.
Shared validators only protect what uses them. When a product adds a new way to fetch a URL, it should go through the same function, and tests should fail if it does not. The most valuable target in many clouds is the metadata endpoint that hands out credentials, which is why the record names it. KEV status is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Who can exploit it?
Per the record, a user who can create or trigger an agent. That is a logged in user, not an anonymous visitor.
What does assert_url_is_safe do?
The record describes it as the shared validator used by other fetch paths. The Invoke component skipped it.
Sources
Last reviewed: 18 October 2026.
