Custom ModSecurity Rules for WordPress on cPanel & WHM (2026)

While the OWASP Core Rule Set (CRS) provides baseline web application firewall protection in cPanel & WHM, deploying it unmodified on high-traffic WordPress websites frequently causes two catastrophic extremes: either crippling false positives that break legitimate WooCommerce checkouts (blocking Pakistani payment gateway callbacks like JazzCash, EasyPaisa, and PayFast), or severe bypasses where malicious botnets exhaust server resources via unthrottled xmlrpc.php and wp-login.php floods.

To achieve robust application-layer defense without sacrificing site functionality, system administrators must implement custom ModSecurity v2/v3 directive rulesets. In this production engineering guide, we construct battle-tested custom ModSecurity rules tailored for WordPress hosting on cPanel, configure rule IDs safely, and eliminate payment gateway callback disruptions.

---

1. ModSecurity Architecture in cPanel (Apache vs. LiteSpeed)

In cPanel & WHM with EasyApache 4, ModSecurity operates as an Apache module (mod_security2.so) or an integrated LiteSpeed Web Server (LSWS) WAF engine:

Incoming HTTP/HTTPS Request
           │
           ▼
┌────────────────────────────────────────────────────────┐
│  Phase 1: Request Headers Analysis                    │
│  - Inspect User-Agent, Host, Cookies, Query String     │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│  Phase 2: Request Body Analysis                        │
│  - Inspect POST Payloads (XML-RPC, JSON REST API)      │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│  Phase 3: Response Headers & Response Body (Phases 4/5)│
│  - Audit Logging & Metric Aggregation                  │
└────────────────────────────────────────────────────────┘

Default rules reside in /etc/apache2/conf.d/modsec_vendor_configs/OWASP3/. However, editing vendor rulefiles directly is dangerous because automated cPanel cPAddons and EA4 updates will overwrite your changes. Custom rules must always be placed in:

• Global Custom Rules File: /etc/apache2/conf.d/modsec2.user.conf
• WHM GUI Path: WHM >> Security Center >> ModSecurity Tools >> Edit Rules

---

2. Blocking XML-RPC Exploitation & Pingback Amplification

Unless a WordPress site specifically uses the Jetpack plugin or WordPress mobile app publishing, xmlrpc.php is almost exclusively an attack vector used for brute-force credential stuffing and distributed pingback DDoS attacks.

Add this rule to /etc/apache2/conf.d/modsec2.user.conf using a custom Rule ID within the user range (1000000 to 1999999):

# Rule 1000100: Block All XML-RPC POST Requests with 403 Forbidden
SecRule REQUEST_URI "@streq /xmlrpc.php" \
    "id:1000100,\
    phase:2,\
    t:none,t:lowercase,\
    chain,\
    deny,\
    status:403,\
    log,\
    msg:'WordPress Protection: Blocked xmlrpc.php execution',\
    tag:'wordpress/security/xmlrpc'"
    SecRule REQUEST_METHOD "@streq POST" ""

If the client requires Jetpack cloud services, restrict access to Automattic IP blocks rather than leaving the endpoint wide open:

# Rule 1000101: Allow Jetpack Cloud IPs, Block All Other XML-RPC Access
SecRule REQUEST_URI "@streq /xmlrpc.php" \
    "id:1000101,\
    phase:2,\
    t:none,t:lowercase,\
    chain,\
    deny,\
    status:403,\
    log,\
    msg:'WordPress Protection: Unauthorized XML-RPC access attempt',\
    tag:'wordpress/security/xmlrpc'"
    SecRule REMOTE_ADDR "!@ipMatch 192.0.64.0/18,122.248.245.240/28,54.217.201.243/32" ""

---

3. Rate-Limiting wp-login.php Brute Force Attacks

Botnets frequently bypass basic IP bans by distributing password guesses across thousands of residential proxy IPs. Using ModSecurity’s persistent memory collections (ip collections), we can throttle failed or rapid login attempts per IP.

# Initialize IP Tracking Collection in Phase 1
SecAction "id:1000200,phase:1,initcol:ip=%{REMOTE_ADDR},nolog,pass"

# Rule 1000201: Count wp-login.php POST requests within a 60-second sliding window
SecRule REQUEST_URI "@streq /wp-login.php" \
    "id:1000201,\
    phase:2,\
    t:none,t:lowercase,\
    chain,\
    pass,\
    nolog"
    SecRule REQUEST_METHOD "@streq POST" \
        "setvar:ip.wp_login_attempts=+1,\
        expirevar:ip.wp_login_attempts=60"

# Rule 1000202: Drop connections exceeding 8 login attempts per minute
SecRule IP:WP_LOGIN_ATTEMPTS "@gt 8" \
    "id:1000202,\
    phase:2,\
    deny,\
    status:429,\
    msg:'WordPress Protection: Rate limit exceeded for wp-login.php',\
    tag:'wordpress/security/rate_limit',\
    log"

When deployed on high-concurrency Dedicated Servers in Pakistan, rate-limiting attacks at the web server layer prevents PHP-FPM worker starvation, maintaining sub-millisecond response times for actual customers.

