PHP2Shell: What Businesses Running Older PHP Systems Should Do Next

Last updated: October 22, 2026.

On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities known as PHP2Shell (CVE-2026-109618, CVE-2026-109619). They let an attacker run code on a server without logging in. The risk was serious enough that several European government bodies took their websites offline until they could update.

Most PHP websites will be patched within days. For many businesses, though, the harder question comes after that: what if your system cannot be patched, or nobody knows which version it runs?

This article is for business owners and IT managers who run a website, online store or internal system built on PHP, especially one that has been running for years.

How hard the fix is depends on your system

Patches exist only for supported PHP versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. That leaves three situations:

• Running PHP 8.2 or later: update to the patched release and you are done. This usually takes a few hours, or your hosting provider does it for you.
• Running PHP 7.4, 8.0 or 8.1: these versions are end of life. This time there are source backports from the PHP team and patched packages from some Linux distributions, but there is no guarantee of that next time.
• Running PHP 7.3 or older: there is no patch. The only safe path is an upgrade.

The worrying part is how many business systems fall into the second and third groups. A website or application built five to eight years ago keeps working, so nobody touches it, and over time nobody really knows what is inside.

Signs your PHP system is at risk

None of these mean you have been attacked. They do make responding to flaws like PHP2Shell much slower and more expensive:

• Nobody knows which PHP version the system runs. When a security alert comes out, you cannot answer the first question: are we affected?
• The person or company that built it no longer supports it. There is no documentation and nobody responsible for updates.
• The framework or platform is very old, for example Laravel 5.x/6.x, CodeIgniter 2/3, or WordPress with many abandoned plugins. Moving to a newer PHP means upgrading the framework too.
• The system has been patched many times by different people, with no automated tests. Every update feels like it might break something.
• There is no regular maintenance. The system only gets attention when something goes wrong. This is the gap that SLA-based maintenance and operations is meant to close.

If two or three of these sound familiar, PHP2Shell is a good moment to take a serious look at the system instead of applying a quick fix and moving on.

Three options for an older PHP system

1. Apply a temporary fix and keep things as they are

Install your distribution's patched packages or apply mitigations (turn off file uploads if unused, block suspicious requests at a WAF).

• Fits when: you need to act within days while you prepare a longer-term plan.
• Limits: it does not fix the root cause. The system still runs on an unsupported version and will face the same problem with the next vulnerability.

2. Upgrade step by step

Move PHP and the framework to supported versions in stages, keeping business logic and screens as they are.

• Fits when: the system still meets business needs and only the platform has aged.
• Watch out for: PHP 8 changed a lot compared with PHP 7. Some functions were removed, type checks are stricter and older libraries may no longer work. Plan for a code review, library updates and regression testing of key business flows. How long it takes depends heavily on the size and condition of the existing code.

3. Rebuild or move to a new platform

Rebuild the system on a new foundation, possibly improving business processes at the same time.

• Fits when: the system no longer meets business needs, or repairing it would cost more than rebuilding.
• Limits: the highest cost and longest timeline, with data migration and a period of running both systems in parallel. Our article on building business systems with C# / .NET and Java covers modernizing in stages in more detail.

For most businesses, the sensible approach is to combine options 1 and 2: apply a temporary fix now to reduce the immediate risk, and plan an upgrade over the next few months. If you are looking for an outside partner, see how to evaluate and choose an offshore vendor.

A five-minute self-check

Answer each question to see how much risk your system carries:

What to do this week

1. Confirm the PHP version in use (see the appendix below).
2. Update to a patched release if you run PHP 8.2 or later. On hosting, ask your provider whether they have updated.
3. If you cannot update right away, apply mitigations and schedule a system review.
4. Check for unusual activity if the server was unpatched on October 21–22: unknown PHP files, unfamiliar admin accounts, spikes in outbound traffic. If anything looks wrong, rotate database passwords, API keys and other secrets on the server.
5. Keep backups from before October 21 and do not overwrite them.

Conclusion

PHP2Shell will fade from the news within weeks, but unmaintained PHP systems will still be there and will face the same risk with the next vulnerability. For a business, the real cost of putting it off is not one patch. It is having to react under pressure every time something happens.

ARIS Vietnam develops and maintains PHP/Laravel systems for businesses, including reviews of existing systems, upgrades from PHP 7.x to 8.x and ongoing maintenance. If you would like to talk about your current system, contact us or read more about our software development services.

Appendix: technical details

Affected and patched versions

Every PHP setup that handles web requests is affected, including PHP-FPM, Apache mod_php and php-cgi. Because the bug is in PHP itself, WordPress, Laravel, Magento and custom code all need checking. Updating WordPress or plugins does not fix it.

How to check your PHP version

• VPS or dedicated server: php -v for the command-line version and php-fpm -v for the version serving the web. The two can differ.
• Most reliable: create a temporary info.php file containing <?php phpinfo();, open it in a browser, then delete it immediately.
• cPanel, Plesk, DirectAdmin: look for "Select PHP Version" or "PHP Settings".
• Docker: check the image tag, pull the new image and rebuild the container.
• WordPress: Tools → Site Health → Info → Server.

Temporary mitigations

If you cannot update yet: turn off file_uploads if the site does not need uploads, block unnecessary multipart/form-data requests at the web server or WAF, and turn off session.upload_progress.enabled. These only reduce the risk. The PHP team is clear that updating is the only complete fix.

Sources

• Help Net Security: PHP2Shell: Critical PHP vulnerabilities patched
• Tenable: php2shell FAQ
• Sophos Security Advisory: PHP2Shell
• AlmaLinux: Patched PHP packages released
• CNBC: Government websites go dark as software flaw sparks security scramble