# CVE-2026-40610: bentoml Path Traversal β€” Fixed in 1.4.39 🐍 🐍 PyPI Not in CISA KEV MEDIUM severity # CVE-2026-40610 β€” bentoml MEDIUM [Fix: bentoml/BentoML@5fb7cd4](https://github.com/bentoml/BentoML/commit/5fb7cd41f92e2a56b45391284cf15b9ac9963a1f) CVE-2026-40610 is a medium-severity (CVSS 5.5) CWE-59 vulnerability in bentoml. A fix is available for bentoml β€” see the affected versions and patch details below. BentoML has Information Disclosure in \`bentoml build\` via symlink traversal in the build context Also known as[GHSA-mcfx-4vc6-qgxv](/vulnerability/GHSA-mcfx-4vc6-qgxv)PYSEC-2026-2399 Published May 22, 2026 Updated Oct 28, 2026 Affected 1 pkg Patched 1 / 1 Exploits None indexed Exploitation data as of Nov 9, 2026 Β· OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### Proof-of-concept exploit code exists - CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40610. ## EPSS Exploitation Probability [via FIRST.org β†—](https://www.first.org/epss/) 0.3%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs21th percentile β€” riskier than 21% of all scored CVEsHighest risk 0.00%0.26%0.52%0.78%0.0%0.3%Jun 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 1 pkg affected 🐍`bentoml` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages β€” download data is not available via public APIs for these ecosystems. ## Description #### 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. image - 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. image image #### 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. ## Affected Packages 1 total 1 fixed Ecosystem Package Vulnerable range Fix 🐍PyPI `bentoml` all versions 1.4.39`pip install --upgrade 'bentoml==1.4.39'` ## Affected Products 1 product Β· 1 configurations Application `bentoml`bentoml < 1.4.39 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for bentoml, including transitive dependencies β€” a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update bentoml to 1.4.39 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range β€” O3 confirms CVE-2026-40610 is resolved across your whole dependency graph. 3. ### Workarounds Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves. ## Frequently Asked Questions \### 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 O3 Security Β· Impact-Aware SCA ### Is CVE-2026-40610 in your dependencies? Find it across PyPI, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)