Imunify360 for Customers — Understanding the Security Layer

Every iWebVault cPanel server runs Imunify360 — a real-time security layer that scans uploaded files for malware, blocks malicious traffic at the firewall, and patches PHP vulnerabilities virtually. Most of the time it works silently. When it surfaces, it’s usually telling you something important: a file was quarantined, an upload was blocked, an attack was stopped. This guide explains what Imunify360 actually does, what its notifications mean, and how to handle the situations you’ll occasionally run into.

What Imunify360 does, in practical terms

• Scans uploaded files in real time. Any file written to your account is checked against malware signatures. Known-bad files are quarantined instantly.
• Periodic full-account scans. Every file in your account is scanned on a rolling schedule (typically daily for active accounts).
• Web Application Firewall. Hostile HTTP requests (SQL injection attempts, exploit probes, brute-force logins) are blocked before reaching your code.
• Reputation-based IP blocking. IPs known to attack across many servers get blocked globally; you benefit from collective intelligence.
• Proactive Defense (PHP). Runs PHP scripts in a sandbox that catches malicious behaviors at execution time — catches malware that signature-scanning missed.
• KernelCare patching. Server kernel security patches applied without reboots — you stay protected without downtime.

Accessing the customer interface

cPanel → Security → Imunify360. You’ll see a dashboard with:

• Files tab — every file flagged or quarantined, with action buttons.
• History — past scans and detections.
• Ignore List — files you’ve marked as safe to skip in future scans.
• Action — manually trigger a scan, view scan settings.

When Imunify360 detects something

You’ll receive an email notification: “Malware found in /home/user/public_html/…”. The file is automatically quarantined (moved to a protected location where it can’t execute) unless your plan is configured otherwise.

Detection types you’ll see:

Responding to a real detection

1. Don’t panic and don’t restore the file — first understand what happened.
2. Check the file path. Is it inside a known plugin, theme, or custom code? Custom code that’s been around for years was probably injected. Plugin/theme files were probably exploited via the plugin/theme itself.
3. Identify entry point. Most WordPress malware gets in via outdated plugins, weak admin passwords, or compromised hosting credentials. Check WP login history, file modification dates near the detection.
4. Clean, don’t just delete. Deleting one infected file doesn’t remove the attacker. Run a full Imunify360 scan: Action → Start Scanning. It walks the entire account.
5. Change passwords. cPanel password, WordPress admin passwords, FTP/SSH credentials. Until you do, the attacker can re-upload.
6. Update everything. WordPress core, all plugins, all themes. The original vulnerability is probably still there.
7. Restore from clean backup if needed. JetBackup 5 → roll back to a backup from before the infection date. Restore guide.

Handling false positives

Sometimes Imunify360 flags a legitimate file — usually a plugin using unusual code patterns or a custom script with eval(). When you’re confident a file is safe:

1. Imunify360 → Files tab.
2. Find the quarantined file.
3. Click Restore.
4. Click Add to Ignore List so it won’t be re-flagged.

Verify before restoring: is the file from the official plugin/theme distribution? Compare against the original from WordPress.org. If the file came from an unofficial source, or has been modified, the “false positive” might actually be real.

If a plugin has many files flagged consistently, contact the plugin author — they may be using techniques that trigger heuristics, and they can adjust their code or get on Imunify360’s whitelist.

Web Application Firewall (WAF)

The WAF blocks malicious HTTP requests before they reach your application. Usually invisible to you — attacks fail silently from the attacker’s perspective.

Occasionally the WAF blocks something legitimate (an admin user uploading a file that triggers an injection signature, or a contact form with unusual characters). Symptoms: 403 Forbidden errors on specific actions.

To resolve:

• Note exact time and what you were doing.
• Open a support ticket with the details — we can identify which rule triggered and whitelist your action.

What Imunify360 doesn’t do

• Won’t catch everything immediately. Zero-day malware bypasses signature-based detection until signatures update. Proactive Defense catches most, but not all.
• Won’t prevent compromise via weak passwords. If an attacker logs into WordPress with your admin password, they’re “legitimate” from the server’s perspective. Strong passwords + 2FA are still your responsibility.
• Won’t undo damage already done. Imunify360 quarantines newly-detected malware; if the attacker exfiltrated data or modified the database before detection, those changes don’t auto-rollback.
• Won’t replace good practices. Keep WP core/plugins/themes updated, use strong passwords, audit users, monitor your site. Imunify360 is one layer, not the whole stack.

The other security layers on iWebVault

Imunify360 doesn’t work alone. iWebVault servers also run:

• CSF (ConfigServer Firewall) — kernel-level firewall. Blocks IPs after repeated failed logins, port-scan attempts. CSF guide.
• ConfigServer Exploit Scanner — secondary malware scanner running independently.
• CPGuard — additional monitoring for cPanel-specific exploits.

Layered defense means a threat that bypasses one layer is likely caught by another. As a customer you interact mostly with Imunify360; the others operate at the server level.

Common Imunify360 questions

“Lots of detections suddenly — am I being attacked?” Probably Imunify360 just finished a thorough rescan after a signature update. Detections all clustered at one timestamp = batch result, not active attack.

“Detections keep coming back even after I clean.” Attacker still has access. Change all passwords, audit cron jobs (attackers often add reinfection crons), check for unknown admin users in WordPress.

“My site is fine but Imunify360 says it’s not.” Quarantined files don’t break sites that don’t depend on them. Many infections lurk in unused theme files or test pages. If your site works, that means the quarantined file wasn’t actively being called — but it was definitely waiting to be.

“Can I disable Imunify360?” No — it runs at the server level for everyone’s protection. You can manage detections (restore, ignore) but not turn off the scanner.

“How often does it scan?” Real-time on file uploads (instant). Background full scans run continuously across the server, with each account getting fully rescanned typically every 24-48 hours.

What’s next

• If you have an active infection: Malware cleanup guide.
• Preventing future infections: Hardening WordPress.
• Origin protection beyond malware: Cloudflare + offshore origin protection.

Imunify360 is doing work for you 24/7 whether you notice or not. Pay attention when it sends notifications — those are real, even when they’re false positives. The interface is straightforward; spending five minutes browsing it once means you’ll know exactly what to do the day something needs action.