ModSecurity Blocked a Legitimate Request: How to Get It Whitelisted

Every Ultra Web Hosting server runs a web application firewall called ModSecurity that inspects incoming requests and blocks the ones that look like an attack. It stops a huge amount of automated abuse before it ever reaches your site, but now and then it blocks something legitimate you were doing, such as saving a page in a builder, updating a plugin, or submitting a form. That is called a false positive. This guide helps you recognize a ModSecurity block, rule out the other things that also cause a 403, and gather the exact details we need to add a targeted exception so the block never happens to you again.

01. What ModSecurity Is and Why It Blocks Legitimate Actions

ModSecurity is a web application firewall that runs on the servers behind your account. Every request that comes in to your site, whether it is a visitor loading a page, a form being submitted, or a login attempt, passes through it first. It compares the request against a large set of rules that describe what an attack looks like: SQL injection, cross-site scripting, remote file inclusion, probes for known exploits, and so on. If a request matches, the firewall stops it before it reaches your application. This is a good thing and it works silently in the background almost all of the time.

The trouble is that some legitimate actions look, to a generic rule, a lot like an attack. A page builder that posts a large blob of layout code, a plugin update that sends unusual data, a contact form where someone pasted a chunk of text with code-like characters in it, or simply a very large POST request can all trip a rule that was written to catch bad traffic. When the firewall blocks something you actually meant to do, that is a false positive. It does not mean your site is broken or hacked. It means one broad rule caught your legitimate request in a net meant for someone else, and we need to widen the net slightly for your account.

02. How to Recognize a ModSecurity Block

A ModSecurity block has a distinct signature once you know what to look for. The most common sign is a sudden 403 Forbidden that appears the instant you take a specific action, when the rest of your site works fine. Our "403 Forbidden Error" guide walks through that error in general; this guide is about the firewall flavor of it specifically.

• It is a sudden 403, or the request just fails. You click Save or Submit and instead of the action completing, you get a 403 Forbidden, a "Not Acceptable" message, or a page that simply will not load.
• It happens on one specific action, not site-wide. Your homepage and other pages load normally. The block only appears when you do one particular thing, such as saving a post or submitting one form.
• The message often names it or gives a reference. The block page may say ModSecurity, show a "Not Acceptable" heading, or include a reference number or Support ID. That reference is gold to us, so copy it if you see one.
• The action is repeatable. If you retry the exact same thing and it fails the exact same way every time, that consistency points at a rule match rather than a random glitch.

One well-known example is an upload or save that fails with a message about a "potential exe" or executable content in the request, even though you were not uploading a program. That is a classic generic-rule false positive. We cover that specific symptom in Unable to Include Potential Executable.

03. Genuine Block vs False Positive

Not every block is a mistake. Sometimes the firewall is doing exactly its job and stopping a genuinely bad request, for example if a form on your site is being probed by a bot, or if content you are submitting really does contain something dangerous. Here is how to tell the two apart before you open a ticket.

04. What to Do First on Your Side

A few quick checks before you contact us will speed the fix and, occasionally, solve it outright.

1. Retry the action once. If it was a one-off network hiccup it will now work. If it fails identically again, you have confirmed it is repeatable, which is exactly what we want to know.
2. Note the exact action and URL. Write down precisely what you clicked and the address in your browser bar when it failed. "Saving a post" is good; "clicking Update on the page at /wp-admin/post.php for my Contact page" is better.
3. If it is a plugin or theme action, test the trigger. If the block happens when a specific plugin runs, briefly deactivate that one plugin and try again. If the action now works, you have identified the trigger for us. Reactivate it afterward; do not leave it off as a fix.
4. Sanity-check the content you are submitting. Make sure you are not, without realizing it, pasting in raw script tags, code snippets, or content copied from an untrusted source. If the submission genuinely contains code-like payloads, the firewall may be right to block it.

05. The Information We Need to Whitelist It

To add a targeted exception we have to find the one matching entry in the firewall log, and the log holds thousands of entries a day. The more of the following you give us, the faster we pinpoint yours. Copy this checklist straight into your ticket and fill it in.

