Access Denied by Imunify360 Bot-Protection

Some visitors see this message even though the website itself loads normally:

Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted

It usually appears when saving in the WordPress editor (“Updating failed”, or “Ha fallado la actualización” in Spanish), in page builders, in the WooCommerce admin, or in an app that talks to the site’s API. This guide explains what triggers it and how to fix it without weakening the rest of your server’s protection.

Why it happens

Imunify360 receives reputation lists from its global threat network. When a visitor’s IP is on one of those lists, Imunify360 sends their traffic through its anti-bot check (WebShield) before it reaches your website.

• Normal page loads pass on their own. The browser runs a short JavaScript check without the visitor noticing, receives a cookie, and the page loads.
• Background requests cannot run the check. The WordPress block editor and Site Editor, Elementor, admin-ajax calls, and REST API requests ask for JSON, not a web page. When the anti-bot cookie expires, these requests get a 403 with the message above instead of the check.

The result is a pattern that looks random: saving works right after the page is loaded, then fails some time later while the editor is still open.

Residential and mobile IPs are often on these lists through no fault of the visitor. Many internet providers assign dynamic addresses, and an address may have been used by an infected device before.

Same cause, different symptoms: Mobile apps and other non-browser clients may receive a “One moment, please…” page instead of their data. Requests that ask for something other than JSON, a text format, or */* get an empty HTTP 415 response.

Quick workaround for the visitor

1. Save or copy the unsaved changes if possible.
2. Reload the editor page (F5 or Ctrl+R).
3. Save again.

Reloading passes the anti-bot check and renews the cookie, so saves work again for a while. This needs no server changes, but the error can come back during long editing sessions. For a lasting fix, use one of the options below.

Confirm the cause

On the server, as root, search the WebShield access log for the visitor’s IP:

grep '^203.0.113.25 ' /var/log/imunify360-webshield/access.log | grep '" 403 107 ' | tail

Replace 203.0.113.25 with the visitor’s IP. Lines with 403 107 (status 403, 107-byte response) are requests that received the bot-protection message. Each line shows the hostname and the URL that was blocked, for example POST /wp-json/... or POST /wp-admin/admin-ajax.php.

If the IP does not appear in this log at all, its traffic is not going through WebShield and the problem has a different cause. Check the greylist and the firewall rules next.

Fix: exclude the domain from the anti-bot check

This is the recommended fix when the visitor’s IP is dynamic or when several people manage the site. It turns off the anti-bot check for that domain only.

1. Add every hostname used to reach the site, including www:

   imunify360-agent whitelist domain add example.com
   imunify360-agent whitelist domain add www.example.com

2. Confirm the list:

   imunify360-agent whitelist domain list

3. Ask the visitor to reload the editor and save again.

WebShield reloads automatically. The Imunify360 web application firewall (WAF), the malware scanner, and Proactive Defense keep protecting the domain; only the anti-bot check is skipped.

To undo it later:

imunify360-agent whitelist domain delete www.example.com
imunify360-agent whitelist domain delete example.com

Alternative: whitelist a static IP

Whitelist an IP only when it is static and under your control, such as an office connection, a monitoring service, or a server that calls the site’s API. A whitelisted IP bypasses all Imunify360 firewall checks on the whole server, not just one domain.

Add an expiration so the entry does not stay forever. This example expires in 30 days:

imunify360-agent whitelist ip add 203.0.113.25 --comment "Office IP, API sync" --expiration $(date -d '+30 days' +%s)

Avoid dynamic IPs: Do not whitelist a home or mobile IP. When it changes, the visitor is blocked again, and the old address may later belong to someone else who then bypasses your firewall.

What not to do

• Do not turn off the anti-bot check (splash screen) server-wide. It protects every site on the server from automated attacks, credential stuffing, and scrapers coming from known bad IPs.
• Do not whitelist whole IP ranges of an internet provider to cover one visitor.

On RemarkableCloud managed servers

Our team handles this for you. Open a support ticket with the domain, the exact error, and the visitor’s IP if you know it (they can find it at any “what is my IP” site). We confirm the cause in the logs and apply the narrowest fix.

Next steps

• Imunify360 overview
• Greylist and whitelist management
• Firewall rules and IP blocking