Vulnerabilities

A vulnerability was found in bentoml OpenLLM 0.6.30. This affects the function async_run_command of the file src/openllm/common.py of the component Model Repository Directory Name Handler. Performing a manipulation of the argument cmd results in command injection. Attacking locally is a requirement. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Prior to 1.4.39, 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. This vulnerability is fixed in 1.4.39.

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. In versions 1.4.38 and prior, the 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. An attacker can exfiltrate local files from the build host into the Bento artifact, exposing secrets such as cloud credentials, SSH keys, API tokens, environment files, or other sensitive local configurations. Because Bento artifacts are commonly exported, uploaded, stored, or containerized after build, the leaked file contents can spread beyond the original build machine. This issue has been fixed in version 1.4.39.

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.

BentoML 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.

BentoML 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.

BentoML 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.

BentoML 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.

BentoML, a Python framework for serving AI models and inference workloads, is affected by an insecure deserialization flaw (CWE-502) in its runner server in all versions prior to 1.4.8. An unauthenticated attacker can trigger the flaw by sending a crafted POST request with specific headers and parameters to a reachable runner service, causing arbitrary code execution on the server. Successful exploitation provides initial access to the host and potential disclosure of sensitive information, such as model data or environment secrets. Anyone running BentoML before 1.4.8 with the runner server reachable by untrusted clients is affected. A public proof of concept is available via the vendor's GitHub advisory, and the high EPSS score (52.1%, 99th percentile) indicates a substantial probability of active exploitation within 30 days, though the flaw is not yet in CISA KEV.

Do: Upgrade BentoML to version 1.4.8 or later. Until patched, restrict network access to the runner service (do not expose its RPC port to untrusted networks or the internet), and review access logs for unexpected POST requests with unusual headers/parameters. If compromise is suspected, rotate secrets and credentials available in the serving environment.

BentoML v1.4.2 contains a critical unauthenticated remote code execution flaw caused by insecure deserialization of untrusted data (CWE-502) in the serde.py serialization code. An attacker with network access to a BentoML serving endpoint can send a crafted serialized request payload that the server deserializes unsafely, triggering arbitrary code execution with no credentials or user interaction required. Successful exploitation yields full control of the serving process (confidentiality, integrity and availability all rated high), typically as the account running the model-inference service. Anyone running the affected version — most commonly AI/ML teams exposing BentoML inference APIs, often in containers or cloud environments — is affected. A public security advisory with PoC reference is available (GHSA-33xw-247w-6hmc), EPSS assigns a 40.3% probability of exploitation within 30 days (99th percentile), but the flaw is not yet on the CISA KEV catalog and no confirmed in-the-wild exploitation is reported.

Do: Upgrade to BentoML 1.4.3 or later immediately (see GHSA-33xw-247w-6hmc for the full advisory). Until patched, restrict network access to BentoML serving endpoints by placing them behind authentication, a reverse proxy, or a private network, and prioritize remediating any instance reachable from the internet. Review process and egress logs on exposed servers for signs of unexpected execution, and monitor closely given the 40.3% EPSS likelihood of exploitation within 30 days.