1. Exact date and time, with your timezone. For example "5 July 2026, 2:14 PM Eastern". Timezone matters because our logs are timestamped and a guess an hour off can point at the wrong entry.
2. Your IP address. The public IP you were browsing from when the block happened. You can find it by searching "what is my IP" in your browser. This lets us filter the log to just your traffic.
3. The URL or page you were on. The full web address in your browser bar at the moment of the block.
4. The action you took. What you clicked or submitted, in plain words: saving a page, updating a plugin, submitting a specific form, importing a file, and so on.
5. Any reference or Support ID from the block page. If the error page showed a reference number, a Support ID, or specific wording, include it verbatim. This is often enough to find the entry on its own.
6. A screenshot of the block page. Attach the full-page screenshot you captured in Section 02, exactly as it appeared.

06. How to Submit It in a Support Ticket

Send the details from Section 05 to our support team by opening a ticket. Email or live chat can work too, but a ticket keeps the whole record, including your screenshot, in one place.

1. Go to the support ticket page and start a new ticket to our Technical Support department.
2. Use a clear subject such as "ModSecurity false positive blocking page save on mydomain.com".
3. Paste in the completed Section 05 checklist: date and time with timezone, your IP, the URL, the action, and any reference or Support ID.
4. Attach the screenshot of the block page.
5. Mention whether you can reproduce the block on demand, so we can confirm the fix right after applying it.

07. What We Do on Our Side

Once your ticket lands, here is what happens. Knowing the process helps you understand why the details in Section 05 matter so much.

1. We locate the entry. Using your timestamp, IP, and URL, we find the exact block in the firewall log and see precisely which check stopped your request.
2. We confirm it is a false positive. We look at what was actually in the request. If it was a legitimate action and not a genuine attack, we treat it as a false positive.
3. We add a narrow exception. Rather than turning protection off, we add a targeted whitelist scoped as tightly as possible, typically to your account and the specific URL or action involved, so the rest of the firewall stays fully active for you and everyone else.
4. We test and reply. If you told us the block is reproducible, we confirm the action now works, then close the ticket letting you know it is resolved.

08. What Not to Do

A few reactions to a firewall block make things worse or send you down the wrong path.

• Do not ask us to disable all security for your site. Turning the firewall off to fix one blocked action leaves your whole site exposed to the automated attacks it stops every day. A narrow exception solves the same problem safely.
• Do not assume every 403 is ModSecurity. As Section 03 covers, a 403 Forbidden is just as often file permissions or an .htaccess rule. Check your .htaccess file for stray Deny or rewrite rules before concluding it is the firewall.
• Do not confuse it with a 500 error. If the page throws an Error 500 rather than a 403 or "Not Acceptable", that is usually a script or configuration fault, not a firewall block, and it needs a different fix.
• Do not keep the plugin deactivated as a workaround. Deactivating a plugin is fine for identifying the trigger, but leaving it off just removes the feature you wanted. Send us the trigger and let us whitelist it instead.

09. Why There Is No .htaccess Self-Fix on Shared Hosting

On some hosts you can add lines to your .htaccess file to switch ModSecurity off for a folder. On our shared hosting that is intentionally not available. The firewall runs at the server level, above your account, and it cannot be disabled from your .htaccess. This is deliberate: it keeps one account's mistake from turning off protection that shields the whole server, and it means a compromised site cannot quietly disable its own firewall.

The practical result is that the correct path for a false positive is always a support ticket, not a config edit on your side. That is not a limitation so much as the design working as intended: we hold the controls for the firewall, we can see the full log to confirm a false positive, and we can scope the exception properly. Your part is to capture the details in Section 05; our part is to make the change safely.

Quick Recap: Getting a False Positive Whitelisted

If you only do a few things from this guide, do these:

1. Confirm it is a firewall block: a sudden 403 or "Not Acceptable" on one specific action, not site-wide, often with a reference or Support ID.
2. Rule out the other causes: check that it is not file permissions, an .htaccess rule, or a 500 error before assuming ModSecurity.
3. Capture the details: exact date, time, and timezone, your IP address, the URL, the action, any reference or Support ID, and a screenshot.
4. Do a quick check on your side: retry once, and if a plugin is the trigger, deactivate it briefly to confirm, then turn it back on.
5. Open a ticket with the completed checklist so we can find the log entry and add a narrow exception.
6. Do not disable all security or leave a plugin off as a workaround; let us scope the fix to your account and URL.

Last updated July 2026 · Browse all Errors and Troubleshooting articles