Attackers now exploit new website vulnerabilities within hours, and this summer even trusted plugins’ own update systems were used to break into websites. No website manager can honestly promise your site will never be hacked. This post explains why, sets out the realistic options for reducing the risk, and shows how to make sure that if the worst happens, there’s little worth stealing.
Why “when, not if”
If your website runs WordPress, the question is no longer whether someone will try to break into it. They already are, probably several times a day. The real question is what happens when one of those attempts succeeds.
That may sound alarmist, but look at who gets breached. In April 2025, the Legal Aid Agency discovered a cyber attack on its online services. The attackers downloaded personal data from people who had applied for legal aid between 2007 and May 2025, including criminal histories and financial details. This was a government agency, working with the National Cyber Security Centre, with far more resources than any chambers or law firm.
Most attacks on websites aren’t even that personal. They’re automated: software scans the internet for any site running a vulnerable version of a plugin, and tries its luck. You don’t need to be a target to be hit. You just need to be running the wrong version on the wrong day. And attackers are now using AI to find and exploit weaknesses faster than ever.
Plugins: the strength and the weak spot
Plugins are what make WordPress so capable. As we explained in our post on plugins, they let you add events listings, member directories, publications, search and much more without building everything from scratch.
But every plugin is code written by someone else, and every plugin adds to what security people call your “attack surface”. According to Patchstack’s 2026 security report, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, up 42% on the year before, and 91% of them were in plugins. WordPress itself is not immune either: a serious flaw in WordPress core was being exploited on 22 September 2026, the same day the fix was released.
The standard advice is simple: keep everything updated. We do, and so should you. But recent events show why updating on its own isn’t enough.
The update catch-22, in three recent examples
Update, or be hacked: Pods (August 2026). Pods is a popular plugin, used on more than 100,000 sites, for creating custom content such as barrister profiles or case listings. In August a critical flaw was disclosed, rated 9.8 out of 10, which let attackers with no login at all reach administrator functions and take over a site. The developers worked round the clock and released fixes on 14 August for every version back to 2.8. Sites that updated quickly were safe. Sites that didn’t were exposed.
Update, and be hacked: Admin Menu Editor Pro (September 2026). On 14 September, someone broke into the developer’s own website and uploaded a poisoned version of the plugin as a routine update. For about seven hours, any site that installed it received a hidden administrator account and a backdoor. At least 1,500 sites were affected. The developer released a clean version the same day, and the attacker poisoned that one too. Here, the sites that updated promptly were the ones that got hacked.
Neither: BdThemes (August 2026). A month earlier, attackers compromised the servers of BdThemes, which makes several popular page-builder add-ons. They didn’t need to touch any update. Instead, they tampered with a promotional feed the plugins loaded inside the WordPress dashboard, which created rogue administrator accounts when a site’s admin logged in. Security researchers linked the same attacker to earlier compromises of two other plugins.
So updating quickly protects you from one kind of attack, exposes you to another, and makes no difference to a third. To make matters worse, speed matters enormously. Patchstack found that for the most heavily targeted vulnerabilities, attackers typically start exploiting them within five hours of disclosure. And 46% of vulnerabilities were made public before any fix was available at all.
Why vigilance alone isn’t enough
So how does anyone decide whether to update? A good website manager watches security alerts, reads the WordPress news, and reacts quickly. We do all of that. But we’d be misleading you if we claimed it was foolproof.
A typical site runs 20 to 40 plugins, and an agency looks after hundreds of different ones across its clients. Alerts arrive at 3am, at weekends and during the summer holidays. People sleep, fall ill and take time off. Five hours is not a long window.
Automated protection helps fill the gaps. Services such as Patchstack and Wordfence can block known attacks at the firewall, sometimes before a fix is even released, and can update vulnerable plugins automatically. We use these tools and recommend them. But they aren’t instant or complete either: free security tools often receive new protection rules weeks after paying customers, and no firewall can block an attack nobody has seen yet.
Reducing the risk: your options and their trade-offs
There’s no perfect answer, but there are several ways to shift the odds in your favour. Most sites benefit from a combination.
- Separate the public website from WordPress (“headless” WordPress). Your team keeps editing content in WordPress exactly as now, but WordPress itself sits on a private address that only your office can reach. A tool called a static site generator turns your content into plain web pages, and that’s all the public ever sees. With no WordPress code running publicly, there’s very little for attackers to exploit. The trade-off: anything interactive, such as search, forms, filtering or members’ areas, has to be rebuilt using separate services, and changes take a few minutes to appear. It suits brochure-style sites well, and portals or complex search less so.
- Move to a different content management system. Less popular platforms attract less attention from attackers, but you lose functionality and the huge community that improves WordPress every day. Other systems have serious vulnerabilities too: Drupal’s “Drupalgeddon” flaws in 2018 are a well-known example. Obscurity is not security.
- Use fewer plugins. Remove anything you’re not using, and replace simple plugins with a few lines of custom code where it makes sense. Be realistic, though: the powerful plugins you can’t easily replace are exactly the ones attackers find most attractive.
- Choose plugins carefully. Favour well-maintained plugins from developers with a good security record. This helps, but it’s worth noting that both Pods and Admin Menu Editor had good reputations.
- Build layers of defence. No single measure is enough, so combine them:
- a web application firewall and virtual patching, which block known attacks before they reach the site
- two-factor authentication for every account that can log in
- restricting the WordPress dashboard to known IP addresses where practical
- hosting that keeps each site in its own isolated container
- file-change monitoring and daily malware scans, to spot an intrusion quickly
- regular security audits, not just a one-off check at launch
Plan for the breach: make sure there’s little to steal
If you accept that a breach is possible, the most powerful question becomes: what would an attacker find? A defaced homepage is embarrassing. Leaked enquiry forms containing clients’ personal details are a regulatory and reputational problem. The Legal Aid Agency breach hurt so much partly because the data stretched back 18 years.
The good news is that reducing the damage is often cheaper and more reliable than preventing every attack.
- Don’t collect what you don’t need. Every form field is a liability. If a contact form only needs a name, email address and brief outline, don’t ask for more.
- Don’t keep it for long. Set a retention policy and have form entries deleted automatically, say after 30 days. The email notification is your working copy, and the website keeps a short-term backup in case an email goes astray (see our post on data retention for why that matters).
- Encrypt sensitive data. Passwords should always be securely hashed, and other non-public data can be encrypted in the database. Be aware that if the encryption key sits on the same server, a full compromise may expose both, so encryption helps most against partial leaks.
- Keep secrets out of reach. Keys and passwords for connected services, such as email sending or payment systems, should be stored securely and changed after any incident.
- Keep logs somewhere safe. An activity log shows what happened and whether data was accessed, but an attacker with admin access can delete a log stored on the site itself. Sending logs to a separate service keeps a trustworthy copy.
- Have backups you’ve actually tested. Keep them off the server, and check that you can restore from them.
- Write an incident plan now. Decide who you’ll call, who makes decisions, and who tells clients. Under UK GDPR, a reportable personal data breach must be notified to the ICO within 72 hours of becoming aware of it, which is very little time to work out who does what.
A safer way to collect confidential information
For most chambers and firms, the simplest rule is this: the website form collects contact details and a brief outline only, and anything confidential moves to a more secure channel.
If your organisation uses Microsoft 365, one easy option is a OneDrive file request. You email a link to the person, and they can upload documents without needing a Microsoft account. They can only upload, so they can’t see the folder, other people’s files or anything else. Two things to note: your IT administrator needs to allow this type of link, and we recommend sending a fresh link for each enquiry rather than publishing one on your website, since anyone with the link can upload.
Many practice and case management systems also offer secure client portals, and there are dedicated secure file-transfer and encrypted email services widely used in the legal sector. Whichever you choose, the principle is the same: keep confidential material off your public website.
What good website security actually involves
We want to be straightforward about this. Keeping a WordPress site secure is not a single task that can be ticked off. It’s an ongoing combination of tools, monitoring, expertise and people’s time, and the threat keeps changing.
A basic maintenance plan that runs automated plugin updates is valuable, and every site should have one. But it isn’t the same as a security programme. Firewalls and virtual patching cost money. Security audits, reviewing logs, removing unneeded plugins, rebuilding features in custom code and planning for incidents all take skilled time. No agency can make any site perfectly secure, and one charging a modest monthly fee cannot realistically provide round-the-clock security cover.
The right level of protection depends on what your site does and what it holds. A simple brochure site with no forms needs far less than one handling enquiries about sensitive legal matters. The important thing is to make that decision deliberately, rather than discovering the gap after a breach.
What to do now
Be proactive rather than reactive. You or your agency can make real progress this month. If an agency manages your site, many of these are questions to ask them rather than jobs to do yourself:
- Review every plugin on the site and remove any that aren’t needed
- Check what your forms collect, and stop asking for anything unnecessary
- Make sure form entries are deleted automatically after a set period
- Make sure two-factor authentication is switched on for every user
- Confirm the site has a firewall and vulnerability monitoring
- Confirm there are off-site backups, and that someone has tested a restore
- Agree a simple incident plan with your agency, including who contacts the ICO
- Book a security audit, and repeat it regularly
If you’d like a second opinion on your website’s security, whether or not we manage it, get in touch. We’re happy to talk it through.
Sources and further reading
- Patchstack, State of WordPress security in 2026
- Pods, Pods 3.3.9.1 security release and backported releases
- Wordfence, Pods <= 3.3.9 unauthenticated privilege escalation
- Admin Menu Editor, Security incident affecting customers 2026-09-14
- BleepingComputer, Malicious Admin Menu Editor Pro plugin backdoors 1,500 WordPress sites
- BleepingComputer, BdThemes plugins supply-chain hack creates rogue WordPress admins
- SecurityWeek, Critical WordPress vulnerability exploited immediately after disclosure
- GOV.UK, Legal Aid Agency data breach
