Every other plugin tells youthe site was hacked.This one gets you out of it.

1. 01

   You get a list of infected files

   No indication of how they got there, what else was touched, or what happens if you delete them.

2. 02

   You delete them. The site comes back anyway

   Because the rogue administrator, the scheduled task and the autoloaded option are still there.

3. 03

   You cannot tell anyone what happened

   No timeline, no evidence, nothing you could hand a client or an insurer.

4. 04

   You never learn whether it is actually over

   A clean scan is not proof. The only real answer comes from watching for re-entry.

1. 01

   Detect

   Across six surfaces at once

   Files, database, accounts, sessions, scheduled tasks and request traffic — correlated into a single incident instead of six unrelated alerts. Core and plugins are checked against their official checksums, not against a guess.

2. 02

   Explain

   In plain language, with the evidence attached

   A deterministic timeline built from evidence timestamps: when the file appeared, when the administrator was created, when the first request hit it. Every statement carries the evidence id behind it.

3. 03

   Contain

   A plan you approve step by step

   Each step shows its risk, what it changes, what it might break, and whether it can be undone. Destructive steps are unchecked by default and need re-authentication.

4. 04

   Clean

   As a transaction, not a delete key

   Snapshot, execute, verify — per step. Files are quarantined encrypted and restorable for 90 days, not deleted on the spot. If a step fails or the site breaks, it rolls back automatically. A crash mid-way is detected and unwound.

5. 05

   Verify

   Against the real site, not a status code

   Loopback checks assert actual content, detect off-host redirects and read the fatal-error log. An incident only moves to “verified” when the outcome is proven.

6. 06

   Watch

   Because they come back

   Re-entry watch tightens the cadence after an incident and steps down over days. If the same actor returns, the original incident reopens instead of a new alert appearing from nowhere.

• Files

  Official checksums for core and repository plugins; content sniffing that ignores the extension; tokenizer features rather than regex alone.

  • Web shell families
  • PHP in uploads
  • Unexpected package files
  • Timestomping
  • Stray wp-config copies

• Database

  Read raw and filtered, so a hijacked option filter cannot hide what it returns.

  • Autoloaded payloads
  • siteurl hijack
  • Role manipulation
  • Malicious posts
  • Hidden plugins

• Identity

  An administrator that appeared without the hook that should have fired is a different fact than one that was created normally.

  • Rogue administrators
  • Display-name mimicry
  • Application passwords
  • Session anomalies

• Persistence

  The parts that bring the site back after you think you cleaned it.

  • Cron with unowned hooks
  • Drop-ins and mu-plugins
  • auto_prepend_file
  • .htaccess handlers

• Traffic

  Bounded and sampled, never bodies or cookies, with proxy handling that cannot be spoofed.

  • REST abuse and enumeration
  • Login bursts
  • First hit on a planted file

• Server

  What WordPress cannot see. Optional, read-only, outbound-only — and when it is absent the page says so instead of implying coverage.

  • Processes in temp
  • Listening sockets
  • crontab entries
  • Direct PHP requests

• 01

  Response as a transaction

  Snapshot, execute, verify, and roll back on failure — for every step, including a crash halfway through. Competing “one-click clean” features are a delete with no record and no way back.

• 02

  Coverage honesty

  Every negative result names what was checked and what was not: “no web-shell signatures in 14,203 files — server-level files not checked.” No other WordPress security tool tells you where it is blind.

• 03

  A tamper-evident journal

  Hash-chained changes, anchored off-site. “What changed before the compromise?” is the first question a responder asks, and it is the one no mass-market product can answer.

• 04

  Your files stay on your server

  Analysis runs on features and hashes. Code excerpts are shared only if you switch it on. Cloud malware scanners upload your site to theirs.

• 05

  Reversible, or refused

  Quarantine is encrypted and restorable, options are snapshotted before they change, roles and users are captured before suspension. Where an action cannot be undone safely it is not offered — destructive database cleanup is refused at the engine boundary until its rollback has been tested against injected failures. Nothing is deleted to make a number go down.

• 06

  An incident report you can hand over

  A self-contained file — assessment, coverage, blind spots, timeline, evidence hashes, every action with its risk and outcome, the journal chain head. No scripts, nothing that can execute.

