For security teams responding to PHP2Shell, the immediate priority is finding affected systems and getting them protected. That starts with establishing where PHP is actually running. An incomplete inventory can leave a vulnerable server outside the response entirely.
A customer has already used Furl’s Forge to find PHP in their environment. In a separate demo, I used Forge to investigate and remediate a vulnerable PHP installation on a web server I built for the session.
The demo exposed three problems that can complicate the response: inventory queries missed PHP, a server built that day contained vulnerable software, and verifying the fix required checking the full Ubuntu package revision.
With operator approval, Forge upgraded 12 PHP packages, restarted the service, and checked the resulting package revisions and service state.
These findings matter because responding to PHP2Shell requires more than distributing an advisory or initiating a patch job. Teams need to identify affected installations, apply the appropriate update or interim protection, and verify what is running afterward. The demo shows how Forge carried that work from investigation through an approved fix.
What security teams need to do now
PHP2Shell refers to two critical vulnerabilities in PHP, software used to run websites and applications. The flaws, CVE-2026-109618 and CVE-2026-109619, can allow attackers to execute code remotely. The PHP project describes them in its out-of-memory advisory and stale request state advisory.
Because the vulnerabilities are in PHP itself, updating an application such as WordPress does not replace the affected PHP software underneath it.
The response needs to cover five steps:
- Find affected installations. Establish where PHP is running, which versions and vendor packages are installed, and which applications depend on them. Verify unexpected inventory results.
- Apply the appropriate security update. Use the PHP project’s guidance or the advisory for the operating system or product supplying PHP.
- Protect systems that must wait. Apply the relevant vendor-recommended mitigations, understand their limits, and track those systems until the underlying issue is resolved.
- Verify the running system. Confirm the corrected software is installed, restart affected services as required, and test the application.
- Investigate possible compromise. Updating vulnerable software does not remove anything an attacker may already have installed.
For a CISO, those steps translate into concrete questions: What have we assessed? What remains exposed? What has been fixed and verified? What requires further investigation?
Our demo illustrates why answering those questions requires more than checking an inventory or issuing a patch instruction.
Forge found PHP that inventory queries missed
I started the session with a direct question:
“Do I have PHP in my environment, and is it vulnerable to PHP2Shell?”
The demo environment contained one Ubuntu server and two Windows servers. Forge’s initial inventory queries returned no PHP results.
Forge continued with searches on the systems themselves. On Ubuntu, it found PHP files, then queried the local package manager to establish what was installed. Service checks showed PHP running a WordPress installation through nginx and PHP-FPM, the service processing PHP requests.
The searches on the two Windows servers found no PHP binaries.
The session did not establish why the inventory queries missed PHP. It established that the installation existed and needed assessment.
During an emergency response, an empty query result should not become a clean bill of health without understanding what the query covers. In this case, gathering additional evidence identified a system the initial results had missed.
The investigation also had boundaries: it was not a comprehensive inspection of container image contents. Those require separate assessment.
A newly built server was already running vulnerable software
The affected Ubuntu server had been built earlier that day. It nevertheless had an older PHP package installed, while a corrected package was already available from its configured software repositories.
A newly provisioned server can inherit old software from its image or installation process. The age of the machine does not establish whether its software is current.
This creates two responsibilities. The immediate task is to update the affected host. The follow-up is to review how it was built so that the next server does not start with the same problem.
The demo confirmed the installed package and the recent build timeline. Establishing the exact provisioning failure would require inspecting the build process.
Forge identified the correct vendor update
Determining whether a system is fixed requires more than reading the headline PHP version.
Operating system vendors can apply security fixes to an existing PHP release without changing its main version number. Teams need to check the full package revision against the advisory for that operating system.
For Ubuntu 22.04, Ubuntu’s security notice identifies the corrected PHP 8.1 package revision as 8.1.2-1ubuntu2.28.
Installed before remediation: 8.1.2-1ubuntu2
Corrected package: 8.1.2-1ubuntu2.28
Both begin with 8.1.2. The additional revision information distinguishes the older package from the one containing the fixes.
The practical point for security leaders is straightforward: verification must account for how the software vendor delivers its updates. A version check that ignores that context can produce the wrong answer.
The operator approved the patch, and Forge executed it
Before patching, the operator requested a targeted check for signs of compromise.
Forge examined recent PHP file changes, potential malicious scripts, processes and network connections associated with PHP, locations commonly used to maintain unauthorized access, and available logs.
Those checks found no signs of compromise within their coverage. They did not prove that the system had never been compromised or replace a full incident investigation.
The operator then approved the patch. Forge upgraded 12 installed PHP packages and restarted PHP-FPM.
The restart matters because replacing software on disk does not establish that an existing service has loaded the corrected code. The workers handling requests also need to be updated.
Afterward, Forge checked the resulting state. The session recorded:
- All 12 upgraded PHP packages at the expected corrected revision.
- PHP-FPM running, with new worker start times.
- A local request through the web server returning an HTTP redirect.
These checks provide evidence that the package upgrade completed, the PHP service restarted, and the local web endpoint responded. Production validation should also test the application functions the business depends on. The demo did not measure downtime or establish that every WordPress workflow worked.
Managing the exposure window requires tracking what remains
Some systems can be updated immediately. Others require application testing, a vendor update, or a scheduled change.
Configuration mitigations can help address specific attack paths while that work proceeds. Teams need to understand what each measure covers and keep unresolved systems visible. Applying a protective setting and installing a corrected runtime have different completion criteria.
In this demo, a vendor update was available. Forge identified the appropriate package, applied it with approval, restarted the affected service, and checked the result. Its role extended from investigating the finding to executing and verifying the change.
Guidance can also evolve during the response. On October 23, PHP published an additional session upload progress advisory, recommending disabling that feature pending the next regular bugfix release to address an unusual remote code execution scenario. The recorded demo predates that guidance and does not show that configuration change.
A verified change needs to remain tied to the issue and guidance it addresses.
Turning the response into continuous remediation
The one-time patch addressed the identified PHP2Shell package vulnerability on the Ubuntu host. The inventory discrepancy and provisioning process still required follow-up.
Forge also proposed turning the work into recurring coverage through a Check to detect the condition, a Strategy defining the remediation, and a Scope controlling where remediation could run. The recorded session completed the one-time patch; it did not activate those recurring artifacts.
That is the opportunity for continuous remediation: use the findings from an investigation to improve how the next affected system is detected and fixed.
For a security leader managing PHP2Shell, progress needs to be supported by evidence: which systems were assessed, which received fixes, whether the corrected software is running, and what remains unresolved.
Forge demonstrated that workflow on the affected demo host, under operator control. It found an installation the inventory queries missed and carried the response through to an approved, verified package upgrade.
Book a demo to see how Forge investigates affected systems and executes approved remediation.
About the author
Derek Abdine is Furl’s founder and CEO. Previously, he served as CTO at Censys and Head of Labs at Rapid7, leading work in security research, threat intelligence, data science, and internet scanning. He holds five cybersecurity patents, and his research has been cited in the 2019 Economic Report to the President. He has also delivered briefings at the White House and on Capitol Hill.
His background in vulnerability discovery informs Furl’s focus on continuous autonomous remediation.