# Imunify360 False Positives: Find the Rule ID and Fix It

Source: https://srvscripts.com/guides/imunify360-false-positives/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** First work out which Imunify360 layer blocked the request: the ModSecurity WAF, the IP firewall/graylist, the WAF for WordPress or the malware scanner. Then get the rule ID from the Incidents page or `imunify360-agent get --by-ip 203.0.113.10`. Disable a ModSecurity rule for one site with `imunify360-agent rules disable --id RULE_ID --plugin modsec --name "reason" --domains example.com`, rather than switching the WAF off. For files flagged by mistake, run `imunify360-agent submit false-positive` and add the path to the malware ignore list.

Commands checked against the official Imunify360 documentation (linked below) on 6 October 2026; not yet run on our lab servers. Our cPanel lab runs ImunifyAV, which has no WAF or firewall. On it we confirmed the syntax of the malware-scanner commands (`submit false-positive`, `malware ignore`, `malware malicious`, `malware on-demand start`) with `--help`.

## Work out which Imunify360 layer blocked it

Imunify360 has several protection layers, and each one has its own way to make an exception. Match the symptom first:

| What the visitor or customer sees | Likely layer | Where to fix |
| --- | --- | --- |
| 403 page from the server when they submit a form, save a post or upload a file | ModSecurity WAF rule | Disable the rule ID for that domain |
| A CAPTCHA / “checking your browser” page on every request | IP is on the Gray List (captcha) | Remove from the Gray List, whitelist if it is a known IP |
| Connection times out completely, on all sites and ports | IP is on the Black List or blocked by the firewall | Remove the block, whitelist the IP |
| Block reported inside the WordPress dashboard (Imunify Security) | WAF for WordPress (per-plugin rules) | wordpress-plugin rules disable |
| A PHP or JS file was cleaned, quarantined or reported as malicious | Malware scanner | Restore, submit false positive, ignore the path |

Under Attack Mode and the L7 rate limiter can also cause challenge pages during a flood. Those are covered in [Imunify360 Under Attack Mode 2026](/guides/imunify360-under-attack-mode-2026/).

## Find the blocking rule ID

**In the UI:** open Imunify360 in WHM, go to **Incidents**, and filter by the visitor’s IP address and the time of the block. The incident description includes the rule ID and the rule message. Note the ID, the domain and the URL.

**From the command line:** the `get` command lists incidents. `--period` takes values such as `30m`, `4h`, `7d` or `today`, and `--by-ip` filters by the client address:

```
imunify360-agent get --period 1d --by-ip 203.0.113.10
imunify360-agent get --period 4h --by-ip 203.0.113.10 --json
```

**From the logs:** the Imunify360 FAQ points to `/var/log/imunify360/console.log` and the ModSecurity audit log. On cPanel with EasyApache 4 the Apache error log also records each ModSecurity hit with an `[id "..."]` field:

```
grep 203.0.113.10 /etc/apache2/logs/error_log | grep -o '\[id "[0-9]*"\]' | sort | uniq -c
grep 203.0.113.10 /etc/apache2/logs/modsec_audit.log | tail
```

Ask the customer for their public IP (for example from a “what is my IP” page) and the exact time. Without those two you are guessing.

## Disable a ModSecurity rule for one domain

If the rule blocks a legitimate action on one site (a page builder saving a layout, an API callback, a form with code samples), disable that one rule for that domain. Do not disable the whole WAF. The `rules` command keeps a list of disabled rules:

```
# disable rule 12345 (placeholder ID) for one site only
imunify360-agent rules disable --id 12345 --plugin modsec --name "FP: Elementor save on example.com" --domains example.com

# list what is disabled
imunify360-agent rules list-disabled

# re-enable later
imunify360-agent rules enable --id 12345 --plugin modsec
```

Per the CLI reference: `--plugin` can be `modsec`, `ossec` or `lfd` (CSF integration mode). `--name` is a name or description you choose, so write down the reason and the ticket number. `--domains` works only with `modsec`. Without `--domains`, the rule is disabled for every site on the server. That is sometimes right, for example when one rule breaks a plugin many customers use, but do it on purpose.

In WHM, the same list lives under Imunify360 settings in **Disabled Rules**: choose **modsec**, enter the rule ID and add it. cPanel’s knowledge base documents this path.