• Wordfence

  Better atSignature breadth, firewall maturity, an excellent free tier.

  Stops atCleanup is manual or a paid human service. No transactional remediation, no incident timeline across database and identity, no coverage statement.

• Patchstack

  Better atVirtual patching depth and disclosure speed — the best in the market.

  Stops atNo malware scanning by design and no incident response. Their customers still need a responder once a site is already compromised.

• MalCare

  Better atGenuinely one-click cleanup, bundled backups and staging.

  Stops atThe cleanup is a black box: your files are uploaded to their cloud, and you get no evidence, no timeline and no account of what was changed.

• Sucuri

  Better atA network WAF, which is stronger than anything a plugin can do.

  Stops atCleanup is a support ticket measured in hours or days, and you receive little forensic detail.

• Cloudflare

  Better atEverything at the network edge that a plugin will never see.

  Stops atZero visibility inside the site: it cannot see a rogue administrator, a cron entry or a modified option. Run it alongside — we integrate rather than pretend.

• One list, sorted by what needs you first

  in development

  Every site you look after on one page, ordered by attention rather than alphabetically: silent sites first, then failed integrity checks, then open incidents, then the rest. A hundred green rows is not information; the three that are not green is.

• Sites grouped by the client they belong to

  in development

  Client organisations are a first-class record, not a tag. A site can be filed under the customer who owns it, which is how an agency actually thinks about a portfolio and what makes a per-client report possible at all.

• Reports you can send to the client

  in development

  A PDF per client or per site, in English or German, generated server-side with no external service involved. It states what was found, what was done about it and what is still open — in language a business owner can read without a glossary.

• Three roles, two privilege levels

  built & tested

  Owner, administrator and member. A member is read-only, so a junior colleague can have the dashboard without being able to redirect a client's alerts, disconnect a site or download its evidence. Enforced in the handler, never by hiding a button.

• Onboarding that cannot be replayed

  in development

  A site is enrolled with a single-use token that expires, can be withdrawn before it is used, and is bound to the agency that minted it. The site generates its own signing key and proves it holds the private half during enrolment.

• Handing a client to another agency

  built & tested

  A two-party handshake with a record: one agency proposes, the other accepts, and only then does the site move. The incident history moves with it. The raw activity journal does not — it was collected under a different agreement with the site owner, so the receiving agency is told plainly that earlier evidence exists and who to ask for it.

• Telemetry the service does not have to take on trust

  built & tested

  Every report a site sends is signed with that site's own key and checked against a replay store. The service re-verifies the hash chain of the site's own journal, so a rewritten or truncated history is visible from outside even while the site reports clean.

• Incident summaries that leave the secrets behind

  built & tested

  What travels is bounded and versioned: findings, file hashes, component versions and a hashed summary of the journal. Not file contents, not option values, not credentials. Code excerpts travel only if you turn that on deliberately.

The agency platform is not on sale. It runs with a small number of agencies we set up ourselves, and connecting a live WordPress installation is not yet self-service — see architecture for exactly which step is unfinished, and pricing for what can be bought today.

• On the site

  WordPress plugin · PHP 8.1+ · WordPress 6.6+

  Detection, correlation, quarantine and remediation all run inside the installation, against repositories over the WordPress database. Nothing here waits for a network.

  • PSR-4, no framework, no Composer dependencies at runtime
  • Repositories over $wpdb / MySQL, with its own tables
  • Hash-chained local journal, tamper-evident
  • XChaCha20-Poly1305 for quarantined files and snapshots

• In transit

  HTTPS only · Ed25519

  Each site holds a key pair it generated itself and signs every request with it. Timestamp and nonce are part of the signature, so a captured request cannot be replayed.

  • Plain HTTP is refused outright by the client
  • Pinned trust roots, with key manifests verified against them
  • Revocation by monotonic manifest replacement
  • Request bodies bounded and schema-checked before anything is parsed

• Collection service

  Node.js

  Receives signed telemetry, re-verifies what the site claims about its own journal, and holds the off-site copy of accepted evidence.

  • Authenticates each site, and trusts none of them
  • Accepted evidence is first-write-wins — a site cannot rewrite its own history here
  • Signed receipts, so acceptance can be proved to a third party
  • No site can read back, export or delete what it has sent

