https://feed.craftedsignal.io/tags/docker/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 03 Apr 2026 23:14:15 +0000https://feed.craftedsignal.io/briefs/2024-02-bentoml-ssti/Fri, 03 Apr 2026 23:14:15 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-02-bentoml-ssti/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.BentoML 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 generate_containerfile() function, which is responsible for creating Dockerfiles. By crafting a malicious bento archive containing a specially crafted dockerfile_template, an attacker can inject arbitrary Python code that executes directly on the host machine when a victim imports and containerizes the bento using bentoml containerize. This vulnerability bypasses all container isolation mechanisms and gives the attacker full access to the host’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.

Attack Chain

1. Attacker crafts a malicious bentofile.yaml file containing a dockerfile_template directive pointing to a Jinja2 template with an SSTI payload.
2. The attacker builds a bento using bentoml build, which copies the malicious template into the bento archive at env/docker/Dockerfile.template.
3. The attacker exports the bento as a .bento or .tar.gz archive and distributes it to victims.
4. A victim imports the malicious bento archive using bentoml import bento.tar. No validation of the template content is performed during the import.
5. The victim attempts to containerize the imported bento using bentoml containerize, triggering the construct_containerfile() function.
6. The construct_containerfile() function detects the presence of the Dockerfile.template and sets the dockerfile_template attribute in the Docker options.
7. The generate_containerfile() function loads the attacker-controlled template into an unsandboxed Jinja2 environment.
8. The template is rendered, resulting in arbitrary Python code execution on the victim’s host machine, outside of any containerized environment. This allows the attacker to achieve full host compromise.

Impact

Successful 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.

Recommendation

• Apply the patched version of BentoML (later than 1.4.37) to remediate CVE-2026-35044.
• Deploy the Sigma rule “Detect BentoML SSTI Payload in Dockerfile Template” to identify potentially malicious Jinja2 templates being written to disk.
• Monitor process creation events for the execution of suspicious commands originating from the bentoml process, particularly after importing a bento archive, to catch potential exploitation attempts using the rule “Detect Suspicious Process Execution from BentoML”.
• Implement 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.
• Review and restrict the extensions used within the Jinja2 environment to only those absolutely necessary for Dockerfile generation, following the recommended fix in the source.

]]>criticaladvisorysstibentomlcode-executiondockerhttps://feed.craftedsignal.io/briefs/2026-04-moby-authz-bypass/Fri, 27 Mar 2026 17:44:58 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-moby-authz-bypass/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.A 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 go/github.com/moby/moby (versions prior to 29.3.1), go/github.com/docker/docker (versions prior to 29.3.1), and go/github.com/moby/moby/v2 (versions prior to 2.0.0-beta.8).

Attack Chain

1. Attacker identifies a Docker environment utilizing an AuthZ plugin that relies on request body inspection for authorization.
2. Attacker crafts a malicious Docker API request targeting a sensitive resource or action.
3. The attacker inflates the request body to exceed a size threshold that triggers the bypass behavior.
4. The Docker daemon receives the oversized API request.
5. Due to the vulnerability, the Docker daemon forwards the request to the AuthZ plugin without the request body.
6. The AuthZ plugin, lacking the request body, makes an authorization decision based on incomplete information.
7. The AuthZ plugin, unable to properly validate the request, grants access to the sensitive resource or action.
8. The attacker successfully executes the unauthorized action, bypassing the intended security controls.

Impact

This 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.

Recommendation

• Upgrade 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.
• For 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.
• Restrict access to the Docker API to trusted parties following the principle of least privilege to reduce the attack surface.

]]>highadvisorydockerauthzauthorizationbypasscve-2026-34040