Update PHP and verify the intervention
Updated on 28 October 2026. The security fixes announced on 21 October are available; this article replaces the pre-release guidance published that morning. The original publication date and URLs are preserved.
Fixed releases for the two vulnerabilities are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Use these or a later fixed release in a supported branch; where a vendor backports fixes, confirm its security advisory. [14][15]
PHP 8.4.27 is an official security release. Package availability and deployment must still be checked with each hosting provider; an announcement does not establish that a particular website has been updated. [13]
Cyberprotech recommends identifying the systems, agreeing the intervention with the technical team and validating both the applied fix and the application’s operation. If the intervention has already taken place, retain evidence of the effective web runtime and the checks performed.
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 public name associated with these vulnerabilities. The PHP project has published two separate advisories describing the affected execution paths and fixes. Exploitability depends on the server, configuration and application; a platform name alone does not establish exposure. [14][15]
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.
Temporary configuration does not replace patching
Disabling session upload progress can block confirmed session lifecycle paths, but is not a complete mitigation. The official stale-state advisory requires administrative configuration and restarting every worker; it also describes other paths that this setting does not cover. [15]
session.upload_progress.enabled = Off
Apply and verify startup configuration with the infrastructure team. Do not rely on ini_set() or an FPM .user.ini change to protect early request processing. The setting concerns progress tracking; it is not a general upload prohibition. [1][3][15]
On 23 October, PHP issued additional guidance about session upload progress and an unusual configuration/application combination, tracked as CVE-2026-115560. Existing administrative restrictions should be reviewed against that advisory rather than removed automatically after updating. [1]
Cyberprotech recommends keeping temporary controls documented, testing their operational impact and confirming the full update. Their presence alone must not close the alert or be presented as proof that the installation is safe.
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]
Update and validate without delay
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 until remediation
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
The original 21 October article also referenced the TeamUpdraft/UpdraftCentral incident. This is a separate issue with its own revocation and website-checking measures; PHP updates do not replace those actions. Consult the supplier’s incident notice for its status. [9]
The priority is acting on verified information
Organizations need to know which systems use PHP, who owns the intervention and how remediation will be demonstrated. The availability of a fixed release does not establish that every hosting account has deployed it. Obtain confirmation 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 review date above. Confirm fixed releases, relevant conditions and current vendor guidance when planning each intervention.