On October 21, the PHP project shipped an urgent security release for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, now widely nicknamed PHP2Shell. If your product runs on PHP, which includes every Laravel application, the practical question this week is how much of your estate you can honestly call patched and running the fixed version, and whether anything reached it before the fix did.
Most of the work sits outside the version number. Fixed releases exist for PHP 8.2 to 8.5, older branches get source backports at best, hosting platforms patch on their own schedules, and security vendors report exploitation attempts that began before the fix was public. A patch closes the door from here on. It cannot tell you who came through earlier.
This guide sets out what is confirmed and what is not, which versions and setups are affected, what remote code execution means for your application and data, how to prioritise and verify the fix, and what the incident says about maintaining PHP and Laravel applications. Where sources disagree, the article says so.
What has been confirmed about the PHP RCE vulnerabilities so far?
On October 20, the PHP security team gave advance notice of a release scheduled for October 21 at 14:00 UTC, covering two vulnerabilities that it rated CVSS v4.0 9.2. The CVE identifiers leaked before the planned date, and according to Tenable’s account of the PHP Foundation’s statement, the release had been planned for October 22 and moved up a day. The fixed versions arrived on October 21: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The two flaws are different bugs with the same outcome. CVE-2026-109618 comes from how PHP aborts a request that runs out of memory: in some code paths, internal request data can be reached before it is fully set up, and the cleanup that follows may treat that half-built data as valid. CVE-2026-109619 is a stale state problem: data owned by one request can survive after the memory behind it is freed, and a later request handled by the same worker may use it. PHP’s advisory describes both as routes to unauthenticated remote code execution. Both are flaws in the PHP runtime, and the PHP security team’s announcement calls the first one a vulnerability in PHP core, so they are not Laravel bugs, WordPress bugs or flaws in your application code.
On exploitation, the sources do not fully agree, so the careful reading matters. PHP’s advisory says a working exploit has been demonstrated against mod_php, where an unauthenticated request can trigger the attack before any application code runs. Several security vendors report attempts against real or decoy systems. Tenable’s summary says Amazon Threat Intelligence observed an attempt on October 17, four days before disclosure, followed by more on October 21 whose payloads and infrastructure Amazon says suggest multiple actors, and that Amazon is unsure whether any of those would have succeeded against production systems. watchTowr reports exploitation in its honeypot network, and SecurityWeek reports that several security companies saw attempts before the patches shipped. Huntress, by contrast, said that as of the afternoon of October 21 it had not seen exploitation across its own partner systems. None of the sources reviewed gives a verified public count of compromised organisations, and watchTowr noted on October 22 that neither CVE had been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog.
A further note arrived on October 23. PHP published an informational advisory about a separate identifier, CVE-2026-115560, describing an unlikely route to remote code execution that needs an unusual combination of settings. PHP suggests setting session.upload_progress.enabled=0 until the next regular release and says a full advisory will follow. It is not one of the two headline flaws, and PHP is handling it in its normal release cycle.
Which PHP versions and setups are affected?
PHP’s advisory says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php. The PHP security team’s announcement lists the affected supported branches as PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. Older, unsupported branches have no official release, and the UK National Cyber Security Centre advises organisations to treat any PHP version as potentially affected rather than limit the search to outdated ones.
PHP’s advisory says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php. The PHP security team’s announcement lists the affected supported branches as PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. Older, unsupported branches have no official release, and the UK National Cyber Security Centre advises organisations to treat any PHP version as potentially affected rather than limit the search to outdated ones.
| PHP Branch | Affected Releases | Fixed Release | Notes |
|---|---|---|---|
| 8.5 | Before 8.5.12 | 8.5.12 | Official fix |
| 8.4 | Before 8.4.27 | 8.4.27 | Official fix |
| 8.3 | Before 8.3.36 | 8.3.36 | Official fix |
| 8.2 | Before 8.2.35 | 8.2.35 | Official fix; the branch reaches end of life on December 31, 2026. |
| 8.1, 8.0 and 7.4 | Treat as affected | No official release | Minimal source backports from the PHP security team; some distributions and LTS vendors backport fixes. |
| Older than 7.4 | Treat as affected | None published by the PHP project | Move to a supported branch. |
Laravel applications are exposed because they run on PHP, not because of anything in the framework. Laravel News makes the same point: the issue covers the way most Laravel apps run in production. That distinction decides who fixes what. Upgrading Laravel itself does not fix this. The runtime has to change, whether that runtime is a server package, a container base image or a platform runtime.
On Laravel’s own platforms, responsibility splits. As Laravel News summarised Laravel’s status on October 21, Laravel Cloud applications were patched in place, Forge servers needed a manual PHP update and Vapor applications needed a redeploy. Those details were changing by the hour, so use Laravel’s status page rather than this article for the current position
What does remote code execution mean for your application and data?
Remote code execution means someone outside your organisation can make your server run instructions of their choosing. Here, according to PHP, the attacker does not need to log in, and on mod_php the attack can trigger before any of your application code runs. Datadog’s security researchers reproduced the out-of-memory flaw with an unauthenticated HTTP POST request and noted that application-level authentication cannot block an attack that PHP processes before the application sees the request.
The injected code runs with the privileges of the PHP worker, so the realistic exposure is whatever that worker can reach. On a typical web server that includes application source code, environment files and the credentials inside them, database connections, uploaded customer files and any cloud or API keys the application uses. That is a reasoned reading of how PHP deployments usually work, not a finding from this incident. The sources reviewed do not describe what attackers have done after gaining access.
For a business, the useful question is not how clever the flaw is. It is whether customer data, secrets and uptime depend on a server you can show is patched. If an attacker ran code on a web server, anything that server could read is in scope for the investigation. A patch applied afterwards stops new attacks of this kind. It does not remove anything an attacker may have left behind, which is why the steps below include a look back.
How should you prioritise the response?
PHP’s guidance is blunt: updating is the only complete fix, and the configuration changes it lists reduce exposure to specific attack paths without making an installation safe. Within that, the order of work matters, because most teams find more PHP than they expected.
Step 1 - Find every place PHP runs
Start with an inventory, internet-facing systems first. The NCSC’s guidance is to identify systems running PHP across the whole infrastructure, prioritising those exposed to the internet, and not to limit discovery to old versions. In practice that means production web servers, staging environments reachable from the internet, container images in your registry and CI pipelines, and any third-party appliance or service that bundles PHP. The NCSC specifically asks organisations to watch for vendor updates to products that may bundle PHP. Background workers that share a PHP build carry lower exposure, but they tell you which images need rebuilding.
Step 2 - Rank by exposure and by who controls the patch
Rank internet-facing systems first, then mod_php deployments, then anything on a branch without an official fix, then anything hosted where you do not control the runtime. For PHP 8.1 and older, the decision is between a vendor backport, a build from the PHP security team’s source backports, or an upgrade. Building from source works, but it also means you now own every future PHP patch for that server. If you are on 8.2, patch now and start the move to a newer branch, since 8.2 reaches end of life on December 31, 2026. Each Laravel release has a minimum PHP version, so the framework upgrade and the PHP upgrade often have to be planned together, and this guide on when and how to move to the latest Laravel version covers the sequencing.
Step 3 - Patch through an expedited change, not around the change process
The PHP team is asking for immediate updates, which makes skipping review tempting. The better answer is an expedited route through your normal change process: a staging deployment, a smoke test of the flows that matter, a rollback path and a named owner. Test the paths the vulnerabilities touch, namely file uploads and sessions, along with whatever your own code depends on.
How you apply the update depends on where PHP lives. Distribution packages come from your vendor, and because some distributions backport fixes into older version numbers, the version string alone can mislead, so read the vendor’s advisory. Containers need a rebuild from a patched base image and a replacement of the running containers. If you run servers through Forge, the update is a manual step per server, and Laravel says servers on Ubuntu 20.04 or older cannot receive it and should be replaced, as Laravel News reported. A complete guide to Laravel Forge for app owners explains how that server model works. Teams hosting on AWS should look at where the PHP runtime is baked in, whether that is an image, a container or a managed service, and these approaches for hosting a Laravel project on AWS lay out the options.
If you cannot update yet, PHP lists interim measures and is explicit that they do not make an installation safe. For CVE-2026-109618 they include removing PHP’s own memory ceiling in a way applications cannot override, setting a low request size limit, enforcing request limits at the web server or proxy, and using a container memory limit as an availability boundary. For CVE-2026-109619 they include disabling session upload progress at the server level and restarting every worker. PHP also says not to rely on ini_set() or .user.ini files for that setting, a detail that is easy to miss. The trade-offs are real. Removing PHP’s memory limit leaves your infrastructure as the only memory safeguard, and PHP lists a container-level limit as an availability boundary alongside it. A web application firewall helps only for traffic that passes through it: Cloudflare’s CTO called its rules a stopgap, and Tenable notes they only cover traffic routed through Cloudflare. CERT-EU’s advice for teams that cannot update is to consider isolating internet-facing applications from public networks until a fix is applied and verified.
Step 4 - Verify what is actually running
After the update, confirm the version the web runtime is using, not just the one that was installed. Laravel’s guidance for Forge servers is to run php -v on the server. On machines with several PHP versions side by side, the command line binary and the web workers can differ, so also confirm the version behind the web process, and confirm that every worker was restarted. PHP’s mitigation guidance repeatedly calls for restarting every worker, and the same discipline applies to a version upgrade, because a long-running worker keeps the code it started with.
Then check each environment: production, staging, the image in your registry and any copy built before the patch. An external scan that fingerprints PHP versions can confirm what is exposed, though a scan result is a snapshot rather than proof of what ran last week.
Step 5 - Look back as well as forward
Because attempts reportedly began before disclosure, patching on October 23 does not tell you what happened on October 17. Amazon recommends, as Tenable reports, that investigations start from at least October 17, not from the disclosure date. Review web server and application logs from that window for unusually large or malformed POST requests, worker crashes or out-of-memory errors, and unexpected child processes. Elastic’s analysis notes that whatever the root cause, the aftermath tends to look the same, a web server process spawning a shell or pulling down a payload, which makes behaviour-based monitoring a practical starting point. If anything looks wrong, treat credentials stored on that server as exposed, rotate them, and involve a security specialist before cleaning up so that evidence is not lost.
When should you bring in a qualified engineer or security specialist?
Some situations justify outside help rather than a late-night update. Bring in a qualified engineer when your application runs on PHP 8.1 or older and you must choose between a vendor backport, the source backports and an upgrade that may force a framework upgrade at the same time. Bring in a security specialist when logs from the exposure window show anything unexplained, when you do not control the hosting layer and cannot get a straight answer from the provider about what was patched and when, or when regulated or customer data lives on the affected servers. Evidence preservation, customer notification and regulatory duties belong with people qualified to handle them.
What does this incident reveal about maintaining PHP and Laravel applications?
Most teams track framework and package versions through Composer and treat the PHP runtime as someone else’s job. This incident sits in the layer below that. Knowing your Laravel version tells you little about whether the PHP under it is patched. A maintenance process needs the runtime version recorded per environment next to the dependency list, with a named owner for each. The advice in these Laravel security practices on keeping first-party and third-party packages current and auditing regularly applies here, and this incident extends the same discipline down to the runtime.
The branches without an official fix are the ones that were already out of support. PHP 8.1 and older receive no updates from the PHP project, and 8.2 reaches end of life on December 31, 2026. Teams on those versions now face this incident again as a calendar problem: sooner or later a critical fix arrives and there is no release to install. When an ageing application is a revamp candidate rather than a patching candidate is the subject of this list of signs that a Laravel application needs a revamp.
The compressed timeline is the lesson for process owners. Details leaked, the release moved a day earlier, and attempts were reported before a fix existed. A team that needs a week to decide who can approve an emergency deploy has spent most of that window. What helps is a pre-agreed expedited change path, a staging environment close enough to production for the test to mean something, a rollback plan, and logging that can answer what ran on a server after the fact.
Patch speed is also only one layer. Running PHP workers with the least privilege they need, limiting what the web tier can reach on the network, and keeping secrets out of places the web process can read where the platform allows it make the difference between a code execution bug and a full compromise. None of that replaces patching, and none of it is specific to this incident. It is the reason the question of what a worker could reach deserves an answer before the next advisory, and the common security pitfalls in Laravel applications are a useful place to start that review.
What should you do next to secure your PHP and Laravel applications?
The facts are narrow even if the impact is wide. Two critical flaws sit in PHP itself, fixed releases exist for 8.2 to 8.5, source backports exist for 7.4 to 8.1, the exploitation picture is still being reported, and a follow-up advisory arrived on October 23. The work is just as narrow: take an inventory, patch the exposed systems first, verify the running version, and look back to October 17. Everything else, from end-of-life planning to hosting ownership, is the maintenance conversation this incident forced. Check the linked advisories again before you act, since details may change.
If you need help assessing your PHP or Laravel application’s security or planning an upgrade, talk to our team.
Your queries, our answers
PHP2Shell is the nickname security vendors use for the pair of flaws CVE-2026-109618 and CVE-2026-109619, two critical remote code execution vulnerabilities in PHP itself that PHP rated CVSS v4.0 9.2. Tenable’s FAQ is one of several vendor write-ups that use the name, while PHP’s own advisory refers to the CVE identifiers.
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fixes. PHP 8.1 and older receive no official updates, but the PHP security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide their own backported fixes.
Yes, in the sense that any application running on an affected PHP runtime is exposed, whatever the framework. Tenable notes that WordPress, Drupal, Joomla, Laravel and Magento all run on PHP. The fix is applied to the PHP runtime, meaning the server package, container image or platform runtime, rather than by upgrading the framework.
Several security vendors report exploitation attempts, including one that Amazon Threat Intelligence says it saw on October 17, four days before disclosure. watchTowr reports exploitation in its honeypot network, while Huntress had not seen it across its partner systems as of the afternoon of October 21. The sources reviewed do not give a verified count of compromised organisations, and neither CVE was in CISA’s KEV catalog as of watchTowr’s October 22 update.
Not completely. PHP states that updating is the only complete fix and that its interim measures reduce exposure to specific attack paths without making an installation safe. Those measures include server-level settings, request size limits at the web server or proxy, and a container memory limit. A firewall rule helps only for traffic routed through it, and CERT-EU suggests considering isolating internet-facing applications until a fix is verified.
Plan a move to a supported branch and treat any interim route as a bridge. The routes are a distribution or LTS vendor package with a backported fix, a build from the PHP security team’s source backports, or an upgrade. Because PHP 8.2 ends on December 31, 2026, a newer branch avoids a second move. Each route short of an upgrade carries an ongoing maintenance cost, since the PHP project no longer ships updates for 8.1 and older.
Compare the running version against the fixed releases above, and confirm that the PHP workers were restarted after the update. Laravel’s guidance for Forge servers is to run php -v on the server. If several PHP versions are installed side by side, also confirm which version the web process uses, since it can differ from the command line one. On distribution packages, read the vendor’s advisory too, because some vendors backport fixes without changing the upstream version number.
It closes this route for the future, but it does not tell you whether the server was reached earlier. Attempts were reported from October 17, so review logs from that date, look for unexpected processes started by the web server, and rotate credentials stored on any server that shows signs of compromise. Keeping PHP workers on narrow privileges and a narrow network reach limits the damage if a future flaw of this kind appears.
What happens after you fill-up the form?
Request a consultation
By completely filling out the form, you'll be able to book a meeting at a time that suits you. After booking the meeting, you'll receive two emails - a booking confirmation email and an email from the member of our team you'll be meeting that will help you prepare for the call.
Speak with our experts
During the consultation, we will listen to your questions and challenges, and provide personalised guidance and actionable recommendations to address your specific needs.
