Securing a 44-site publishing network in 14 days.
- Client
- Japan-based digital publisher running content, review and e-commerce sites (names withheld)
- Platform
- WordPress (42 sites) and Plikli (2 sites) on one shared server, behind Cloudflare
- Period
- 7–20 October 2026
- Product
- Cyber Securitise (plugin + fleet dashboard)
At a glance
| Sites protected | 44 (7 at the start, 37 added on day 13) |
|---|---|
| Malicious and abusive requests blocked | 5,103 |
| AI training-crawler requests turned away | 35,349 |
| Disguised scrapers stopped | 47,524 |
| Known vulnerabilities found | 290 across 25 sites |
| Hacked site found and cleaned | 1 (pharmacy spam injected into a live article) |
| Dangerous hosting leftovers removed | 20 files on 6 sites |
AI-crawler, scraper and agent counts come from each site's rolling 30-day report; all other figures are for the 14-day period.
The challenge
The publisher runs dozens of WordPress sites that earn from search traffic, display ads and affiliate links. Each site had been built and maintained separately over several years, some after moves between hosting companies. There was no single view of which plugins were installed, which were vulnerable, or whether any site had already been compromised. AI companies' crawlers were copying content at scale, and automated attacks hit every site daily.
What Cyber Securitise found
A site that was already hacked
The dashboard's database scan flagged an existing restaurant-menu article on one site that had been injected with French-language pharmacy spam ("buy Cialis without a prescription"), invisible to the editors but served to visitors and Google. The spam was removed the same day, and the site's outdated page-builder plugin, which had a known unauthenticated stored-scripting flaw, was identified as the likely way in.
290 known vulnerabilities on 25 sites
Every installed plugin and theme version was matched against vulnerability intelligence (Wordfence, CISA's Known Exploited Vulnerabilities catalog, GitHub/OSV advisories). Highlights:
- An auto-republishing plugin with no available fix was installed on 17+ sites; it was switched off fleet-wide and removed.
- An abandoned AI-checker plugin (no fix) on 5 sites and several unmaintained editor add-ons were switched off.
- Outdated premium SEO, caching and theme components were listed for vendor updates.
- When a supply-chain compromise of a popular premium SEO plugin was announced, the fleet was checked within minutes: no site ran the infected version, and an alert now fires automatically if any site ever reports it.
- Old code libraries bundled inside backup and indexing plugins were traced to the plugin that carries them, so the fix is one update instead of guesswork.
Dangerous leftovers from previous hosts
A sweep of each site's web folder turned up 20 files that should never have been public, including:
- a backup copy of a site's configuration file containing its database password;
- public scripts that let anyone clear the server's PHP cache;
- connectors and firewall files left behind by a previous security service.
All were moved out of the web folders (kept in a private backup), with no change to how the sites work.
Gaps in day-to-day security
The first fleet scan showed where the network was exposed: administrators without two-step sign-in on 40 sites, default "admin" usernames on 14 sites (one username was already being targeted by password-guessing from a dozen addresses), 41 sites carrying unused plugins, and 4 sites whose configuration file was readable by other accounts on the server.
What Cyber Securitise blocked
In 14 days the firewalls rejected 5,103 malicious or abusive requests:
| Attack type | Blocked |
|---|---|
| Malformed requests from automated scanners (OWASP Core Rule Set protocol checks) | 2,896 |
| Traffic from hijacked networks on the Spamhaus DROP list | 736 |
| Bots from data-centre networks trying to reach login pages | 611 |
| File-inclusion and path-traversal attempts (reading server files) | 363 |
| SQL injection | 215 |
| Remote command and PHP code injection | 183 |
| Tor and anonymous-VPN traffic on login pages | 21 |
The plugin also refused 17 targeted attempts to download secrets, such as database dumps, old configuration backups and even a server's private SSH key, and locked out 73 password-guessing attempts, including distributed attacks spreading guesses across many addresses.
Keeping content out of AI training
With AI Shield on, the network turned away 35,349 requests from AI training crawlers while still letting AI search assistants read and cite its pages. A further 47,524 disguised scrapers (bots pretending to be browsers) were stopped, and 13,474 AI-agent visits were identified and rate-limited rather than blocked, so legitimate agent traffic keeps working.
What changed across the network
From the single dashboard, without logging in to each site:
- The firewall moved from monitoring to blocking on all 42 WordPress sites, with data-centre, Tor and VPN traffic blocked on login pages, while the publisher's CMS, publishing tools and AI writing assistant kept working.
- XML-RPC switched off, version-revealing files hidden, debug logs blocked and configuration-file permissions tightened, network-wide in one step.
- Vulnerable plugins can now be updated in one click (or all at once), with an automatic health check that rolls back a plugin if it breaks a page.
- Alert email was cut from per-event messages to one security digest per account, twice a day, carrying only what needs a person.
Lessons and what we improved
Onboarding 37 sites in one afternoon surfaced things we have since fixed in the product:
- False alarms on real-world content. The first scan flagged ordinary images, embedded social posts and ad scripts. The detection rules were tightened the next day and every rule change now has to pass a test set built from real false alarms.
- Safer roll-outs. Two plugin defects reached the whole fleet at once during the rollout. Updates now go to a few test sites first, wait for clean health checks, and only then reach everyone; new detection rules start in log-only mode.
Results
Within two weeks the publisher went from no central view to a fully monitored network: one confirmed compromise found and cleaned, hundreds of known vulnerabilities identified with a clear fix for each, dangerous leftovers removed, thousands of attacks blocked every week, and its content kept out of AI training sets, all managed from one dashboard.
Figures are taken from the Cyber Securitise dashboard for the period stated. Site names are withheld at the client's request.