PHP leak of October 21: what happened and how things stand now

On Wednesday, October 21, two serious security vulnerabilities in PHP became known, the programming language that powers the vast majority of all websites, including WordPress. You may have noticed, as websites with us were offline for part of the day. In this article, we'll outline what happened, how we handled it, and where things stand now.

What was going on?

The vulnerabilities (CVE-2026-109618 and CVE-2026-109619) made it possible for unauthorized parties to execute code on a web server. That's about the worst kind of vulnerability there is: an attacker doesn't need a password for it, and it affects almost the entire internet.

How we handled it

1. Temporary measureWednesday, October 21, 10:00 AM

   At that point, it was only known that there were two serious vulnerabilities in all PHP versions, with a CVE score of 9.2. Details were not yet available and there were no known successful hacks yet, although Cloudflare, for example, was seeing an increasing number of attempts. Because the details of the vulnerability were not known, no one knew exactly what was going on or what could be done to reduce the risk. More and more mitigations and possible actions to reduce the risk were becoming known. We implemented these immediately, such as disabling certain PHP functions and updating the firewall multiple times.
   From 10:00 AM, we also continuously ran very strict malware scans, so we would immediately see if a script was placed anywhere on our servers or in our customers' accounts. That did not happen.

2. Websites offlineWednesday, October 21, 3:15 PM

   Although we saw no attempts at misuse on our servers, we decided to choose the safest option: everything offline. The main reason for this is that we had our doubts about the effectiveness of the mitigations (temporary solutions) circulating on the internet, because no one could confirm that this would offer sufficient protection.
   In a situation with so much uncertainty and potentially enormous consequences, a few hours of downtime is justifiable; taking the risk is not.

3. Official solutionWednesday, October 21, 4:00 PM

   The makers of PHP released the official update containing the fix for versions 8.3, 8.4, and 8.5. After that, it was a matter of waiting for updated packages from CloudLinux, the supplier of the PHP versions on our servers.
   When the update was published, the details of the vulnerabilities also became known, and that confirmed our suspicion: the known mitigations and extra firewall rules reduced the risk of a hack, but this was not enough to protect the server.

4. Temporary solutionWednesday, October 21, 7:00 PM

   Unfortunately, it took much longer than we had hoped and expected for CloudLinux to have the updates ready. Our contact with other providers revealed that we weren't the only ones who were surprised. Since we saw that they had already missed their self-imposed deadlines multiple times, we worked on a temporary solution.
   We installed PHP version 8.3.36 ourselves on all our servers and temporarily switched all our customers to this version. 90% of the websites came back online between 7:00 PM and 8:30 PM. The only websites that didn't come back online were outdated and couldn't handle a modern PHP version.

5. UpdatingThursday, October 22, 12:30 AM

   The updates became available and we immediately started installing and checking, server by server.

6. ResolvedThursday, October 22, 2:30 AM

   All servers had been updated and all websites were back online, on the PHP version they had previously used.

We fully understand that it's frustrating when your website is unreachable for an afternoon and evening. However, this inconvenience does not outweigh the potential consequences. We've never had to decide to take everything offline as a precaution before, but if the same situation arises again, we'll do exactly the same thing.

Where do things stand now?

• All PHP versions we offer, from 5.2 through 8.5, contain the security fixes for both vulnerabilities.
• The few websites that were running on an even older PHP version, for which no fix exists, have been moved to a fixed version.
• We checked the servers during and after the vulnerability for traces of misuse, such as hanging PHP processes, suspicious processes, uploaded files, and requests matching the known attack. We found no evidence that the vulnerability was exploited on our servers, and no attempts to do so were found before we went offline either.

Is my website separated from others?

Yes. Every hosting package runs in its own, isolated environment with us. PHP runs under the user of your package, without administrative rights on the server, and cannot access the files or databases of other customers. The use of processor and memory is also limited per package. We deliberately don't share more details about our security publicly: the less an attacker knows, the better.