• Account service

  Node.js · PostgreSQL

  Agencies, clients, subscriptions and the dashboard. Every tenant boundary is enforced twice, in the query and in the database.

  • Row-level security enabled and forced on every tenant table
  • The service connects as an unprivileged role that cannot bypass it
  • Authorization decided server-side, never by what the page renders
  • Isolation tests run as that same unprivileged role

Not yet verified The hop from a live WordPress installation to our collection service has not been exercised end to end. An installation pins our release trust roots and correctly rejects anything signed with development keys, and closing that properly needs a signing step we have not done. The site half — detection, correlation, quarantine, remediation — does not depend on it and is tested on real WordPress.

• It is not a network firewall. Requests that never reach PHP are invisible to it — run Cloudflare or a host WAF alongside.
• It cannot change PHP settings from inside WordPress. When the runtime configuration is dangerous, it says so and marks the finding as not reversible by the agent.
• On Nginx it cannot enforce upload rules itself. It gives you the exact configuration block and marks the control as not enforced.
• It never claims a site is clean. The strongest verdict is "no signs of compromise", always with the coverage that produced it.
• Against an attacker with root on the server, no WordPress plugin is authoritative. The optional host agent widens coverage; it does not change that fact.

• Free

  €0foreverNo account, no card, no expiry.€0foreverNo account, no card, no expiry.

  Unlimited sites, local only

  The whole detection and response engine, running on your own server. Not a trial.

  • All local detection layers
  • Core and plugin integrity checks
  • Guided remediation, with each step stating what it can and cannot undo
  • Incident correlation and timeline
  • Encrypted quarantine and restore
  • Change journal (at least 7 days, hash-chained; security events kept)
  • Local incident report
  • PHP end-of-support checks
  • Email notification of new incidents from your own site
  • Known-vulnerability data for plugins and themes
  • Off-site evidence
  • External probe
  • Alerts that work when the site is down
  • AI analyst
  Download↓ Download↓
• Recommended

  Solo

  €7per monthBilled €7 every month. Cancel at any time.€69per yearSaves €15 against monthlyBilled €69 once a year — €5.75 a month.

  Up to 3 sites

  Everything that needs something outside your server — so an incident still reaches you when the site is down.

  • Everything in Free
  • Off-site copy of findings and the activity journal
  • External liveness probe, so a site that goes quiet is noticed
  • Email notifications, and a webhook to any https endpoint
  • Known-vulnerability data for plugins and themes
  • Alerts when your site stops reporting at all
  • Known-exploited catalogue (CISA KEV) alongside the advisory data planned
  • AI-assisted incident analysis planned
  • Retention guarantees for the off-site copy planned
  • Fleet dashboard
  • Autopilot mode
  • Host agent
  Subscribe monthly → Subscribe yearly →

• Agency

  €29per monthBilled €29 every month. Cancel at any time.€290per yearSaves €58 against monthlyBilled €290 once a year — €24.17 a month.

  Up to 10 sites · €2 per additional site

  When the same incident repeats across a portfolio and has to be reported to someone.

  • Everything in Solo
  • Up to 10 sites on one subscription
  • Client organisations, so sites are filed under the customer who owns them
  • Three team roles, with read-only membership
  • Site transfer between agencies, as a two-party handshake
  • Fleet dashboard and bulk actions planned
  • Fleet-wide policy planned
  • Autopilot and lockdown modes planned
  • Client-branded PDF reports planned
  • Pooled AI-assisted analysis planned
  • API access planned
  • Host agent
  • SSO
  Subscribe monthly → Subscribe yearly →

• Business

  from €149per monthFrom €149 a month, depending on the number of sites and the terms.negotiatedper yearAnnual terms are agreed with the contract, including the DPA and support response.

  From 100 sites

  Server-level coverage, contractual terms and named support.

  • Everything in Agency
  • Dedicated rule requests
  • Terms, availability and support response agreed in the contract
  • Host agent (server visibility) planned
  • Hosting and Cloudflare integrations planned
  • SSO and role-based access planned
  • Evidence escrow planned
  • Extended retention, agreed with the contract planned
  Subscribe monthly → Talk to us→