One morning an email arrives from DigitalOcean with “URGENT” in the subject line. It opens with two critical vulnerabilities in PHP: both allow remote code execution (RCE), and they are numbered CVE-2026-109618 and CVE-2026-109619. Some emails cannot be left for “later”, and this is one of them. PHP powers a very large share of the world’s websites, and a flaw like this does not even require a login or password.
In this article we explain what happened, what the vulnerabilities are about, which measures actually protect against them and how our team closed the issue within a single day. The goal is to give you a clear guide for checking your own website and server and to show how a business should act in such a situation.
What happened
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These are security updates that fix two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. PHP itself described both as vulnerabilities that can lead to unauthenticated remote code execution and urged all users to update immediately. The flaws are often referred to as PHP2Shell, and both are rated 9.2 on the CVSS v4.0 scale, which is the critical range.
The notice reached us from our hosting provider. DigitalOcean warned its customers about the situation and asked them to update urgently. The important point here is that attempts to exploit a vulnerability appear soon after it becomes known. Some security research reported exploitation attempts even before the official disclosure, so in this case time is measured in hours, not weeks.
The vulnerabilities in plain language
The essence can be explained without going deep into technical detail. Both vulnerabilities come from a memory-handling error: while processing a request, PHP frees a piece of memory and then still treats it as in use. In real conditions such an error lets an attacker read the contents of the server’s memory or run their own code.
The first (CVE-2026-109618) is caused by a flaw in the mechanism that tracks file upload progress, and its consequence is memory disclosure and code execution. The second (CVE-2026-109619) works like this: after a fatal error, the internal state of one request remains in memory even after it has been freed, and the next request handled by the same worker process uses it. One known path to the second vulnerability is the “session upload progress” feature, which is enabled in PHP by default and works even if the application never uses sessions. The main takeaway is simple: this is a gap in PHP itself, not in the code of an ordinary website, even a well-written one, so it cannot be fixed at the application level.
Why this matters to business
WordPress, Joomla, many online store systems, CRMs and admin panels run on PHP, as do custom projects built on frameworks such as Laravel. So this vulnerability affects not one website but everything that relies on PHP: a corporate site, a catalog, a personal account area, an internal accounting system. If a vulnerable PHP version is installed on a server, it is not just one site’s problem but a risk to every project hosted on that server.
The consequences are also business-level: a defaced site, leaked customer data, malicious code planted on the site, the server being used for someone else’s purposes and, as a result, lost reputation. This is the invisible but essential technical foundation of a website: you can make a site beautiful, but if the PHP it runs on is not updated, all that work can collapse with a single request. We discussed similar risks in our article “Open ports and forgotten services”.
How we acted: a one-day plan
As soon as the notice arrived, we treated this not as planned work but as an emergency. First we took stock of the situation: which servers and projects use PHP, which versions are installed and who has access to them. This step matters, because without an answer to “how many systems are at risk?” a full update cannot be done: very often one forgotten old server turns out to be the new risk.
Then we acted on two layers. As a quick first step we enabled the temporary security settings recommended by PHP itself: we turned off the session upload progress feature and, for PHP 8.5, applied the setting that disables fatal error backtraces. We knew from the start that this was not a full solution, so we treated it only as a bridge until the update was ready. As the second, main step, we upgraded PHP to the patched versions: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. An important note: after the update, PHP-FPM and the web server must be restarted, otherwise old processes still in memory keep running in the vulnerable state.
The third step was verification. After the update we re-confirmed the PHP version on every server and checked that the sites were up and that forms and admin panels responded correctly. After that we stepped up monitoring of security logs and unusual activity, because attack attempts increase in the first days after a vulnerability is disclosed. As a result we closed the issue within one day: from the moment we learned of the vulnerability to updated and restarted systems took less than one working day. That speed was no accident: it was made possible by an existing server inventory, clearly named owners and a process ready to roll out updates quickly.
Temporary measure vs. full fix: what is the difference
The most common mistake here is to treat temporary settings as a complete solution. The PHP project stated openly that there is no fully protective mitigation and that updating is the only reliable choice. Disabling session.upload_progress.enabled closes one of the known paths to the second vulnerability, but not every possible variant, and it does not apply to the first one (CVE-2026-109618). So this measure can only serve as short-term protection until you update.
Where you set the option matters too. According to the official recommendation, it must be in php.ini or in the PHP-FPM pool configuration; setting it through ini_set() or .user.ini does not work, because the path to the vulnerability is processed before the request even reaches the script. After changing the setting, all worker processes must be restarted. And after updating, if your hosting provider disabled features temporarily, do not turn them back on yourself: wait until the provider confirms that the patch is out.
Ask a question or leave a request
We will identify the PHP versions on your servers, update them and set up monitoring, with no downtime for your business.
By submitting the form, you agree to the processing of personal data.
How to check your PHP version
If you have your own server, first find out which version is installed. On the command line, php -v shows the version in use, but keep in mind that for the web server, PHP-FPM or the Apache module may use a different version, so it is best to check each pool separately. If the version is below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, the server is vulnerable.
On Debian- and Ubuntu-based systems the update is usually done through the package manager; for example, it is best to upgrade all PHP packages together: sudo apt update && sudo apt install --only-upgrade 'php8.*'. After that, restart the PHP-FPM service, for example sudo systemctl restart php8.3-fpm (the name depends on the version), or reload Apache if you use it. After updating, check the version again with php -v and make sure the site works. If you use Docker, rebuild the image with the new PHP version and restart the container. Remember that PHP 8.1 and older received no official update from the PHP project: in that case ask your provider for a backport or move to a supported version.
What to do if your site is on hosting
If your site is on shared hosting, the server’s PHP version is managed by the hosting provider, so the main action is to read the provider’s notice and find out when and how the update will be carried out. Many providers update themselves quickly in such cases, while some first enable protective settings and only then release the patch. If your control panel lets you choose the PHP version, switch to a supported, patched version.
At the same time check your own side: update WordPress, plugins and themes, remove unused plugins, and enable a strong password and two-factor authentication for the admin panel. These do not protect against this vulnerability itself, but they close other paths for an attacker and raise the site’s overall security. If a developer or studio maintains your site, ask them in writing what exactly was done: that is a normal part of a support agreement.
What we learned from this
This episode confirmed several simple but important things. First, an accurate list of servers and projects is the main factor of speed in an emergency: if you do not know how many systems you have and where they run, you cannot update everything at once. Second, postponing updates to a “quiet time” is costly: when a vulnerability goes public, attacks begin within hours (depending on how severe it is), and a team with a ready process is already at work at that moment.
Third, you must tell a temporary measure from a full fix: turning off a setting brings calm but does not remove the danger. Fourth, provider notices cannot be ignored: an “URGENT” email from a provider like DigitalOcean is most often about a real threat, and it must not be missed by mistaking it for advertising. And finally, this case shows the point of a support agreement: the basis of security is not building a site and forgetting it, but updating it continuously. We wrote about this in our articles on technical support agreements and website maintenance.
Checklist
- You have a list of all servers and projects, with those that use PHP marked
- The PHP version is checked on every server (8.2.35, 8.3.36, 8.4.27 or 8.5.12 and above)
- Until the update is done, the temporary setting is enabled (session.upload_progress.enabled = 0, plus fatal_error_backtraces = 0 on PHP 8.5) and it is set in php.ini or the PHP-FPM pool
- PHP is updated, and PHP-FPM/Apache and other long-running processes are restarted
- After the update the version is re-confirmed, and sites, forms and admin panels are checked
- For PHP 8.1 and older, a backport or a move to a supported version is planned
- Docker images are rebuilt and containers restarted
- The hosting provider’s notice is read and the update date confirmed
- Monitoring of security logs and unusual activity is stepped up
- A person responsible for security updates is named in the support agreement
