On 21 October 2026 the PHP project fixed two critical vulnerabilities that can allow unauthenticated remote code execution. The risk spans PHP installations serving web requests, but the demonstrated pre-application attack is on mod_php; exposure differs by SAPI and configuration. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. We move estates onto a supported branch and verify the application after the switch, on a path that has been rehearsed rather than attempted.
PHP sits underneath the CMS, the framework, the plugins and the theme, which makes it the most consequential dependency in the stack and the least likely to have an owner. It is usually pinned once, during a build or a host migration, and then left alone for years while the branch it was pinned to goes end of life. The scale is the reason this is never one site: PHP is the server-side language on 69.3% of the sites whose language can be identified, and 26.8% of those sites are still on the 7.x line, which has been outside regular PHP project support since PHP 7.4 reached end of life in November 2022 (W3Techs, read 24 October 2026). One-off source or vendor backports may still be available. Advisories are published against the engine rather than against the application on top of it, so a site whose own code is flawless inherits engine flaws through request handling alone — and the reason that becomes expensive is not the patch. It is that most estates cannot say which versions, which SAPIs and which configurations they are actually serving, so the first task is always enumeration.
You need to know what is actually running before you can decide anything, and the person who knew has left. The inventory is useful on its own, and it is the artifact every later decision refers back to.
The same runtime is behind more than one site, and the upgrade has to be planned as a repeatable procedure rather than improvised per site. The inventory covers the estate; the procedure covers the next site.
The complete fix is an update, and the question is how to apply it without breaking a site that is currently working. Where the update cannot happen this week, the advisory's configuration measures reduce exposure in the meantime, and the page is explicit about what they do and do not cover.
The CMS or forum release you want may require a runtime you do not have, and the platform upgrade may require code changes that the runtime change also requires. Sequencing them badly means doing the work twice.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
After end of life, a branch no longer receives regular fixes from the PHP project, and the deferred upgrade becomes the lasting remedy. One-off source backports or fixes from a distribution or long-term support vendor may exist, so check the specific package rather than assuming either way. PHP 8.1 reached end of life on 31 December 2025, so this is the current position for every site still running it rather than a future risk.
The October 2026 vulnerabilities are reached through request parsing, which happens before the application runs. Nothing in the site's own code, framework or plugin audit changes that, and no amount of application hardening compensates for a runtime that is three branches behind.
Deprecations accumulate in the application while the runtime moves on underneath it. Each branch skipped adds compatibility work and removes community experience with that particular path, which is why long-deferred upgrades are usually applied as a sequence of smaller jumps rather than as one change.
Runtime faults are not subtle: a version mismatch typically produces a blank page or a fatal error rather than a degraded one. The cost is measured in the traffic that arrives during the window, and in whatever the search engines make of a site that served errors for an afternoon.
Where the runtime is not yours to choose, the deadline is somebody else's, and it can arrive with less notice than a planned upgrade would have needed. That is a reason to move the branch before the host does rather than after.
Each of these is work we carry out, not an area we advise on.
Every runtime the estate actually serves: version per host, pool and vhost, the SAPI in front of it, the configuration in force, and the extensions loaded with the ones the application genuinely requires. It is unglamorous work and it is the prerequisite — an advisory naming versions cannot be answered without it.
Deprecations and removals between the current branch and the target, extension availability per branch, framework and platform version requirements, and the plugin inventory that decides what actually breaks. The output names the blocking items rather than describing the risk of them.
A supported branch rather than the newest one, bounded by what the application supports and what its vendors support. Where the platform upgrade needs a newer runtime than the site can currently run, the sequencing is planned, because the two changes interact and doing them in the wrong order does the work twice.
The upgrade applied to a replica or a canary carrying the real application, the real plugins and real data — not a clean install, which passes for reasons that do not survive contact with production. Where a step cannot be rehearsed, that is stated before the window rather than discovered during it.
mod_php, PHP-FPM, FrankenPHP, LSAPI and CGI have different exposure under these flaws. PHP identifies all PHP installations serving web requests as at risk, with the highest risk on mod_php, where a demonstrated attack can trigger before application code runs. Pool and worker behaviour, configuration and where the runtime actually lives are part of the assessment.
The measures the advisory names — an administratively enforced memory limit, conservative request-size limits enforced at the proxy as well as in PHP, upload progress disabled, workers restarted so the settings actually apply. Applied as exposure reduction while the update is scheduled, and described as exactly that: the advisory is explicit that configuration removes specific paths and that updating is the only complete mitigation.
Both runtimes installed and selectable, so the branch can be switched per pool or vhost rather than only by re-deploying. A rollback that has never been run is a plan, not a control, so it is exercised before the window rather than during it.
Error rate, the deprecation log, the functional paths that carry traffic, request latency and caching behaviour, read after the change rather than assumed from a successful deploy. The check confirms which runtime is serving the request, because a site can pass every functional test while still being served by the version that was supposed to have been replaced.
The estate's runtime versions recorded where they can be looked up, and a maintenance calendar keyed to the project's own support dates. Without that, the next advisory produces the same investigation as this one, and the estate drifts back out of support between incidents.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
An estate that has never been inventoried has an unknown number of runtimes in it, and the first upgrade applied to a guessed inventory is a lesson in how many were actually there. The inventory is also the document that makes the rest of the work auditable.
These are two different changes and they carry different risk. Applying the current security release within the branch a site already runs is usually a small, contained change. Moving branch is a project with compatibility work, and it is the only answer to end of life. Saying which one is being done, and why, is part of the plan.
A clean runtime install proves the runtime works. The failures that matter come from the application — a deprecated call reached on one template, an extension loaded by a plugin, a caching layer keyed to the runtime version — and they appear on a copy of the real site or they appear in production.
Runtime, then application code, then configuration, in that order and with a verification between each. Bundling them means a fault cannot be attributed, and an unattributed fault is usually resolved by reverting all three.
A deploy that reports success has reported that files were written. The evidence that matters is a request served by the new runtime, with the application's own logs and the response times read afterwards. Anything less is a statement about the deployment rather than about the site.
The version list, the support dates and the procedure are kept current, so the next disclosure is answered from a document instead of from a rebuild of this investigation. An estate that cannot answer "which versions are we running" quickly is one that pays for the same discovery repeatedly.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Posture applied during an upgrade window, taken from the advisory's own mitigation list. It belongs in the pool or server configuration rather than in the application, because a value fixed there cannot be raised from inside a request — and it has to be in force before request parsing begins, which is earlier than any application code runs.
; FPM pool: values the application cannot override at runtime
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = offThe advisory names an enforced memory_limit of -1 as the primary configuration mitigation for the memory-exhaustion flaw, and is equally clear that it is not a complete one. It removes PHP's own limit on a runaway request, which is why the same advisory pairs it with a container or cgroup limit as the availability boundary, and why it is a measure for a window rather than a configuration to leave in place indefinitely.
Engagements where this capability was the substance of the work rather than a line item.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The other half of the same problem, and the one an engine update cannot touch: functions a supported branch removed, deprecated syntax, extension surfaces that moved, and components nobody maintains. It is a codebase change rather than a configuration one, and the two are usually sequenced together.
Legacy PHP modernisationCapacity, process management, database and OS-level maintenance are a different engagement from the runtime version, even though both end up in the same configuration files.
Server managementAn unpatched engine is a way in, and a site that shows symptoms has moved past the point where an upgrade is the first step. Containment, scope and recovery come first, and the upgrade follows.
Hacked website recoveryHardening is the application layer: authentication, file permissions, plugin surface, update policy. It is worth doing and it does not compensate for an unsupported runtime, which is why it is a separate page.
WordPress security hardeningA CMS or forum release usually brings its own version requirements and its own code changes. Where the platform move is the goal, that page sequences it; this one deals with the runtime the platform sits on.
XenForo installation and upgradeThe upgrade is a project with an end. Keeping a runtime and its applications patched afterwards is a cadence, with an owner and a record of what was applied.
Website security maintenanceOur client reviews are published on our public Google Business Profile. We reproduce them verbatim, with attribution, so you can read the original feedback and verify it directly at the source. We believe reviews should speak for themselves.
We reached out to this company when our website was hacked, and we are incredibly grateful for their prompt assistance in securing our project. They also provide regular, timely updates and invaluable support with other aspects of our platform.
Excellent work! They patiently accommodated all my requests and offered fair pricing. Highly recommended.
The two engine vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — were fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP identifies installations serving web requests across PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, while naming mod_php as the highest risk because an unauthenticated attack was demonstrated before application code runs. For PHP 8.1 and older, check whether your distribution or long-term support vendor has backported a fix; otherwise, move to a supported branch.
No. PHP 8.1 reached end of life on 31 December 2025 and no longer receives regular fixes from the PHP project. A distribution or long-term support vendor may provide a backport for a specific vulnerability, so check the package you run; do not assume every vulnerability is fixed or that a backport is available. The branches in support are 8.2, 8.3, 8.4 and 8.5, and each leaves security support on a published date: 8.2 on 31 December 2026, 8.3 on 31 December 2027, 8.4 on 31 December 2028 and 8.5 on 31 December 2029. A branch being supported today is not a permanent state, which is the reason the maintenance calendar is part of the deliverable.
Yes, and for many estates that is the correct change: moving from one patch level to the current release within the same branch is a small, contained update with a good track record. Moving branch is a different and larger project, because it changes deprecations, extension availability and platform compatibility at the same time. We will say which one a situation actually needs rather than treating every case as the larger job. What is not a choice is staying on a branch that no longer receives fixes.
The failures cluster. Code written for an older branch hits deprecations that have since become errors, or functions that have been removed or renamed. Plugins and extensions turn out to require a specific branch even though the platform does not. Some sites carry warnings that have been suppressed for years, and the upgrade stops suppressing them — which is a fix being applied, not a regression. Less obviously, a caching layer or opcache configuration keyed to the runtime version can behave differently after the switch, which is why verification reads the application's own logs and response times rather than only checking that pages load.
Usually with very short windows rather than none at all, and the sequence is arranged to keep them to a minimum. Both runtimes stay installed and selectable per pool or vhost during the change, so the switch is a configuration change rather than a redeploy, and the rollback is the same operation in reverse. Steps that genuinely require the application to be quiet — a migration whose schema depends on the runtime, for instance — are identified in the plan with the window they need, rather than being discovered on the night.
On shared hosting or a managed platform you may have no shell and no direct control of the branch, and that changes the work rather than preventing it. What can be established is which version is serving the site, which branch it is on, whether the plan around it will move and when. Where the answer is that it will not move, the honest recommendation is to move the site — and the useful thing is to know that before the branch reaches end of life rather than afterwards.
For estates we operate under a maintenance arrangement, critical PHP security releases are triaged the same business day: we establish whether the estate is exposed, which branches and SAPIs are affected, and whether the mitigation posture needs to change ahead of the update. That is the commitment, and it is the only one on this page. No timeframe is claimed for an upgrade itself, because a branch move's duration depends on what the compatibility analysis finds, and we would rather tell you that after looking than before.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.