CVE-2025-32375

What it actually does

This is a critical insecure deserialization flaw in the BentoML runner server. A remote attacker who can reach the runner server can send a crafted POST request with specific headers and parameters that cause the server to deserialize attacker-controlled data. Because deserialization occurs in the runner server process, successful exploitation can execute arbitrary code with the privileges of the BentoML service account or container. The impact includes remote code execution, unauthorized initial access, disclosure of environment variables, model artifacts, API keys, service credentials, and possible pivoting to adjacent infrastructure.

Why it matters to the business

A vulnerable BentoML deployment can be turned into an entry point for attackers, allowing them to take over model-serving infrastructure, steal secrets or proprietary model data, disrupt inference services, and move further into connected systems. The issue has a CVSS score of 9.8, weaponized exploit maturity, and a high EPSS probability, so exposed runner servers should be treated as urgent even though the vulnerability is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker first identifies an exposed or reachable BentoML runner server, often through internet scanning, service fingerprinting, or lateral discovery inside a network. They then send a crafted POST request to the runner server using headers and request parameters that select the vulnerable deserialization path. The request body contains a malicious serialized object or payload that is processed by the runner server. When BentoML deserializes the supplied data, attacker-controlled code executes inside the BentoML runner process. From there, the attacker can run shell commands, inspect environment variables, read mounted files and model artifacts, extract tokens or cloud credentials, establish persistence if the host allows it, and use the compromised service as a foothold for further access.

How to fix it

Upgrade BentoML to a version that includes the upstream fix. For source-based deployments of bentoml/bentoml, ensure the code includes commit 1ddd7e782f1ce74a0a37f51c70a44474eb58d5e1 or a later trusted release containing that commit. Rebuild and redeploy all BentoML images and services after upgrading; simply updating source code is insufficient if old containers remain running. Remove public exposure of runner servers wherever possible, because runner components should generally be reachable only by trusted BentoML service components. Place runner endpoints behind network controls, service mesh policy, firewall rules, or private subnets. Require authentication and authorization at any gateway in front of BentoML services. If immediate upgrade is not possible, restrict access to known trusted callers, block suspicious serialized-content POST requests at a reverse proxy or WAF, disable unnecessary runner exposure, rotate secrets available to affected services, and monitor aggressively for post-exploitation activity.

How to confirm the fix worked

Confirm the deployed BentoML code or package contains commit 1ddd7e782f1ce74a0a37f51c70a44474eb58d5e1 or a later fixed release. Validate running containers and images, not only dependency manifests, because stale images may still include vulnerable code. Use software inventory, image SBOMs, package metadata, and runtime checks to identify all BentoML deployments. Confirm that runner server ports are not publicly reachable and are accessible only from intended internal components. Review reverse proxy, ingress, firewall, and service mesh policies to verify POST access to runner endpoints is restricted. After patching, perform a controlled security test using a benign deserialization probe or vendor-safe proof-of-concept to confirm the vulnerable request path no longer executes attacker-controlled code. Also verify that no old pods, containers, virtual machines, or batch jobs continue running vulnerable BentoML runner code.

Typical attack path

1. Scan for BentoML services or runner-server ports exposed to the internet or reachable from another compromised host.
2. Fingerprint the service using HTTP responses, health endpoints, headers, error messages, or BentoML-specific behavior.
3. Send a crafted POST request that uses the vulnerable serialization headers and parameters.
4. Trigger insecure deserialization of attacker-controlled data in the runner server.
5. Execute arbitrary commands as the BentoML runner process or container user.
6. Collect environment variables, API keys, model files, configuration files, and cloud or platform credentials accessible to the process.
7. Establish a reverse shell, download additional tooling, or create another access path if outbound connectivity and permissions allow it.
8. Pivot to connected services, data stores, orchestration platforms, or cloud resources using harvested credentials.

How to detect it

Check for evidence of prior exploitation across HTTP access logs, reverse proxy logs, ingress controller logs, BentoML application logs, container runtime logs, EDR telemetry, cloud audit logs, and network flow records. Focus on POST requests to BentoML runner or internal inference endpoints using unusual serialization-related headers, nonstandard content types, unexpected query parameters, large binary payloads, or requests followed by 500 errors and then successful command execution. Review BentoML and Python process activity for child processes such as shells, downloaders, scripting interpreters, network utilities, or privilege-discovery commands. Inspect containers and hosts for files dropped in temporary directories, unexpected startup scripts, new SSH keys, cron entries, or modified application files. Examine outbound network connections from BentoML containers to unfamiliar IP addresses, paste sites, file-sharing services, crypto-mining pools, or command-and-control infrastructure. If the runner server was internet-exposed before patching, assume exploitation was plausible and perform credential rotation and forensic review even if logs are incomplete.

• POST requests to BentoML runner endpoints with Content-Type containing "pickle"
• POST requests to BentoML runner endpoints with Content-Type containing "application/vnd.bentoml"
• HTTP headers containing "BentoML" on unexpected external POST requests
• HTTP query parameters containing "batch" or "batching" on unexpected runner-server POST requests
• Python or BentoML process spawning "/bin/sh"
• Python or BentoML process spawning "/bin/bash"
• Python or BentoML process spawning "sh -c"
• Python or BentoML process spawning "bash -c"
• Python or BentoML process spawning "curl"
• Python or BentoML process spawning "wget"
• Python or BentoML process spawning "nc"
• Python or BentoML process spawning "ncat"
• Python or BentoML process spawning "python -c"
• Python or BentoML process spawning "perl -e"
• Python or BentoML process spawning "chmod +x"
• Unexpected files created under "/tmp" by a BentoML or Python process
• Unexpected files created under "/var/tmp" by a BentoML or Python process
• Unexpected outbound connections from a BentoML runner container immediately after a POST request
• BentoML logs containing deserialization errors followed by process crashes or restarts
• BentoML logs containing "pickle" near an external client request

What your security team should do

• Immediately inventory all BentoML deployments, including development, staging, ML experimentation, and production model-serving environments.
• Prioritize any BentoML runner server exposed to the internet or reachable from untrusted networks; treat those systems as high-risk due to weaponized exploitation and high EPSS likelihood.
• Upgrade or rebuild to a fixed BentoML version containing commit 1ddd7e782f1ce74a0a37f51c70a44474eb58d5e1 or later.
• Restrict runner server network access to trusted service components only; do not expose runner servers directly to users or the public internet.
• Review access logs for suspicious POST requests with unusual serialization-related content types, BentoML internal headers, malformed parameters, or large opaque payloads.
• Hunt for command execution from BentoML processes, including shell launches, outbound curl or wget activity, reverse shell behavior, cryptomining tools, or unexpected child processes.
• Rotate secrets, tokens, API keys, and cloud credentials that were available to vulnerable BentoML services, especially if exposure existed before patching.
• Capture forensic evidence before rebuilding highly exposed systems, including container logs, process listings, filesystem changes, network connections, and relevant cloud audit logs.
• Add SIEM detections for BentoML runner POST abuse and EDR detections for shell or downloader processes spawned by Python/BentoML runtime processes.
• After remediation, continuously monitor for reintroduced vulnerable images through CI/CD, container registry, and Kubernetes admission controls.