What do the PHP2Shell PHP vulnerabilities mean for your website?
If your website or a business application uses an affected PHP runtime, contact the team responsible for its hosting and request immediate patch verification. PHP2Shell refers to two critical vulnerabilities that can let an attacker run code on an affected server without logging in. The PHP project released fixes on October 21, 2026. Read PHP’s security advisory.
At Datapath, we recommend starting with a concrete question: who owns the PHP runtime underneath each website or application, and who can confirm that the fix is actually running? A current-looking website is not evidence of a current server.
What happened, and why is the response urgent?
On October 21, the NSA issued an advisory recommending urgent PHP patching. The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each carry a CVSS v4.0 severity score of 9.2 out of 10. These are flaws in PHP itself, not just a particular website plugin.
PHP’s technical advisories describe memory corruption during out-of-memory handling and stale internal state carried between requests. Both can lead to remote code execution: an attacker getting the server to run their instructions.
CERT-EU’s advisory notes that technical details and initial proof-of-concept material are public. Do not wait for a confirmed incident at your organization before checking exposure. We recommend assigning an owner and beginning the review today, rather than waiting for the next routine maintenance cycle.
What is PHP, and which systems should you check?
PHP is a programming language that runs on servers and supports many websites and browser-based applications, including WordPress, Joomla, and Drupal deployments. Your review should include public websites, internal applications, and vendor products that embed PHP. The Dutch National Cyber Security Centre’s PHP2Shell inventory tracks potentially affected software beyond ordinary websites.
Ask about:
- Your public website, whether a hosting company, independent developer, or internal team maintains it.
- Websites and browser-based business applications on servers you control, including hosted virtual machines and containers.
- Vendor-installed systems, appliances, and management interfaces with an embedded web server.
- Older tools whose original developer or support contact has changed.
- Websites and internal tools built with an AI coding assistant, if they use PHP.
Do not assume that a system is covered because another vendor installed it. Record who can update it, who approves downtime, and who will verify the result. Our IT asset inventory guidance explains how to turn that ownership list into a repeatable process.
Does this mean Microsoft 365 or every computer is affected?
No. These vulnerabilities concern affected PHP software, not every device or service your organization uses. Using Outlook, Teams, SharePoint, or OneDrive does not itself establish PHP2Shell exposure. However, a workstation, hosted service, or appliance should not be declared unaffected solely because of its product category; first establish whether it runs or embeds vulnerable PHP.
For a fully managed cloud application, the provider usually controls the underlying runtime. Ask for its security notice or remediation confirmation instead of trying to patch infrastructure you do not administer. This is a responsibility distinction, not a blanket claim that all accounting, payroll, or CRM services are immune.
Which PHP versions contain the fixes?
The first fixed upstream releases are listed below. Use the matching branch’s fixed release or a later supported update. For distribution-managed packages, ask the vendor to identify its patched package and advisory; a vendor may backport a fix without adopting the same upstream version number.
| PHP branch | First fixed upstream release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
The PHP security advisory identifies these releases and vendor-backport options. PHP 8.1 and older are outside normal upstream support. An exceptional source patch or vendor backport is not the same as a maintained upgrade plan. Also note that PHP 8.2 security support ends December 31, 2026: patching it now does not remove the need to plan its replacement.
What should you ask your website provider today?
Ask for a written answer that identifies the website, its running PHP version or patched vendor package, and when the update was applied. Include production, staging, and any separate hosting accounts. Do not treat a generic statement that the hosting platform is secure as confirmation for your particular site.
You can send this checklist:
- Does our website use PHP, and who is responsible for updating it?
- Has the running web-server runtime received the fix for both CVEs?
- What version or vendor package confirms that, and when was it deployed?
- Were any required service or worker restarts completed?
- Were logs and site files reviewed for suspicious activity, and what was the result?
- If the site uses an unsupported branch, what is the upgrade owner and deadline?
For WordPress sites, WordPress’s official notice explains that PHP version information is available under Tools > Site Health > Info > Server. It also confirms that this issue requires a PHP update, not a WordPress core update. A current dashboard, theme, or plugin list alone does not close the PHP task.
What about servers you own or tools built with AI?
List every server or deployment under your control that serves a website or business application, then assign someone to check its runtime. Include vendor-managed systems and AI-assisted projects. How the code was written does not determine PHP2Shell exposure; the deployed software and its maintenance status do.
For a tool created with ChatGPT, Claude, Copilot, Replit, or another assistant, ask who owns the deployment, dependencies, credentials, and updates. If nobody can answer, involve your IT team or Datapath account manager before assuming it is maintained. This is an inventory recommendation, not a claim that those tools automatically deploy PHP or vulnerable software.
What if a system cannot be patched immediately?
Escalate the exception to the application owner and security team, document the business impact, and agree on containment and an upgrade deadline. The NSA recommends taking a system offline if an immediate update is not feasible until it can be fully mitigated; CERT-EU advises considering isolation of internet-facing applications until the fix is applied and verified.
Plan that interruption carefully. Identify critical workflows, notify affected users, and decide how service will be restored. Follow the vendor’s specific instructions rather than applying configuration changes copied from an unrelated system. PHP states that temporary measures address particular attack paths but do not fully fix the vulnerabilities. A firewall rule should not be recorded as a completed runtime update.
Our patch-management audit checklist and vulnerability-remediation SLA guide can help you track open exceptions without losing ownership.
How should you verify that remediation is complete?
Close the task only after someone verifies the deployed environment, not merely an installation ticket. Record the affected asset, the patch evidence, any required restart, the application test result, and the person who approved closure. If the provider reports a backport, retain the relevant vendor advisory with that evidence.
Test the business functions that matter: forms, logins, uploads, checkout, and integrations as applicable. Review suspicious changes through your incident-response process. Updating a runtime addresses the vulnerability; it does not by itself prove that a previously compromised server is clean. Our incident-response planning guide explains why remediation and investigation need distinct owners.
How can Datapath help with PHP2Shell?
Datapath is reviewing systems we manage for clients and will reach out directly if anything needs attention. Websites or vendor systems outside that management scope still need a named owner. If you are unsure where your website is hosted or who maintains its PHP runtime, we can help you establish the next step.
Our managed cybersecurity services and cybersecurity risk assessments connect asset discovery, remediation priorities, and verification. Explore our security resources or call 800-838-1488. For help coordinating with your hosting provider, contact Datapath.
Need help checking your PHP exposure?
Talk with Datapath about website ownership, vendor patch confirmation, and the systems that need review.
Frequently asked questions
Does updating WordPress fix PHP2Shell?
No. WordPress’s notice identifies these as PHP runtime vulnerabilities and says no WordPress update is required or planned for them. Ask your host to confirm that PHP itself has been patched. Continue normal WordPress, theme, and plugin maintenance separately.
Is an older PHP version number always proof that a vendor system is unpatched?
Not necessarily. A vendor may backport the security fixes into its supported package. Request the vendor advisory and installed package details rather than relying only on a version banner. An unsupported version without documented remediation still needs urgent attention.
Does a web application firewall replace the PHP update?
No. Protective rules may reduce exposure, but they are not evidence that the underlying runtime is fixed. Keep the patch task open until the vendor-supported update is installed and verified. Discuss isolation when an exposed system cannot be promptly remediated.
Does using an AI coding assistant make a site vulnerable?
No. PHP2Shell exposure depends on the deployed PHP runtime, not the tool used to write the application. Include AI-assisted projects in the inventory because they need the same ownership, supported dependencies, and update process as any other business system.
Sources and further reading
Sources checked October 22, 2026. Provider guidance and software-impact lists may change as investigations continue.
- PHP: October 21 security advisory and fixed releases.
- PHP: CVE-2026-109618 technical advisory.
- PHP: CVE-2026-109619 technical advisory.
- NSA: Critical patches recommended for PHP vulnerabilities.
- CERT-EU: Security Advisory 2026-018.
- NCSC-NL: PHP2Shell operational information and software inventory.
- WordPress: Critical PHP security release.
- PHP: Supported versions and support deadlines.
