Why do WordPress, plugin and PHP updates matter?
A WordPress site runs on three layers: PHP on the server, WordPress itself, and your plugins and theme. Each gets security fixes, and once a fix is public, attackers scan for sites without it, often within hours. Updating one layer doesn't fix the others, and a layer past its end of life gets no fixes at all.
The short version
- A WordPress site has three layers that each need updates: PHP (the server’s language), WordPress core, and plugins and themes.
- A published fix is also a map for attackers. Automated tools look for sites still running the old code.
- Updating WordPress doesn’t update PHP, and updating PHP doesn’t fix a plugin.
- When a layer reaches end of life, nobody fixes it any more, however serious the next flaw is.
- Back up first, test the update, then apply it. Don’t skip it.
What are the three layers?
| Layer | What it is | Who updates it | Where the fix comes from |
|---|---|---|---|
| PHP | The language your server uses to build each page | Your host | PHP.net, through your host |
| WordPress core | The software behind your dashboard and pages | WordPress itself, your host or your web team | WordPress.org |
| Plugins and theme | Add-ons for forms, page building, stores, SEO | Whoever maintains the site | Each plugin’s developer |
A hole in any layer can let an attacker in. That’s why a site can be “fully updated” in the dashboard and still be exposed, if the server underneath is running an unpatched PHP.
Why is a published fix a race?
When a developer ships a security fix, the change becomes visible to anyone who compares the old and new code. Attackers do exactly that, then scan the web for sites that haven’t updated. CISA’s update advice puts it plainly: attackers move on flaws soon after they appear, so waiting leaves you exposed.
What did 2026 show?
Three real examples from the last few months, one per layer:
- PHP, October 2026. On October 21, the PHP project shipped emergency releases (8.5.12, 8.4.27, 8.3.36 and 8.2.35) for two critical flaws, CVE-2026-109618 and CVE-2026-109619. The advisory says an unauthenticated web request could run code on the server, and that updating is the only safe choice. No WordPress or plugin update could fix it. Only the host could. See our alert.
- WordPress core, October 2026. WordPress 7.1.4, released October 28, fixed 13 security issues, including one in the update process itself. Sites with automatic background updates got it on their own.
- A plugin, August 2026. Elementor Pro 4.2.2 fixed CVE-2026-32475, which let anyone upload a program through a form’s file upload field. BleepingComputer reported that attacks began the day the fix came out.
What does end of life mean for each layer?
End of life (EOL) means the people who make the software have stopped fixing it. The site keeps working, which is what makes it easy to miss.
- PHP: each version gets about two years of bug fixes, then security fixes only, then nothing. PHP 8.1 reached end of life on December 31, 2025, and PHP 8.2 follows on December 31, 2026, per PHP.net. When the October flaws hit, the PHP team said 8.1 and older no longer get updates from the project.
- WordPress: only the latest major release is officially supported. Older versions get security fixes only as a courtesy, with no promised period, per WordPress.org.
- Plugins: a plugin is effectively end of life when its developer stops updating it, or when a paid license lapses and updates stop arriving.
Our page on what end of life means covers the wider picture, and the end-of-life tracker lists the dates.
Why not just turn on auto-updates for everything?
Automatic updates are better than none, and WordPress installs minor core releases on its own by default. The catch is that nobody checks the site afterwards. A form can stop sending and nobody notices for a week. The safer pattern is a backup, the update on a test copy, a check of the pages that matter, then the live site. Our answer on plugin updates walks through it.
What are the common mistakes?
- Assuming the dashboard tells the whole story. It shows WordPress and plugin updates, not whether the server’s PHP is patched. Ask your host.
- Staying on an old PHP to avoid breaking a plugin. That trades a known small problem for an open security hole. Replace the plugin instead.
- Keeping deactivated plugins. Their files are still on the server and can still be attacked. Delete them.
- Letting paid plugin licenses lapse. Updates stop, quietly.
How do I check where my site stands?
See whether your site is on an old PHP or WordPress for the checks and the questions to ask your host.
How does E-3 handle this?
E-3 keeps the sites it hosts on supported PHP versions, so the server layer isn’t left behind. On sites we look after through website care, WordPress, plugin and theme updates are tested on a staging copy first. Monitoring tracks each hosted site’s PHP version, waiting updates and known plugin vulnerabilities, and we send security alerts and keep daily backups.
Related questions
Sources
- PHP news archive 2026: Security advisory, critical remote code execution vulnerabilities (PHP.net, October 21, 2026)
- RCE via OOM corruption, CVE-2026-109618 (PHP security advisory, GitHub)
- Supported versions (PHP.net)
- WordPress 7.1.4 (WordPress.org News, October 28, 2026)
- Supported versions (WordPress.org Documentation)
- Requirements (WordPress.org)
- Critical unauthenticated file upload to RCE in Elementor Pro, CVE-2026-32475 (Patchstack, August 2026)
- Critical Elementor Pro flaw exploited to take over WordPress sites (BleepingComputer, September 2026)
- Update Software (CISA Secure Our World)
Next step
- Next: What does end of life (EOL) mean for software, and is it still safe?The next guide in Cybersecurity basics.
- Website careUptime monitoring, tested updates, daily backups and security alerts.
Still stuck? Ask E-3 for an answer from our help guides.
Rather we handled cybersecurity basics for you?
It’s part of what we do every week for small businesses, as part of website care. Start with a free check of your site and profile, or call and ask.