CVE-2025-27520: Critical BentoML Flaw Allows Full Remote Code Execution, Exploit Available

This security issue gives an attacker the ability to achieve remote code execution on servers running vulnerable BentoML versions by sending a specially crafted HTTP request that exploits an insecure deserialization flaw. The following protection guardrails can further prevent the following steps an attacker can take: Initially, when the attacker attempts to exploit the pickle.loads() function with a malicious payload by manipulating an HTTP request to omit buffer-lengths in the metadata, Python Deserialization Protection intercepts this deserialization process, applying policies to restrict harmful function calls from the deserialized object, thereby aiming to block the arbitrary code execution before it fully materializes on the server. Should the attacker's code, now running on the server, attempt to execute operating system commands for reconnaissance, such as trying to run find or grep to locate AI model files or API keys, Python OS Command Injection Prevention would detect and block these OS command execution attempts originating from the Python process. If the compromised application is running within a container and the attacker, after gaining initial execution, tries to download and run additional tools like network scanners or malware not present in the original container image, Container Drift Protection (Binaries & Scripts) would prevent the execution of these new, unauthorized binaries by maintaining a manifest of original executables. Furthermore, if the attacker's code attempts to execute any script or binary, including legitimate system tools used for malicious purposes like establishing a pivot point with socat, from a non-standard or unauthorized directory such as a temporary download folder, Process Path Exec Allow would block such execution by enforcing that processes only run from pre-approved filesystem paths. Finally, to prevent data theft or unauthorized modification, such as the attacker trying to read sensitive AI model files, configuration files containing credentials, or attempting to corrupt model files on disk to sabotage AI operations, Sensitive File Access monitors and can block these unauthorized access attempts to files designated as critical.

• T1203: Exploitation for Client Execution: The attacker can send malicious payloads via HTTP requests to exploit the deserialization flaw. This involves 'Exploitation for Client Execution' where the attacker sends data to a vulnerable server to trigger execution of arbitrary code. The article mentions that 'the payload content is sourced from an HTTP request, which can be fully manipulated by the attack.' This aligns with the technique of exploiting client-side vulnerabilities through crafted requests.

F1: Exploitation of BentoML CVE-2025-27520 via insecure deserialization of a user-controlled HTTP request payload, leading to Remote Code Execution (RCE).

