406 Not Acceptable (mod_security)

What’s actually happening

A request that worked a minute ago suddenly returns 406, usually a form POST, a WordPress admin save, or an API call. The browser shows a short "Not Acceptable" page from the server, not your app. It is intermittent and tied to specific content: the same page loads fine on GET but fails the moment you submit certain text or a particular User-Agent hits it. cPanel/Apache hosts running OWASP CRS are the usual setting.

Common causes

• A POST payload contained a string that matched a CRS rule — SQL keywords, <script>, base64 blobs, or even the word "DROP" in a comment field.
• The User-Agent or Referer header was empty or matched a blocklist pattern (curl, python-requests, and wp-cli are common false positives).
• A query string parameter looked like directory traversal or an injection attempt (../ , UNION SELECT, %00).
• An overly aggressive custom rule the host added on top of the default CRS, often anti-spam or anti-bot.
• Page builder or REST API content (Elementor, WooCommerce) posting large serialized arrays that trip generic injection rules.

How to fix it

1. Get the exact rule ID from the audit logThe 406 page tells you nothing. SSH in and look at the ModSecurity audit log — on cPanel it's /usr/local/apache/logs/modsec_audit.log or /etc/apache2/logs/modsec_audit.log. Find your request by timestamp/URI and read the [id "......"] and [msg "..."] fields. That ID is what everything else hangs on.
2. Ask the host to whitelist that rule IDOn shared hosting you usually can't edit the WAF yourself. Open a ticket with the rule ID, the URL, and the time — "please whitelist rule 949110 (or disable it for /wp-admin/post.php on this domain)". Reputable hosts (SiteGround, A2, Cloudways) do this within an hour. Vague tickets get bounced, so give them the ID.
3. Add a per-directory disable if you have accessWith a dedicated/VPS box or a host that allows .htaccess overrides, scope it down rather than killing the whole engine. Use SecRuleRemoveById 949110 inside a <Directory> or <LocationMatch> block for just the affected path. Never put SecRuleEngine Off in a global .htaccess — that strips protection from the entire account.
4. Fix the payload if the rule is legitimately correctSometimes the WAF is right and your form is shipping something that looks like an attack. If a textarea legitimately needs angle brackets or SQL-looking text, encode it client-side before POST, or move that field to a JSON body the rule set handles better. Don't whitelist a rule that's catching a real injection vector.