Name: Exein Analyzer
Brand: Exein

WordPress powers roughly 40% of all websites, and nearly 60% of every site built on a CMS,¹ which makes it the most consistently targeted web platform on the internet. And the trajectory worsens each year: 11,334 new vulnerabilities were disclosed across the WordPress ecosystem in 2025, a 42% increase over the prior year, with highly exploitable vulnerabilities up 113%.² Two facts compound the problem: 46% of disclosed vulnerabilities ship with no patch at the moment of disclosure, and for the most heavily exploited ones, mass-scale attacks begin within a median of five hours.² Patch cycles measured in days are structurally insufficient against both.

In this post we focus on what happens after a vulnerability fires: why the tools most teams already run cannot see that stage, and how Exein Runtime covers it.

How WordPress workloads are protected today

Three categories of tools cover WordPress security today, each on a different layer.

Security plugins run inside WordPress itself: they scan for known malware, block suspicious logins, and apply virtual patches. Their limit is the layer they live on. When a plugin exploit gives the attacker code execution inside the web server process, they have no visibility into what happens next. The typical outcome is a webshell: a malicious PHP file that gives the attacker persistent, browser-accessible control over the host, independent of any WordPress credential.

WAFs and CDN-based filtering inspect HTTP traffic before it reaches the server. They see the request, not the process. Once a request has been forwarded to PHP and a vulnerability fires, the WAF has already done everything it can do.

Generic cloud workload protection platforms monitor the OS level, and for the environments they target (large cloud estates run by dedicated security teams) they do it well. A shared WordPress hosting fleet is a different problem: thousands of small tenants on the same infrastructure, and attack patterns specific to PHP, MySQL, and web server processes. That is simply outside the scope these platforms are optimized for.

The gap is structural, not a failure of any single tool: each layer blocks what it can see, and none of them can see what happens after an exploit fires inside the server. And the pressure on that gap is constant: in Q4 2025 alone, 2,213 new vulnerabilities were logged, and over the course of a year more than 100 billion credential stuffing attacks were blocked across the sites protected on one major WordPress security network.³

What Exein Runtime adds

Exein Runtime monitors and enforces behavior at the kernel level, across the entire LAMP or LEMP stack. It deploys once per host: no per-site plugins, no dependency on a site being updated.

When a vulnerability gives an attacker code execution in the PHP-FPM process, Exein Runtime is the layer that sees what that process does next: which files it opens, which processes it spawns, which network connections it attempts. Policies define the expected envelope for the workload; anything outside it is alerted on or blocked. Three post-exploit behaviors matter most.

Credential and file access. The first move with a compromised web server process is reading sensitive files: database passwords, credential stores, private keys. These reads generate no HTTP request and are invisible to WAFs and plugins. Exein Runtime sees them at the kernel level.

Privilege escalation. Published research shows a three-phase chain from WordPress compromise to root (in-memory PHP sandbox escape, kernel exploitation, manipulation of a privileged binary) that never writes a suspicious file to disk and is invisible to every application-layer control.⁴ Exein Runtime intercepts the kernel operations each phase requires, and those operations are shared across the whole class of escalation techniques, not just the published ones.

Persistence. Webshell drops, unauthorized kernel modules, outbound connections to command-and-control servers. Exein Runtime detects and can block all of these before they complete.

The common thread is the operations these attacks require, not the specific vulnerabilities. A zero-day that needs to write to a protected path or load a module hits the same constraint as a known CVE. And because enforcement runs in the kernel, it cannot be disabled by a compromised PHP process, even one running with elevated permissions.

What a policy looks like

Policies are declarative, and a handful of rules covers the behaviors above on a typical WordPress host.

One of the three post-exploit behaviors above is a compromised web server process spawning a shell. After a plugin exploit gives an attacker code execution inside Apache, the next step is almost always to run a command interpreter, and from there download tooling, drop a webshell, or start the escalation chain. A legitimate Apache process has no reason to execute /bin/sh. A single rule turns that assumption into enforcement:

toml

[[rules]]
name        = "Block shell spawned by web server"
type        = "exec"
category    = "execution"
severity    = "high"
description = "Apache should never launch a shell; this is a hallmark of post-exploitation"
condition   = 'header.image.abs == "/usr/sbin/apache2" && payload.file_path.abs == "/bin/sh"'
action      = "block"

The rule fires on the operation, not on any known exploit: it does not matter which plugin was vulnerable or which CVE was used. If the compromised Apache process tries to execute a shell, the attempt is blocked at the kernel level before the shell ever runs. The same pattern extends to the other behaviors: a rule that blocks the web server from writing .php files into wp-content/uploads stops webshell drops, and a rule scoped to credential paths stops the process from reading files it never legitimately touches.

Catching real post-exploitation on a WordPress host does not require a signature feed. It requires expressing a few behavioral rules, which Exein Runtime then enforces at the kernel boundary.

Where this fits

Exein Runtime does not replace plugins, WAFs, or patching: those block known attacks at the point of entry. It takes over where they stop, after the exploit has fired. It is the cloud end of the same spectrum we described in our post on protecting legacy devices, with one policy model and one alert pipeline from ARM32 boards to cloud servers.

For hosting providers and agencies, one more property matters: a single deployment on a host covers every site on that host. No per-tenant configuration, no plugin rollout, no dependency on site owners keeping their own tooling current. The protection lives at the infrastructure layer, the layer the provider already owns, and it plugs into the monitoring stack that layer already feeds.

How this fits your existing monitoring

Larger hosting providers already run a security operations center, and a new tool earns its place only if it feeds the pipeline they already have. Exein Runtime is built to sit inside that workflow rather than beside it: the detections and enforcement decisions it makes are emitted as structured events, so kernel-level activity on the host becomes another source your SOC can collect, correlate, and alert on alongside the rest of your telemetry. The layer that sees post-exploitation is also the layer that reports it, in a form your existing monitoring can consume.

Conclusion

Nearly half of WordPress vulnerabilities arrive without a patch, and the exploitable ones reach mass-scale attack within hours. Runtime protection does not change those numbers, but it changes what an attacker can accomplish inside that window, whether a patch exists yet or not.

If you host or manage WordPress at scale, as a hosting provider or an agency running client sites, contact the Exein team for a demo and see what a single Exein Runtime deployment covers across your fleet.