Before you disable a rule, check the request in the audit log. A rule that fires on `wp-login.php` or `xmlrpc.php` from an unknown IP is most likely an attack the WAF stopped correctly, not a false positive.

## Whitelist or unblock an IP address

When a whole IP is blocked (timeouts or a CAPTCHA on everything), the problem is the IP lists, not a single WAF rule. Remove the block, then whitelist the IP if it is trusted, such as the customer’s office or your monitoring service:

```
# remove from the Gray List (captcha) or the Black List
imunify360-agent ip-list local delete --purpose captcha 203.0.113.10
imunify360-agent ip-list local delete --purpose drop 203.0.113.10

# whitelist with a comment
imunify360-agent ip-list local add --purpose white 203.0.113.10 --comment "Office IP, ticket 1234"
```

The documentation also lists `--expiration` for temporary whitelisting and `--full-access`, which ignores blocked-port rules. Use `--full-access` only for your own infrastructure. Our [Imunify360 whitelist IP CLI guide](/guides/imunify360-whitelist-ip-cli/) covers whitelisting in depth, including countries and subnets.

There is also `imunify360-agent whitelist domain add example.com`. The CLI reference shows the syntax and wildcards (`"*.example.com"` for subdomains only, `.example.com` for the domain plus subdomains), but it does not say which checks a whitelisted domain skips. For a WAF false positive on one site, use the documented `rules disable --domains` above.

## WAF for WordPress: now on by default

Imunify360’s blog announced on 31 August 2026 that WAF for WordPress, the WAF layer in the Imunify Security WordPress plugin, is now enabled by default for every site running that plugin on Imunify360 servers, including new hosting accounts. It launched in March 2026 in monitoring mode. Its rules are virtual patches matched to the plugins installed on each site. So if a WordPress site started blocking requests after August 2026 and you see nothing in the ModSecurity logs, check this layer.

Site owners see incidents and can manage rules on the **Imunify Security** page in their WordPress dashboard. As the host, use the CLI:

```
# where is it on or off, and is it the server default or a per-account override?
imunify360-agent wordpress-plugin waf status

# disable one WordPress WAF rule for specific sites only
imunify360-agent wordpress-plugin rules disable --rule RULE_ID --domains example.com blog.example.com
imunify360-agent wordpress-plugin rules list-disabled
imunify360-agent wordpress-plugin rules enable --rule RULE_ID

# turn the WordPress WAF off for one account (last resort)
imunify360-agent wordpress-plugin waf set --status disabled --users bob
```

The hosting-provider guide also documents turning it off server-wide (`imunify360-agent config update '{"WORDPRESS":{"waf_enabled": false}}'`). Because these rules protect against known plugin vulnerabilities, disable a single rule for a single site first. Then make sure the plugin it protects gets updated.

## Malware scanner false positives

If a legitimate file was flagged, first see what the scanner recorded, then report it and stop it from being flagged again:

```
imunify360-agent malware malicious list                     # flagged files
imunify360-agent submit false-positive --reason "Licensed plugin file, unchanged from vendor zip" /home/bob/public_html/wp-content/plugins/example/inc/loader.php
imunify360-agent malware ignore add /home/bob/public_html/wp-content/plugins/example/inc/loader.php
imunify360-agent malware ignore list
```

If the file was cleaned and the site broke, `imunify360-agent malware malicious --help` lists `restore-original`, which restores the copy taken before the cleanup attempt. Be strict before you ignore a file. Compare it with a fresh copy from the vendor. For WordPress core and wordpress.org plugins, use `wp core verify-checksums` and `wp plugin verify-checksums`, as shown in our hacked-WordPress cleanup steps. Obfuscated code in a “nulled” premium plugin is usually a correct detection.

## Report the false positive to Imunify360

- **Files:** `imunify360-agent submit false-positive --reason "..." /full/path` sends the file to the Imunify team for analysis. A file that should have been detected goes through `submit false-negative`.

- **WAF rules:** open a ticket with Imunify360/CloudLinux support. Include the rule ID, the domain, the full URL, the time, the client IP and the audit-log entry, so they can fix the rule for everyone.

Remove your exception once the vendor fixes the rule. Re-enable it with `rules enable` and test again, so the list does not grow forever.

## Check that it worked

