The October 2026 PHP security alert leaves website teams with an uncomfortable question: is the site protected, or is the update still waiting on the host? A WordPress dashboard with no pending updates cannot settle that question, because PHP is separate software running behind the site.
PHP helps turn website code into the pages visitors see. The UK National Cyber Security Centre (NCSC) warned that two flaws could let an attacker run their own instructions on an affected server, potentially exposing data or disrupting the website. PHP released fixes on October 21.
If you are responsible for leads, orders or search traffic, you need a clear answer from the host and a plan for any interruption. This guide explains how to confirm the fix, handle downtime if it becomes necessary, and check that visitors and search engines can reach the right pages afterward.
What PHP2Shell means for your website
PHP2Shell is the name commonly used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both concern how PHP handles information in server memory. Under the conditions described in the advisories, an attacker can make PHP run unauthorized code without first logging in to the website.
The first flaw can make PHP mishandle information when it runs out of memory. The second flaw can make a server process reuse information from an earlier web request after the memory holding that information has been released. The details differ, but both require fixes to PHP itself.
The important distinction is between your website application and the PHP software that runs it. Updating WordPress, a theme or a plugin does not update PHP itself. WordPress's own announcement says these issues require a PHP update and recommends checking with your hosting provider.
A WordPress security plugin cannot substitute for those fixes. Wordfence explains that its firewall protects the WordPress application layer, while PHP needs its own updates. One confirmed attack path can run before WordPress even starts.
Check which sites and hosting services need attention
PHP asks all installations serving web requests to update, including those using PHP-FPM, Apache mod_php and LiteSpeed. These are different ways a host can run PHP; their names do not establish that a site is safe. Actual attack conditions vary with the setup.
On most shared or managed hosting, the provider controls PHP. If your business manages its own server, assign the update to that server's administrator. Confirm who owns the work rather than assuming the hosting company will do it.
If you use WordPress, open Tools > Site Health > Info > Server to find the reported PHP version. Send that information to your host or developer. They should confirm the status of the PHP actually serving your website; a version shown in one dashboard is a starting point, not the whole check.
Also ask about other places your organization uses PHP, such as a separate blog, an older application or a test copy of the site. NCSC recommends prioritizing internet-facing systems while checking the wider environment too. Being affected by a vulnerability does not, by itself, prove that a site has been breached.
How to fix PHP2Shell and confirm the update is running
Once you know who manages PHP, give them a specific question: has the PHP serving this website received the October 21 security fixes?
Unpatched releases before the versions below are affected in each listed PHP series. The PHP project's release announcement identifies these October 21 fixes for the original two flaws:
| PHP release series | October 21 fixed release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Some providers apply the same security fixes to an older release, a process called backporting. In that case, the version number alone may not show whether the fix is present. Ask for the provider's advisory and the full version identifier covered by that security notice. PHP 8.1 and earlier no longer receive regular supported releases from the PHP project, so an older installation also needs an upgrade plan.
The provider should check that the updated software is actually running, including any required restart. Installing files is not enough if the website continues using an older running copy. You can keep the handoff short:
Please confirm that the PHP serving our website includes the fixes for CVE-2026-109618 and CVE-2026-109619, that any required restart is complete, and which version or vendor package is now running. Please also review PHP's October 23 follow-up notice and tell us whether any further action or investigation is needed.
Include the October 23 follow-up in that conversation
PHP later disclosed a separate issue, CVE-2026-115560, which depends on particular settings and application behavior. As of October 24, PHP recommends temporarily turning off its feature for tracking file-upload progress, with an exception for some configurations, until the next regular bugfix release. Ask the host to review the exact conditions in the official follow-up notice. The October 21 fixes should stay installed; this later notice is an additional check, not a reason to undo them.
Attack attempts make the timing important
Confirming the update tells you what is running now. Your technical team may also need to investigate what happened before the fix.
AWS reported an exploitation attempt dated October 17, four days before public disclosure, and further attempts on October 21. It also said it was unclear whether those attempts would have succeeded against real systems. This is evidence of attempted attacks, not proof that your website was breached.
Ask the host to preserve relevant server logs and involve its security team if there are concerns about earlier access. AWS recommends investigating from at least October 17. Unexpected website-file changes deserve investigation; installing a patch does not remove changes an attacker may already have made.
If patching is delayed, agree on a safe temporary response
If the host cannot apply the fixes promptly, ask how it will reduce exposure in the meantime. NCSC says organizations should consider taking vulnerable systems offline if they cannot mitigate the risk quickly. If the host relies on a web application firewall, which filters incoming traffic, ask whether PHP itself is also patched. Firewall rules may reduce exposure to some attack paths, but they do not replace the update.
If they decide the site must be unavailable, involve the SEO team in how that downtime is presented. For an urgent closure lasting about one or two days, Google recommends a 503 Service Unavailable response with an informational page. A 503 tells a crawler that the interruption is temporary. Ask the host to serve that page from a safe setup that does not depend on the vulnerable PHP installation.
Keep robots.txt, the file that gives crawlers access instructions, available. Avoid a site-wide noindex instruction, which asks search engines to remove pages from search results, or returning 404 or 410 responses that say content is missing or gone. Google warns that prolonged closure can affect indexing, so a 503 is not a guarantee against search impact.
After the fix, check the experience visitors and Google receive
After the update, or once the technical team approves reopening a site taken offline, start with ordinary visitor tasks. Open important landing pages, submit a test inquiry where appropriate, and check login, checkout and file-upload flows relevant to your site. This checks whether the website works after the change; it does not replace the security team's investigation.
Then review the signals search engines use to reach and understand those pages. If you have a recent crawl or approved configuration, compare against it so that intentional settings are not mistaken for problems.
- Page responses: confirm that pages intended to be available return the expected content and a successful 200 response, rather than an error or maintenance page. Our guide to HTTP status codes explains these server responses.
- Redirects: check that important old URLs still lead to the intended destinations. Review any changed URL redirects, especially if the team restored an earlier site configuration.
- Canonical URLs: these signals tell search engines which URL you prefer when similar pages exist. Check that canonical tags still point to the intended live pages.
- Crawling and indexing instructions: check robots.txt and page-level
noindexsettings against the intended setup. A test site's restrictions should not accidentally become the live site's instructions.
After the security response, Quattr's technical SEO recommendations can help prioritize further website improvements using Lighthouse website audits and organic traffic data.
Conclusion: confirm the fix and the website's recovery
Use the host request above to get written confirmation of the running PHP update and any further action required by the latest advisory. Keep that response with your visitor and SEO check results. If anything remains unresolved, agree on a named owner and a time for the next update. That gives your team a clear handoff from the security response to checking that the website works as intended.
PHP security FAQs
Does HTTPS protect a website from these PHP flaws?
No. HTTPS protects data traveling between a browser and a website. These flaws concern software running on the server. Keep HTTPS enabled, but do not treat an HTTPS address or browser security indicator as confirmation that PHP has been patched.
Why might WordPress and a server command show different PHP versions?
A server can have more than one PHP installation. The command-line tool a developer uses may differ from the PHP serving web requests, and PHP can also load different configuration files in different environments. Ask the host which installation serves your website and to verify that specific installation.
How should we test whether a theme or plugin works after the update?
Use an isolated test copy of the website, often called a staging site, to check important pages and tasks without disrupting visitors. If something fails, ask the developer to inspect errors and follow WordPress's guidance for isolating theme and plugin conflicts. Compatibility testing should support urgent patching, not become an open-ended reason to leave an exposed site vulnerable.
Can we restore a backup if the website breaks after patching?
A restore may help recover the website, but agree its scope with the host first so it does not reintroduce vulnerable PHP software. The backup also needs to be trustworthy: NCSC advises checking backups for malware, since an infection may predate its discovery. Restore the required site data while keeping the security fixes in place.
Do we need to change passwords after this alert?
The alert alone does not prove that credentials were stolen. If there are signs the site was compromised, involve the security team in cleanup and access recovery. WordPress's recovery guidance includes resetting access credentials. Password changes are part of recovery; they do not replace patching or removing an attacker's access.
Quattr is an AI-native Search Visibility Platform founded in Palo Alto, California, built for mid-market and enterprise brands competing in the age of generative search. Recently recognized across G2's Spring 2026 reports with #1 rankings in AEO Results, Usability, and Relationship, Quattr helps brands win visibility across traditional search and AI-generated answer surfaces.
Quattr's AI agent, GIGA, evaluates content the way AI systems do, identifying gaps across structure, authority, internal linking, and discoverability to surface the highest-impact fixes. With capabilities like autonomous internal linking, E-E-A-T intelligence, and the new GIGA Landing Page Generator for keyword-matched, AI-search-ready pages, Quattr helps teams move from diagnosis to deployed changes without manual bottlenecks.