Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/basev2.j2:71-73: env.value is bash-quoted via the bashquote filter, but env.name is interpolated raw with no escaping or newline filtering. The template is rendered by bentomlimpl/docker.generatedockerfile (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 bashquote to…
Recommended action: Upgrade to 1.4.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The same Dockerfile template that mishandles envs[].name (pending GHSA-w2pm-x38x-jp44) also interpolates docker.baseimage raw with no escaping, newline filtering, or validation. A malicious bento.yaml with a multi-line docker.baseimage 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/basev2.j2:38 (current main, 2026-04-28): optionsbaseimage resolves to DockerOptions.baseimage (src/bentoml/internal/bento/buildconfig.py:176): 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(dockerattrs) and rendered as-is. PoC Malicious bentofile.yaml: Minimal reproduction of the unsafe interpolation: Output: Three valid Dockerfile directives instead of one. The RUN curl executes…
Recommended action: Upgrade to 1.4.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: There is no validation that the resolved path of srcfile remains inside ctxpath 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…
Recommended action: Upgrade to 1.4.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.4.38 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Commit ce53491 (March 24) fixed command injection via systempackages in Dockerfile templates and images.py by adding shlex.quote. However, the cloud deployment path in src/bentoml/internal/cloud/deployment.py was not included in the fix. Line 1648 interpolates systempackages 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. Details Fixed paths (commit ce53491): - src/bentomlsdk/images.py:88 - added shlex.quote(package) - src/bentoml/internal/bento/buildconfig.py:505 - added bashquote Jinja2 filter - Jinja2 templates: basedebian.j2, basealpine.j2, etc. Unfixed path: src/bentoml/internal/cloud/deployment.py, line 1648: def buildsetupscript(bentodir: str, image: Image | None) - bytes: content = b"" config = BentoBuildConfig.frombentodir(bentodir) if config.docker.systempackages: content +=…
Recommended action: Upgrade to 1.4.38 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The docker.systempackages field in bentofile.yaml accepts arbitrary strings that are interpolated directly into Dockerfile RUN commands without sanitization. Since systempackages 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. Affected Component - src/bentomlsdk/images.py:85-89 — .format(packages=" ".join(packages)) into shell command - src/bentoml/internal/container/frontend/dockerfile/templates/basedebian.j2:13 — {{ optionssystempackages | join(' ') }} - src/bentoml/internal/bento/buildconfig.py:174 — No validation on systempackages - All distro install commands in src/bentoml/internal/container/frontend/dockerfile/init.py Affected Versions All versions supporting docker.systempackages in bentofile.yaml, confirmed on 1.4.36. Steps to Reproduce 1. Create a project directory with: service.py:…
Recommended action: Upgrade to 1.4.37 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Arbitrary File Write via Symlink Path Traversal in Tar Extraction Summary The safeextracttarfile() 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. Affected Component - File: src/bentoml/internal/utils/filesystem.py:58-96 - Callers: src/bentoml/internal/cloud/bento.py:542, src/bentoml/internal/cloud/model.py:504 - Affected versions: All versions with safeextracttarfile() Severity CVSS 3.1: 8.1 (High) AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H Vulnerability Details Vulnerable Code (filesystem.py:58-96) The Bug 1. Line 64: Path(path).isrelativeto(destination) checks the member's OWN path, not the symlink target 2. Line 75:…
Recommended action: Upgrade to 1.4.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BentoML's bentofile.yaml configuration allows path traversal attacks through multiple file path fields (description, docker.setupscript, docker.dockerfiletemplate, conda.environmentyml). 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. Details The vulnerability exists in how BentoML resolves user-provided file paths without validating that they remain within the build context directory. Vulnerable function in src/bentoml/internal/utils/filesystem.py:114-131: Vulnerable code in src/bentoml/internal/bento/bento.py:348-355: All four vulnerable fields: - description: "file:../../../etc/passwd" → copied to README.md - docker.setupscript: "../../../etc/passwd" → copied to env/docker/setupscript -…
Recommended action: Upgrade to 1.4.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There's an SSRF in the file upload processing system that allows remote attackers to make arbitrary HTTP requests from the server without authentication. The vulnerability exists in the serialization/deserialization handlers for multipart form data and JSON requests, which automatically download files from user-provided URLs without proper validation of internal network addresses. The framework automatically registers any service endpoint with file-type parameters (`pathlib.Path`, `PIL.Image.Image`) as vulnerable to this attack, making it a framework-wide security issue that affects most real-world ML services handling file uploads. While BentoML implements basic URL scheme validation in the `JSONSerde` path, the `MultipartSerde` path has no validation whatsoever, and neither path restricts access to internal networks, cloud metadata endpoints, or localhost services. The documentation explicitly promotes this URL-based file upload feature, making it an intended but…
Recommended action: Upgrade to 1.4.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. PoC - First, create a file named model.py to create a simple model and save it - Then run the following command to save this model - Next, create bentofile.yaml to build this model - Then, create service.py to host this model - Then, run the following commands to build and host this model - Finally, run this below python script to exploit insecure deserialization vulnerability in BentoML's runner server. And I can replace the NdarrayContainer with PandasDataFrameContainer in Payload-Container header and the exploit still working. After running exploit.py then the output of the command id will be send out to the WebHook server. Root Cause Analysis: - When handling a request in…
Recommended action: Upgrade to 1.4.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details It exists an unsafe code segment in `serde.py`: ```Python def deserialize_value(self, payload: Payload) -> t.Any: if "buffer-lengths" not in payload.metadata: return pickle.loads(b"".join(payload.data)) ``` Through data flow analysis, it is confirmed that the `payload `content is sourced from an HTTP request, which can be fully manipulated by the attack. Due to the lack of validation in the code, maliciously crafted serialized data can execute harmful actions during deserialization. PoC Environment: - Server host: - IP: 10.98.36.123 - OS: Ubuntu - Attack host: - IP: 10.98.36.121 - OS: Ubuntu 1. Follow the instructions on the BentoML official README(https://github.com/bentoml/BentoML) to set up the environment. 1.1 Install BentoML (Server host:…
Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An insecure deserialization vulnerability exists in the BentoML framework, allowing remote code execution (RCE) by sending a specially crafted POST request. By exploiting this vulnerability, attackers can execute arbitrary commands on the server hosting the BentoML application. The vulnerability is triggered when a serialized object, crafted to execute OS commands upon deserialization, is sent to any valid BentoML endpoint. This issue poses a significant security risk, enabling attackers to compromise the server and potentially gain unauthorized access or control.
Recommended action: Upgrade to 1.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.