- Ask the customer to repeat the exact action (same URL, same form).

- Run `imunify360-agent get --period 30m --by-ip 203.0.113.10` again. No new incident for that rule means the exception works.

- Run `imunify360-agent rules list-disabled` and check that the rule appears with the right domain.

- Re-test a known attack pattern against another domain on the server to confirm the rule still works there.

## Common problems

- **The rule is disabled but requests are still blocked.** Another rule now fires on the same request. Repeat the incident lookup, because each rule needs its own exception.

- **Blocked only for one customer.** It is probably their IP, not the WAF: check the Gray/Black List first.

- **CSF and Imunify360 both installed.** lfd blocks can look like Imunify360 blocks. Check `csf -g IP` too, or use `--plugin lfd` in CSF integration mode. See [cURL error 28 with Imunify360 and CSF](/guides/wordpress-curl-error-28-imunify360-csf/).

- **Imunify360 menu missing in WHM**, so you cannot reach Incidents: see [Imunify360 missing from WHM](/guides/fix-imunify360-missing-from-whm/).

**Official documentation:** [Imunify360 docs: command-line interface](https://docs.imunify360.com/command_line_interface/) · [Imunify Security plugin: hosting provider guide](https://docs.imunify360.com/wordpress_plugin/hosting_providers/) · [Imunify360 blog: WAF for WordPress now on by default (31 Aug 2026)](https://blog.imunify360.com/one-million-sites-in-waf-for-wordpress-is-now-on-by-default/) · [cPanel KB: disable an Imunify360 ModSecurity rule](https://support.cpanel.net/hc/en-us/articles/1500007960082-How-to-disable-an-Imunify360-ModSecurity-Rule-in-Imunify360)

**Related:** [Imunify360 Whitelist IP and Countries from the CLI: Commands](/guides/imunify360-whitelist-ip-cli/) · [Imunify360 Under Attack Mode 2026: WAF and L7 Rate Limit](/guides/imunify360-under-attack-mode-2026/) · [Imunify360 Missing from WHM: 4 Fixes](/guides/fix-imunify360-missing-from-whm/) · [Harden Shared cPanel Server: Secure CageFS and ModSecurity Setup](/guides/harden-shared-cpanel-server/) · [Imunify360 review: worth it on a shared cPanel server?](/reviews/imunify360-review/)

**See also:** [Clean a Hacked WordPress Site on cPanel: Step-by-Step](/guides/clean-hacked-wordpress-cpanel/) · [WordPress CVE-2026-64638 Patch: Find and Update Every Vulnerable Site](/guides/wordpress-cve-2026-64638-patch/) · [WordPress Version Audit: Find Every WordPress Site and Its Version](/scripts/wordpress-version-audit/) · [CSF Commands Cheat Sheet: Allow, Deny, Ports and Tempbans](/guides/csf-commands-cheat-sheet/) · [Imunify360 Without CSF: Remove CSF and Use Imunify as the Firewall](/guides/imunify360-without-csf/)

**See also:** [Imunify360 CLI: Scan, List and Clean Malware from the Command Line](/guides/imunify360-cli-malware-cleanup/)

## Frequently asked questions

### How do I find which Imunify360 rule blocked a request?

Open Incidents in the Imunify360 WHM plugin and filter by the client IP, or run imunify360-agent get –period 1d –by-ip IP. The incident shows the rule ID and message. The Apache error log also shows ModSecurity hits with an [id “…”] field.

### Can I disable an Imunify360 ModSecurity rule for one domain only?

Yes. Use imunify360-agent rules disable –id RULE_ID –plugin modsec –name “reason” –domains example.com. Without –domains the rule is disabled for the whole server.

### Why did WordPress sites start getting blocked in late 2026?

Imunify360 made WAF for WordPress (in the Imunify Security plugin) on by default in August 2026. Check imunify360-agent wordpress-plugin waf status and the Imunify Security page in the WordPress dashboard.

### How do I report a false positive to Imunify360?

For files, run imunify360-agent submit false-positive –reason “text” /full/path. For WAF rules, open a support ticket with the rule ID, URL, time and IP.

### Should I just disable the WAF if customers complain?

No. Disable the single rule for the affected domain, and remove the exception once the rule or the plugin is fixed. Turning the whole WAF off removes protection for every site.