In late October 2026, two critical vulnerabilities in PHP became public before their planned disclosure date. Security researchers nicknamed the pair "PHP2Shell." Because PHP powers a large share of the web, including WordPress, Drupal, Joomla, many online stores, and countless custom business applications, this was not a problem limited to a single product or plugin. It was a problem in the engine underneath them.
This post explains what PHP2Shell is in plain terms, what businesses should do about it, and why events like this show the value of having a managed IT provider watching your systems.
What Is PHP2Shell?
PHP is an open-source scripting language that runs on web servers. When someone visits a website or submits a form, PHP often handles that request behind the scenes.
PHP2Shell is the nickname for two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619. A CVE (Common Vulnerabilities and Exposures) identifier is a standard ID used to track publicly known security flaws. Both vulnerabilities are rated 9.2 out of 10 (Critical) under the CVSS v4.0 scoring system.
Both flaws can allow unauthenticated remote code execution. In everyday language, that means an attacker who has never logged in could send specially crafted web requests to a vulnerable server and run their own commands on it, with the same permissions as the web server.
CVE-2026-109618 involves how PHP handles running out of memory partway through processing a request. The cleanup process can then trust data that was never fully set up.
CVE-2026-109619 involves internal information that outlives the request it belongs to. A later request handled by the same PHP worker process can act on that leftover data.
Neither flaw lives in a website's own code. That is what made PHP2Shell so serious: a well-built, fully updated website could still be exposed if the PHP version underneath it was vulnerable. According to the PHP project, the risk applies to PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, with Apache mod_php considered the highest-risk setup.
How the Situation Unfolded
The timeline moved quickly:
October 17, 2026: Amazon Threat Intelligence reported an exploitation attempt, before the vulnerabilities were publicly disclosed.
October 20, 2026: Details of the vulnerabilities leaked on social media ahead of the coordinated disclosure date.
October 21, 2026: The PHP project released fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Security firms, including watchTowr, also reported observing exploitation attempts in the wild.
When details of a critical flaw leak before a fix is available, defenders and attackers start at the same moment. The organizations that come through these events best are usually the ones that already know what they are running and have someone ready to act.
It Is Not Just Websites
PHP is also built into many products that do not look like websites at first glance. Firewalls, network appliances, management portals, and other vendor products can include PHP internally. In those cases, you usually cannot update PHP yourself. You have to wait for the vendor to release an update and then install it.
Several major security vendors published advisories about how PHP2Shell affected their own products. Some reported that their products were not affected, while others identified affected versions and scheduled fixes. For businesses, this means a complete response involves more than updating your web server. It also means checking every device and application that might include PHP and tracking each vendor's guidance.
What Businesses Should Do Now
If your business runs or relies on PHP-based systems, here are the practical steps to take.
- Find out where PHP is running. Identify servers, websites, and applications that use PHP, starting with anything reachable from the internet. Check the actual running version rather than relying only on old records or install locations.
- Update to a fixed version. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install the patched package provided by your Linux distribution or hosting provider. After updating, restart PHP and web server processes so the fix actually takes effect.
- Address older PHP versions. PHP 8.1 and earlier are no longer supported by the PHP project. The project published source code fixes for PHP 7.4, 8.0, and 8.1 but no official ready-to-install releases. Systems on those versions should be moved to a supported version or covered by a vendor that provides extended support. PHP 8.2 itself reaches end of life on December 31, 2026, so it is a good time to plan ahead.
- Check vendor products separately. Review advisories from the makers of your firewalls, appliances, and hosted services, and apply their updates as soon as they are available.
- Use temporary measures only as a bridge. If you cannot update right away, the PHP project has published temporary mitigations, such as disabling the session upload progress feature and restarting worker processes. Some providers also offered web application firewall (WAF) rules to block known attack patterns. These steps can reduce risk, but the PHP project has stated that they are not complete fixes. Updating is the only safe long-term choice.
- Look for signs of compromise. Because exploitation attempts were reported before the fix was released, review web server logs, error logs, and server activity on internet-facing systems. Warning signs include unexpected file upload requests, spikes in memory errors or crashes, unfamiliar programs launched by the web server, and new or modified PHP files in website folders.
How Grand Rapids Tech Responded for Our Clients
When the PHP2Shell details leaked on October 20, our team began reviewing the available information that same day. By October 21, we had started carrying out checks and mitigations across the client environments we manage.
Our management tools helped us quickly identify PHP installations on the client servers we manage. Where an installation could not be automatically confirmed as vulnerable or safe, we did not assume the best. Our technicians manually verified those PHP installations on each managed client server so that no detected installation was left unchecked.
This kind of response is difficult to put together on short notice if you are starting from scratch. It depends on already knowing what is installed, already having access and procedures in place, and having people whose job is to pay attention when a major vulnerability becomes public.
Why a Managed IT Provider Matters During Events Like This
PHP2Shell is a good example of why cybersecurity cannot rely only on occasional maintenance or on someone noticing the news. A few things made the difference for businesses during the first days:
Visibility. You cannot patch what you do not know you have. A managed IT provider maintains an inventory of your servers, software, and devices, which makes it much faster to answer the question, "Are we affected?"
Speed. With details public before a fix was available, the gap between disclosure and attack was very short. Having a team that is already monitoring security news and vendor advisories means work can begin right away instead of after a breach is discovered.
Thoroughness. Automated tools are valuable, but they do not always give a clear answer. Following up with hands-on verification closes the gaps that automation can leave behind.
Follow-through. A complete response does not end with one update. It includes tracking vendor patches for appliances, planning upgrades away from unsupported versions, and watching for signs of compromise.
For many small and medium-sized businesses, keeping that level of attention in-house is not practical. A managed IT partner gives you that coverage without needing to build a full security team yourself.
The Takeaway
PHP2Shell showed how quickly a vulnerability in widely used software can become an urgent business problem. If your organization runs PHP-based websites or applications, confirm that every installation is on a fixed version, check your vendor products, and review your systems for signs of suspicious activity.
If you are not sure whether your systems were affected, or you want a partner who will be watching the next time a critical vulnerability is disclosed, contact Grand Rapids Tech. Our team can help you understand where you stand and build a plan to keep your business technology secure.