Short answer: on October 21, 2026, the PHP project fixed two critical flaws in PHP, the language WordPress runs on. On a server without the fix, someone could run their own code without logging in. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. WordPress itself needs no update for this: the fix goes on your hosting server. Ask your host to confirm it in writing.
What happened
PHP is the programming language WordPress runs on. It is installed on the server that hosts your website, not inside WordPress, so the fix goes on that server.
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two flaws that "can allow unauthenticated remote code execution": someone could send a request to a website and run their own code on its server, with no password. The PHP team says a working attack has been shown on the server setup it rates most at risk, and that changes to the settings only lower the risk: "updating is the only safe choice."
Each flaw has a CVE number, the ID used to track a security problem: CVE-2026-109618 and CVE-2026-109619. The PHP security team rated both critical, 9.2 out of 10 on CVSS 4.0, the standard scale for how serious a security flaw is.
watchTowr, a security company, says its honeypots, servers set up as bait for attackers, saw attacks using both flaws since October 21. CISA, the US agency whose catalog lists the vulnerabilities known to be used in attacks, had not added either one when we checked on October 22, 2026.
WordPress.org says the flaws "are not specific to WordPress and affect any server that hosts a PHP application," and that "No WordPress update is required or planned for these issues."
Sources: PHP's security advisory and release notes of October 21, 2026. PHP's advisories on GitHub, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. The CVE records CVE-2026-109618 and CVE-2026-109619; NVD also lists its own CVSS 3.1 scores, 9.8 and 8.1. watchTowr, PHP Remote Code Execution. CISA, Known Exploited Vulnerabilities Catalog. WordPress.org News, Critical PHP Security Release. Read October 22, 2026.
How to check your PHP version, and whether it has the fix
Every WordPress site runs on PHP, so each one was at risk until its server got the fix.
To see your version, sign in to WordPress as an administrator. Go to Tools, then Site Health, and open the Info tab. Open the Server section and look for PHP version. Many hosts also show it in the hosting control panel. Compare it with this table:
| If your site shows | Fixed in | What to do |
|---|---|---|
| PHP 8.5 | 8.5.12 | Get the fix confirmed by your host |
| PHP 8.4 | 8.4.27 | Get the fix confirmed by your host |
| PHP 8.3 | 8.3.36 | Get the fix confirmed by your host |
| PHP 8.2 | 8.2.35 | Get the fix confirmed, and plan a move: 8.2 will get no security fixes after December 31, 2026 |
| PHP 8.1, 8.0, 7.4 or older | No new release from the PHP project | Ask your host whether a fix is installed for your version, and plan the move to a supported version |
A lower version number doesn't always mean the fix is missing, so take it as a first clue and get the final answer from your host. On GoDaddy's Web Hosting, the fix came as a new build of the same version, "so your site can still show a version like 8.5.11 while including the fix."
If your site runs PHP 8.1 or older, the PHP project no longer updates those versions. Some hosts get a fix for older versions from the companies that supply their server software, so ask your host. WordPress recommends PHP 8.3 or newer.
Sources: PHP, security advisory, release notes of PHP 8.2.35 and Supported Versions; WordPress.org, Get a faster, more secure website: update PHP today and Requirements; GoDaddy, Important PHP security update: What website owners need to do, updated October 22, 2026. Read October 22, 2026.
Who installs the update
PHP lives on the server, so the answer depends on your hosting.
- Shared or managed WordPress hosting. The host usually runs PHP for you and installs the fix. On October 21, GoDaddy said it had patched every PHP version on its Managed Hosting for WordPress, where customers "don't need to take any action" for this. Kinsta, a WordPress hosting company, said on October 22 that it had rolled out the PHP security updates across its platform and had no evidence of breaches.
- Your own server, such as a VPS (virtual private server) or a cloud server. Usually nobody updates PHP for you unless your contract says so. GoDaddy tells its VPS customers that "you'll want to update PHP yourself," because on a VPS the customer manages the server's software. If an agency or a freelancer set up that server for you, ask them who installs the update, and when.
WordPress.org notes that many hosts let you change the PHP version yourself. Make a backup before you switch away from an old version, and ask the host whether the version you pick already includes the October 21 fix.
Sources: GoDaddy, Important PHP security update, published October 20, 2026 and updated October 21 and 22; Kinsta, PHP Security Vulnerability Update, October 21 to 22, 2026; WordPress.org, update PHP today. Read October 22, 2026.
What to do today
- Get the fix confirmed. Ask your host, or the agency that runs your site, to confirm in writing that your server runs a PHP version with the October 21 fix, and since when.
- Check that you have a backup you can restore. Ask when the last copy was made, where it is kept and who would restore it. WordPress.org's guide for hacked sites also tells owners to ask the host about its backup policy.
- Keep WordPress, plugins and themes up to date. This won't fix the PHP flaw, but WordPress asks for it before any change of PHP version. If an agency handles your updates, ask them to run them. If you do it yourself, do it after step 2, in Dashboard, then Updates, and then check your main pages and your contact form.
- Look at who can sign in. In Users, select Administrator at the top of the list. An administrator you don't recognize is a reason to call your host or agency the same day. WordPress lists new users nobody created among the signs of a hacked site, and says the first step is to write down what you see, and when.
- Ask for a check of the files. Whoever runs the server can look for files that changed on days when nobody worked on the site. The UK's National Cyber Security Centre (NCSC) asks for a check of servers that could not be updated right away. It wants a look for "evidence of compromise" and for "backdoors installed by an attacker," hidden ways back into the server.
- If something looks wrong, change the passwords. Change your WordPress and hosting panel passwords, and ask every user with access to do the same. Ask your host or agency to change the file access (FTP or SFTP) and database passwords too, and to turn on two-step login (on WordPress this usually needs a plugin). WordPress.org says to change them all again once the site is clean.
If your site runs PHP 8.1 or older, plan the move to a supported version now; on 8.2, plan it before December 31, 2026. Before the switch, WordPress.org asks for a backup, up-to-date WordPress, themes and plugins, and a compatibility check. If you run your own server on PHP 8.1 or older, WordPress.org says to consider taking it offline while you prepare the update. The NCSC gives the same advice for any system that can't be fixed in time.
Sources: WordPress.org, FAQ My site was hacked, Site Health Screen, update PHP today and Critical PHP Security Release. NCSC, Critical security issue affecting PHP, published October 21, 2026 and updated October 22. Read October 22, 2026.
What to ask your agency or hosting provider
- Which PHP version does my site run today, and does it include the October 21, 2026, fix?
- When did you install it?
- Did you check the site for signs of intrusion, such as administrator users nobody created or files changed on days nobody worked on it? What did you find?
- How do backups work: how often you make them, how long you keep them, where they are stored, and who restores the site and how fast?
- If my site runs PHP 8.2 or older, when will you move it to a newer version, and who tests the site after the change?
Frequently asked questions
Do I need to update WordPress to fix this?
No. WordPress.org says the flaws are not specific to WordPress and that no WordPress update is required or planned for them. The fix goes on the server that runs your site. Keeping WordPress, plugins and themes up to date is still worth doing, and WordPress asks for it, after a backup, before any change of PHP version.
How do I know if my site's PHP has the fix?
In WordPress, open Tools, then Site Health, the Info tab and the Server section, and read PHP version. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or later releases of the same series, have it. Some hosts add the fix as a new build that keeps the old number, as GoDaddy explains, so the surest answer is your host's written confirmation.
Are attackers already using these flaws?
watchTowr, a security company, says its honeypots, decoy servers that attract attackers, saw attacks using both flaws since October 21, 2026. CISA, the US agency that lists vulnerabilities known to be used in attacks, had not added them to its catalog when we checked on October 22, 2026. Get the update confirmed with your host.
My site runs PHP 7.4, 8.0 or 8.1. What should I do?
Those versions no longer get updates from the PHP project, though some hosts get a fix from the companies that supply their server software, so ask your host first. Then plan the move to a supported version: WordPress recommends 8.3 or newer. Make a backup and update WordPress, themes and plugins before switching, and test the site afterward.
My host says it already patched PHP. Is there anything left for me to do?
Not for PHP itself. Ask for that confirmation in writing, with the date. Then do the usual checks: a recent backup you can restore, WordPress, plugins and themes up to date, and no administrator you don't recognize. If something looks wrong, change your passwords and tell your host the same day.
If you'd rather not handle this yourself
Our website maintenance plan includes updates tested before they go live, daily backups kept for 30 days, and security and downtime monitoring. For what a site costs to build and keep running, see our article on how much a website costs.
