Introduction

WordPress uses admin-ajax.php for many background actions that users never notice until they stop working. Autosaves fail, buttons spin forever, plugins lose live features, and parts of the admin start behaving unpredictably. When the trigger is a WAF or security plugin blocking those requests, the origin is online but WordPress cannot complete key AJAX actions. The fix is to identify the exact blocking rule and narrow it without weakening unrelated protection.

Symptoms

  • Buttons, autosaves, filters, or plugin dashboards stop working in WordPress
  • Browser tools show admin-ajax.php requests returning 403, 406, or challenge responses
  • The issue started after enabling a WAF, CDN security feature, or security plugin
  • Only certain actions fail while the rest of wp-admin still loads
  • Security logs show blocked POST requests or suspicious query patterns on admin-ajax.php

Common Causes

  • A WAF rule flags a normal WordPress AJAX payload as suspicious
  • Bot protection or challenge logic blocks background requests without a browser interaction flow
  • A plugin sends large or unusual request bodies that trigger generic security rules
  • Multiple security layers inspect the same AJAX request and one of them denies it
  • The site uses a custom admin path, proxy, or hostname pattern that the WAF policy did not account for

Step-by-Step Fix

  1. Reproduce the failing action and capture the exact admin-ajax.php request in browser developer tools.
  2. Check WAF, CDN, server, and plugin security logs for the blocked request, including rule ID, action, and matched condition.
  3. Confirm the request is expected WordPress behavior and not part of an abuse pattern before changing any allow rules.
  4. Identify whether the block comes from a managed ruleset, bot challenge, rate limit, or custom security expression.
  5. Narrow the exception to the specific path, action, method, or trusted user flow rather than broadly disabling protection for wp-admin.
  6. Re-test the affected plugin or admin feature after the rule adjustment to confirm the background action completes normally.
  7. Review whether a second security layer is still challenging the same request even after the first exception is added.
  8. Compare behavior for logged-in users, editors, and admins if only one role triggers the block.
  9. Keep the final exception documented so future WAF updates do not silently break the same WordPress workflow again.