---

4. Whitelisting Pakistani Payment Gateways (JazzCash, EasyPaisa, PayFast)

One of the most persistent headaches for Pakistani WooCommerce store owners is finding that customers complete their payment on the JazzCash or EasyPaisa mobile app or web portal, but orders remain stuck in “Pending Payment” status.

This occurs because payment gateways send server-to-server HTTP POST webhook callbacks containing transaction signatures, hashes, and URLs that trigger OWASP CRS SQL Injection (Rule 942100) and Cross-Site Scripting (Rule 941100) filters.

To prevent ModSecurity from intercepting legitimate IPN (Instant Payment Notification) webhooks, configure exclusion rules in Phase 1:

# Rule 1000300: Whitelist JazzCash IPN Callbacks
SecRule REQUEST_METHOD "@streq POST" \
    "id:1000300,\
    phase:1,\
    t:none,\
    chain,\
    nolog,\
    pass"
    SecRule REQUEST_URI "@rx /(wc-api/jazzcash|checkout/order-received|wp-json/jazzcash)" \
        "ctl:ruleRemoveTargetById=942100;ARGS,\
        ctl:ruleRemoveTargetById=941100;ARGS,\
        ctl:ruleRemoveById=949110"

# Rule 1000301: Whitelist EasyPaisa Webhook Responses
SecRule REQUEST_METHOD "@streq POST" \
    "id:1000301,\
    phase:1,\
    t:none,\
    chain,\
    nolog,\
    pass"
    SecRule REQUEST_URI "@rx /(easypaisa_ipn|wc-api/WC_EasyPaisa|wp-json/easypaisa)" \
        "ctl:ruleRemoveTargetById=942100;ARGS,\
        ctl:ruleRemoveTargetById=941100;ARGS,\
        ctl:ruleRemoveById=949110"

Notice the use of ctl:ruleRemoveTargetById: rather than disabling ModSecurity entirely for the URL, it selectively disables only the offending inspection targets while keeping protocol validation and other threat vectors active.

---

5. Blocking WordPress User Enumeration & REST API Scanning

Malicious reconnaissance scripts harvest WordPress usernames by sending requests to /?author=1, /?author=2, or /wp-json/wp/v2/users. Block this profiling activity with custom header inspection:

# Rule 1000400: Block query-string author enumeration for unauthenticated visitors
SecRule ARGS_NAMES "@streq author" \
    "id:1000400,\
    phase:2,\
    t:none,t:lowercase,\
    chain,\
    deny,\
    status:403,\
    msg:'WordPress Reconnaissance: Blocked Author Enumeration Attempt',\
    tag:'wordpress/security/recon'"
    SecRule REQUEST_COOKIES_NAMES "!@rx (wordpress_logged_in|wp-saving-post)" ""

# Rule 1000401: Restrict Public Access to WP REST API User Directory
SecRule REQUEST_URI "@rx ^/wp-json/wp/v2/users" \
    "id:1000401,\
    phase:1,\
    t:none,t:lowercase,\
    chain,\
    deny,\
    status:403,\
    msg:'WordPress Protection: Blocked REST API User List Query',\
    tag:'wordpress/security/rest_api'"
    SecRule REQUEST_COOKIES_NAMES "!@rx wordpress_logged_in" ""

---

6. Testing, Syntax Validation & Safe Reload

Never reload Apache or LiteSpeed without validating your ModSecurity configuration. An unescaped quotation mark or duplicated rule ID will crash the web server.

Execute configuration tests from the SSH terminal:

# 1. Test Apache Configuration Syntax
apachectl configtest

# Expected Output:
# Syntax OK

# 2. Rebuild and restart the Apache service via cPanel scripts
/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd

# 3. For LiteSpeed Web Server installations:
/usr/local/lsws/bin/lswsctrl test
/usr/local/lsws/bin/lswsctrl restart

Verify your rules in real-time by inspecting the ModSecurity audit log:

tail -f /etc/apache2/logs/modsec_audit.log | grep -E "(1000100|1000202|1000300)"

---

7. Comparative Performance Matrix

Protection Mechanism	Attack Vector Mitigated	Server CPU Impact	Risk of False Positives
Custom Rule 1000100	XML-RPC Brute Force / DDoS	Near Zero (Blocks at Phase 2)	Negligible (Unless Jetpack used)
Custom Rule 1000201	wp-login.php Password Floods	Very Low (In-memory IP tracking)	Low (Threshold > 8/min)
Custom Rule 1000300	Payment Webhook Failures	None (Bypasses false positive checks)	Zero (Restores JazzCash/EasyPaisa)
Custom Rule 1000400	User Enumeration Scanners	Negligible	Low (Whitelists logged-in admins)

For enterprise mission-critical WordPress sites requiring dedicated compute isolation, pairing custom ModSecurity rules with cPanel PHP-FPM Pool Tuning, cPanel Mod_evasive DoS Hardening, and cPanel Leech Protect Anti-Scraping on enterprise Dedicated Servers delivers bulletproof uptime and impenetrable defense.