PHP2SHELL: What You Need to Know and What SecureCyber is Doing
SecureCyber Blog | Published October 21, 2026 | Updated 12:30 PM Eastern with the official PHP release
PHP has released an emergency security update for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively being called PHP2Shell. Both are rated 9.2 on the CVSS v4.0 scale and allow unauthenticated remote code execution. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Exploitation was underway before the patch existed. If your organization runs anything on PHP, and most organizations do whether they realize it or not, this needs attention today.
What we know
PHP gave advance notice on October 20 that a fix was coming. Technical details and a proof-of-concept exploit leaked publicly before the release, and Cloudflare began reporting exploitation attempts early this morning. The official advisory confirms two separate bugs. In the first, out-of-memory handling can interrupt PHP while request data is only partially initialized, and cleanup then treats that invalid data as valid. In the second, internal request state can survive after its memory is freed, and a later request handled by the same worker can reuse it. The practical impact is the same for both: an unauthenticated request can trigger the attack before your application code runs, which means login pages, CSRF checks, maintenance mode, and security plugins do not help. PHP considers Apache with mod_php the highest-risk configuration, but PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are all affected.
Now that the fix is public, attackers can compare the patched code against the old code to build reliable exploits, so the window between release and broad automated attacks is short.
Who is affected
Every PHP installation serving web requests is affected. Official fixes are available for 8.2, 8.3, 8.4, and 8.5. If you are on an older version, you have more options than it first appeared: Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages before assuming you are stuck. PHP has also published minimal source backports for 7.4, 8.0, and 8.1 for anyone building from source or without a vendor. Those backports are a bridge, not a destination. PHP 8.2 reaches end of life on December 31, 2026, so if you are on 8.2 the upgrade conversation should start now as well.
Think broadly about where PHP lives in your environment. WordPress, Drupal, Joomla, and most content management systems run on PHP. So do many internal portals, intranet tools, vendor-provided web applications, and the admin interfaces on various appliances. If a system accepts HTTP requests from the internet and runs PHP, assume it is in scope.
What to do
Start with inventory. Know every host running PHP and what version it is on. Running php -v on each server is the quick way, and your vulnerability scanner should flag it as well. Then patch to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to your vendor's updated package. This is the only complete fix. PHP's own words: there are no complete mitigations, updating is the only safe choice. Distribution packages often backport the fix without changing the version number, so verify by package version or vendor advisory rather than php -v alone. After you patch, restart PHP-FPM, Apache, and any long-running PHP workers, because they keep the old code in memory until they do.
If you cannot patch within hours, you have options, but none of them make you safe. Taking non-essential internet-facing PHP systems offline until the patch is applied is the cleanest. Blocking multipart requests at the web server or edge for applications that do not need file uploads keeps the request from reaching PHP at all, at the cost of breaking uploads on anything you block. PHP has also published interim configuration measures: setting session.upload_progress.enabled=0 in php.ini or your FPM pool configuration and restarting every worker blocks the confirmed session path for one of the two bugs, and setting memory_limit=-1 in a way applications cannot override, along with a low post_max_size (8M without uploads, 32M with), reduces exposure to the other. PHP is explicit that these reduce exposure to specific attack paths only. Keep in mind that a WAF or edge rule only helps if attackers cannot reach your origin server directly. Security vendors have begun releasing detection signatures, so confirm your edge and web application firewalls have pulled the latest updates.
Once you are patched, check for compromise. Attacks were underway before the fix existed, so a patched system is not necessarily a clean one. Look for web shells, unexpected files in web directories, modified PHP files, new administrative accounts, and unusual outbound connections from web servers. In your web logs, watch for multipart POST traffic hitting endpoints that do not normally accept uploads, especially requests with very long filenames.
PHP patch: https://www.php.net/downloads.php?os=osx&osvariant=osx-homebrew&version=default&source=Y
What SecureCyber is doing
We are identifying every customer with PHP exposed to the internet and prioritizing outreach by risk. Where SecureCyber manages the firewall layer, we are applying protections to reduce exposure until hosts are patched, and we will keep those in place until each customer confirms the fix is applied. We are also watching for signs of exploitation across managed environments and for any indication that a customer environment was accessed before patching, and that monitoring will continue well past the patch date.
Managed customers will hear directly from their SecureCyber account team with their specific exposure and recommended next steps. If you have not heard from us by end of day and believe you have PHP in your environment, please reach out rather than wait.
What we need from you
Patch. The protections we can apply at the network layer reduce exposure but do not replace the fix. Apply the fixed versions, restart your PHP services so the new code is actually running, and let your account team know when you are done so we can adjust protections and confirm you are clear. If you are on a version that only has a vendor backport, treat that as a stopgap and plan the upgrade. We will work with you on isolating or retiring systems that cannot be patched, but the sooner that conversation starts, the better.
If you are unsure whether you have PHP exposed or need help prioritizing, reach out to your SecureCyber account team or sales@secdef.com. We would rather have the conversation now than after an incident.