PHP2Shell: rapid response to critical PHP vulnerabilities in a complex enterprise environment

Case study · Client: a major telecommunications provider in Hungary · 28 October 2026

On 21 October 2026, two critical PHP vulnerabilities were disclosed that could allow unauthenticated remote code execution. Here is how Inshipia prepared before the fixes were even released, and how the patched PHP versions were deployed across a heterogeneous, high-availability environment.

Executive summary

The critical vulnerabilities in the PHP runtime known as PHP2Shell – CVE-2026-109618 and CVE-2026-109619 – were publicly disclosed on 21 October 2026 and required urgent action. Successful exploitation could allow attackers to execute code remotely on affected servers without authentication, putting data security and service operation at risk. [1–4]

In the client’s environment, the work covered web servers, the phpMyAdmin service and PHP-based components of the email services. The objective was to eliminate the security risk as quickly as possible while meeting high availability requirements.

Inshipia began preparing as soon as it received the advance notification. The team:

• identified affected systems and update options,
• prepared to obtain packages directly,
• used trial builds wherever possible to reduce uncertainty during the subsequent rollout.

Once the fixes were released, platform-specific deployment and build approaches were required, because prebuilt binary packages were not available in time for every environment.

Outcome: the patched PHP versions were successfully deployed to production across the affected systems, and the final checks confirmed that the patched environment was operating correctly.

Background and business risk

Affected services and technology environment

The work covered web servers, the phpMyAdmin service and the components of the email services that used PHP.

The environment included multiple FreeBSD versions, Debian- and Ubuntu-based systems, and infrastructure that started from boot images. Differences in PHP versions and runtime modes, custom modules and dependencies inherited from earlier system designs meant that the update approach had to be determined for each system individually.

The PHP2Shell vulnerabilities

PHP2Shell is the collective name for two groups of vulnerabilities in the PHP runtime, registered under two CVE identifiers. Both are rated critical, with a CVSS 4.0 score of 9.2. [1–4]

• CVE-2026-109618 – incorrect handling of out-of-memory (OOM) conditions: if request processing is interrupted by an out-of-memory condition before PHP’s internal data structures have been fully initialised, the runtime may treat those structures as valid data during request shutdown. This can lead to memory corruption and remote code execution. [2]
• CVE-2026-109619 – internal state left over from a previous request: internal state associated with an earlier request may persist after the memory it refers to has been freed. If the same PHP worker uses that state during a subsequent request, before normal initialisation, it may access memory that has already been freed, potentially enabling remote code execution. [3]

The vulnerabilities affect the PHP runtime itself, so updating applications alone is not sufficient to fix them. Actual exploitability depends on the PHP version, runtime mode (such as Apache mod_php or PHP-FPM), configuration and application. In a successful attack, code can execute with the privileges of the process running PHP; this does not automatically grant administrator access.

Complete remediation requires installing a PHP release containing the fixes – version 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on the supported branches – or an equivalent package containing the fixes, followed by a restart of all PHP processes. [1–3]

Business significance

Exploitation could have enabled unauthorised access to and modification of data and resources accessible to the affected PHP process, as well as disruption of services. Depending on the permissions and isolation in the environment, this could have put web content, application configurations, credentials, and connected databases or email data at risk. In addition to code execution, the researchers demonstrated the ability to read sensitive data from process memory. [4]

The client therefore had two simultaneous priorities:

• eliminating the security exposure quickly – a successful attack could have compromised data security and availability;
• maintaining service continuity – an inadequately prepared update could have caused application errors or service outages.

The work had to be prepared and scheduled to address both risks.

Challenges

Urgent remediation within an evening maintenance window

The update had to be prepared for services with high availability requirements, where planned maintenance was only permitted during the evening maintenance window. Despite the urgency, avoiding disruption visible to users and minimising any necessary interruptions remained essential requirements.

All of the following had to fit within the available time:

• deployment,
• the required restarts,
• checks of business-critical functions,
• and, if problems arose, rollback.

A server or PHP process starting successfully was not, on its own, sufficient evidence that the service was operating correctly.

Different platforms and custom build requirements

Custom PHP modules made it necessary to compile PHP from source in several environments. Build prerequisites, dependencies and compatibility had to be addressed separately for the different operating system and PHP versions.

