Preparing the response
Information checked on 21 October 2026 at 12:05 mainland Portugal time (UTC+1). The official announcement still described the security release as scheduled for 15:00 local time.
Organisations using PHP for their websites, online shops or applications should contact their technical teams and prepare an urgent update. The PHP security team announced a security release for 21 October 2026 at 14:00 UTC, equivalent to 15:00 in mainland Portugal, to address two critical vulnerabilities rated CVSS v4.0 9.2 out of 10. [1]
At the time of this review, the official announcement still described the release as forthcoming and stated that technical details, affected versions and fixed versions would be published with the update. Hosting providers may make their packages available at different times. [1]
Cyberprotech® recommends identifying systems now, confirming who can update PHP and assessing temporary reductions in Internet exposure. Waiting for the patches should be part of a prepared response with assigned responsibilities and defined checks.
What is known about the vulnerabilities
CERT-EU identifies the flaws as CVE-2026-109618 and CVE-2026-109619 and warns of potential unauthenticated remote code execution. A successful attack could allow code to run on the server with the affected process permissions, compromising the website and data accessible to that process. [2]
PHP2Shell is the name used in public reporting about these vulnerabilities. Their exact scope still depended on official details: CERT-EU states that versions from PHP 5 onwards could be affected, but this does not establish that every PHP website can be exploited under the same conditions. [1][2]
WordPress websites and other PHP applications should be checked, including internal services, subdomains and test environments accessible from the Internet. The hosting provider, infrastructure administrator or maintenance company may be responsible for the update. Updating WordPress, themes or plugins does not establish that the server PHP runtime has been updated.
The circulating configuration change does not establish protection
Suggestions are circulating to disable file upload progress tracking using this php.ini setting:
session.upload_progress.enabled = Off
The same option is also being suggested for a PHP-FPM pool:
php_admin_flag[session.upload_progress.enabled] = off
The option exists, and the PHP documentation allows it to be disabled when the feature is not used, as a general security measure. This does not validate its effectiveness against these two CVEs. It disables upload progress recording; it does not block all file uploads or fix vulnerable code. The PHP-FPM form applies the same option in a different configuration context. [3]
The official PHP announcement recommends preparing to upgrade as soon as the security release is available. The official sources consulted do not support declaring a system protected simply because this option has been disabled. [1]
Cyberprotech® recommends that this change must not be used to close the alert, postpone patching or assure customers that the risk has been eliminated. If it has already been applied, PHP remediation still needs to be confirmed.
Temporary protections require technical verification
The official Cloudflare changelog includes emergency WAF updates dated 21 October, including updates to the free ruleset, targeting anomalous request patterns. This alone does not establish complete coverage of both CVEs in each deployment. Temporary protection must accompany patching. [6]
Where a website uses this service, the technical team should confirm that traffic actually passes through the proxy, relevant rules are active and no exceptions or direct access to the server bypass inspection. Cloudflare documents origin protection measures, including restrictions on traffic that can reach it. [7]
Improvised multipart/form-data blocking, isolated php.ini changes or rules copied from social media must not be presented as complete protection. Such measures require technical validation and assessment of their impact on forms, uploads and application integrations.
Where immediate remediation is not possible, CERT-EU recommends considering temporary isolation of Internet-facing applications. The decision should account for exposure, the data processed and service continuity. [2]
As a practical application of that guidance, Cyberprotech® recommends assessing access restrictions at the network or web server before requests reach PHP. For institutional websites, a temporary static page with essential contact details can preserve communication, provided the PHP application is genuinely inaccessible to the public. A maintenance mode implemented within WordPress does not establish this isolation.
Syhunt: a temporary option to assess for Apache
The php2shell-protection project provides an Apache rule rejecting multipart/form-data POST requests before PHP, plus a functional test. It may be assessed where those requests are unnecessary. It also blocks legitimate forms and uploads. [12]
A 403 test result does not prove CVE remediation. The rule depends on effective Apache configuration and does not cover every HTTP method or alternative handler. Cyberprotech® recommends controlled testing, log review, a rollback plan and removing the test file afterwards. The official update remains necessary. [12]
What to do before patches become available
1 Identify systems and the person responsible for the intervention
Record domains, applications, servers and containers using PHP. Confirm the version actually used by each service and who has access to update it. Include secondary environments and old copies that remain publicly available.
2 Check whether the version still receives fixes
If PHP is unsupported, prepare migration to a supported, patched version and validate application compatibility. Where a provider offers extended maintenance or its own fixes, request documentary confirmation that these vulnerabilities are covered. [11]
3 Contact the hosting provider and maintenance company
Request confirmation of exposure to CVE-2026-109618 and CVE-2026-109619, the update plan and available temporary controls. Ask for a concrete intervention timeline and written confirmation of the result.
4 Prepare the change and recovery
Confirm usable backups, dependencies and essential tests. Preserve logs and evidence if there are signs of intrusion. A backup taken after a possible compromise may already contain malicious changes.
5 Reduce exposure while waiting
Validate protections supplied by providers and assess temporary access restrictions where necessary. Continue monitoring alerts, unexpected errors, file changes and the creation of administrative accounts.
What to confirm after updating
Cyberprotech® recommends closing the intervention only after the following conditions have been checked:
Identified fix: the installed version or package revision must be documented by PHP or the provider as addressing both CVEs. If a provider retains an earlier version number with backported fixes, require the corresponding security advisory.
PHP used by the website: confirm the interpreter processing web requests. Running php --version identifies the command-line executable; it does not independently establish which version PHP-FPM or the web server uses. The build date is also not proof that the fixes are included. [8]
Processes actually updated: restart or replace the necessary services, processes and containers according to the provider instructions. Check every node and the images used for new instances.
Functionality validated: test authentication, forms, uploads, payments and integrations where present. Record the version, date, responsible person and intervention result.
Suspicious activity investigated: patching does not prove that no previous access occurred and does not automatically remove malicious code or attacker-created accounts. Where indicators exist, initiate a separate investigation and recovery process.
The PHP alert is separate from the UpdraftCentral incident
A separate notice concerns unauthorised access to TeamUpdraft and exposure of UpdraftCentral keys. This is a distinct incident requiring its own connection revocation and website checks. Updating PHP does not replace those actions; updating UpdraftPlus does not patch the server PHP runtime. [9]
The priority is acting on verified information
Organisations need to know which systems use PHP, who will carry out the intervention and how remediation will be demonstrated. The announced release time does not guarantee that every hosting service will be updated at that moment. Confirmation is required for each environment.
Cyberprotech® can help identify exposed systems, coordinate with providers and validate the measures applied. To assess your organisation’s situation, contact us through https://cyberprotech.pt/.
This article reflects the information available at the stated review time. Fixed versions, exploitation conditions and provider guidance should be checked against official sources at the time of intervention.