{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/docker/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["ssti","bentoml","code-execution","docker"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eBentoML versions 1.4.37 and earlier contain a critical vulnerability related to server-side template injection (SSTI). The vulnerability stems from the use of an unsandboxed Jinja2 environment within the \u003ccode\u003egenerate_containerfile()\u003c/code\u003e function, which is responsible for creating Dockerfiles. By crafting a malicious bento archive containing a specially crafted \u003ccode\u003edockerfile_template\u003c/code\u003e, an attacker can inject arbitrary Python code that executes directly on the host machine when a victim imports and containerizes the bento using \u003ccode\u003ebentoml containerize\u003c/code\u003e. This vulnerability bypasses all container isolation mechanisms and gives the attacker full access to the host\u0026rsquo;s filesystem, environment variables, and potentially other sensitive information. The lack of input validation during the import process allows the malicious template to be embedded within the bento archive undetected until the containerization process.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker crafts a malicious \u003ccode\u003ebentofile.yaml\u003c/code\u003e file containing a \u003ccode\u003edockerfile_template\u003c/code\u003e directive pointing to a Jinja2 template with an SSTI payload.\u003c/li\u003e\n\u003cli\u003eThe attacker builds a bento using \u003ccode\u003ebentoml build\u003c/code\u003e, which copies the malicious template into the bento archive at \u003ccode\u003eenv/docker/Dockerfile.template\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker exports the bento as a \u003ccode\u003e.bento\u003c/code\u003e or \u003ccode\u003e.tar.gz\u003c/code\u003e archive and distributes it to victims.\u003c/li\u003e\n\u003cli\u003eA victim imports the malicious bento archive using \u003ccode\u003ebentoml import bento.tar\u003c/code\u003e. No validation of the template content is performed during the import.\u003c/li\u003e\n\u003cli\u003eThe victim attempts to containerize the imported bento using \u003ccode\u003ebentoml containerize\u003c/code\u003e, triggering the \u003ccode\u003econstruct_containerfile()\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003econstruct_containerfile()\u003c/code\u003e function detects the presence of the \u003ccode\u003eDockerfile.template\u003c/code\u003e and sets the \u003ccode\u003edockerfile_template\u003c/code\u003e attribute in the Docker options.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003egenerate_containerfile()\u003c/code\u003e function loads the attacker-controlled template into an unsandboxed Jinja2 environment.\u003c/li\u003e\n\u003cli\u003eThe template is rendered, resulting in arbitrary Python code execution on the victim\u0026rsquo;s host machine, outside of any containerized environment. This allows the attacker to achieve full host compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows arbitrary code execution on the host machine of any user who imports and containerizes the malicious bento archive. This provides the attacker with: full access to the host filesystem, the ability to install backdoors or pivot to other systems, and access to sensitive information such as credentials and API keys stored in environment variables. Due to the placement of the malicious code within a bento archive, and the nature of the containerize operation, users may be unaware of the risk and impact of this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patched version of BentoML (later than 1.4.37) to remediate CVE-2026-35044.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect BentoML SSTI Payload in Dockerfile Template\u0026rdquo; to identify potentially malicious Jinja2 templates being written to disk.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for the execution of suspicious commands originating from the \u003ccode\u003ebentoml\u003c/code\u003e process, particularly after importing a bento archive, to catch potential exploitation attempts using the rule \u0026ldquo;Detect Suspicious Process Execution from BentoML\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement strict input validation and sanitization for any user-provided templates or configuration files to prevent server-side template injection vulnerabilities, as described in the overview.\u003c/li\u003e\n\u003cli\u003eReview and restrict the extensions used within the Jinja2 environment to only those absolutely necessary for Dockerfile generation, following the recommended fix in the source.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T23:14:15Z","date_published":"2026-04-03T23:14:15Z","id":"/briefs/2024-02-bentoml-ssti/","summary":"BentoML versions 1.4.37 and earlier are vulnerable to server-side template injection (SSTI), where the Dockerfile generation function uses an unsandboxed jinja2.Environment allowing arbitrary Python code execution on the host machine when a malicious bento archive is imported and containerized, bypassing container isolation and potentially granting full access to the host filesystem and environment variables.","title":"BentoML SSTI via Unsandboxed Jinja2 in Dockerfile Generation","url":"https://feed.craftedsignal.io/briefs/2024-02-bentoml-ssti/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["docker","authz","authorization","bypass","cve-2026-34040"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in Moby (Docker) that can be exploited to bypass authorization plugins (AuthZ) when processing API requests. This vulnerability occurs because the Docker daemon may forward a request to an authorization plugin without the request body if the body is oversized. This incomplete fix for CVE-2024-41110 allows an attacker to craft a specific API request that triggers this behavior. This could lead to an AuthZ plugin making incorrect authorization decisions, potentially allowing unauthorized actions to be performed. This affects deployments that rely on AuthZ plugins that inspect the request body for access control. The vulnerable packages include \u003ccode\u003ego/github.com/moby/moby\u003c/code\u003e (versions prior to 29.3.1), \u003ccode\u003ego/github.com/docker/docker\u003c/code\u003e (versions prior to 29.3.1), and \u003ccode\u003ego/github.com/moby/moby/v2\u003c/code\u003e (versions prior to 2.0.0-beta.8).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a Docker environment utilizing an AuthZ plugin that relies on request body inspection for authorization.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious Docker API request targeting a sensitive resource or action.\u003c/li\u003e\n\u003cli\u003eThe attacker inflates the request body to exceed a size threshold that triggers the bypass behavior.\u003c/li\u003e\n\u003cli\u003eThe Docker daemon receives the oversized API request.\u003c/li\u003e\n\u003cli\u003eDue to the vulnerability, the Docker daemon forwards the request to the AuthZ plugin without the request body.\u003c/li\u003e\n\u003cli\u003eThe AuthZ plugin, lacking the request body, makes an authorization decision based on incomplete information.\u003c/li\u003e\n\u003cli\u003eThe AuthZ plugin, unable to properly validate the request, grants access to the sensitive resource or action.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully executes the unauthorized action, bypassing the intended security controls.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability primarily impacts Docker environments that utilize authorization plugins and rely on request body inspection for access control decisions. If exploited successfully, an attacker can bypass the intended authorization mechanisms, potentially leading to unauthorized access to sensitive resources, data breaches, or other malicious activities within the containerized environment. The severity is high for affected installations, however, the base likelihood of exploitation is low, and only impacts those using AuthZ plugins.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Moby version 29.3.1 or later to address the vulnerability. This resolves the incomplete fix for CVE-2024-41110 and prevents the AuthZ bypass.\u003c/li\u003e\n\u003cli\u003eFor environments where immediate upgrades are not possible, avoid using AuthZ plugins that rely on request body inspection for security decisions as described in the overview.\u003c/li\u003e\n\u003cli\u003eRestrict access to the Docker API to trusted parties following the principle of least privilege to reduce the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-27T17:44:58Z","date_published":"2026-03-27T17:44:58Z","id":"/briefs/2026-04-moby-authz-bypass/","summary":"A vulnerability in Moby allows attackers to bypass authorization plugins by crafting API requests with oversized bodies, causing the Docker daemon to forward the request without the body to the plugin, potentially leading to unauthorized actions.","title":"Moby Authorization Plugin Bypass via Oversized Request Bodies","url":"https://feed.craftedsignal.io/briefs/2026-04-moby-authz-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — Docker","version":"https://jsonfeed.org/version/1.1"}