In April 2016, reporters began publishing stories from 11.5 million documents taken from Mossack Fonseca, a Panamanian law firm that set up offshore companies for clients around the world. The Panama Papers ran to 2.6 terabytes and 4.8 million emails. Within days, the leak had brought down the prime minister of Iceland.
Then people looked at the firm's websites. WIRED found a client portal running a version of Drupal last updated in August 2013, and webmail last updated in 2009. "They seem to have been caught in a time warp," one security professor told the magazine. Wordfence found the firm's main WordPress site running Revolution Slider 2.1.7, an image slider plugin with a flaw that let anyone upload and run code. A working exploit had been public since October 2014.
Nobody has ever shown how the documents left the building. WIRED noted that the exact flaw used wasn't known. Wordfence called the slider a "possible cause," and laid out how an attacker could have gone from the website to the mail servers sitting on the same network. It was a theory, and they labeled it one.
The theory stuck because nothing in it was hard. A flaw like that doesn't need anyone to pick a target. Automated scans sweep huge numbers of sites looking for it, and whoever answers gets hit, a global law firm or a food bank.
The bots got faster
Ten years later, the gap between a public flaw and an attack is shorter than a workday. Patchstack's 2026 report found that the most heavily attacked WordPress flaws of 2025 drew their first exploit attempts a median of five hours after disclosure. About half of the high-impact ones were under attack within a day. Forty-six percent of all the vulnerabilities it tracked had no fix from the developer when they went public.
Old flaws don't retire, either. Only four of the ten most attacked WordPress vulnerabilities in 2025 were published in 2025. Number six was a 2024 flaw in GiveWP, a donation plugin on more than 100,000 sites, rated the maximum 10.0. Wordfence reported it to the developer in June 2024, got no reply, and escalated it to WordPress.org three weeks later. The fix shipped in August 2024. Attackers were still working it hard enough through 2025 to make the top ten.
None of that requires anyone to care about your organization. It requires your site to answer a bot. Most of what decides whether it answers is checkable, and you can check it in about 20 minutes.
1. Confirm the updates ran, all the way down
Log in and go to Dashboard, then Updates. WordPress core, plugins, and themes should all be current. If anything is waiting, find out why. Sometimes a plugin is held back on purpose because an update broke something. Sometimes nobody noticed.
Don't take automatic updates on faith. When the "wp2shell" flaws hit WordPress core in July 2026, letting an attacker with no account create an administrator, WordPress pushed the fix automatically. Rapid7 still told admins to confirm that every site had upgraded. In October, when WordPress 7.1.4 fixed a flaw in the update process itself, Wordfence's firewall rule for it saw its first attack nine minutes after going live.
Then go one layer lower. Under Tools, then Site Health, then Info, open Server and find your PHP version. PHP is the language WordPress runs on, and most site owners have never looked at theirs. About one in three WordPress sites runs PHP 8.1 or older, according to WordPress.org's own stats. All of those versions are past end of life. PHP 8.2 joins them on December 31, 2026.
This stopped being theoretical in October. Two critical PHP flaws known as PHP2Shell let attackers run code on some servers without logging in, and CISA told organizations on PHP 8.1 or older to take those systems offline until they could patch or upgrade. If you're on an old version, ask your host two questions. Does our build include the October 21, 2026 fixes? When can we move to a supported version?
2. Delete plugins you don't use
Go to Plugins and look at what's installed. Every plugin is someone else's code, running with your site's permissions. Patchstack found that 91 percent of new WordPress vulnerabilities in 2025 were in plugins. In one October week alone, Wordfence logged 268 new vulnerabilities across 182 plugins and 15 themes.
Deactivated plugins still sit on the server. If nobody can say what a plugin does, it should probably go.
Two kinds deserve a closer look. Premium plugins and themes, the paid ones, had three times as many known exploited vulnerabilities as free ones in Patchstack's count, partly because fewer researchers can see their code. Plugins that connect to outside services hold keys to those services. Attackers made more than 17 million attempts against a flaw in Gravity SMTP, an email plugin, that could expose email API keys and tokens. The flaw was rated medium. The keys it leaked were not.
3. Check who has admin access, and don't trust the screen
Go to Users, filter by Administrator, and ask three questions:
- Do we recognize every name?
- Does every one of these people still work with us?
- Does each person need admin access, or would Editor do?
Former staff, old agencies, and one-time contractors tend to keep access for years. Remove anyone who doesn't need it.
Then know that the screen can lie. This fall, two separate attacks created administrators that don't show up there. One hid its account through a form plugin flaw. The other came through stolen keys for a site management service, and its plugins could hide users from the Users screen. TeamUpdraft, the company behind that service, recommends listing administrators with WordPress's command line tool, with plugins switched off: wp user list --role=administrator --skip-plugins. If you don't use the command line, ask your host or developer to run it and compare the result with what you see.
4. Turn on two-factor login
Two-factor login asks for a code from your phone along with your password. A stolen password alone stops working.
The October attack on UpdraftCentral showed why this matters even after a cleanup. Nethemba, the firm that spotted it, found that the backdoor created an account with a known password, and the account stayed after the backdoor was removed. The attacker could log in through the normal login form "unless two-factor authentication is enabled for that account."
There are several free plugins that add it. Start with administrators and editors.
5. Test a restore, from far enough back
Most hosts say they back up your site. Fewer customers have ever restored one. Ask your host or developer to restore a recent backup to a staging site and confirm that it works.
Then ask how far back the backups go. After the UpdraftCentral breach, TeamUpdraft's advice to anyone who found a compromise was to restore from a backup taken before October 17, the start of the incident. On some sites, a plugin the attacker left behind sat quietly and was used later, after the site had been disconnected. A backup is only useful if it reaches back past the day something went wrong, and you may not know that day yet.
A backup you have never restored is a guess. We wrote more about this in What we check before we trust a WordPress backup.
6. Look at your forms, and at what's still connected
Forms are the front door of most nonprofit and B2B sites. Donations, applications, event sign-ups, and contact requests all come through them. They're also a way in.
In August 2026, attackers went after a flaw in Elementor Pro's form uploads the same day the fix came out, with about 190,000 blocked attempts in the first five days. In October, attackers hid scripts inside form submissions that ran when a staff member opened them. So look at your forms and ask:
- Do we collect anything we don't use?
- Does any form accept file uploads it doesn't need?
- Are old submissions still stored in WordPress or a plugin?
- Who can read them?
Then look for what you forgot you had. When the Archives & Records Association was breached this fall, the attackers reached a database attached to the association's old website, retired in 2021, with records going back to 2013. Old submissions, old sites, and old databases are all exposure with no upside. Delete what you don't need, and take retired sites offline.
If this sounds like a lot
By the time the Panama Papers became public, the exploit for Mossack Fonseca's slider had been posted for about 18 months. We'll never know if that's how the documents left. Closing that door took one plugin update either way.
This check takes about 20 minutes once you know where to look. Doing it every month is harder, and that's the work that matters. If you'd rather hand it off, our WordPress care covers it. If you aren't sure what you'd find, get in touch and we'll take a look.
Common questions
How often should we run this check? Once a month, and again any time a big WordPress or PHP security release comes out.
How do I find out which PHP version my site runs? In WordPress, go to Tools, then Site Health, then Info, and open the Server section. As of November 2026 the supported versions are PHP 8.2 through 8.5, and 8.2 reaches end of life on December 31, 2026.
Do we need a security plugin? A firewall can help, but it doesn't replace updates. In 2025 testing by Patchstack, which sells its own protection, common tools such as server firewalls and Cloudflare blocked only 12 percent of attacks on known exploited WordPress vulnerabilities.
What if we find an admin account we don't recognize? Don't delete it and move on. Treat the site as compromised, change every admin password, and get help checking for backdoors. Recent attacks left hidden accounts and files that survive a simple cleanup.
