Furthermore, the parser accepts file:// schemes or bare file paths. If a path exists on the local filesystem, the server attempts to open and process it. Because the server returns distinct error messages for valid vs. nonexistent paths, attackers can use the application as an oracle to enumerate the existence and type of files on the server. The vulnerability also enables resource exhaustion (Denial of Service) due to the lack of request timeouts and file size limits during the fetching and reading process.

Attack Chain

1. Attacker sends a crafted POST request to the /v1/chat/completions endpoint.
2. The request includes a messages object containing a malicious image_url or audio_url field.
3. The mistralrs-server-core backend passes this unvalidated string to parse_image_url or parse_audio_url.
4. For SSRF: The backend uses reqwest::get to fetch the attacker-supplied URL, following redirects to internal or cloud-metadata destinations.
5. For File Enumeration: The backend attempts File::open on the provided string; success confirms file existence, triggering an image decoding error.
6. The server returns a specific HTTP 500 error response reflecting the outcome of the filesystem operation.
7. The attacker parses the error response to confirm file existence or probe internal network services.

Impact

Successful exploitation allows unauthenticated attackers to probe internal networks, including sensitive cloud metadata services, and enumerate files on the host filesystem. While actual file content disclosure is not directly achieved, the existence oracle provides significant information for lateral movement or further exploitation. Additionally, the lack of input constraints enables a Denial of Service attack by forcing the server to process oversized files or hang on non-responsive internal network requests.

Recommendation

1. Update mistralrs-server-core to a version that implements input validation and restricts media loading.
2. Implement strict allowlists for media domains and block access to private/loopback/link-local IP ranges and cloud metadata services.
3. Deploy web application firewall (WAF) rules to inspect image_url and audio_url parameters for file:// schemes or suspicious local file paths (e.g., /etc/, C:\).
4. Ensure appropriate resource limits and timeouts are configured for the request-handling service to mitigate potential Denial of Service exploitation.