Malware Scanner: Cleanup and restore loop issue

Issue

Imunify360's Malware Scanner enters a repeating restore/cleanup loop on one or more files, most commonly WordPress plugin files. Imunify360 detects a file as malware and cleans it (truncates it to zero bytes). Some time later, the file is automatically restored to its original content, the real-time scanner immediately re-detects it, and the cycle repeats. This can occur across multiple files, generating repeated malware notifications.

Example affected files:

• wp-content/plugins/maintenance/maintenance.php
• wp-content/plugins/contact-form-7/includes/formatting.php

Environment

• Imunify360
• Malware Scanner
• WordPress

Solution

1. Confirm the pattern: check the Imunify360 malware history for the affected file. You should see a repeating sequence: detected –> cleaned (file size drops to zero) –> restored to its original size –> detected again –> recurring periodically.
2. As an interim measure, add the affected file to the local ignore list to stop the repeated cleanup and notifications. 
   2.1. Run as root: imunify360-agent malware ignore add /path/to/affected/file 
   2.2. Repeat for each affected file.
3. Do not rely on forcing a signature update or restarting Imunify360 services to resolve this loop. Both the detection verdict and the automated restore are controlled centrally (cloud-side); refreshing the local signature database (imunify360-agent update sigs --force) and restarting the imunify360, imunify-realtime-av, or aibolit-resident services are not yet confirmed to stop the loop.
4. If you're reporting this to CloudLinux support, include the SHA-256 hash of each affected file and a diagnostic bundle: imunify360-agent doctor. This helps tie your specific files to the ongoing signature review.
5. Once CloudLinux corrects the detection rule centrally, the loop stops automatically across all affected servers with no further action required on your end. At that point, the ignore-list entries added in step two can be removed

Cause

The loop is caused by two cloud-side systems disagreeing. A malware detection rule is still classifying the affected file's content as malicious, while the same content has already been queued, separately, for a false-positive correction. Server logs show this correction being applied by CleanupRevertPlugin, with initiator: imunify (a cloud-driven channel, not a local process). Because the file is still flagged by the detection rule, the real-time scanner cleans it again as soon as it's restored, and the cycle repeats. The local scan result field try_restore: False is unrelated to this cloud-driven restore.

Since both the detection verdict and the restore queue live centrally, local remediation (signature refresh, service restart) has no effect on the loop. CloudLinux's malware processing team has the affected detection rule under active review; the loop resolves automatically once the rule's verdict is corrected.

Useful Links

Internal Task: DEF-48094