In July 2026, WordPress released an important security update. Researchers began seeing real attempts to exploit the vulnerabilities roughly 90 minutes after the updated version became available.
Ninety minutes.
That’s barely enough time to notice a security alert, understand what it means, and contact the person who manages your website.
That’s probably a very different picture of website security than most nonprofit leaders have in mind. Security is often understood as something that matters in a general sense. You know passwords should be strong. You know software should be updated. You know getting hacked would be bad.
What is harder to see from the outside is how fast the threat has become.
Unless you spend your spare time reading security forums and Reddit threads about the latest exploits, this shift probably happened without you noticing. That isn’t because you weren’t paying attention. Your job is running a nonprofit, not tracking how quickly attackers can reverse-engineer a software update.
But the internet is not the internet most people still picture. If your security plan begins when the alert arrives, it begins too late. The monitoring, protection, backups, and people responsible for responding need to be in place before the clock starts.
On July 17, WordPress released version 7.0.2 to address one critical and one high-severity security issue. The problems affected specific recent versions of WordPress and, when combined, could allow an attacker to take control of a vulnerable website.
WordPress recommended that affected websites update immediately. Because of the severity, the WordPress security team also used its automatic update system to push the fixes to affected sites that supported background updates. Fixes were released for multiple supported versions, not only the newest one. WordPress documented the release and affected versions.
The surprising part was what happened next.
Patchstack, a security company specializing in WordPress vulnerability protection, detected the first real exploitation attempts roughly 90 minutes after WordPress 7.0.2 was released. Over the following days, Patchstack blocked more than 65,000 attempts against websites that were still running vulnerable versions. Those attempts came from more than 1,500 IP addresses. Patchstack published a detailed account of the campaign.
There’s some important context here. These were blocked attempts. But the window had opened. Attackers were already looking.
When people imagine a website attack, they often picture a person sitting at a computer and selecting an organization to target.
That still happens. But a large share of the activity hitting websites today is automated. Software can scan huge numbers of sites, identify the versions they appear to be running, and test them for a newly disclosed weakness.
The attacker may not know your organization’s name. They may not know what your nonprofit does. They may not care whether your annual budget is $500,000 or $500 million.
They’re just looking for a door that opens.
That’s unsettling, but it also helps explain the risk more honestly. Your nonprofit doesn’t need to be famous, controversial, or wealthy to receive malicious traffic. At the same time, seeing an attack attempt does not mean someone has singled you out. Much of this activity is opportunistic and indiscriminate.
Being small is not protection. But there’s also no reason to panic every time a firewall blocks something. That’s just part of the game now.
No software platform can honestly promise that it will never have a vulnerability. Websites, operating systems, browsers, email platforms, donation systems, and customer databases all receive security updates.
WordPress attracts attention because it is widely used and can be extended in thousands of different ways. That gives researchers and attackers plenty of reason to study it closely.
But this incident also shows the security process working.
Researchers found the problems. The vulnerabilities were reported. WordPress released fixes for affected versions, recommended immediate action, and enabled forced automatic updates because of the severity. Hosting providers and security companies were able to add additional protection while sites updated.
The lesson is that WordPress, like any important software, needs active care.
That distinction matters. A website should not be thought of as something that gets built, launched, and left alone for the next five years. It changes. The software underneath it changes. The tools connected to it change. The threats change too.
See content credentials
The obvious answer is to install security updates immediately.
And yes, that matters. WordPress supports automatic background updates, and security releases are enabled automatically on most sites. WordPress strongly discourages disabling them because timely updates are one of the most effective ways to keep a site protected. WordPress explains how its automatic update system works.
But “update immediately” becomes more complicated when a website depends on a custom theme, donation integration, event system, CRM connection, or other tools that also need to keep working. Some updates should be tested. Sometimes an update fails. Sometimes automatic updates have been disabled without the organization realizing it.
And sometimes 90 minutes simply is not enough time for a human being to see an alert, understand it, test the fix, and install it.
That’s why website security needs layers.
This is why we take a layered approach to security for the websites we manage. Cloudflare filters suspicious traffic before it reaches the server. A second web application firewall (WAF) provides protection at the hosting level. Wordfence works inside WordPress to scan the site, monitor known vulnerabilities, and block WordPress-specific threats.
We also keep recoverable backups and monitor websites for unexpected changes or downtime. Straightforward plugin updates can happen automatically, while more complex plugins and integrations follow a separate plan so they can be reviewed and tested without creating new problems.
Each layer has a different job. None of them can stop everything on its own. Together, they reduce the chance that one missed update or failed defense becomes a larger problem.
Security is not one setting. It is a system.
Nonprofit leaders do not need to learn how to analyze attack traffic or install emergency WordPress patches themselves.
They do need to know that someone is responsible for it.
Here are the questions I would ask whoever manages your website:
You don’t need a deeply technical answer to every question. You just need a clear answer that shows there is an actual process.
“We update things when someone remembers” is not a process 😂
See content credentials
Ninety minutes. It’s a soccer match. A movie. One trip around the Earth aboard the International Space Station. A long staff meeting…
That’s all the time that’s needed from when a major security update comes out to when attackers can start to exploit it.
The good news is that your Communications Director or Executive Director doesn’t need to monitor security feeds or become a website security expert. Your organization just needs someone keeping an eye on the website with a plan to protect and react if something happens.
And then you can get back to watching movies or soccer matches in staff meetings while the ISS circles the world – knowing that your website is okay 🍿
