BentoML CVE-2026-27905

Exploitation requires the victim to pull/import and extract an attacker-crafted bento or model tar through BentoML's extraction routine safe_extract_tarfile() (invoked from cloud/bento.py:542 and cloud/model.py:504); the malicious archive must contain a symlink whose target escapes the destination directory followed by a regular file written through it. This affects all versions prior to 1.4.36 in their default behavior - no special configuration toggle is needed. The key limiting factor is that the attacker does not need credentials on the target host (PR:N) but DOES need the victim to ingest the malicious artifact, so exploitation hinges on a supply-chain/social delivery step rather than direct remote access; it is not reachable against an idle BentoML installation that never imports an untrusted bento/model.

Signals are mixed and point to a real-but-not-urgent issue. The flaw is a genuine arbitrary file write (CWE-59 symlink following) confirmed by the vendor's GHSA advisory and fixed in 1.4.36, and public exploit code exists (a working PoC is embedded in the GHSA). However, EPSS is only 0.01% (0th percentile) and the CVE is NOT in CISA KEV, indicating no evidence of widespread automated exploitation - consistent with a supply-chain-style flaw that requires a victim to import an attacker-crafted bento/model artifact rather than a remotely sprayable bug. The two CVSS representations conflict on the delivery vector and must be reconciled: the NVD CVSS 4.0 vector states AV:L/UI:N (local, no user interaction) while the vendor GHSA CVSS 3.1 vector states AV:N/UI:R (network-delivered artifact requiring user action to extract). The AV:L framing is misleading - the realistic path is an attacker-supplied tar pulled from a registry/peer and then extracted, which is better modeled as AV:N/UI:R; verify intended threat model with the vendor. Both representations agree exploitation needs no privileges on the target (PR:N) and that integrity impact is high. Net: moderate real-world priority - patch promptly where BentoML ingests untrusted bentos/models, but this is more a targeted/supply-chain risk than a mass-exploited one given low EPSS and no KEV listing.

An attacker publishes or shares a malicious bento/model packaged as a tar containing a symlink that points outside the extraction directory (e.g. to /etc or a Python site-packages path), followed by a regular file that writes through that symlink. When a victim pulls and extracts the artifact via BentoML's cloud bento/model import path, open() follows the symlink and writes attacker-controlled content to an arbitrary host location, which can escalate to code execution by overwriting a config or script. A working proof-of-concept is published in the GHSA advisory.