CVE-2026-35044 — HIGH (CVSS 8.8)

CISO Take

Any team running `bentoml containerize` on externally-sourced or shared bento archives is at risk of full host compromise — the payload executes on the host before Docker is even invoked, bypassing container isolation entirely. Patch immediately to BentoML 1.4.38 and audit any CI/CD pipeline that automates bento imports from untrusted sources. If you cannot patch, block import of third-party bento archives until the fix is validated.

What is the risk?

High risk. CVSS 8.8 reflects realistic exploitability: the attack requires no authentication, no AI/ML expertise, and the PoC is a trivial 3-line Jinja2 template. The blast radius is the host machine — including credentials, SSH keys, cloud tokens, and source code in the developer or CI/CD environment. Exposure is especially acute in MLOps teams that import pre-built bento archives from model hubs, S3 buckets, or collaborative workflows. The deceptive trust boundary (users expect containerize to be a safe build step) amplifies likelihood of successful exploitation.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
bentoml	pip	<= 1.4.37	`1.4.38`
8.6K OpenSSF 6.5 22 dependents Pushed 12d ago 55% patched ~11d to patch Full package profile →

Do you use bentoml? You're affected.

Severity & Risk

CVSS 3.1

8.8 / 10

EPSS

0.0%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, CISA SSVC, EPSS, trickest/cve, and Nuclei templates.

Attack Surface

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I High

A High

What should I do?

5 steps

PATCH

Upgrade bentoml to >= 1.4.38 immediately. This replaces the unsandboxed Environment with SandboxedEnvironment and removes the jinja2.ext.do extension.
AUDIT

Review any bento archives imported from external sources; inspect env/docker/Dockerfile.template inside archives for Jinja2 {% do %} or {% debug %} tags before trusting.
DETECT

Add pre-import scanning for jinja2.ext.do patterns in Dockerfile.template files within bento archives. In SIEM, alert on bentoml containerize executions followed by unexpected child process spawning (bash, sh, python outside expected paths).
ISOLATE

Until patched, run bentoml containerize only in isolated VMs or ephemeral sandboxed environments, never on developer workstations or shared CI/CD runners with access to production secrets.
RESTRICT

Implement allowlists for approved bento archive sources; reject imports from untrusted origins.

CISA SSVC Assessment

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

Classification

Supply Chain Code Execution Framework AML.T0010.001 - AI Software AML.T0011 - User Execution AML.T0011.000 - Unsafe AI Artifacts AML.T0050 - Command and Scripting Interpreter AML.T0105 - Escape to Host

Compliance Impact

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity Art. 9 - Risk management system

ISO 42001

8.4 - AI system security 8.7 - AI supply chain management

NIST AI RMF

GOVERN 1.7 - AI supply chain risk management MANAGE 2.2 - Mechanisms for AI risk treatment

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-35044?

Any team running `bentoml containerize` on externally-sourced or shared bento archives is at risk of full host compromise — the payload executes on the host before Docker is even invoked, bypassing container isolation entirely. Patch immediately to BentoML 1.4.38 and audit any CI/CD pipeline that automates bento imports from untrusted sources. If you cannot patch, block import of third-party bento archives until the fix is validated.

Is CVE-2026-35044 actively exploited?

No confirmed active exploitation of CVE-2026-35044 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-35044?

1. PATCH: Upgrade bentoml to >= 1.4.38 immediately. This replaces the unsandboxed Environment with SandboxedEnvironment and removes the jinja2.ext.do extension. 2. AUDIT: Review any bento archives imported from external sources; inspect `env/docker/Dockerfile.template` inside archives for Jinja2 `{% do %}` or `{% debug %}` tags before trusting. 3. DETECT: Add pre-import scanning for `jinja2.ext.do` patterns in `Dockerfile.template` files within bento archives. In SIEM, alert on `bentoml containerize` executions followed by unexpected child process spawning (bash, sh, python outside expected paths). 4. ISOLATE: Until patched, run `bentoml containerize` only in isolated VMs or ephemeral sandboxed environments, never on developer workstations or shared CI/CD runners with access to production secrets. 5. RESTRICT: Implement allowlists for approved bento archive sources; reject imports from untrusted origins.

What systems are affected by CVE-2026-35044?

This vulnerability affects the following AI/ML architecture patterns: MLOps pipelines, model packaging and containerization workflows, CI/CD model deployment pipelines, model sharing and collaboration workflows, developer workstations running local model serving.

What is the CVSS score for CVE-2026-35044?

CVE-2026-35044 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.02%.

Technical Details

NVD Description

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.38, the Dockerfile generation function generate_containerfile() in src/bentoml/_internal/container/generate.py uses an unsandboxed jinja2.Environment with the jinja2.ext.do extension to render user-provided dockerfile_template files. When a victim imports a malicious bento archive and runs bentoml containerize, attacker-controlled Jinja2 template code executes arbitrary Python directly on the host machine, bypassing all container isolation. This vulnerability is fixed in 1.4.38.

Exploitation Scenario

An adversary targeting a team that uses BentoML for LLM/ML model serving builds a plausible bento archive — perhaps a useful open-source model wrapper or a dependency of an internal project. They embed a malicious `Dockerfile.template` containing a `{% do %}` SSTI payload that exfiltrates environment variables (cloud API keys, database credentials, Anthropic API key) to an attacker-controlled endpoint, then installs a reverse shell. The archive is published to a public S3 bucket or a GitHub release alongside legitimate model artifacts. A CI/CD runner executing automated `bentoml import && bentoml containerize` workflows pulls the archive during a dependency update or model refresh. The SSTI payload fires during template rendering — before any Docker layer exists — giving the attacker full host access to the runner, its mounted secrets, and any production systems reachable from the CI/CD network.