Imunify360 combines several protections for compatible hosting environments. Understanding their roles helps you interpret an alert and choose an appropriate response. Available features depend on your service, installed components and configuration; an icon in cPanel does not establish that every protection mode is active.
Three complementary protections
- The web application firewall (WAF) examines web requests and can block those matching its rules. A blocked request does not, by itself, establish that the website was infected.
- File scanning looks for suspicious content within its scan scope. Results and history help distinguish a detection, pending cleanup and a completed action.
- Proactive Defense analyzes PHP script behavior when a compatible module is loaded and enabled. Logging mode records events; blocking mode can stop execution detected as malicious.
These mechanisms operate at different stages. See the Imunify360 administration documentation for their settings. None guarantees the absence of every intrusion or inspection of every item of data, database or application. A scan with no detections must be interpreted in light of its scope and timing.
Read an alert before acting
If your panel provides Imunify360 access, record the domain, date and time zone, affected file or URL, reason and status. The user interface guide describes results and history. A missing cleanup button may simply reflect your permissions.
An alert on a legitimate file may be a false positive. It needs investigation, not an automatic exclusion. Adding a file to an ignore list reduces the checks applied to it; restoring the original after cleanup can reintroduce suspicious content. Have the case reviewed before taking those actions, and do not turn off protections globally just to remove a message.
If a website function is blocked
Record the exact action, time and displayed message, then check for a corresponding event. An HTTP 403 response or PHP error does not establish that Imunify360 caused it. The Proactive Defense FAQ confirms that false positives are possible. Any exception should be narrowly scoped, justified and validated with the technical administrator.
If a compromise is confirmed
Contact support promptly and preserve useful diagnostic evidence before cleanup. Depending on the incident, the response may involve limiting exposure, retaining a copy of the affected state, and choosing a verified restore or repair. Avoid deleting files in bulk based only on their names.
Recovery must address the entry point, vulnerable components and compromised access. A restore can reintroduce a vulnerability; file cleanup alone does not revoke stolen access. For WordPress, the official post-compromise guide explains the approach. Relevant credentials and sessions should be renewed or revoked from a trusted environment, coordinated with recovery.
Reduce everyday risks
Maintain your CMS, plugins and themes, remove unused components, and use trusted sources. Limit administrator accounts, use unique passwords and enable multifactor authentication where available. Keep separate backups and test restoration. The WordPress hardening guide explains these complementary measures.
Have Nuagerie review the situation
Open a request in your client area with the symptoms, times and relevant alert references. Remove passwords, tokens and personal data; do not send a suspicious file unless the team provides instructions. We can help define the problem’s scope and the response appropriate to your service. To arrange website maintenance or security work, contact our team.
