A critical PHP flaw puts nonprofit WordPress sites at risk worldwide
PHP shipped an emergency fix for two flaws that let attackers take over a website’s server without logging in. Governments took their own sites offline rather than wait. Updating your plugins won’t help.
October 21, 2026Last updated October 21, 2026
Picture a nonprofit whose website was built on WordPress a few years ago. A volunteer set it up, or a staff member who has since moved on. The donate button works. The plugins update themselves, so the site feels looked after. Nobody has logged into the hosting account in years, and nobody is sure who has the password.
That site is the kind most exposed right now.
On October 21, PHP released emergency fixes for two critical security flaws. PHP is the programming language WordPress runs on, and it runs about 7 in 10 websites. Researchers at Wiz and Calif found the flaws and named them PHP2Shell. Both let an attacker run their own code on a website’s server with a single request, without a password. Each is rated 9.2 out of 10 for severity.
Governments treated it as an emergency. Several took their own websites offline rather than risk waiting for the fix.
Here’s what’s inside:
- How serious this is. Why governments pulled their own sites offline.
- What’s at stake for a nonprofit. Your donate page, your forms and your name.
- Why plugin updates don’t fix it. Where the problem sits.
- What to do this week. How to check your site, and what to ask your host.
Governments took their own websites offline
PHP is the layer underneath a WordPress site. When someone visits a page, PHP builds it. According to W3Techs, PHP runs 69.3% of the websites whose technology can be identified. These flaws are in PHP itself, so they affect any site that runs on it, whatever theme or plugins it uses. The researchers showed working attacks against WordPress.
Security agencies in Britain, Europe, Australia and Japan told organizations to update immediately or take their sites offline until they could. Many didn’t wait. The Dutch national cybersecurity agency took its own website down. The Port of Rotterdam, the Dutch government portal and the country’s five largest political parties followed. Finland shut down the government’s public web services as a precaution. France took its prefectures’ websites offline. In the UK, the sites of Edinburgh and Oxford councils and the Metropolitan Police were reported offline.
Those organizations have security teams and IT budgets. A nonprofit whose website nobody has checked in years is in a weaker position.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those lines is exposed.
Attackers are already trying. Cloudflare saw attack traffic aimed at its customers, with attackers changing their code to get past its defenses. The security firm watchTowr has seen exploitation attempts in its traps. As of October 21, nobody had reported a confirmed break-in.
Your donate page and your supporters’ trust
An attacker who controls your server controls your website. They can change any page, including the one where people give. They can read what the site stores, like contact forms, volunteer sign-ups and event registrations. Wiz found that one of the flaws can expose passwords and keys kept in the server’s memory.
For a nonprofit, the damage goes past the website. Picture a supporter who clicks “Donate” from your year-end email and lands on a page someone else rewrote. Or a local reporter who finds your site serving spam the week of your biggest event. Fixing the site takes a day. Explaining it to donors takes much longer.
The timing matters, too. Year-end giving season is weeks away, and it’s when your website works hardest.
Your plugins can be current and your site still exposed
Most WordPress owners know to keep plugins and WordPress itself updated. That habit doesn’t cover this. The problem is in the PHP version your server runs, and only whoever manages the server can change it. Wordfence, the WordPress security company, warned that automatic updates won’t apply this fix.
A PHP core developer, Gina Peter Banyard, said it plainly: applying the official fixes is the only permanent defense. Settings changes can reduce the risk for a while. They don’t remove it.
Older sites carry the most risk. PHP 8.1 and earlier no longer get regular updates. If your site still runs on one of those versions, plan the upgrade now.
Three checks, about ten minutes
- Find out your PHP version. Log in to WordPress and go to Tools, then Site Health, then the Info tab. Under Server you’ll see the PHP version. If nobody on staff can log in, that’s your first finding.
- Compare it with the fixed versions. You want PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or newer on the same line.
- Ask whoever manages your hosting to confirm. On a managed WordPress host, the host controls PHP and many will update it for you. Several have already posted updates. WP Engine says it added protection at the network level and is rolling out PHP updates. Kinsta, SiteGround and Pressable told customers they don’t need to do anything. GoDaddy is asking customers to check and update their own PHP version. Don’t assume it’s done. Send their support team one question: has our site been updated to a fixed PHP version for CVE-2026-109618 and CVE-2026-109619? On a shared hosting plan, you or your web person may need to switch the PHP version in the hosting control panel. If a volunteer or a former vendor manages the server, find them today.
If your site sits behind Cloudflare, its firewall now blocks the known versions of this attack, including on the free plan. That buys time. It doesn’t replace the PHP update.
If your site is built on a hosted platform like Webflow, Squarespace or Wix, you don’t manage a PHP server, so there’s nothing for you to update.
If you’re not sure what your site runs on, or who has the keys to it, that’s worth finding out before year-end giving starts. Book a free 30-minute call and we’ll help you sort it out.
