Security that runs before WordPress does

A signature scanner looks for known-bad code that is already on your disk. Must-Have Security first stops the code from being written at all. It runs before WordPress, judges every file write by its content, and refuses executable code that nothing on your site was authorised to create, so a brand-new webshell with no signature anywhere is still refused. It also has a scanner for what was already there, but a different kind: core is verified against the official checksums, and everything else is read as code. A classifier follows request input through the file and either proves it harmless, condemns it by rule, or hands the rare undecidable case to AI. No signature list to be one step behind.

No. When you update a plugin, theme or core, you open a scoped write permission from the screen you're on with one tap of a passkey. It covers exactly that path, for a few minutes. If you would rather watch first, switch file writes to monitor mode and see what enforce would do on your real site before turning it back on.

It is engineered specifically not to. The response layer fails toward letting people in, an address a trusted admin has used is never refused, no firewall rule can block the admin or the login screen, and the loader is retired in two safe stages rather than deleted. If the engine itself ever fatals, it switches itself off, lets the site boot and e-mails every trusted administrator, who re-arms it from the dashboard. (That self-disable is a switch: if you would rather a broken engine mean a 500 than an unprotected site, you can turn it off, behind your passkey, because the other direction is a weakening.)

Each file operation round-trips through PHP userland, which cost about 2–45 microseconds per operation on our test hosts, so a few milliseconds on a full admin request. Hosts differ, so treat these as our measurements, not a promise for yours.

WordPress and PHP with the ability to set auto_prepend_file via .user.ini or .htaccess, which covers almost all shared and managed hosting. Where no loader fits, it falls back to booting after WordPress. It needs no root, no server module and no daemon.

The administrator role lives in the database, which is exactly what an injection can rewrite. So the trusted-admin registry and every credential live outside the database, protected by the engine as its own control files. Being a WordPress admin, even a freshly injected one, is never enough to write executable code.

WordPress moves uploads with move_uploaded_file(), which skips the write wrapper, so the upload gate judges the temp file first, by both its bytes and its name. A JPEG carrying a PHP payload is refused, and so is shell.php.jpg, because every dotted segment of the name is checked.

The write engine is fully deterministic: no network, no database, no AI. The same inputs give the same verdict on every request, and nothing can overturn it. The malware scanner is the one part that talks to a service, and it is off until you turn it on and acknowledge that. Even then it sends as little as possible: core is checked by hash, files already known to the shared reputation database by hash, and of the rest a classifier decides most on your own server. Only files it cannot prove harmless or condemn by rule (under 1 % on a real site) are sent to be judged by AI, over HTTPS, while your secrets (wp-config, .env, keys, backups) are checked on your own server only, and nothing about them is sent. Scanner use is capped per subscription: 3,000 requests and 300 AI reviews an hour. A scan that reaches the request cap pauses and carries on by itself; a file over the AI cap waits its turn.

It stops persistence, not post-exploitation. Code that is already executing in a request can call exec() or unhook the wrapper. This layer stops a payload from becoming a file; it does not contain code that is already running. The documentation names those gaps rather than pretending they're closed.

Yes. The engine keeps enforcing, so your security is never held hostage. An active subscription is required for updates and support. Deactivating cleanly removes the loader, and uninstalling keeps your settings unless you tick "delete all data".