Universal Imunify360 Cache Ignore Script: How to Whitelist WordPress Cache Paths, Stop False Positive Malware Alerts, and Fix WP-Content Cache Scanning Issues on cPanel/WHM Servers

---

Why Imunify360 Flags WordPress Cache Files as Malware

If you manage shared hosting, VPS, or dedicated servers running cPanel, WHM, DirectAdmin, or Plesk with Imunify360 as your security layer, you’ve almost certainly encountered a frustrating scenario: WordPress cache files being flagged as malware, quarantined without warning, and your clients’ websites breaking overnight — not because of an actual infection, but because Imunify360’s real-time file scanning engine mistakenly identifies legitimate cache output as a security threat.

This is one of the most common pain points for Linux server administrators, hosting providers, and WordPress site owners relying on caching plugins such as WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache (LSCache), Breeze, Comet Cache, Cache Enabler, Swift Performance, and dozens of others. These plugins generate dynamic PHP files, precompiled HTML, minified JavaScript/CSS files, and serialized data files inside the wp-content/cache/ directory hierarchy. Imunify360’s heuristic detection engine, in trying to protect your server from obfuscated malware and backdoor shells, can misidentify these cache files — particularly minified or encoded JS/CSS — as suspicious.

The result? Broken pages, missing assets, confused clients, and support tickets piling up.

The definitive solution is to configure the user_ignoremalware whitelist file in Imunify360 with a carefully crafted set of wildcard path patterns that cover every possible WordPress installation path across all cPanel user accounts — including addon domains, subdomains, and nested directory structures. This guide walks you through the complete, bulletproof implementation: what the commands do, why each path matrix matters, how to clean up the config, and how to verify it’s active.

---

What Is Imunify360 and How Does Its Malware Scanner Work?

Imunify360 is a comprehensive, AI-powered security suite developed by CloudLinux Inc. and widely deployed on shared hosting and managed WordPress hosting environments. It bundles together several security components:

• Real-time file system scanner (On-Access scanning / inotify-based)
• Signature-based malware detection engine
• Heuristic and behavioral analysis
• Web Application Firewall (WAF) — ModSecurity-based
• Intrusion Detection and Prevention System (IDS/IPS)
• Proactive Defense™ module
• Reputation management and IP blocklisting

The malware scanning module monitors file system events via inotify on Linux. When a file is created or modified, Imunify360 scans it against a database of malware signatures and runs it through heuristic analysis. If a file matches a known pattern — obfuscated PHP, base64-encoded scripts, suspicious eval() calls, web shells — it gets flagged, optionally quarantined, and reported.

Why Cache Files Trigger False Positives

WordPress caching plugins generate files that can look suspicious to automated scanners:

• Minified JavaScript with compressed, unreadable code patterns
• Serialized PHP objects stored in flat files
• Precompiled PHP cache files with dense, non-human-readable output
• HTML files with embedded inline scripts (after minification)
• Advanced cache files (advanced-cache.php) with dynamic bootstrapping code
• Object cache files from Redis or Memcached fallback layers

These files are, by nature, compact, encoded, and structurally similar to techniques used by malware authors to obfuscate malicious payloads. Imunify360’s scanner — particularly its heuristic engine — can misclassify them. The fix is not to disable Imunify360, but to tell it which directories are safe to ignore during malware scanning.

---

Understanding the user_ignoremalware Configuration File

Imunify360 provides an official mechanism for excluding paths from malware scanning: the user_ignoremalware file located at:

/etc/sysconfig/imunify360/user_ignoremalware

This is a plain-text file where each line defines a path or glob/wildcard pattern that Imunify360’s scanner should skip. It is the server-level (root-controlled) whitelist, as opposed to the per-user ignore list that individual cPanel account holders can configure through the Imunify360 interface in cPanel.

Key characteristics of this file:

• One path or pattern per line
• Supports standard shell glob wildcards (* for any string, ? for single character)
• Applied globally across all users on the server
• Requires a daemon restart to take effect
• Must be managed as the root user via SSH

Security note: Whitelisting cache directories does not disable malware scanning entirely. Files outside these paths continue to be scanned normally. You are instructing Imunify360 to trust these specific directory trees — which is appropriate since their contents are generated by your WordPress stack, not uploaded by external attackers.

---

The Four Bulletproof Wildcard Path Matrices Explained

WordPress installations on cPanel servers can live in many different directory configurations:

1. Primary domain — installed directly in public_html
2. Addon domain — installed in a subdirectory of public_html (e.g., public_html/addondomain.com/)
3. Subdomain — typically in a folder like public_html/blog/ or public_html/subdomain/
4. Deeply nested installations — WordPress inside multiple subdirectory levels

This is why a single wildcard path is not enough. You need four distinct pattern matrices to cover every realistic scenario across all cPanel user accounts.

