Attacks stop before
WordPress loads.

Problem — A firewall that runs as a plugin only wakes up after WordPress and every other plugin is already in memory — by then the malicious request has run code.

Solution — The compiled signature engine runs at the very start of PHP, before a single line of WordPress loads, and stops the request there.

Problem — Password attempts don't only arrive at wp-login.php; XML-RPC, REST and application passwords reach the same account through separate doors, and a lock that counts one door never sees them.

Solution — Every login path is routed through one identity gate; the lock counts per IP, per account and globally at the same time.

Problem — A stolen administrator password is full control on its own — and password leaks usually come from some other service, not from your site.

Solution — TOTP, a recovery code or a passkey is enforced at the authentication gate; application passwords are separately audited so they cannot walk around the second factor.

Problem — Automated tools try hundreds of passwords a second; a cost that is invisible to a human is a scaling problem for a bot.

Solution — The login request must carry a proof-of-work solved in the browser — milliseconds for a user, an unpayable cost for a hundred-thousand-attempt campaign.

Problem — An attack starts with a list of valid usernames, not with a password guess — and WordPress hands that list over through ?author=1, REST /users and its own login error messages.

Solution — All three leaks are closed and the login error is reduced to a single message that does not distinguish an existing user from a missing one.

Problem — Changing the password does not invalidate the cookie already in the attacker's hands; while the session stays open, a password change solves nothing.

Solution — A password reset drops every session and a password change drops all the others immediately; whatever remains can be revoked in bulk from one screen.

Problem — Protecting wp-login.php is not enough; admin-ajax.php and REST endpoints can be called without authentication and do the same job at a larger scale.

Solution — REST and AJAX paths are placed under the same rate limit; unambiguous matches are blocked, and grey ones are recorded without blocking.

Problem — A single XSS flaw exposes the session cookie, the forms and everything else on the page once the browser enforces no restriction at all.

Solution — CSP, X-Frame-Options, Referrer-Policy and Permissions-Policy are sent, and a scheduled audit separately measures that the headers actually reach the browser.

Problem — Headers are sent by PHP, but images, PDFs and JS files are served directly by the web server — PHP never runs for those responses, so they carry no security headers at all.

Solution — A server-level rule that adds the same headers is generated, and the audit measures whether it is installed; if it is not, the row does not turn green.

Problem — WordPress ships open for compatibility: the version number, RSD/WLW links, pingback and the in-dashboard file editor. Each one hands an attacker either information or a way to write code directly.

Solution — One profile closes them and each item is reported separately; whichever is still open is not hidden.

Problem — The extension and the MIME header are whatever the client claims; a file ending in .jpg can perfectly well be PHP.

Solution — An allowlist, a three-way extension/MIME/content match and a re-encode are applied; a file that claims to be an image but cannot be decoded as one is rejected.

Problem — The wp-content/uploads directory is writable from outside by definition; if a single PHP file dropped there can be requested directly, getting past the upload filter is enough.

Solution — A server rule that disables PHP execution under that directory is written, and a scheduled audit measures that the rule is still in place.

Problem — A backdoor is usually not a new file but a few lines added to an existing core file; it is invisible to the eye.

Solution — Every core file is compared against the official checksum published by WordPress.org; bundled plugins that update independently are excluded, otherwise even a spotless install raises an alarm.

Problem — A security layer that slows the site down is eventually switched off — and most of a page's weight is images.

Solution — WebP/AVIF versions of uploaded images are produced; the work runs in scheduled slices instead of blocking a single request.

Problem — Hardening is done once at install; then someone turns on WP_DEBUG, a plugin adds a capability, a user becomes an administrator — and nobody notices.

Solution — Ten items are measured daily: dangerous capabilities, the registration role, critical constants, file permissions, orphaned cron, weak administrator passwords and end-of-life PHP. The baseline taken on the first run is never moved forward — an unacknowledged change must not become the new normal.

Problem — Dropins such as wp-config.php, .htaccess and object-cache.php load before WordPress does; an attacker who can write to one of them adds code to every request.

Solution — The contents of these files are baselined and each change is raised as its own finding.

Problem — Deleting a file flagged as malicious takes the site down when the flag is wrong; leaving it alone leaves the attacker's file in place.

Solution — The file is moved into quarantine atomically, nothing is ever deleted automatically, and restoring it is a single step.

Problem — The first thing an attacker with administrator rights does is clean up the traces; a log that can be edited tells you nothing after the fact.

Solution — The log is append-only and every row carries the digest of the one before it; if anyone intervenes the chain breaks, and that break is measurable.

Problem — Tightening a security setting sometimes breaks the site; with no way back, even the correct change never gets made.

Solution — A snapshot is taken before every write, and a setting that breaks something is rolled back in one step.

Problem — Text search does not find malicious code — an eval call hides comfortably behind base64, a variable function name or string concatenation.

Solution — Files are analysed through PHP's own token stream, so a hidden call is visible regardless of how it was spelled in the source.

Problem — Ad injection lives in the database, not in a file: an option, a post body, a meta field. A file scan never sees it.

Solution — Options, post content and meta fields are scanned separately for injected markup.

