CVE-2025-32375 is a critical (CVSS 9.8) insecure deserialization flaw in the BentoML runner server. A crafted POST request can run arbitrary code on the host. Versions from 1.0 up to but not including 1.4.8 are affected, and 1.4.8 is the fix.
What's affected
The GitHub advisory GHSA-7v4r-c989-xh26 lists the pip package bentoml, affected versions >=1.0,<1.4.8, patched in 1.4.8. The NVD record describes the problem as insecure deserialization in the runner server, reachable by setting specific headers and parameters in a POST request, leading to arbitrary code execution on the server.
The weakness class is CWE-502 (deserialization of untrusted data). The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no login, full impact on all three properties.
The record's KEV flag is false and the advisory does not report attacks in the wild. The advisory does include a proof of concept, which is public. I am not repeating it here.
How to check if you're exposed
Check the installed version in every environment that serves models.
pip show bentoml
pip list 2>/dev/null | grep -i bentoml
grep -ri "bentoml" requirements*.txt pyproject.toml poetry.lock 2>/dev/null
Anything between 1.0 and 1.4.7 is affected. Remember to check container images as well as virtual environments, since a pinned old version can sit in a base image. Then ask a second question: is a runner server port reachable from anywhere other than the API process that talks to it? The flaw is in the runner server, so exposure depends on who can send it requests.
The free in-browser dependency scan takes a manifest or lockfile and lists known CVEs for the packages in it, and the Gold directory lets you look up a CVE by id.
What to do now
- Upgrade
bentomlto 1.4.8 or later and rebuild any images or bentos that pinned an older version. - Redeploy every service that uses runners, then confirm the running version with the command above.
- Make sure runner servers listen only on a private interface or socket, and that only your own API process can reach them.
- Put network policy or a service mesh rule around model serving pods.
- Look at serving hosts for processes or files you do not recognise, since the impact of this class of bug is code execution as the serving user.
- Review any other place your pipeline loads pickled data, and treat it as code.
Why it matters
Deserialization turns bytes back into objects. Some formats, Python's pickle among them, can run code as part of that conversion, so loading data from an untrusted source is the same as running code from it. Model serving frameworks use these formats because models themselves are often saved that way.
The runner server is an internal component, which is why network isolation is as important as the upgrade. A good rule for ML infrastructure is to treat every serialization boundary as a trust boundary and prefer formats that carry data only.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which versions are affected?
The advisory lists bentoml from 1.0 up to but not including 1.4.8. Version 1.4.8 is the patched release.
Is the runner server public by default?
The advisory does not say. Check your own deployment, and keep runners off public networks.
Sources
Last reviewed: 19 October 2026.