Package availability also varied. Across the managed environments, the time between fixes becoming available in source code and the release of prebuilt binary packages ranged from several hours to one or more days. For certain combinations of platform, operating system and PHP version, no suitable updated package was available at the time of the work.

The use of boot images introduced an additional requirement: the fixes also had to be incorporated into the system images used at startup, ensuring that the patched environment would remain in place after a subsequent restart.

Legacy environment and verification constraints

System designs and custom dependencies accumulated over more than a decade added to the complexity. These prevented the team from applying the same update procedure to every server.

No central vulnerability scanner was available to verify remediation. Identifying affected systems and confirming that the fixes had taken effect therefore had to rely on system-level checks, alongside testing of business-critical application functions.

Inshipia’s preparation and response

1. Preparing on the basis of advance notification

The first advance notification only confirmed the existence of the vulnerabilities and the need to prepare for an update. Detailed technical information was still under embargo; the team also encountered withheld details in the PHP changelog.

From that point, Inshipia monitored Debian security announcements and the release of new packages in the Sury repository. The aim was to ensure that preparatory work would no longer delay deployment once the fixes became available.

2. Assessing affected systems and service impact

The team identified which systems had PHP installed, the interfaces or runtime modes through which it was used, and how it could be updated in each environment. The assessment also covered the extent of service disruption that a shutdown or restart would cause.

This made it possible to determine, system by system, where prebuilt packages could be used, where compilation from source was required, and where the impact of a potential service outage needed to be managed.

3. Preparing to obtain packages

Under normal operating procedures, Debian updates would have become available through the client’s internal package mirror during its scheduled synchronisation the following morning. The team prepared to download the required packages directly from the Sury repository so that obtaining the fixes would not have to wait for the next synchronisation.

4. Trial builds before the fixes were released

Wherever possible, Inshipia compiled the previous PHP version before the fixes were released. These trial builds were intended to identify and resolve issues with the build environment, dependencies and custom modules in advance.

As a result, a prepared build environment was already available when the new source code was released. However, successfully compiling the previous version did not replace the need to build the patched version and verify that the applications worked correctly.

5. Platform-specific builds and deployment

Once the fixes were released, several environments required the updated PHP version to be built from source rather than waiting for prebuilt packages. The following approaches were needed:

Environment or circumstance	Approach used
Debian-based systems with an internal package mirror synchronised daily	Obtaining Sury packages directly instead of waiting for the following morning’s synchronisation.
A FreeBSD system for which no suitable updated binary package was available at 22:00 on 21 October, six hours after the official release	Compiling PHP using the ports system.
A FreeBSD target system without a ports environment	Compiling in the ports environment of a separate virtual machine, then transferring the resulting binary to the target system.
An Ubuntu-based system	Manually compiling PHP from source, including the custom modules.

Using a binary produced in a separate build environment also required verification of its compatibility with the target system. The boot images and running environments also had to be kept consistent.

6. Production deployment, functional verification and completion

In addition to updating PHP, the production rollout included checks of related services and business-critical functions. Final verification confirmed that:

• the patched version was actually running,
• the required modules loaded,
• restarting from the boot images did not restore the previous state.

The fixes were successfully deployed to production across the affected systems.

Value delivered to the client

Inshipia’s work reduced obstacles to deployment before the fixes were even released. Identifying affected systems, assessing service impact, preparing to obtain packages directly and carrying out trial builds allowed several tasks to be completed in advance that would otherwise have consumed time during the evening maintenance window.

The build and deployment approaches selected for each platform meant that the work did not depend on the release of prebuilt binary packages or the internal package mirror’s daily synchronisation. As a result, the client successfully completed the urgent security work within the maintenance constraints, even in a heterogeneous legacy environment.

Lessons learned

This case demonstrates that the time needed to deploy a critical PHP update depends not only on the release of the fixes, but also on package availability, build prerequisites, application dependencies and verification. In this environment, a rapid response depended on existing knowledge of the systems and preparation completed before the fixes became available.

The experience also points to areas for further improvement. The following can reduce preparation time and uncertainty during the next urgent intervention:

• an up-to-date component inventory,
• a repeatable build process,
• consistent management of boot images,
• automated functional checks.

References

1. PHP – Security advisory: Critical remote code execution vulnerabilities, update now – PHP security advisory dated 21 October 2026.
2. PHP – CVE-2026-109618: RCE via OOM corruption
3. PHP – CVE-2026-109619: RCE via stale global state
4. Wiz Research – PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet