Blog

Upgrading PHP and your server stack with AI, safely and fast

Posted on Friday, October 30th, 2026 by Jeroen Derks

TL;DR: In October 2026 critical remote code execution flaws were fixed in PHP (PHP2Shell) and in the Brotli library used by Node.js, Python, Java, .NET and more (Node2Shell). PHP 8.1 or older, and Node.js 20 or older or the odd-numbered 21, 23 and 25 release lines, get no supported release with a fix from the PHP or Node.js project. A fixed package from your distribution or vendor, including a maintained backport, closes these flaws, but it does not make an end-of-life version supported by the PHP or Node.js project again; the lasting step is an upgrade to a supported version. I use AI to inventory, analyse and upgrade servers and applications faster, with every change reviewed and tested on a copy first.

Many servers run longer than anyone planned. A website or application goes live, it works, and the server under it is left alone for years. Then a hosting provider sends a warning, a security scan flags an outdated version, or a vulnerability makes the news. By then the upgrade is no longer one step but several, and nobody remembers why that one cron job or Apache module is there.

Upgrading a server takes care and testing, but much of the work is tedious reading and comparing, and that is where AI helps. This article describes how that works and what it can do for your server.

PHP2Shell: why this matters right now

On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They can let an attacker run code on the server without logging in; which attack paths work depends on the PHP handler, the configuration and the application. According to the PHP project, the risk is highest with mod_php, where a demonstrated exploit runs the attack before any application code is executed. That means a fully up-to-date WordPress, Drupal or Joomla site is still exposed if the PHP version underneath isn't patched.

According to Uni Bamberg, the flaws go back to PHP 5.4, which came out in 2012; for anything older, check your package vendor's advisory rather than assume it is unaffected. The fixed upstream releases from the PHP project are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Linux distributions and vendors ship the fix in their own packages, often with lower version numbers; Ubuntu 24.04, for example, fixed it in php8.3 package version 8.3.6-0ubuntu0.24.04.13. So the package changelog or security advisory for CVE-2026-109618 and CVE-2026-109619 decides whether a server is patched, not the version number alone. The other versions stand as follows:

  • PHP 8.1, 8.0 and 7.4: the PHP project no longer releases updates for these. The security team did publish minimal source patches, and some Linux distributions and commercial support vendors offer backported fixes. Such a package fixes these two flaws, but the version stays unsupported by the PHP project, so check what your vendor covers and plan the upgrade.
  • PHP 7.3 and older, including all of PHP 5.x: the PHP project offers no fix for these, not even a source patch. Some commercial vendors do ship backported packages. For example, CloudLinux reports patched alt-php packages for PHP 5.2 to 5.6 and 7.0 to 7.4, patched cPanel EasyApache ea-php packages, and TuxCare ELS packages. Such packages can buy time while an upgrade is planned, but they don't make these versions supported by the PHP project again. The lasting solution is still an upgrade to a supported version.
  • PHP 8.2: patched, but this version reaches end of life on 31 December 2026. After that the PHP project releases no more security fixes for it, so this is the moment to plan the next step.

The PHP project does list temporary configuration measures, but states plainly that they don't make an installation safe. Only an update does.

Separate from these two flaws, the PHP project published an informational advisory on 23 October 2026 about CVE-2026-115560, a third remote code execution vector that remains after the emergency releases. It's considered unlikely and only affects applications that configure session.serialize_handler as php_binary or php_serialize, then switch it to php at runtime with ini_set() before session_start(), while session upload progress is enabled. If that applies to your application, the PHP project suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, which will come with a full advisory.

Not just PHP: Node.js, Python and more

The same day, Node.js released a security update fixing ten vulnerabilities, four of them rated high. The most serious one, CVE-2026-111497, is in Google's Brotli decompression library and goes by several names: Node2Shell, HTTP2Shell and Broccoli2Shell. Decompressing data supplied by an attacker can lead to remote code execution. The fixed versions are Node.js 22.23.4, 24.22.1 and 26.12.1. Node.js 20 and older, and the odd-numbered 21, 23 and 25 release lines, are end of life and get no fix from the Node.js project.

The flaw is in the Brotli library, which Node.js bundles, so check the Node.js runtime itself as well as your dependencies. Brotli is affected from version 1.0.3 onwards; the fixed releases are 1.0.10, 1.1.1 and 1.2.1, one for each release line. Linux distributions often backport the fix without changing the version number, so the package changelog or security advisory decides whether you're affected, not the version number alone. The flaw reaches far beyond Node.js:

  • Python: the brotli and brotlicffi packages must be updated to 1.2.1 and 1.2.1.0 or newer. Note that popular HTTP clients such as requests (through urllib3), httpx, aiohttp and Scrapy use these packages automatically once they're installed. Your code doesn't have to mention Brotli anywhere to be affected.
  • Java: brotli4j is fixed in version 1.24.0.
  • .NET: fixed in 8.0.33, 9.0.22 and 10.0.14. .NET 7 gets no fix.
  • Ruby and Go: these are also listed as affected. Whether your application is exposed depends on the Brotli library it uses. A library that carries its own copy of the decoder stays vulnerable until it ships its own update.
  • PHP on Windows: the Brotli decoder can be reached through the cURL extension when automatic HTTP decompression is enabled. The rebuilt Windows packages 8.2.35-1, 8.3.36-1, 8.4.27-1 and 8.5.12-1, released on 26 October 2026, bundle Brotli 1.2.1. The -1 suffix marks a package rebuild and PHP still reports the same version, so an earlier Windows package of the same PHP version doesn't contain the Brotli fix.
  • Other software: curl, Bun, Envoy and Istio, as well as the Brotli packages of Linux distributions. Not every distribution had a fix ready yet at the time of writing.