---

Path Matrix 1: Primary WordPress Installation Cache

/home/*/public_html/wp-content/cache/*

What this covers:

This is the most common case — WordPress installed at the root of the primary cPanel domain, with the standard wp-content/cache/ directory structure intact.

• /home/ — The base home directory for all cPanel accounts
• */ — Wildcard for any cPanel username (e.g., john, mysite, client42)
• public_html/ — The web root for the primary domain
• wp-content/cache/ — The standard WordPress cache directory used by all major caching plugins
• * — Any file or subdirectory within the cache folder

Plugins covered: WP Rocket (wp-rocket/), W3 Total Cache (w3tc/), WP Super Cache (supercache/), LiteSpeed Cache (lscache/), Cache Enabler, Breeze, Comet Cache, and all others that write to wp-content/cache/.

---

Path Matrix 2: WordPress Installed in a Subdirectory (Addon Domains / Subdomains)

/home/*/public_html/*/cache/*

What this covers:

When a WordPress site is installed not at the public root but inside a subdirectory of public_html, this pattern handles the cache path. This is typical for:

• Addon domains managed through cPanel, where the domain folder lives inside public_html
• Subdomains mapped to subdirectories within public_html
• Staging sites placed in a subfolder (e.g., public_html/staging/wp-content/cache/)

The extra wildcard */ between public_html/ and cache/ matches any one directory level — meaning /home/user/public_html/addondomain/wp-content/cache/ and /home/user/public_html/myblog/wp-content/cache/ are both covered.

---

Path Matrix 3: Deep-Level Cache Paths (Two-Level Nesting)

/home/*/*/cache/*

What this covers:

Some hosting configurations and control panel setups place WordPress installation directories at deeper paths that don’t follow the standard public_html web root convention. This pattern covers:

• Custom document roots set at the account level
• Reseller hosting environments where the directory tree is an extra level deep
• Direct ~/domain.com/ style paths some cPanel themes configure
• Non-standard WordPress multisite setups with custom directory structures

The pattern /*/*/cache/* matches any two directory levels below /home/username/ before reaching the cache folder — giving flexibility for non-standard layouts.

---

Path Matrix 4: Ultra-Deep Nested Cache Paths (Three-Level Nesting)

/home/*/*/*/cache/*

What this covers:

This is the catch-all for deeply nested WordPress installations, which occur in:

• WordPress Multisite (WPMS) network sub-installations with custom paths
• Reseller or multi-tier hosting structures with extra organizational directories
• DevOps deployment pipelines that create deep directory hierarchies
• Custom cPanel directory roots with multiple intermediate folders
• Environments where site managers place WordPress inside public_html/sites/client/wordpress/-style structures

Together, all four path matrices create a comprehensive whitelist that handles virtually every WordPress + cPanel directory topology in production use.

---

Step-by-Step: The Universal Imunify360 Cache Ignore Script

All commands below must be run as the root user via SSH. Do not use sudo if you are already root. If you need to switch to root, run sudo su - first.

---

Step 1: Create the File and Inject All Four Path Matrices

echo "/home/*/public_html/wp-content/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/public_html/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/*/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware

Command breakdown:

• echo "..." — Outputs the path pattern as a string
• >> — Appends the output to the file (creates the file if it doesn’t exist; does not overwrite existing content)
• /etc/sysconfig/imunify360/user_ignoremalware — The target configuration file path

Running all four echo commands sequentially ensures that every path matrix is appended to the whitelist file in order. The >> append operator is safe to use even if the file already contains entries from previous configurations — existing lines will not be disturbed.

Important: If the directory /etc/sysconfig/imunify360/ does not exist yet (unusual but possible on fresh installs), create it first with mkdir -p /etc/sysconfig/imunify360/.

---

Step 2: Remove Duplicates and Sort the File

sort -u /etc/sysconfig/imunify360/user_ignoremalware -o /etc/sysconfig/imunify360/user_ignoremalware

Command breakdown:

• sort — Linux utility to sort lines of text
• -u — Unique flag: removes duplicate lines after sorting
• -o /etc/sysconfig/imunify360/user_ignoremalware — Writes the sorted, deduplicated output back to the same file (in-place output; safe to use with the same input and output path)

This step is critical if you’ve run the echo commands multiple times, or if you had previously added some entries manually. Duplicate whitelist entries are harmless to Imunify360’s parsing but can cause confusion during audits. Running sort -u ensures a clean, readable, duplicate-free configuration.

---

Step 3: Restart the Imunify360 Daemon

systemctl restart imunify360

Why this is required:

Imunify360 reads its whitelist configuration at startup. Changes to user_ignoremalware are NOT applied dynamically — the daemon must be restarted to reload the file into memory. The systemctl restart imunify360 command gracefully stops and restarts the Imunify360 service via systemd (the standard init system on modern CentOS 7/8, AlmaLinux, CloudLinux, Rocky Linux, and Ubuntu servers).

Impact of the restart:

• The restart takes only a few seconds
• Active web traffic is not interrupted (the WAF/ModSecurity component may have a brief gap during reload, but this is negligible in practice)
• The new whitelist patterns are active immediately after the service comes back online
• No server reboot is required

To check the service status after restarting:

systemctl status imunify360

Look for Active: active (running) in the output.

---

Step 4: Verify the Active File Contents

cat /etc/sysconfig/imunify360/user_ignoremalware

Expected output:

/home/*/public_html/*/cache/*
/home/*/public_html/wp-content/cache/*
/home/*/*/cache/*
/home/*/*/*/cache/*

Note: The order may differ from input because sort rearranges lines alphabetically. This is normal and expected. Imunify360 processes all lines regardless of order.

If you see all four entries (and nothing unexpected), the configuration is correct and active.

---

Advanced Verification: Confirming Whitelist Is Active

Beyond just reading the file, you can confirm the whitelist is being loaded by Imunify360 through its own tooling:

Check via Imunify360 CLI

imunify360-agent malware ignore list

This command queries the Imunify360 agent’s active ignore list at runtime. If the entries appear here, they are actively being enforced by the scanner.

Check the Imunify360 Log

tail -f /var/log/imunify360/console.log

After restarting, look for log lines confirming the config was loaded. Any errors in parsing the user_ignoremalware file will appear here.

Test with a Real Cache File

Create a test file in a cache directory and verify it’s not flagged:

touch /home/testuser/public_html/wp-content/cache/test_file.php
imunify360-agent malware on-demand --path /home/testuser/public_html/wp-content/cache/test_file.php

If the whitelist is working, this file should not be reported as a threat.

---

Additional Cache Paths You May Need to Whitelist

Depending on your WordPress plugin stack and server configuration, you may want to extend the whitelist with additional path patterns. Below are common additional entries to consider:

LiteSpeed Cache (LSCache) — Object Cache

echo "/home/*/public_html/wp-content/object-cache.php" >> /etc/sysconfig/imunify360/user_ignoremalware

