For agencies
You run ten, fifty or two hundred WordPress sites for clients. Every alert you forward costs you a ticket, and every cleanup that breaks a page costs you an afternoon. Segurium is built for the other outcome: find the infection, leave the client's own code alone, and put the file back together so nothing goes dark.
No account, no key, no console to keep logged in. Every site runs the full product free, with 3 cleanups per 30 days on each.
Every alert you forward to a client is real. A scanner that matches patterns against your files flags your client's theme, their custom snippet, a minified script. You answer for every one of those.
Segurium sends a hash of each file and gets back a single answer for it, decided against a body of known good and known bad code rather than a rule that guesses. A file the cloud has already settled never leaves the server at all.
Bespoke theme functions, a client's own plugin, an agency boilerplate: none of it resembles known malware, which is the whole reason the cloud is asked instead of a pattern. Segurium is built to stay quiet on a client's own code, and a row you still disagree with can be ignored by hash or by path.
Detection reaches inside otherwise-legitimate files too, so an injection three lines into a working plugin is named as precisely as a shell dropped in the uploads directory.
Removal is where security plugins cost you the day. Delete the file and the page dies. Overwrite it and the client's customisation goes with the malware. Three things happen here instead, and none of them guesses.
Restored to the canonical content published by WordPress.org, verified end to end. No guessing at what the file used to look like, and no tampered bytes swapped in.
When malware sits inside a file that is otherwise legitimate, only the injection comes out. Your client's theme still renders and their custom functions still run.
A file that is nothing but malware is emptied where it stands, so a backdoor, a dropper or an uploader has nothing left to execute. The path stays, and stays harmless, so nothing that referenced it hits a missing file.
The original file is encrypted and kept on the site, and every cleaned row carries a Restore button. A verdict you disagree with is one click back, not a call to the host about last night's backup.
Segurium checks the installed release of every plugin, theme and WordPress core against the cloud.
A release with a known vulnerability gets a red Vulnerable badge on the Integrity tab and a red mark on the Segurium menu, so you see it from any admin screen. Where a newer release exists the row carries the normal WordPress Update button; where none does, it reads No update available and the decision to keep or drop the component is yours. No CVE feed to read and no separate subscription.
Segurium Research publishes patch-diff write-ups of WordPress plugin vulnerabilities, so you can read what a fix actually changed before you push it to a client list.
Point every site at the same address at rollout. Sites whose local digest hour falls together are collapsed into a single mail, so a client list in one timezone reads as one email instead of fifty. Sites in another timezone get their own mail at their own hour.
Threats still present, plus the vulnerable components found on each site, detailed for up to ten sites and counted beyond that. Every component line names the version installed and the action available: update or delete it. It arrives on both the free and the paid tier.
A new infection on a site that was clean does not wait for tomorrow. That one arrives on its own, for that site, as soon as the cloud is sure.
Every capability ships in every install, free and paid alike. The paid plan changes one number, further down.
Nothing on this page needs an admin page load. Consent, settings and licensing all have a command, so site fifty-one takes the same four lines as site two.
The plugin stays idle until someone accepts the external service disclosure. The command accepts it exactly as the admin screen does, so nothing waits on a browser tab.
wp plugin install segurium --activate
wp segurium consent accept --i-accept --email=soc@agency.exampleTwo constants in wp-config.php do the same on a site nobody logs into. Consent applies on the first request, so a fresh site does not sit idle waiting for cron.
define( 'SEGURIUM_CTI_CONSENT', true );
define( 'SEGURIUM_ALERTS_EMAIL', 'soc@agency.example' );Configure the first site, export the profile, import it on the rest. Secrets stay behind unless you ask for them, and each site keeps its own identity. Read the file before you push it: cloud detection and the uninstall data-wipe choice travel with it, so an export from a cloud-enabled site switches uploads on at the target. A dry run reports what would change without writing.
wp segurium settings export --file=profile.json
ssh site16 wp segurium settings import - --dry-run < profile.json
ssh site16 wp segurium settings import - < profile.jsonA key activates from the shell on the one site that needs the cleanup ceiling lifted. The quota command tells you which site that is.
wp segurium license activate <key>
wp segurium quotaRun a scan, read the verdict per file, click Clean. The injected code comes out, the file keeps working, and the original waits in the encrypted store in case you want it back.
Any site cleans 3 files every 30 days for nothing, counted on a rolling window. A site with an infection bigger than that takes Pro on that site alone: $79 a year, unlimited cleanups, same plugin, nothing else about the site changes. You pay for the incident, on the one site that had it, while the rest of the client list stays free.
If you run a hosting company and want Segurium in your WordPress installer's optional plugin list, or in your recommended-plugins article, write to us.