WAF for WordPress is a second, separate firewall layer that Imunify shipped in 2026, on top of the server-level ModSecurity WAF that already comes with Imunify360 Unlimited. It doesn't inspect Apache or LiteSpeed traffic generically — it runs inside each WordPress install via a companion plugin, matches requests against a ruleset built specifically for known plugin and theme CVEs, and blocks the exploit attempt before it reaches the vulnerable code. The plugin itself stays outdated; the request just never lands.
This matters on shared cPanel and Plesk hosts because plugin updates are the customer's problem, not yours, and customers don't patch. A CVE drops for a page builder or a WooCommerce add-on, proof-of-concept exploit code is public within days, and a chunk of your fleet is running the vulnerable version six months later. WAF for WordPress closes that gap without you touching a single site's files.
How it differs from the WAF you already have
If you've read tuning the Imunify360 WAF for false positives, you already know Imunify360 Unlimited ships a Comodo/OWASP ModSecurity ruleset at the web server layer. WAF for WordPress is not that ruleset with more rules — it's a different engine entirely:
| Server-level WAF (ModSecurity) | WAF for WordPress | |
|---|---|---|
| Runs at | Apache/LiteSpeed, before any PHP | Inside WordPress, via the Imunify Security plugin |
| Rule scope | Generic SQLi/XSS/RCE patterns | Per-CVE rules for specific plugins and themes |
| Applies to | Every site on the server | WordPress installs with the plugin active |
| Included with | Imunify360 Unlimited only | Both ImunifyAV and Imunify360 Unlimited |
| Blocking behaviour | Blocks on Imunify360 | Blocks on Imunify360; log-only on ImunifyAV/AV+ |
That last row is the one worth knowing before you promise a customer anything: on an ImunifyAV server, WAF for WordPress detects and logs a matching exploit attempt but does not block it — you need Imunify360 Unlimited for the request to actually get a 403. It's also distinct from ProactiveDefense, which watches PHP execution behaviour rather than matching known CVE signatures at the request layer — the two run independently and catch different things.
Version requirements
Check these before rolling it out on a fleet — the feature silently does nothing if the agent is too old:
- WordPress 5.0.0 or later on the site itself
- PHP 5.6 or later
- Imunify360 8.12.5-3 or later, or ImunifyAV/AV+ 8.7.1-2 or later
- Imunify Security WordPress plugin
wp-3.0.1-2or later
Run imunify360-agent version on the server to check your agent build. If it's older than 8.12.5-3, update the package through your OS package manager (yum update imunify360 or apt-get upgrade imunify360) before enabling the plugin — see the Imunify360 agent CLI reference if you're unfamiliar with the update commands.
Enable it server-wide
The plugin isn't distributed through the WordPress.org repository — it's pushed from the Imunify control panel, and it installs itself into every active WordPress site on the server in one pass.
cPanel/WHM
- Open Imunify360 (or ImunifyAV) from WHM or the account's cPanel.
- Go to Settings → General.
- Find the WordPress Plugin section.
- Check Install WordPress plugin.
- Save.
The agent installs the plugin into every WordPress docroot it can detect in the background — no per-account action needed, and no site downtime. On a large fleet the rollout can take a few hours to reach every site.
Plesk
The same toggle lives under Imunify360 → Settings → General → WordPress Plugin in the Plesk extension. Enabling it triggers the same fleet-wide background install.
CLI
The same setting is exposed through the agent, useful for scripting a fleet rollout instead of clicking through WHM per server:
imunify360-agent config update '{"WORDPRESS" : {"security_plugin_enabled": true}}'
This writes the config change and kicks off the same background install as the UI toggle. Confirm the agent picked up the change with the general health check from the Imunify360 CLI reference:
imunify360-agent rstatus
Verify it's active on a site
The most reliable check is from the WordPress admin side: once the background install reaches a site, the owner sees an Imunify Security entry in their dashboard sidebar, showing whether WAF for WordPress is active and a feed of any blocked or logged exploit attempts for that install specifically. If it's missing after a few hours, confirm the plugin file itself landed in wp-content/plugins/ on that account, and re-check imunify360-agent rstatus for a stalled rollout.
Reading incidents
Blocked and logged exploit attempts show up in two places:
- WHM/cPanel: Imunify360 → Incidents, filtered by Plugin = "WordPress WAF" — the same incident log used for the ModSecurity WAF and ProactiveDefense, just tagged differently.
- WordPress admin: the Imunify Security plugin's own incident feed, scoped to that one site, useful for handing a customer proof their site was under attack without giving them shell access.
Each incident logs the CVE or plugin/theme name the rule targets, the request path, and the source IP — the same triage flow as the incidents covered in the Imunify360 CLI reference applies here.
What it won't catch
Rule coverage depends on Imunify's team writing a rule for a given CVE, and they're explicit that it's not exhaustive — new critical CVEs typically get a rule within 24 hours of disclosure, but a zero-day with no public CVE yet has no rule to match against. It also only protects plugins and themes it has a written rule for; an obscure or custom-built plugin with a vulnerability nobody's reported publicly gets no coverage. This is a mitigation layer on top of keeping plugins updated, not a replacement for it — pair it with ProactiveDefense for behavioural coverage of the gaps.
Next steps
- Tune Imunify360 WAF false positives
- Configure Imunify360 ProactiveDefense for PHP malware blocking
- Imunify360 agent CLI reference