GPU VulnDB

Database/AI/ML frameworks & serving

BentoML: newline in docker.env keys injects Dockerfile instructions during bentoml containerize

CVSS 8.5CVE-2026-112264AI/ML frameworks & servingcurated

Impact

BentoML packages models into container images, so its build step is where a model artifact crosses into something a GPU fleet will run. Keys in the docker.env mapping are rendered into the legacy base.j2 template without escaping newlines, so a crafted bentofile.yaml or an imported bento archive can append arbitrary RUN instructions that execute during docker build. The attacker gets whatever the build host holds - build secrets passed to the builder, registry credentials, CI tokens - and can poison the resulting image so every node that later pulls it runs their code. This is the model-supply-chain path: accepting a bento from a tenant or a third party means handing them your build pipeline.

Who can reach it

Whoever supplies the bentofile.yaml or the imported bento archive that an operator then runs bentoml containerize against. No authentication to BentoML itself; it requires the victim to build an attacker-influenced bento, which is routine in a shared or automated build pipeline.

What to do

No fixed version is named in the record - it describes BentoML through 1.4.39 and the references point only at the vulnerable template and build code. Mitigate for now: treat every bentofile.yaml and imported bento as untrusted input, review docker.env keys before building, build only in a disposable runner that holds no long-lived registry or cloud credentials, and avoid passing build secrets to bento builds. No node maintenance needed; this is a CI/build-pipeline change.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.