WP Rocket — Advanced Cache File

echo "/home/*/public_html/wp-content/advanced-cache.php" >> /etc/sysconfig/imunify360/user_ignoremalware

W3 Total Cache — db-cache and object-cache

echo "/home/*/public_html/wp-content/db.php" >> /etc/sysconfig/imunify360/user_ignoremalware

Temporary Upload Directories

echo "/home/*/tmp/*" >> /etc/sysconfig/imunify360/user_ignoremalware

WordPress Transient / Session Cache (Custom Paths)

If you use Redis or Memcached with file-based fallback in a custom directory:

echo "/home/*/public_html/wp-content/cache/redis-cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware

After adding any new entries, always re-run the deduplication step and restart the daemon:

sort -u /etc/sysconfig/imunify360/user_ignoremalware -o /etc/sysconfig/imunify360/user_ignoremalware
systemctl restart imunify360

---

Troubleshooting Common Issues

Issue: user_ignoremalware File Is Not Being Respected

Symptoms: Files in whitelisted paths are still being flagged or quarantined.

Solutions:

1. Confirm the daemon was restarted after editing: systemctl status imunify360
2. Verify the file path is correct (note: it’s user_ignoremalware, not ignoremalware or user_ignore_malware)
3. Check file permissions: ls -la /etc/sysconfig/imunify360/ — the file should be readable by root
4. Confirm the wildcard pattern matches the actual path: use ls /home/*/public_html/wp-content/cache/ to verify

Issue: The Config Directory Doesn’t Exist

Symptoms: echo command returns a “No such file or directory” error.

Solution:

mkdir -p /etc/sysconfig/imunify360/

Then re-run the echo commands.

Issue: Imunify360 Service Fails to Restart

Symptoms: systemctl restart imunify360 returns an error or the service doesn’t come back up.

Solutions:

1. Check the system journal: journalctl -xeu imunify360 --no-pager | tail -50
2. Look for syntax errors or permission issues in the config file
3. Validate the user_ignoremalware file has no binary or non-UTF8 characters: file /etc/sysconfig/imunify360/user_ignoremalware
4. As a last resort, backup and empty the file: cp /etc/sysconfig/imunify360/user_ignoremalware /etc/sysconfig/imunify360/user_ignoremalware.bak && > /etc/sysconfig/imunify360/user_ignoremalware

Issue: Imunify360 Keeps Re-Quarantining Already-Whitelisted Files

Symptoms: Files return to quarantine even after whitelisting.

Root cause: The files may have been quarantined before the whitelist was added. Imunify360 does not automatically restore quarantined files when a whitelist entry is added.

Solution: Restore quarantined files through the Imunify360 interface (WHM > Plugins > Imunify360 > Malware Scanner > History) or via the CLI:

imunify360-agent malware restore --hash <file_hash>

---

Security Considerations and Best Practices

Whitelisting cache directories is a balanced, industry-accepted approach — but it should be done thoughtfully:

What You Should NOT Whitelist

• /home/*/public_html/ (the entire web root) — This would defeat Imunify360’s protection entirely
• /home/*/public_html/wp-includes/* — Core WordPress files should always be scanned
• /home/*/public_html/wp-admin/* — Admin files are high-value targets for attackers
• /home/*/uploads/* — The uploads directory is a common malware injection point

Complement Whitelisting with Proper File Permissions

Ensure your WordPress cache directories have correct permissions:

chmod 755 /home/username/public_html/wp-content/cache/
find /home/username/public_html/wp-content/cache/ -type f -exec chmod 644 {} \;

Monitor What Gets Written to Cache Directories

Consider enabling audit logging on cache directories using auditd to detect if a real attacker is using the cache path as a malware drop location:

auditctl -w /home/username/public_html/wp-content/cache/ -p wa -k wp_cache_writes

Keep Imunify360 Updated

Regularly update Imunify360 to ensure its signature database and heuristic engine are current, reducing false positives over time:

yum update imunify360-firewall

---

Quick Reference: The Complete Script

Copy and paste this entire block as root to implement the universal cache whitelist in one shot:

# Step 1: Add all four wildcard path matrices
echo "/home/*/public_html/wp-content/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/public_html/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware
echo "/home/*/*/*/cache/*" >> /etc/sysconfig/imunify360/user_ignoremalware