Problem — A plugin may have no known vulnerability today; but if it has not been updated for two years, no patch will arrive for the one found tomorrow either.

Solution — Maintenance signals are read for every plugin and theme in the inventory; this is not a vulnerability scan, it is a measure of abandonment.

Problem — If a header that is not part of the cache key changes the response, a single attacker request can produce a poisoned page served to every visitor.

Solution — Inputs that alter the response without entering the key are audited, and each one found is raised as a finding.

Problem — Password resets, login alerts and security notifications all travel by e-mail; if the server's own mail() path lands silently in spam, the warning never arrives.

Solution — Outbound mail is bound to an authenticated SMTP server, and delivery is measured rather than assumed.

Problem — When a certificate expires the site becomes unreachable — and visitors are usually the first to notice.

Solution — The certificate's remaining lifetime, its chain and its renewal state are measured regularly, and the warning comes before the expiry.

Problem — If these three records are missing, anyone may send forged e-mail in your domain's name — and you cannot see that from inside your own site.

Solution — The records are read from the outside with an independent resolver, and a missing or weak policy is reported with the exact correction to apply.

Problem — A backup is cut short, a scan never finishes, an upload fails — and the cause is usually not security but memory_limit or max_execution_time.

Solution — The real limits at runtime are measured, and which job hits which limit is stated explicitly.

Problem — An unverified backup is not a backup; most backups are tried for the first time during a restore, and that is exactly where they turn out to be broken.

Solution — A backup is taken and its restorability is verified separately; an unverified backup does not count as taken.

Problem — Expired transients, old revisions, spam comments and orphaned meta inflate the database, and every query in an inflated database gets slower.

Solution — These four classes are counted and cleaned regularly, and what will be removed is shown before it is removed.

Problem — If a logged-in user's page is cached and then served to an anonymous visitor, session content and sometimes nonces leak out.

Solution — Whether logged-in requests actually bypass the cache is measured; if they do not, a finding is raised.

Problem — An open redirect turns your own domain into a phishing tool; broken links cost you both the visitor and the ranking.

Solution — Redirects are defined in one place and their targets are restricted; having no redirects at all is not the same as being protected, so that state is reported separately.

Problem — When files like wp-config.php, .git/, .env and debug.log are requested directly, PHP never runs; with no rule on the server, the file is handed over as-is.

Solution — A server rule closing the sensitive paths is generated; if the server does not read .htaccess (nginx, LiteSpeed) the equivalent configuration is shown on screen to apply by hand, and the row is not counted as green.

Problem — Options marked autoload are read into memory on every single request; a few megabytes left behind by plugins slow the whole site down permanently.

Solution — The autoload weight is measured, the heaviest entries are listed one by one, and the unnecessary ones are taken out of autoload.

Problem — Most of this plugin's scans hang off the WordPress scheduler, and that scheduler runs on visitor traffic: on a quiet site, or a host that sets DISABLE_WP_CRON, none of them ever run — the screens say “not scanned yet” and the operator reads it as safe.

Solution — The plugin measures whether scheduled work actually runs on this server, and when it does not it says so by name instead of looking like a delay.

Problem — When a site gets slower the security plugin is the first suspect, and nobody can show otherwise, because no plugin measures its own cost.

Solution — The plugin measures its own cost — per-request time, its own autoloaded options, admin queries — against a budget it publishes, and reports itself when it goes over.

Problem — A CVE list for your installed plugins is not actionable on its own: it does not say which of the hundreds is actually being exploited.

Solution — The inventory is joined against CISA KEV (known exploited) and EPSS (probability of exploitation), so the ranking rests on measurement rather than guesswork.

Problem — If the patch has not shipped yet, or the update is being deferred because it would break the site, the hole stays open until it is closed.

Solution — A rule that cuts the known exploitation pattern is applied in the layer ahead of WordPress; the plugin's own code is left untouched.

Problem — A single site cannot tell whether the attack aimed at it is part of a new campaign or just background noise.

Solution — Signature and indicator feeds are distributed centrally, so behaviour first measured on one site meets the next one as a rule.

Problem — During an incident the real problem is not a shortage of alerts but not knowing the order: what to isolate first, what to roll back, what to preserve as evidence.

Solution — Findings are collected on a single timeline, and isolation, rollback and evidence preservation are carried out in order.

Problem — A change to an NS or MX record means the whole site and all of its mail have been handed to someone else — and the site cannot see that from the inside.

Solution — NS, MX, A/AAAA, TXT and DMARC records are baselined from outside, and when drift is reported "could not resolve" is never conflated with "no record".

Problem — From the inside a site looks healthy; what it leaks outward — an open directory listing, a reachable backup file, mixed content — is only visible from outside.

Solution — Headers, redirects, the server banner and known sensitive paths are measured from an independent location, and a path that was never probed is never reported as clean.

Problem — A third party obtaining a certificate for your domain is the first visible sign of hijacked DNS — and it leaves no trace at all on your server.

Solution — Public CT logs are watched; a certificate issued under an unrecognised organisation raises an alert, and a fingerprint an operator has closed is never raised again.