Critical Remote Code Execution vulnerability reported in Imunify360 AV

CloudLinux has patched a critical remote code execution vulnerability in Imunify360 AV, a malware scanning solution that protects approximately 56 million websites across Linux-based hosting environments. 

The security flaw, which has not yet been assigned a CVE allows remote attackers to execute arbitrary commands and potentially achieve complete server takeover through exploitation of the scanner's deobfuscation logic. The vulnerability affects versions of the malware scanning component prior to v32.7.4.0, impacting both the full Imunify360 security suite as well as ImunifyAV+ and free ImunifyAV products.

The root cause of the vulnerability is in flawed deobfuscation logic within the AI-bolit component that processes potentially malicious PHP files. When the scanner attempts to analyze obfuscated malware by converting encoded PHP into readable code, it executes untrusted function names and payloads extracted directly from attacker-supplied files without proper validation. The scanner uses the PHP function call_user_func_array to dynamically invoke functions discovered during deobfuscation, but critically fails to verify whether these functions are safe to execute. This design flaw allows attackers to embed specially crafted obfuscated PHP code that matches Imunify360's deobfuscation signatures, causing the scanner to execute dangerous PHP functions including system(), exec(), shell_exec(), passthru(), eval(), and assert().

Two primary exploitation vectors are an "eval-hex function pattern" where attackers encode malicious function names and commands using hexadecimal escape sequences, which the deobfuscator unwraps and then executes. The second vector exploits the deobfuscateDeltaOrd function, which takes a string and a list of function names recovered from obfuscated payloads and applies those functions sequentially through the Helpers::executeWrapper method. Both flows rely on the same flawed execution wrapper that provides no safeguards against executing attacker-controlled code.

Deobfuscation is enabled by default in the Imunify360 integration, unlike to the standalone AI-Bolit CLI where it remains disabled unless explicitly activated. Analysis of the Imunify360 codebase reveals that the scanner wrapper always passes the --deobfuscate flag when invoking AI-bolit, meaning all scan types automatically trigger the vulnerable code path. 

On November 14, 2025, researchers disclosed an additional attack vector that significantly increases the severity of the vulnerability. The database scanner component (imunify_dbscan.php) was found to be vulnerable in exactly the same manner as the file scanner. This means attackers do not even need to upload malicious files to hosting servers to trigger exploitation. Instead, on a WordPress site for example, an attacker can simply post a malicious comment containing the exploit payload. The comment does not require moderator approval, and when Imunify360 performs its routine database scan, the malicious payload is pulled directly from MySQL and passed into the same vulnerable deobfuscation functions. 

Imunify360 AV typically runs as a privileged service with root access to facilitate comprehensive malware scanning across multiple customer accounts on the same physical server. When an attacker successfully exploits this vulnerability, they can escalate from compromising a single website to gaining complete control of the entire hosting server.

CloudLinux released patches for the vulnerability on October 21, 2025, under internal tracking reference DEF-36789, advising customers to update immediately. The vendor provided minimal public communication about the critical security issue, with the only official notification appearing as a brief advisory on the company's Zendesk support portal on November 4, 2025. 

System administrators running any version of Imunify360, ImunifyAV+, or ImunifyAV should immediately upgrade to AI-bolit version v32.7.4.0 or later. Administrators should also contact CloudLinux support to inquire about potential exposure, request information on detecting exploitation attempts in log files, and obtain post-incident guidance if compromise is suspected. Given the lack of official information about active exploitation, hosting providers should proactively investigate their environments for signs of compromise, including unexpected file modifications, unauthorized administrator accounts, suspicious processes running with elevated privileges, or unusual network connections originating from scanner processes.