Notably, part of these vulnerabilities were found by researchers using AI. If AI helps find bugs that sat unnoticed for years, I expect security updates to keep coming at a higher pace. A server that's several versions behind can't keep up with that.

Why upgrades are usually postponed

How complex an upgrade is varies from server to server. Much of the effort, though, is tedious investigation and comparison that's hard to estimate:

  • You first have to find out what's actually on the server: packages, PHP extensions, Node.js and Python versions, configuration tweaks, virtual hosts, scheduled tasks and services.
  • You have to check every application for code that no longer works on the new version. From PHP 5 that's a big jump: the old mysql_* functions were removed in PHP 7.0, and each() and create_function() in PHP 8.0, to name a few.
  • Old PHP versions often run on an old operating system release, which then has to be upgraded too, together with the database and web server.
  • Release notes and migration guides for every component have to be read and compared against your setup.
  • Then everything has to be tested, ideally without touching the live site.

Most of this is careful reading and comparing, which makes it expensive when done fully by hand. That's where AI helps.

How I use AI in an upgrade

AI doesn't replace experience here. It speeds up the reading, comparing and repetitive changes, while I stay in charge of every decision.

1. Inventory of the server

The AI helps me write scripts that map the server systematically: installed packages and versions, PHP extensions and php.ini settings, Node.js and Python runtimes and their dependencies, web server configuration, cron jobs, services and log files. The AI then works from the anonymised output of those scripts, not from the live server. This also turns up the forgotten parts, such as a bundled copy of a vulnerable library, that would otherwise only come to light after the upgrade.

2. Analysis of the code

Static analysis tools such as PHPStan, Rector and PHPCompatibility find code that's deprecated or removed in the target PHP version. For Node.js and Python, npm audit and pip-audit report dependencies with known vulnerabilities, and npm outdated and pip list --outdated show which dependencies are behind. These tools cover the project's dependencies, not the Node.js or Python runtime itself, which is checked separately. The AI goes through the results, groups them, proposes which are real problems and which are noise, and suggests concrete fixes; I check that triage against the advisories and the code before acting on it. With a jump from PHP 5 or 7 to a current version, this is where I find AI most useful.

3. Release notes and dependencies

For each component, the AI compares the changes between the current and target versions with your configuration and code: changed defaults, removed options, packages that need a newer major version. This produces a list of points that matter for your server specifically, not a generic checklist.

4. Upgrade plan

From this I draw up a step-by-step plan: the order of the upgrades, what gets tested after each step, and how to roll back if something goes wrong. For a large jump, such as PHP 5.6 to 8.4, that may mean intermediate steps. After a database upgrade, going back usually means restoring the backup rather than reinstalling the old software, so it is agreed in advance how data written after the switch-over is handled.

5. Execution on a copy first

The upgrade is first done on a copy of the server, for example a VPS cloned from a backup. How that is done depends on how the server is hosted. For a bare-metal server, I first restore a copy onto a VPS for the rehearsal; hardware-specific behaviour needs separate checks, because a virtual copy cannot reproduce it. Before the copy runs anything, its scheduled tasks are stopped, and outgoing email, payment providers and other live integrations are switched off or pointed at test accounts, so the copy cannot act on live data or customers. When something fails there, the AI helps analyse the error messages and logs, and the fix goes back into the plan. An available security fix should not wait for the whole migration: where a maintained package fixes the flaw, that focused update can be tested and deployed first, and the larger upgrade of framework, operating system and database follows its own rehearsed plan.

Before the switch-over, I check on the copy:

  • The application's automated tests, where there are any
  • The key functions: logging in, forms, search, and orders or payments in test mode
  • That scheduled tasks, queues and background workers run without errors
  • That email is generated correctly (captured, not sent)
  • That the PHP, web server and database versions, extensions and settings are the ones planned
  • That error logs stay clean, and that pages respond about as fast as before

Only once the upgrade works on the copy do I carry it out on the production server, at a time agreed with you and with a fresh backup in place.

6. Checking afterwards

After the switch-over I check on the production server, so problems surface as early as possible, ideally before your users or customers notice them:

  • The same key functions, checked again
  • Logs and error rates, watched for an agreed period
  • That what's actually running uses the patched versions: PHP-FPM and Apache workers and Node.js processes restarted, containers rebuilt, and bundled copies of libraries such as Brotli updated. An updated package on disk doesn't help a process that's still running the old code.

What AI does and doesn't do

Usually the AI gets no access to the server or to private data at all. I use it to write the scripts that do the inventory and upgrade work, based on copies of configuration files, inventory output and log excerpts, with credentials removed and domain names and other identifying details anonymised.

AI makes mistakes. It can propose a fix that looks plausible but is wrong, or base a conclusion on outdated documentation. That's why AI output is never applied unchecked. I review every proposed change, it's tested on a copy first, and decisions about your production environment stay with me as a person.

The gain is in speed and thoroughness. AI can save time on the reading and searching an upgrade involves, and because it checks systematically, it can help reduce missed details. That can lower the cost of a well-founded upgrade.

What I can upgrade

  • PHP, from 5.x and 7.x to a current version, including extensions and configuration
  • Node.js and npm dependencies
  • Python and pip dependencies
  • The operating system (e.g. Debian or Ubuntu to a newer release)
  • Web servers: Apache and nginx
  • Databases: MySQL and MariaDB
  • Composer dependencies and frameworks
  • Supporting services such as Redis and TLS certificates

Is your server due for an upgrade?

Still running PHP 5, 7, 8.0, 8.1 or 8.2, or an older Node.js or Python version? Not sure which versions your server runs at all? Get in touch. I'll start with an inventory and tell you what the upgrade involves and what it'll take, before any change is made.

Contact me about upgrading your server.

Sources

Call now +31207775488 and your server will soon be up to date again!