CVE-2026-35044
Remote Code Execution via Jinja2 Template Injection in BentoML Containerization
Publication date: 2026-04-06
Last updated on: 2026-04-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bentoml | bentoml | to 1.4.38 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1336 | The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-35044 is a high-severity Server-Side Template Injection (SSTI) vulnerability in the BentoML Python library versions up to 1.4.37. The vulnerability occurs in the Dockerfile generation function generate_containerfile(), which uses an unsandboxed Jinja2 environment with dangerous extensions to render user-provided Dockerfile templates.
Because the Jinja2 environment is unsandboxed and includes extensions like jinja2.ext.do and jinja2.ext.debug, an attacker can embed malicious Jinja2 template code in a Bento archive. When a victim imports this malicious archive and runs bentoml containerize, the attacker-controlled template executes arbitrary Python code directly on the host machine, bypassing Docker container isolation.
This means the attacker can run any Python code on the host before any container is created, leading to full host compromise.
How can this vulnerability impact me? :
This vulnerability allows an attacker to execute arbitrary Python code on the host machine of any user who imports and containerizes a malicious Bento archive.
- Full arbitrary code execution on the host machine.
- Potential access to sensitive host filesystem data such as source code, credentials, SSH keys, and cloud tokens.
- Ability to install backdoors or pivot to other systems.
- Exposure of environment variables containing secrets like API keys and database credentials.
- Risk of supply chain compromise, especially if the victim’s machine is part of CI/CD pipelines.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking if your BentoML installation is using a vulnerable version (prior to 1.4.38) and if the Dockerfile generation function uses an unsandboxed Jinja2 environment with dangerous extensions like jinja2.ext.do and jinja2.ext.debug.
To detect exploitation attempts, you can look for unexpected files or commands executed on the host, such as the presence of files like /tmp/pwned which may indicate arbitrary code execution.
Suggested commands to check for signs of exploitation or vulnerability include:
- Check BentoML version: `bentoml --version` or inspect installed package version via `pip show bentoml`.
- Search for suspicious files created by exploitation payloads, e.g., `ls -l /tmp/pwned`.
- Monitor recent commands or processes that might indicate template injection, e.g., `ps aux | grep bentoml` or check shell history for unusual `bentoml containerize` usage.
- Audit Bento archives imported recently for malicious Dockerfile templates containing Jinja2 payloads.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade BentoML to version 1.4.38 or later, where the vulnerability is fixed.
This fix replaces the unsandboxed Jinja2 environment with a sandboxed one and removes dangerous extensions like jinja2.ext.do and jinja2.ext.debug from the Dockerfile generation process.
Additionally, avoid importing and containerizing untrusted Bento archives, as malicious templates embedded in these archives can execute arbitrary code on the host.
If upgrading immediately is not possible, consider auditing and sanitizing any Bento archives before importing and containerizing them.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows attackers to execute arbitrary Python code on the host machine, potentially leading to full host compromise.
Such a compromise can result in unauthorized access to sensitive data including source code, credentials, SSH keys, cloud tokens, and environment variables containing secrets like API keys and database credentials.
Exposure or theft of sensitive personal or protected health information due to this vulnerability could lead to non-compliance with regulations such as GDPR and HIPAA, which mandate strict controls over data confidentiality and integrity.
Additionally, the risk of supply chain compromise, especially in CI/CD pipelines, increases the likelihood of widespread data breaches and regulatory violations.