The Scanner That Turned Against the Web
- Javier Conejo del Cerro
- hace 4 días
- 4 Min. de lectura
A critical and long-undetected remote code execution flaw in ImunifyAV/Imunify360—one of the most widely deployed malware scanners in the Linux hosting ecosystem—turned the security tool into an attack vector itself. Through a single vulnerability in AI-Bolit’s deobfuscation engine, threat actors could execute arbitrary PHP functions, compromise entire websites, escalate to full server takeover, and—after the November 14 update—achieve RCE without uploading malware at all. With 56+ million websites protected by Imunify, the flaw represents one of the most severe supply-layer weaknesses disclosed in recent years.
Phase 1 — The Hidden Weakness in the Web’s Defense Layer
The vulnerability originated in AI-Bolit’s deobfuscation logic, used by Imunify360, ImunifyAV+, and the free ImunifyAV versions. The scanner attempted to unpack and analyze obfuscated PHP samples, but its internal mechanism relied on call_user_func_array to execute whatever function names were extracted—without validating whether the function was safe.
This meant that if an attacker supplied obfuscated code containing strings resolving to system, exec, shell_exec, passthru, eval, or similar high-risk PHP functions, the scanner would execute those functions during analysis. That single design flaw transformed the malware scanner into an unintentional PHP execution engine—capable of running attacker-controlled commands on the host.
Imunify360 made the issue far worse: unlike the standalone AI-Bolit CLI, where deep deobfuscation is disabled by default, Imunify360 forces deobfuscation to “always on” for background scans, rapid scans, on-demand scans, and user-initiated scans.
In other words, every scan guaranteed the vulnerability could be triggered.
Phase 2 — The RCE Trigger: From File Upload to Server Takeover
Before the November 14 update, exploitation required the attacker to place a malicious PHP payload somewhere on the target filesystem. This could be done via any basic foothold: a vulnerable plugin, an upload form, or a misconfigured directory. When Imunify360 scanned the file, the deobfuscation engine would reconstruct the obfuscated function names and unwittingly call attacker-specified system-level commands.
Patchstack demonstrated a Proof of Concept: a simple obfuscated PHP snippet placed in /tmp triggered the scanner to execute system commands and write a file to disk.
In shared hosting environments—where Imunify frequently runs with elevated privileges—this could escalate from:
single-site compromise →
cross-account access →
root-level server takeover
This made the vulnerability catastrophic for hosting providers, cPanel/WHM servers, Plesk servers, and managed WordPress hosting.
Phase 3 — The November 14 Disclosure: A Second, Even Deadlier RCE Vector
On November 14, researchers uncovered a second RCE vector—the database scanner (imunify_dbscan.php)—vulnerable in exactly the same way as the file scanner. This made the problem far more severe:
Why the DB scanner vector changes everything
Attackers do not need to upload malware at all.
On platforms like WordPress, a malicious comment or form submission is enough.
The comment does not need approval to be processed.
During Imunify360’s routine DB scan, the payload is pulled directly from MySQL.
The database scanner passes that payload into the same dangerous deobfuscation path.
The scanner then executes attacker-controlled PHP functions, achieving full RCE.
This means that trivial actions—posting a comment, filling a contact form, adding a username—could allow attackers to execute arbitrary commands on the webserver when the next scheduled DB scan runs.
Severity revision
Because the DB vector removes all upload requirements, researchers revised the severity to:
CVSS 9.9 — near-maximal criticality.
Phase 4 — Vendor Response and Patch Analysis
CloudLinux quietly patched the issue in late October (DEF-36789) and backported fixes on November 10 (DEF-37355). Public disclosure was limited to a brief Zendesk note, with:
no coordinated advisory
no assigned CVE
no public detection guidance
no confirmation of exploitation in the wild
This lack of transparency increased risk for hosting providers who may still be unaware of their exposure. The fix introduced a whitelist of safe decoding functions (e.g., base64_decode, gzinflate, chr, ord) and blocks all other functions, ensuring the scanner can no longer execute attacker-controlled PHP.
Despite the patch, the ecosystem remains at risk because:
Many hosting providers update slowly
Imunify’s footprint covers tens of millions of sites
No tools currently exist to detect whether exploitation occurred
Payloads were designed to be inherently obfuscated and leave minimal artifacts
Phase 5 — Required Actions for Hosting Providers
Administrators should take immediate steps to contain risk:
Immediate
Patch all Imunify360/ImunifyAV/AI-Bolit installations to v32.7.4.0+
If patching is not possible, disable or isolate the scanner (VM/container)
Remove elevated privileges for scanning services
Audit MySQL tables for obfuscated payload indicators
Review logs for unusual PHP exec/shell activity
Contact CloudLinux for assessment of potential exploitation
Short-term
Harden file upload and comment workflows
Deploy WAF rules blocking obfuscated PHP patterns
Audit cross-account privileges in shared hosting environments
Long-term
Implement zero-trust scanning practices
Adopt sandboxed malware scanning environments
Require vendor transparency for future security incidents
The ImunifyAV/Imunify360 vulnerability highlights a fundamental truth about cybersecurity: when the tools meant to protect the web become attack paths, the blast radius is enormous. A single oversight in a deobfuscation function cascaded into a global, high-severity threat affecting tens of millions of websites—culminating in a second RCE vector that requires nothing more than a comment field.
The incident is a wake-up call for the hosting industry:
security layers must be validated with the same rigor as the threats they defend against.
Administrators who act quickly and patch immediately will contain risk. Those who hesitate may discover that the scanner designed to protect their environments has already executed the attacker’s code.
Bleeping Computer:
Comentarios