Skip to main content
90% of hacked CMS installs run WordPress

WordPress Security

Your firewall is a free plugin and the admin password hasn't changed since launch. Most hacked WordPress sites looked exactly like this first. WordPress security done properly lives in the infrastructure, and that's where we put it.

Hacked WordPress site?
You have plenty of company

WordPress dominates the hacked-CMS numbers, but the platform itself is rarely the culprit. The real pattern is operational. Plugins get left to rot, admin passwords get recycled from other services, and a firewall never makes it onto the setup at all.

The case files all look alike. An agency shipped the site and moved on; two years later nobody can say when a plugin was last updated. Three of them carry publicly documented CVEs. The contact form quietly delivers to a Gmail inbox nobody opens, and the login page faces the open internet with no second factor protecting it. Nobody is watching any of it.

The owner finds out last. Google flags the domain as deceptive in search results, and by the time anyone thinks to read the server logs the intruder has been inside for weeks.

90%

Share of hacked CMSes running WordPress

847

Attacks our WAF blocked in the last 30 days

<30min

Guaranteed response on critical incidents

24/7

Monitoring, all year round

WordPress security at every layer

A security plugin protects only the application it runs inside. We put the protection in the layers around it instead, from the container up to the network edge where traffic arrives. All of it is wired in from the very first deploy.
01 / 04

Web Application Firewall

SQL injection and XSS get rejected at the network edge, before a request ever touches WordPress. This runs on dedicated infrastructure rather than as one more plugin in the stack.
02 / 04

Two-Factor Authentication

Admin access requires a second factor, full stop. Brute force bots hammer login pages around the clock, and given enough attempts a password alone will eventually lose.
03 / 04

Isolated Containers

Each site runs in its own container with its own IP address. A compromised neighbour stays the neighbour's problem.
04 / 04

Automated Security Updates

Core and plugin updates roll out automatically via WP-CLI, with a staging pass first and production after. Nothing depends on someone remembering.

Every update
earns its deploy

Outdated plugins top the list of reasons WordPress sites get hacked. Second place stings more. Updates applied in good faith, straight to production, that take down a checkout or a booking form on the other side of the site.

That second problem is the one our pipeline exists to prevent. Every update lands first in a staging copy of the live site, never anywhere near production until it has earned its place there. Automated checks drive the contact forms and walk through the checkout exactly as a customer would, while a visual regression suite diffs screenshots pixel by pixel to catch any layout the change quietly broke. Promotion to production happens only on a fully green run, so nobody ships on a Friday afternoon and spends the weekend hoping.

The attacks we block, day in and day out

Attackers rarely improvise. The same handful of techniques shows up in our logs every single day:

  • SQL injection probing search fields, comment forms and exposed URL parameters
  • Brute force runs against wp-login.php and xmlrpc.php, often from botnets
  • Cross-site scripting (XSS) through inputs that were never validated
  • File inclusion attempts pulling malicious payloads from external servers
  • Direct requests for wp-config.php and other files that should never be public
  • Traffic floods (DDoS) aimed at knocking the site offline

Backups you can
actually restore

Every hosting contract promises "daily backups". Very few people have ever watched one of those backups actually restore. A backup that has never been through a restore is just a folder of hope, and ransomware operators do not negotiate with hope.

Our snapshots cover the full infrastructure every night: the database, the files, and the server config wrapped around them. Everything is AES-256 encrypted and replicated across EU regions. We rehearse restores on a schedule, because the worst moment to learn the procedure is during an incident with the clock running.

Rolling back takes less than ten minutes, ticket queue not included.

Six things we never stop scanning

01 / 06

WordPress Core

Every install is checked against the latest core release. Critical security patches trigger an alert within hours of publication.
02 / 06

Plugin Vulnerabilities

Daily lookups against the WPScan Vulnerability Database. A matching CVE means the plugin gets patched immediately.
03 / 06

File Integrity

Hash checks run against every core file. Any change that arrives without a deploy behind it trips an automatic alert.
04 / 06

SSL and Security Headers

Certificate validity, HSTS, CSP and X-Frame-Options are watched continuously. Expiry never arrives as a surprise.
05 / 06

User Accounts

Dormant accounts are flagged before they become a liability, and weak passwords never make it past validation. Each admin login leaves an IP-stamped, timestamped record.
06 / 06

Malware Scanning

All files are matched against known malware signatures. Anything suspicious is quarantined on the spot.

Hacked anyway?
We measure response in minutes

After a break-in, speed decides the outcome. Google can blacklist a domain within hours, and a blacklisted domain keeps bleeding customers long after the malware itself is gone.

Suspicious activity pages our on-call team directly. On critical incidents, response time is typically under 30 minutes from the first alert to a human actively working the problem. The priority order rarely changes. We seal the site off so the attacker loses their foothold, bring it back from the last verified-clean snapshot, then run a forensic pass through the logs until the precise entry point is identified and permanently shut. That last step is what stops the same break-in from happening twice.

Compare that with the 24-hour response window most hosts call an SLA, assuming they bother to offer one at all.

Security plugin versus infrastructure

Free plugin
Firewall placement
Application level
Update handling
Manual
Active monitoring
Limited
Backup approach
Plugin-dependent
DDoS mitigation
No
Incident response time
No SLA
Site isolation
No (shared server)
Two-factor (2FA)
Optional
PXL security
Built for business
Firewall placement
Infrastructure level (WAF)
Update handling
Automated with testing
Active monitoring
24/7 proactive
Backup approach
Infrastructure snapshot
DDoS mitigation
Network level
Incident response time
<30 min guaranteed
Site isolation
Yes (dedicated)
Two-factor (2FA)
Required for admin

GDPR and Norwegian requirements, handled

01 / 04

Data Storage in the EU

All of it stays in European data centres, and nothing crosses into a third country without a data processing agreement signed first. That is the standard Datatilsynet, the Norwegian DPA, holds Norwegian businesses to.
02 / 04

Logging and Traceability

Every admin action is logged with the user behind it, plus IP and timestamp. When a GDPR request lands, the evidence already exists.
03 / 04

Encrypted Communication

HTTPS everywhere, with certificates renewing automatically through Let's Encrypt. HTTP/2 and HTTP/3 are on by default, and unencrypted traffic simply has no route in.
04 / 04

Access Control

Permissions follow the least-privilege principle, so an editor can publish content but never touch the plugin directory. Access creep has nowhere to start.

Six signs your site is exposed

Count how many of these apply, honestly:

  • The plugin list hasn't been touched in over three months
  • Admin accounts have never had two-factor authentication
  • Nobody can say for certain who has wp-admin access
  • The hosting agreement mentions neither WAF nor DDoS protection
  • No backup has ever been through an actual restore
  • Google noticed your last security incident before you did

Three or more? Get someone qualified onto it soon. Our maintenance plan covers every item above.

WordPress security, the do-it-yourself version

  1. 01

    Apply security patches to core, themes and plugins the day they're released

  2. 02

    Turn on two-factor authentication for every admin account

  3. 03

    Delete unused plugins and themes, because deactivated code is still attack surface

  4. 04

    Rate-limit or otherwise shield wp-login.php from brute force

  5. 05

    Switch off XML-RPC unless something genuinely depends on it (rarely anything does)

  6. 06

    Put a WAF in front of the server rather than trusting a plugin alone

  7. 07

    Run one real restore from backup so you know the procedure works

  8. 08

    Watch file integrity so unauthorized changes surface automatically

Frequently asked questions

SB
CG
JB
About us

How is your WordPress security holding up?

Send us the URL and we'll come back with a short, concrete list of what needs closing. No sales pitch attached.