Last updated October 30, 2026. This post summarizes publicly available information from PHP’s security team, government cyber agencies, and security researchers as of that date. The situation is still developing and details may change. See the sources and the note at the end of this article.
Quick answer: PHP’s security team has disclosed two critical remote code execution vulnerabilities in the PHP language itself, CVE-2026-109618 and CVE-2026-109619, which the industry has nicknamed PHP2Shell. According to PHP’s advisory, both are rated 9.2 (Critical) on the CVSS 4.0 scale and can allow an attacker to execute code on a vulnerable web server without logging in. PHP released fixed versions on October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP has stated that updating is the only complete fix. A third, related issue, CVE-2026-115560, was disclosed by PHP on October 23 and, as of the date above, has no permanent patch; PHP recommends a configuration change as an interim measure. If your business runs anything on PHP, including a WordPress website, the recommended action is to confirm with whoever operates that system that it has been updated.
PHP is one of the most widely used server-side languages on the web and the foundation of WordPress, so it is present in many businesses that have never heard of it. Here is what has been publicly reported, who may be exposed, what we do not yet know, and the steps security authorities are recommending.
What has been reported, in order
Before disclosure. Datadog Security Labs reported that Amazon Web Services observed exploitation attempts matching these vulnerabilities as early as October 17, 2026, several days before public disclosure. We have not independently verified that observation; we cite it because it is the basis for the widely repeated statement that attackers had the details early.
October 20. According to Huntress and other security firms, technical details of both vulnerabilities became public ahead of the coordinated disclosure PHP had planned. Security research firms, including Datadog and watchTowr, reported reproducing the vulnerabilities, and proof-of-concept exploit code was subsequently published on public code repositories. We are deliberately not linking to it.
October 21, 14:00 UTC. PHP released security updates: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP’s release notes state that these fix two critical vulnerabilities that can allow unauthenticated remote code execution, that all users are strongly encouraged to update immediately, and that there are no complete mitigations other than updating. The same day, the Canadian Centre for Cyber Security issued alert AL26-026, and hosting and platform vendors including Plesk and Laravel Forge published patched builds.
October 23. PHP’s security team published an informational advisory for a third issue, CVE-2026-115560, involving PHP’s session upload progress feature. PHP has indicated a full advisory and fix will accompany its next regular release.
October 27. The Canadian Centre for Cyber Security updated its alert to note that, until an update for CVE-2026-115560 is available, PHP recommends disabling the session upload progress feature.
October 29. Palo Alto Networks Unit 42 published a threat brief stating that its Cortex Xpanse telemetry had identified more than 22.6 million exposed instances potentially vulnerable to the two original flaws. That is Palo Alto’s estimate and its wording; it does not mean 22.6 million systems have been compromised.
What the vulnerabilities are, in plain terms
Both vulnerabilities concern how PHP handles certain fatal error conditions, and both are categorized by the Canadian Centre for Cyber Security as use-after-free weaknesses.
Public descriptions of CVE-2026-109618 indicate it involves PHP’s handling of out-of-memory conditions, which can leave internal request memory in an inconsistent state that an attacker can exploit. Public descriptions of CVE-2026-109619 indicate that after certain fatal errors PHP can retain references to memory that has already been freed, which later requests may read or act upon.
The point that security researchers have emphasized, and the reason this is treated as unusually serious, is that according to Datadog’s analysis PHP processes the malicious request before any application code runs. If that analysis is correct, application-level protections such as a login page or security features built into a content management system would not prevent exploitation, because the attack occurs before authentication is checked. Huntress, citing PHP, reported that complete remote code execution was validated over HTTP against mod_php with default PHP input and memory limits.
Who may be affected
Based on PHP’s advisory, any server running a PHP 8.x version earlier than the fixed releases is affected in default configurations. In practice, that may include:
- Business websites built on WordPress, Drupal, Joomla, Magento, Laravel, or other PHP-based platforms
- Websites on shared or managed hosting, where the hosting provider, not the business, controls the PHP version
- Internal web portals, intranets, and custom applications written in PHP
- Vendor appliances and devices with PHP-based administrative interfaces
- Development, staging, and test servers, which are often overlooked
PHP did not publish official releases for end-of-life versions (8.1 and earlier). Some hosting and platform vendors have published their own patched builds for those branches. Systems on end-of-life PHP should be treated as exposed unless the system’s vendor or host has confirmed otherwise in writing. PHP’s release notes also state that PHP 8.2 reaches end of life on December 31, 2026, after which it will receive no further security fixes.
What we do not know yet
In the interest of accuracy, several things remain unclear from public reporting as of this writing. The full extent of exploitation in the wild has not been established; reports of attempts are not the same as confirmed compromises. The exact conditions under which CVE-2026-115560 is exploitable have been described as configuration-dependent and narrower than the original two flaws, and PHP has not yet published its full advisory. Mitigations short of updating have been described by researchers as partial and are not endorsed by PHP as complete. We will update this post as PHP and the relevant authorities publish more.
Recommended actions, based on published guidance
These reflect the guidance published by PHP, the Canadian Centre for Cyber Security, and the security firms cited below. Your situation may differ, and you should confirm specifics with your hosting provider, developer, or IT provider.
1. Identify where your business runs PHP. Your public website is the obvious case. Less obvious cases include internal tools, forgotten staging sites, vendor appliances, and systems set up by former staff or contractors. If you do not have an inventory, your IT provider can help build one.
2. Confirm your website host has applied the fix. If your site is on a hosting platform, the host typically controls the PHP version. Check the PHP version shown in your hosting control panel, or ask the host directly whether your site is running PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor-patched build. Many major providers have published their own advisories; your host’s status page or support team is the authoritative source for your site.
3. Update anything you operate yourself. For servers, applications, and appliances under your control, PHP’s guidance is to update to the fixed release for your branch or to your vendor’s patched package. PHP has stated there are no complete mitigations other than updating. Researchers have described certain configuration changes as blocking known exploitation paths, but have cautioned they are not a substitute for the update.
4. Apply the interim measure for CVE-2026-115560. PHP’s current guidance, as relayed by the Canadian Centre for Cyber Security, is to disable the session upload progress feature until a fix is released. Whether this affects your application depends on whether it uses that feature; your developer or host can confirm.
5. Check for signs of prior compromise. Because exploitation attempts were reported before the patch was available, applying the update does not reverse an intrusion that may have already occurred. Indicators security firms have described include unexpected processes or commands executed by the web server account, unfamiliar files in web directories, new scheduled tasks or user accounts, and unusual outbound connections from web servers. If you find any of these, engage a qualified incident response resource.
6. Plan the retirement of end-of-life PHP. Systems on PHP 8.1 or older did not receive official fixes. This event is a reasonable trigger to upgrade them.
Why this matters beyond the website
A compromised web server can be used to steal data, distribute malware to visitors, host phishing pages under a trusted domain, redirect payments, or reach other systems on the same network. The FBI’s Internet Crime Complaint Center reported $20.877 billion in cybercrime losses for 2025 in its 2025 Internet Crime Report. Vulnerabilities of this kind are one of the ways such incidents begin.
It is also a reminder about visibility. Organizations responding well to this event are generally those that already knew every system running PHP, patched on a defined cycle, and had monitoring capable of noticing a web server beginning to execute system commands.
How we are approaching it for our clients
CyberDuo does not build or manage client websites. For clients’ public websites, our role has been to help them confirm with their hosting providers that fixes were applied and to explain what to ask. Within the environments we manage, our vulnerability management process is used to identify PHP-based systems and appliances, available fixes are applied through our patching process, and our in-house 24/7 security operations center and endpoint detection and response tooling monitor for the kind of web-server-originated command execution that researchers associate with exploitation. Our vulnerability management and 24/7 threat detection and response pages describe that work in general terms. No security measure eliminates risk, and nothing in this post should be read as a guarantee against compromise.
If you are a business in Los Angeles, Orange County, or San Diego and are unsure where you run PHP or whether it has been updated, we are glad to talk through how to find out.
Frequently asked questions
Is my WordPress website affected by PHP2Shell? If it runs on a PHP version earlier than the October 21, 2026 fixed releases, PHP’s advisory indicates it is affected regardless of WordPress version or plugins. Your hosting control panel or hosting provider can confirm the PHP version your site runs.
Does a login page or a web application firewall protect against it? According to analysis published by Datadog Security Labs, PHP processes the malicious request before application code runs, so application-level authentication would not prevent it. PHP has stated that updating is the only complete fix.
Which PHP versions contain the fix? PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21, 2026, according to PHP’s release notes. Some vendors have published their own patched builds for older, end-of-life branches.
Is CVE-2026-115560 fixed? Not as of October 30, 2026, based on PHP’s advisory and the Canadian Centre for Cyber Security’s October 27 update. PHP’s interim recommendation is to disable the session upload progress feature until a fix is released.
Were these vulnerabilities exploited before the patch? Datadog Security Labs reported that AWS observed exploitation attempts as early as October 17, and proof-of-concept code was published after the October 20 leak. Public reporting describes attempts; the extent of actual compromises is not established.
Will CyberDuo fix my website? We do not manage client websites. We can help clients confirm their host has applied the fix, identify PHP running inside the environments we manage, apply available updates there, and monitor for exploitation.
Sources
- PHP release announcements for PHP 8.2.35 and PHP 8.4.27, October 21, 2026, and PHP’s security advisory at php.net
- Canadian Centre for Cyber Security, Alert AL26-026, October 21, 2026, updated October 27, 2026
- Huntress, Rapid Response: php2shell, October 20, 2026
- Datadog Security Labs, PHP2Shell: detection, analysis, and remediation, October 2026
- Palo Alto Networks Unit 42, Threat Brief: CVE-2026-109618, CVE-2026-109619, updated October 29, 2026
- SOC Prime, CVE-2026-115560 analysis, October 26, 2026
- Plesk, vendor advisory on PHP2Shell, October 2026
- FBI Internet Crime Complaint Center, 2025 Internet Crime Report, April 2026
About this article
This article is provided for general informational purposes only. It summarizes information published by third parties as of the date shown and is not a substitute for the official advisories of PHP, your software vendors, your hosting provider, or government cyber security agencies, which should be consulted directly. It does not constitute legal, security, or other professional advice for any specific situation, and no action should be taken or withheld based solely on its contents. CyberDuo, Inc. makes no representation or warranty as to the completeness, accuracy, or timeliness of third-party information summarized here, and disclaims liability for any loss arising from reliance on it. CyberDuo is not affiliated with the PHP Group or any vendor named above; product names are the trademarks of their respective owners. If you believe any statement in this article is inaccurate, please contact ask@cyberduo.com and we will review and correct it.