• Attacker identifies a target system running a vulnerable version of BentoML (e.g., =1.3.4, or any version <1.4.3 but not 1.4.3 itself). (Cited from: "The following versions of BentoML are affected:=1.3.4, <1.4.3", "latest version (v1.4.2) of BentoML")
• Attacker crafts a malicious serialized Python object (pickle payload) designed to execute arbitrary code upon deserialization. (Cited from: "maliciously crafted serialized data can execute harmful actions during deserialization.")
• Attacker constructs an HTTP request where the payload content contains the malicious serialized object. (Cited from: "payload content is sourced from an HTTP request, which can be fully manipulated by the attack.")
• Crucially, the attacker ensures that the payload.metadata within the HTTP request does not include the key "buffer-lengths" to trigger the vulnerable code path in serde.py. (Cited from: "if 'buffer-lengths' not in payload.metadata: return pickle.loads(b"".join(payload.data))")
• The attacker sends this crafted HTTP request to the vulnerable BentoML server.
• The BentoML server's deserialize_value function in serde.py receives the payload. Due to the absence of "buffer-lengths" in the metadata, it proceeds to call pickle.loads() on the attacker-controlled data. (Cited from: "def deserialize_value(self, payload: Payload) -> t.Any: if 'buffer-lengths' not in payload.metadata: return pickle.loads(b"".join(payload.data))")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because the vulnerability involves insecure deserialization in Python (pickle.loads). BR-76 intercepts the Python deserialization process and applies policies to restrict the execution of function calls from deserialized objects, potentially blocking the harmful actions of the malicious payload before full code execution occurs.
• The pickle.loads() function deserializes the malicious object, executing the arbitrary code embedded by the attacker on the server. (Cited from: "It allows any unauthenticated user to execute arbitrary code on the server.", "maliciously crafted serialized data can execute harmful actions during deserialization.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it aims to limit the actions (like function calls) that Python deserialized objects can take. By intercepting the deserialization process and applying restrictive policies, it can prevent or limit the execution of the arbitrary code embedded in the malicious object.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the executed arbitrary Python code might attempt to run OS-level commands. BR-77 monitors Python runtime for patterns indicative of OS command injection (e.g., execution of system binaries/shell commands from Python) and blocks such attempts.
  • BR-92: Python Eval Protection - This mechanism is applicable if the arbitrary Python code executed as part of the RCE uses the eval() function with untrusted input. BR-92 intercepts calls to eval() and can block its execution, preventing code injection that relies on this function.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, this mechanism is applicable because the RCE might lead to the execution of new binaries or scripts not present in the original container image. BR-54 maintains a manifest of original executables and blocks execution of anything new.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because the RCE could lead to unauthorized new processes starting. BR-82 uses NSJail to sandbox and restrict process execution based on predefined rules, potentially blocking new processes spawned by the RCE.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the RCE attempts to execute a process from a filesystem path not on the pre-defined allowlist. BR-88 intercepts exec() calls and blocks execution from non-allowed paths.
  • BR-90: Process Exec Deny - This mechanism is applicable if the RCE attempts to execute a process whose path suffix matches a predefined deny list (e.g., /nc, /wget, /curl). BR-90 intercepts exec() calls and blocks execution of denied processes.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because the RCE could involve adding new executable files to the host filesystem outside of trusted package managers. BR-62 monitors for such additions and blocks their execution.
  • BR-86: PTrace Protection - This mechanism is applicable if the arbitrary code executed by the RCE attempts to use the ptrace system call to inspect or manipulate other processes' memory, for instance, to inject code or escalate privileges. BR-86 intercepts and monitors ptrace calls to prevent unauthorized memory access.
• As a result, the attacker achieves Remote Code Execution (RCE), potentially leading to complete system compromise, data theft, denial of service, or malware installation. (Cited from: "Successful exploitation allows an attacker to execute arbitrary code on the server, potentially leading to:Complete system compromise Data theft Denial of service Installation of malware")
  • BR-76: Python Deserialization Protection - This mechanism applies by attempting to block malicious function calls from the deserialized object, thus preventing the RCE from fully materializing or limiting its impact.
  • BR-77: Python OS Command Injection Prevention - This mechanism applies by blocking attempts from the RCE payload to execute OS-level commands, which are often a key part of system compromise, data theft, or malware installation.
  • BR-92: Python Eval Protection - If the RCE payload uses eval() for its malicious actions, this mechanism applies by blocking such eval() calls, thereby hindering the RCE.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, this mechanism applies by preventing the RCE from executing any newly dropped malware (binaries/scripts) not part of the original image, which is a common follow-on action to RCE.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing the RCE from starting unauthorized new processes, which could be used for further compromise, data theft, or running malware.
  • BR-88: Process Path Exec Allow - This mechanism applies by blocking any executables run by the RCE if they reside in a disallowed filesystem path, limiting the attacker's ability to run tools or malware.
  • BR-90: Process Exec Deny - This mechanism applies by blocking the RCE from executing specific denied tools (like /nc, /wget, /curl by default) often used for data exfiltration or downloading further malware.
  • BR-91: Sensitive File Access - This mechanism applies by monitoring and potentially blocking attempts by the RCE payload to access (read or modify) files designated as sensitive (e.g., configuration files, credentials, SSH keys), which is critical for preventing data theft.
  • BR-52: Data Resource Mandatory Access Control - This mechanism applies by enforcing an allow-list of binaries permitted to access critical data directories. If the RCE involves an unauthorized binary (e.g., newly dropped malware) attempting to access these directories for data theft or ransomware-like actions, it would be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism applies by preventing any process, including one compromised by RCE, from making unauthorized write attempts to specified critical directories, which can help prevent system compromise or malware installation in those locations.
  • BR-62: Linux/Host Drift Protection - This mechanism applies by blocking the execution of any new executable files (malware) introduced by the RCE if they weren't installed via a trusted package manager.
  • BR-86: PTrace Protection - If the RCE payload attempts to use ptrace for further compromise (e.g., injecting into other processes, tampering with memory), this mechanism would apply by blocking unauthorized ptrace calls.
• The availability of a proof-of-concept exploit facilitates this attack. (Cited from: "A proof-of-concept exploit for CVE-2025-27520 is available")