Last updated: October 23, 2026. We'll update this article as PHP and Linux distributions publish new information.
PHP2Shell is the nickname of two critical vulnerabilities in PHP that let an attacker run code on a web server without logging in. PHP released the fixes on October 21, 2026, and IT and security teams now need to know which of their servers and computers run a vulnerable PHP version, so they can patch those first.
If you're dealing with PHP2Shell right now, start with the action plan below. Then check which PHP versions are vulnerable and follow the steps to find every vulnerable PHP install with InvGate Asset Management, using a Smart Tag to build the work list and a dashboard to track the fix.
How to check if you're vulnerable to PHP2Shell: action plan
These five steps take you from the first alert to an environment without vulnerable PHP versions. The sections below cover each one.
- Find every server and computer that runs PHP, using your software inventory.
- Compare each installed version with the patched releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On Linux, check your distribution's fixed package instead.
- Start with internet-facing servers and with branches older than 8.2, which need a full upgrade.
- Apply the patched release or your distribution's fixed package, and restart the web server or the PHP processes.
- Track the progress until no vulnerable version is left.
Which PHP versions are vulnerable to PHP2Shell
Every PHP release older than the patched versions is affected, including the 7.x and 5.x branches. PHP only ships fixes for the branches it still supports, so the branch you run decides whether you patch or upgrade.
According to PHP's supported versions page, 8.2 reaches End of Life on December 31, 2026, so a server on 8.2.35 is protected from PHP2Shell and still needs an upgrade plan. Servers on 8.1 or older run deprecated software that stays exposed until it moves to a supported branch or gets a fixed package from its Linux distribution or long-term support vendor.
Which PHP2Shell patch to apply
According to PHP's advisories, updating to a patched release is the only complete fix. On a supported branch, that means moving to the patched version of the same branch; on 8.1 or older, it means upgrading to 8.2 or later, or installing the fixed package your distribution or long-term support vendor provides. Restart the web server or the PHP processes afterwards so they load the new version.
Linux distributions and long-term support vendors received the patches in advance, so check your vendor for updated packages.
What to do if you can't update right away
PHP also lists temporary configuration changes, mostly around memory limits and upload settings, for teams that can't update right away, and it states that they don't make an installation safe. Until a server is patched, limit its exposure to the internet, and run the update through your usual Patch Management process so every unpatched server gets an owner and a deadline.
How to find every vulnerable PHP install with InvGate Asset Management
InvGate Asset Management is IT Asset Management software that offers an enterprise experience without the complexity or the price of one, and its software inventory records the PHP version installed on each computer the Agent covers. With a Smart Tag and a dashboard, you get the list of assets to work on and a view of how the fix is progressing.
The inventory comes from four sources: the Agent, network discovery, integrations and manual or CSV import. This tutorial relies on the software installations the Agent reports, so the servers and computers you want to check need the Agent installed.
1. Find assets running PHP in the Asset Explorer
Start in the Asset Explorer with a filter that keeps every asset with PHP and leaves out the ones already on a patched release. All the conditions go in the same group, so an asset has to meet every one of them:
- Go to Assets and open the filters of a new view.
- Add Computer > Software Installations > Software Name, is, PHP.
- Add Computer > Software Installations > Reported Version > is not > 8.2.35.
- Add the same Reported Version condition for 8.3.36, 8.4.27 and 8.5.12.
- Click Update to see every asset that runs PHP on a version without the fix.
The filter uses Reported Version, which holds the exact release (8.3.36). Market Version holds the branch (8.3), and the dashboard uses it later to group the results by branch.
2. Save the filter as a Smart Tag
A Smart Tag turns the filter into a list that maintains itself. Assets join the tag when they match the conditions and leave it when they stop matching, for example after the Agent reports a patched version:
- With the filter applied, click Quick Smart Tag, next to Update.
- Name the tag "PHP2Shell: vulnerable", pick a color, add a description and click Create.
The tag is applied in the background, so the first assignment can take a while on large inventories, while the filtered view shows the results right away. When PHP publishes newer releases, add them to the excluded versions so patched assets leave the tag.
3. Work through the list of affected assets
The tag is the list of assets your team needs to work on. Open it from the Asset Explorer to see the owner and location of every asset, and start with the internet-facing servers. Assets on a branch older than 8.2 need a branch upgrade, which takes longer and needs to start now, and assets on 8.2 or later only need the patched release of their branch.
Check Linux servers against your distribution's security advisory before scheduling an upgrade. Distributions such as Ubuntu ship the fix under the original version number, so a server can appear in the tag and already be protected.
4. Build a dashboard to track PHP2Shell remediation
The Smart Tag gives your team the work list, and a dashboard shows the exposure by risk and the progress at a glance. Go to Dashboard, click + to create a custom dashboard and add these five charts, built as the walkthrough above shows:
- Assets running PHP: the total number of assets with PHP installed.
- Unsupported PHP versions: assets on a branch older than 8.2, grouped by location.
- PHP supported versions: installations on 8.2 or later that still need the patch, grouped by branch.
- Assets with the latest PHP version: assets already on 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
- Software installations by Market version: every PHP installation without the patch, grouped by version.
Grouping unsupported versions by location shows which sites carry the most exposure and need an upgrade first, and the chart of supported versions shows which branches still need the patch. As your team updates servers and the Agent reports the new versions, the unsupported and supported charts shrink and the latest-version chart grows, which gives you a progress report to share with security and management.
Conclusion
PHP2Shell affects every PHP release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and updating is the only complete fix. The hard part for most IT teams is knowing where PHP runs, and a software inventory answers that: with InvGate Asset Management, a single Smart Tag gives you the assets to work on and a dashboard shows how the fix is progressing.
The same approach works for the next critical vulnerability in a widely used component. To try it with your own inventory, start a free trial or talk to Sales.
Frequently Asked Questions
These answers cover the questions that come up most while teams check their exposure to PHP2Shell. Each one points to the official source where it applies.
What is PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?
PHP2Shell is the nickname for two vulnerabilities in the PHP core: CVE-2026-109618, a memory corruption triggered by out-of-memory errors, and CVE-2026-109619, a flaw that lets data from a previous request survive in memory and get reused. Both have a CVSS v4.0 score of 9.2 and allow remote code execution without authentication. According to PHP's security announcement, every PHP installation that serves web requests is at risk, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, and the risk is highest for mod_php, where PHP confirms a working exploit with default settings.
How do I check my PHP version?
Run php -v in a terminal on the server: it prints the PHP version and the interface it runs as, such as cli, as PHP's manual shows. The web server can use a different PHP build, so also check it with phpversion() or phpinfo() in a page it serves, and delete that page afterwards. In InvGate Asset Management, the Reported Version field shows the exact PHP version of every computer that runs the Agent.
Is PHP 8.3.6 on Ubuntu 24.04 vulnerable to PHP2Shell?
Not if its package is 8.3.6-0ubuntu0.24.04.13 or later. Linux distributions often add security fixes to the PHP version they already ship and keep its original number, so a patched Ubuntu server still reports 8.3.6. Compare the package version with your distribution's security advisory, such as Ubuntu Security Notice USN-8948-1.
Are appliances and other products that bundle PHP affected?
They are affected when they run a vulnerable PHP version to serve web requests. Many appliances and self-hosted applications ship their own PHP, so check each vendor's security advisory for a fixed release. InvGate Asset Management reports the PHP installed on computers that run the Agent, so for appliances the vendor's advisory is the source to follow.
Is WordPress affected by PHP2Shell?
WordPress runs on PHP, so a WordPress site is exposed whenever its server runs a vulnerable PHP version. The fix happens at the server level: update PHP there, or ask your hosting provider to do it, since WordPress updates leave the PHP version as it is.
