Critical PHP vulnerabilities: from the morning alert to patch deployment
This case study traces how the 1000ideas maintenance team responded to critical PHP vulnerabilities: from the morning warning and task assignment, through a risk assessment ahead of a client event, to patch deployments that same evening. It matters because a website that appears to work normally can still need an urgent security update. The response depends on patch availability, knowledge of the environment and clear ownership of each change.
On 21 October 2026, the PHP team released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they could allow an unauthenticated attacker to execute code on a server. The issue was in PHP itself, so updating application code or plugins alone was not enough.
Our preparations began that morning, before the patch was released. At 08:35, the team’s channel received a warning about the forthcoming vulnerability announcement. By 11:34, tasks had been created for individual projects. We were establishing which applications were affected and who was responsible for updating them.
Before the patch was released, we informed clients that we were working on our response to the vulnerabilities. Client communication ran alongside preparations for the updates.
The first three hours: from signal to tasks
Two hours and 59 minutes elapsed between the first signal and task creation. That measures how quickly we organised the work. Deployment still required an available patch, checks of the environment and a decision for each application.
All times in the timeline are Polish local time (CEST). We deployed patches on the evening of 21 October.
One threat, different responsibilities
The work covered custom applications, WordPress and Magento. The update process depended on how each system was run. Containerised applications required attention to the PHP image and configuration in the repository. Other environments also depended on the administrator’s access.
We divided the work among project developers and the administrator. For some websites, the update was assigned to the hosting provider. Separating these roles helped establish who would make each change and who needed to confirm its completion.
An evening event changed the risk assessment
One client had an event scheduled on their platform at 19:00 that same day. The team weighed two risks: leaving a vulnerable environment in place and destabilising the application shortly before the event. The discussion considered possible brief downtime during the change and the time needed to check the system.
Patch availability also depended on the distribution channel. At 17:15, a developer reported that the expected patched Docker image was not yet available. A release from the PHP team did not mean the fix could immediately be pulled in every image in use. We carried out patch deployments that same evening.
Patch deployments: from testing to production
The work also included rebuilding PHP with the official patch from the PHP security team. In the documented update process, the fix was checked in a test environment before deployment to production. A database backup was taken before that change.
The upload progress tracking mechanism used by one confirmed attack path was also disabled. The report states that file uploads and existing file size limits remained unchanged. This configuration change supplemented the official patch; it was not a complete fix on its own.
What this case shows about application maintenance
An application can appear to work normally while its runtime environment needs an urgent security update. In this case, the team had to establish the scope, assign responsibilities and account for both the client’s schedule and patch availability.
We also agreed that developers would report deployments to the project lead so clients could receive confirmation of the work. This account distinguishes decisions, deployment reports and updates assigned to hosting providers.
We adapted the update method to the environment, available permissions and patch distribution channel.
Who is responsible for urgent updates to your system?
If that responsibility is unclear, a review of the application, its dependencies and its environments is a useful place to start.
Technical sources
The sequence is based on internal team records, a developer’s report and confirmation of the evening deployment timing. Account current as of 23 October 2026. Client names and infrastructure details have been omitted.
