A “Blocked by ModSecurity” error comes from your web host’s firewall, not from WP Ghost. ModSecurity runs one layer above WordPress and rejects the request before WordPress or any plugin ever loads, so no plugin can cause it and no plugin can stop it. The fix is almost always a one-line whitelist rule on the server, not a change inside the plugin. This guide explains what ModSecurity is, why a security plugin is the single most common thing to trip it, how to confirm the block is server-side, and how to whitelist the offending rule without weakening your firewall.
What “Blocked by ModSecurity” Means
ModSecurity (often shortened to “modsec”) is a Web Application Firewall that runs inside Apache, Nginx, or LiteSpeed, before PHP and WordPress start. Most shared hosts (cPanel, Plesk, GoDaddy, SiteGround, Hostinger, Bluehost, and others) enable it by default and load a public rule set on top of it, usually the OWASP Core Rule Set (CRS) or a commercial pack like Comodo WAF or Imunify360.
These rule sets work by pattern-matching the raw HTTP request, including the URL, the query string, the POST body, the headers, and the cookies, against thousands of signatures of what attacks tend to look like. When a request matches one of those signatures, ModSecurity blocks it and returns one of the following:
- 403 Forbidden
- 406 Not Acceptable
- A branded “Not Acceptable!” or “Mod_Security blocked” error page
- A generic 500 error on some LiteSpeed setups
The detail that matters most: the block happens at the server layer. WordPress, and therefore WP Ghost, never sees the request. The plugin cannot cause the block and cannot catch it.
Why ModSecurity Blocks Security Plugins
This is the part that feels paradoxical, so it is worth understanding clearly. A WAF matches on what a request looks like, not on who sent it or why. A security plugin, by its nature, sends requests that contain firewall rules and code patterns, which is exactly what the WAF is trained to block. With WP Ghost, four situations account for almost every report.
Saving firewall rules looks like an attack payload. When you enable the 7G or 8G Firewall or save your Change Paths and Header settings, the admin form posts rule text containing strings such as base64_encode, eval(, union select, ../, <script, wp-config.php, and RewriteRule. Those are the exact signatures CRS scans for. ModSecurity reads “SQL injection” or “file inclusion attempt” in the POST body and blocks the save, even though it is only a settings form. This is the most common cause by far.
Writing rewrite rules to server config. WP Ghost writes its rewrite rules into .htaccess on Apache and LiteSpeed (or into the Nginx and IIS config). Some managed hosts run a ModSecurity rule that blocks any request whose body contains .htaccess directives, treating it as a config-tampering attempt.
Requests to changed admin paths. When the login URL and the wp-admin and wp-content paths are changed, requests now hit unfamiliar URLs carrying long query strings and tokens. A few aggressive rule sets flag unfamiliar admin-style paths or the redirect parameters as suspicious.
AJAX and REST traffic. Settings saves, security checks, and 2FA or brute force flows fire admin-ajax.php and REST requests with encoded values that occasionally match generic anomaly-scoring CRS rules.
In every one of these cases the request is legitimate. It is the admin saving settings, or the plugin doing its job. The shape of the request simply matches an attack signature. That is a false positive, and false positives are a known, documented characteristic of signature-based WAFs. The OWASP CRS documentation dedicates an entire section to tuning them out.
Is This a WP Ghost Problem? How to Confirm in 60 Seconds
Run these three checks. Any one of them confirms the block is server-side.
1. Temporarily turn off ModSecurity, then retry the action. In cPanel, use the ModSecurity toggle, or ask your host. If the action now works, the WAF was the cause, confirmed. Re-enable ModSecurity afterward and whitelist the rule (below). Note that you are toggling the host’s firewall here, never WP Ghost itself.
2. Read the server error log, not WordPress’s. A ModSecurity block appears in the Apache or LiteSpeed error log, or in modsec_audit.log, with the ID of the exact rule that fired, for example [id "211730"] or [id "949110"]. WordPress’s debug.log shows nothing, because WordPress never ran. That absence alone proves the block is server-side.
3. Look at the response page. A ModSecurity block returns a 403 or 406 immediately with a server-branded error page. A block generated by a plugin looks like a styled WordPress page. If the page does not look like WordPress, WordPress did not produce it.
If disabling ModSecurity fixes the action and the rule ID shows up in the server log, the plugin is definitively not the cause. It is the host’s WAF being overly broad. This is the same reason WP Ghost runs the 7G and 8G Firewall at the server layer in the first place: rejecting bad traffic before WordPress loads is the goal, and ModSecurity is simply a second firewall doing the same thing one level higher.
How to Fix It
The goal is to keep ModSecurity on and stop it from blocking the few legitimate plugin requests. The options below run from easiest to most technical.
Ask Your Host to Whitelist the Rule
This is the recommended route on shared and managed hosting, where you usually cannot edit ModSecurity rules directly. Send your host’s support team this message, with the rule IDs from your server log:
ModSecurity is blocking legitimate requests from my security plugin. Please whitelist the following rule IDs for my domain: [the IDs from the error log]. Alternatively, please whitelist requests to /wp-admin/admin.php and /wp-admin/admin-ajax.php for my domain.
Hosts do this routinely. It is a two-minute job for them.
Whitelist Specific Rule IDs Yourself
If you have access to .htaccess or the server config, disable only the offending rule for the admin endpoints, never the whole WAF. Take the rule ID from the audit log and add a scoped exception:
apache
<IfModule mod_security2.c>
# Whitelist the plugin's settings and AJAX endpoints from the offending rules
<LocationMatch "https://wpghost.com/kb/ghost-admin/(admin|admin-ajax)\.php">
SecRuleRemoveById 211730 300013 949110
</LocationMatch>
</IfModule>Replace the IDs with the real ones from your log. The example IDs above are placeholders. ModSecurity rule IDs vary by host and rule set, so use the values that actually appear in your modsec_audit.log. Scoping the exception to admin.php and admin-ajax.php keeps the WAF fully active everywhere else on the site.
Disable a Single Rule in cPanel
On cPanel, open ModSecurity and use Disable specific rules to turn off the individual rule ID that fired. This switches off one rule without touching anything else and without disabling the WAF.
Imunify360 or Comodo WAF
If your host runs Imunify360 or the Comodo WAF instead of plain CRS, each has its own whitelist interface, and the rule IDs and procedure differ. Open your hosting panel’s security section, or ask host support to whitelist the rule ID for your domain.
What Not to Do
Do not disable ModSecurity entirely and leave it off. It is a real protection layer that works alongside WP Ghost, not against it. The correct move is a surgical whitelist of a handful of admin requests, not removing the WAF. Likewise, never deactivate WP Ghost to work around a ModSecurity block. Deactivating the plugin does not touch the server firewall, so it does not solve the problem and it removes your hack prevention layer at the same time.
If you ever need to reach the WP Ghost settings while a block is in the way, the emergency disable guide restores admin access safely. For Nginx-specific setups, see Setup WP Ghost on Nginx Server, and for Apache rewrite handling, see How to Set AllowOverride All.
Frequently Asked Questions
Does WP Ghost cause ModSecurity blocks?
No. ModSecurity is your host’s firewall and runs before WordPress loads. The block happens above the plugin, so WP Ghost cannot trigger it and cannot prevent it. The plugin only appears related because saving its settings sends a request that the WAF mistakes for an attack.
Why does saving WP Ghost settings get blocked?
Because the settings form posts the actual firewall rule text, which contains code patterns like eval(, union select, and base64_encode. ModSecurity reads those patterns as an attack signature and blocks the save. The request is legitimate, but its shape matches what the WAF is built to stop. Whitelisting the rule for your admin pages resolves it.
Should I just turn ModSecurity off?
No. ModSecurity is a useful layer that works alongside WP Ghost. Turn it off only as a temporary diagnostic to confirm the source of the block, then re-enable it and whitelist the single rule that fired. Leaving the whole WAF off removes a real protection layer.
Will whitelisting a rule weaken my security?
When the exception is scoped to /wp-admin/admin.php and /wp-admin/admin-ajax.php, the impact is minimal. The rule stays active across the rest of your site, and WP Ghost’s own server-level firewall continues to protect those admin endpoints. Whitelisting one rule on admin pages is far safer than disabling the entire WAF.
Where do I find the rule ID?
In the server error log, not WordPress’s. Look in the Apache or LiteSpeed error log, or in modsec_audit.log, for an entry like [id "949110"]. Common CRS culprits include 949110 (the anomaly score threshold), the 941xxx range (cross-site scripting), and the 942xxx range (SQL injection). Your host can also pull this ID for you.
Does WP Ghost modify WordPress core files?
No. WP Ghost uses server-level rewrite rules and WordPress filters. No core files are modified. Deactivating WP Ghost restores every original path and default instantly, with no leftover performance cost.