mistral.rs: Unbounded Remote Media Fetch and Video Frame Expansion DoS
What to do
Vendor fix available. Upgrade each affected package to the fixed version on its release line (mistralrs-server-core 0.8.18), redeploy, then verify what is actually installed.
This page has no inventory attached, so it cannot say whether you are affected. A vendor fix is not proof that your deployment is fixed.
Affected packages
crates.io mistralrs-server-core
- Affected
- <= 0.8.4
- Fixed in
- 0.8.18
Sources
- Open Source Vulnerabilities (OSV.dev), including the GitHub Advisory Database
OSV record GHSA-m3wp-48jr-vr4g lists affected ranges: crates.io mistralrs-server-core >=0 <0.8.18 (fixed)
VerifiedObserved Structured OSV record; GitHub-reviewed advisory.
- GitHub Advisory Database and maintainer security advisories on GitHub
GitHub-reviewed advisory GHSA-m3wp-48jr-vr4g lists affected ranges: crates.io mistralrs-server-core >=0 <=0.8.4
VerifiedObserved Structured GitHub Advisory Database record (type=reviewed) from the GitHub REST API.
Severity and exploitation
- Exploitation
- No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.
- CVSS
- 7.5 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- EPSS
- No dated EPSS signal available.
Source description
As published by the source; long descriptions are shortened.
Unbounded Remote Media Fetch and Video Frame Expansion DoS Summary The POST /v1/chat/completions endpoint in mistral.rs fetches attacker-supplied media URLs (image, audio, video) into server memory with no byte limit, and extracts every frame of a supplied video when numframes is None. An unauthenticated remote attacker can exhaust server memory, disk space, and CPU by pointing the endpoint at an infinite-streaming HTTP server or a long high-framerate video, causing a complete denial of service. No credentials or special configuration are required; the route is open by default. Details Three independent sinks contribute to the vulnerability: 1. Unbounded image/audio fetch (mistralrs-server-core/src/util.rs:59–62) bytes().await buffers the entire HTTP response body before returning. There is no Content-Length check, no streaming limit, and no timeout specific to the media fetch. An attacker-controlled server that never closes the connection causes the server process to accumulate…
Dates and revisions
- Published by the source
- Last modified by the source
- Source last checked
- Revision 2 · amended ·
Amended from ghsa record GHSA-m3wp-48jr-vr4g
- Revision 1 · created ·
Published from osv record GHSA-m3wp-48jr-vr4g
Agent brief
Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.
# Patch Next advisory brief: GHSA-m3wp-48jr-vr4g Advisory: mistral.rs: Unbounded Remote Media Fetch and Video Frame Expansion DoS IDs: GHSA-m3wp-48jr-vr4g Record: https://patchnext.com/advisories/ghsa-m3wp-48jr-vr4g (revision 2, source checked 26 Oct 2026, 15:43 UTC) Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected. Severity: High (CVSS 7.5) Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV. Vendor response: Vendor fix available; fixed versions by package: mistralrs-server-core 0.8.18. A vendor fix does not mean a deployment is fixed. ## Affected components - crates.io mistralrs-server-core: affected <= 0.8.4; fixed in 0.8.18 ## Suggested inspection (read-only) - crates.io mistralrs-server-core: check the installed version with your package manager. ## Supported action Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version. ## Required regression checks - Run the test suite and a production build. - Exercise the features that depend on mistralrs-server-core. - Repeat the inspection and confirm that only fixed versions remain installed. ## Rollback considerations - Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward. ## Unresolved questions - Which deployments run an affected version? - Exploitation status can change. Check again before lowering the priority. - Mark the work resolved only after the fixed version is verified in production. ## Sources - Verified: https://osv.dev/vulnerability/GHSA-m3wp-48jr-vr4g (OSV record GHSA-m3wp-48jr-vr4g lists affected ranges: crates.io mistralrs-server-core >=0 <0.8.18 (fixed)) - Verified: https://github.com/advisories/GHSA-m3wp-48jr-vr4g (GitHub-reviewed advisory GHSA-m3wp-48jr-vr4g lists affected ranges: crates.io mistralrs-server-core >=0 <=0.8.4) Commands are suggestions: review each one before running it.
Loading voting…