Imunify360 Under Attack Mode 2026: WAF and L7 Rate Limit

Imunify360 shipped more behavioural changes between July and September 2026 than in the previous two years. Three of them affect every request that reaches a customer site: the WordPress-specific WAF is now enabled by default, a Layer 7 rate limiter sits in front of the web server, and WebShield gained an Under Attack Mode that challenges every visitor when a site is being hammered. Each is useful and each has a false-positive profile you need to understand before customers do. This guide walks through the settings on a cPanel or CloudLinux host.

Short answer: Since the August and September 2026 agent releases the WordPress WAF is on by default in FULL mode, the Layer 7 rate limiter returns 429s to sources that exceed a per-domain threshold, and WebShield’s Under Attack Mode challenges every visitor with JavaScript. Tune them with imunify360-agent config update and per-domain rule whitelists, fix real-IP handling for proxied sites before raising limits, and enable Under Attack Mode only for the duration of an attack with payment callbacks excluded.

Confirm the version and the defaults

imunify360-agent version
imunify360-agent config show | grep -A6 -E '^(MOD_SEC|WEBSHIELD|RATE_LIMIT|ADMIN_CONTACTS)'

The 2026 changes arrived in the agent releases around late August and mid-September; if your version predates 31 August 2026 the WordPress WAF default may still be off and the rate limiter may be absent. The agent updates itself through the Imunify repository on the normal dnf cycle, so an out-of-date agent usually means a broken repository or a held package rather than a choice.

WAF for WordPress by default

Since 31 August 2026 the WordPress rule set is on for every new install and was switched on during upgrade for existing servers unless an admin had explicitly disabled it. The rule set is narrower than the general ModSecurity vendor rules: it targets known plugin and theme exploit signatures, admin-ajax abuse, XML-RPC amplification and the wp2shell family of upload-to-RCE attacks that prompted the emergency rules in July.

Check whether it is active and which mode it is in:

imunify360-agent config show | grep -A4 MOD_SEC
imunify360-agent config update '{"MOD_SEC": {"ruleset": "FULL"}}'

MINIMAL keeps only the highest-confidence rules and is the right choice on a server where customers run heavily customised WordPress with unusual request patterns. FULL is the default and correct for most shared hosting. Per-domain exclusions belong in the Imunify UI or through imunify360-agent:

imunify360-agent whitelist rule add 33301 --domain shop.example.com

Rule IDs appear in the Incidents tab and in /var/log/imunify360/console.log; do not disable a rule globally to fix one customer.

The Layer 7 rate limiter

Added on 27 August 2026, the rate limiter counts requests per source per domain at the HTTP layer, before they reach Apache or LiteSpeed, and returns a 429 when a source exceeds the threshold. The defaults are conservative and tuned for shared hosting, but three scenarios trip it: sites behind a CDN or Cloudflare where every request appears to come from the proxy, search-engine crawlers on large catalogue sites, and monitoring services that poll aggressively.

For proxied sites the fix is not to raise the limit but to make Imunify see the real client address. On cPanel with Cloudflare, that means the real-IP configuration in our Cloudflare and cPanel guide and confirming Imunify’s trusted proxy list includes the CDN ranges:

imunify360-agent config show | grep -A3 TRUSTED_PROXIES

For crawlers and monitors, add them to the rate-limit allow list rather than the global whitelist, so they are still subject to the WAF:

imunify360-agent config update '{"RATE_LIMIT": {"whitelist_domains": ["status.example.net"]}}'

The per-domain threshold is adjustable in the UI under Settings, then General, then Rate Limiting. A doubling of the default is a reasonable ceiling for busy WooCommerce sites; beyond that the limiter stops being useful.

Under Attack Mode

WebShield’s Under Attack Mode arrived on 4 August 2026. When enabled for a domain, every new visitor receives a lightweight JavaScript challenge before the request is passed to the web server. It is a blunt instrument: real users pass in under a second, most bots do not, and anything that cannot execute JavaScript (API clients, webhooks, some payment gateway callbacks) fails. It is meant to be turned on during an attack and off afterwards, not left on.

Enable and disable per domain from the shell:

imunify360-agent webshield under-attack enable --domain example.com
imunify360-agent webshield under-attack disable --domain example.com

Before enabling it on a site with payment integration, add the gateway’s callback paths to the WebShield exclusions, otherwise you will learn about it from a merchant whose orders stopped confirming. Similarly, the AI-bot throttling introduced earlier in 2026 applies to identified crawlers by user agent and reputation, and a customer who wants their site indexed by those crawlers needs an exclusion.

Malicious service worker cleanup

The 22 September 2026 release added detection and removal of malicious service-worker scripts, which persist in visitors’ browsers after a site is cleaned and keep redirecting them. It runs as part of the normal scan; if a customer reports that their site “still redirects” after cleanup, run an on-demand scan and check the report for service-worker findings:

imunify360-agent malware on-demand start --path /home/username/public_html
imunify360-agent malware on-demand list

Common pitfall

Turning the WAF, the rate limiter and Under Attack Mode all on at once for a site with a problem, then trying to work out which one is blocking the customer. Change one control at a time and read /var/log/imunify360/console.log between changes; each block records which component produced it.

Verify

For each feature, trigger it deliberately from a test address and confirm the outcome:

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?s=<script>alert(1)</script>'
for i in $(seq 1 200); do curl -s -o /dev/null -w '%{http_code}\n' https://example.com/; done | sort | uniq -c
imunify360-agent list incidents --limit 10

The first should return 403 from the WAF, the second should show 429s appearing partway through, and the incidents list should record both with the component named. Then remove the test address from any block it earned, and document the per-domain exclusions you added so the next engineer does not remove them as clutter. Our broader cPanel hardening guide covers where Imunify360 sits alongside CageFS and ModSecurity.

Imunify360 Under Attack Mode at a glance

Official documentation: Imunify360 documentation, cPanel & WHM documentation, Linux man pages.

Related guides: Fix WordPress “cURL error 28: Failed to connect” caused by Imunify360 or CSF · Whitelist IPs and countries in Imunify360 from the CLI · Hardening a shared cPanel server with CageFS, ModSecurity (OWASP CRS) and Imunify/ClamAV.

Frequently asked questions