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.
Share of hacked CMSes running WordPress
Attacks our WAF blocked in the last 30 days
Guaranteed response on critical incidents
Monitoring, all year round
WordPress security at every layer
Web Application Firewall
Two-Factor Authentication
Isolated Containers
Automated Security Updates
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
WordPress Core
Plugin Vulnerabilities
File Integrity
SSL and Security Headers
User Accounts
Malware Scanning
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
GDPR and Norwegian requirements, handled
Data Storage in the EU
Logging and Traceability
Encrypted Communication
Access Control
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
- 01
Apply security patches to core, themes and plugins the day they're released
- 02
Turn on two-factor authentication for every admin account
- 03
Delete unused plugins and themes, because deactivated code is still attack surface
- 04
Rate-limit or otherwise shield wp-login.php from brute force
- 05
Switch off XML-RPC unless something genuinely depends on it (rarely anything does)
- 06
Put a WAF in front of the server rather than trusting a plugin alone
- 07
Run one real restore from backup so you know the procedure works
- 08
Watch file integrity so unauthorized changes surface automatically