# Step 2: Deduplicate and sort
sort -u /etc/sysconfig/imunify360/user_ignoremalware -o /etc/sysconfig/imunify360/user_ignoremalware

# Step 3: Restart the daemon
systemctl restart imunify360

# Step 4: Verify
cat /etc/sysconfig/imunify360/user_ignoremalware

---

Frequently Asked Questions (FAQ)

Q: Will whitelisting the cache directory affect Imunify360’s WAF (Web Application Firewall)? A: No. The user_ignoremalware file only affects the malware scanner module. The WAF, IDS/IPS, Proactive Defense, and other Imunify360 components are unaffected and continue to operate normally.

Q: Does this work with DirectAdmin, Plesk, or standalone servers (not just cPanel)? A: Yes, the user_ignoremalware file mechanism is the same across all Imunify360 deployments regardless of control panel. However, the paths (e.g., /home/*/public_html/) are cPanel-specific. For DirectAdmin, adjust to /home/*/domains/*/public_html/cache/*; for Plesk, adjust to /var/www/vhosts/*/httpdocs/wp-content/cache/*.

Q: Can individual cPanel users manage their own ignore lists? A: Yes. Individual users can add paths to their own ignore list via cPanel > Imunify360 > Malware Scanner > Ignore List. However, this only applies to their own account and doesn’t require root access. The user_ignoremalware file is the server-wide, root-level equivalent.

Q: How often do I need to run this script? A: Once is sufficient. The user_ignoremalware file persists across Imunify360 updates and server reboots. However, you should verify the file still exists after major Imunify360 version upgrades.

Q: My caching plugin stores cache outside wp-content/cache/ — will this help? A: Only partially. If your plugin writes cache to a different directory (e.g., some LiteSpeed configurations use server-level cache directories), you’ll need to add those specific paths separately. Always check your plugin’s documentation for its cache storage location.

Q: Is there a per-domain version of this whitelist? A: Not directly in user_ignoremalware. You can, however, add highly specific paths (e.g., /home/specificuser/public_html/wp-content/cache/*) instead of wildcards if you want granular control.

---

Conclusion: A Stable, Scalable Solution for Imunify360 + WordPress Hosting

The four-path-matrix approach documented in this guide represents the most comprehensive and reliable method for eliminating Imunify360 false positive malware detections in WordPress cache directories across all cPanel hosting environments.

By appending all four wildcard patterns to /etc/sysconfig/imunify360/user_ignoremalware, deduplicating with sort -u, and restarting the Imunify360 service via systemctl, you achieve:

• Zero false positives for all major WordPress caching plugins (WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, Cache Enabler, Breeze, and more)
• Full coverage across primary domains, addon domains, subdomains, and nested WordPress installations
• No reduction in real security protection — only cache paths are excluded
• Server-wide application — all cPanel user accounts benefit from a single configuration
• Persistent configuration — survives reboots and Imunify360 updates

This approach is used by system administrators, managed WordPress hosting providers, and DevOps engineers worldwide to maintain the balance between aggressive security scanning and the operational requirements of high-performance WordPress hosting environments.