PHP2Shell: two critical PHP flaws, and what we did about them at Alama

On 21 October 2026, two critical flaws in PHP were made public. PHP is the language a very large part of the web runs on, including many of the sites our customers host with us. Attacks have already been seen on the Internet.

This post says what these flaws are, what we found when we checked our own systems, what we changed, and what you can do if you run PHP yourself. No jargon, and nothing hidden.

The short version

• We found no sign of an intrusion in our logs or on our servers.
• Automated probes did hit our sites: about 690 file-upload requests, all of them rejected.
• PHP has been updated everywhere at Alama: the shop, the game panel, our sites, the webmail, and the "eggs" our customers use to host their own PHP sites.
• The customer whose own PHP site was affected was told directly.

What the flaws are

The two flaws have been given the names CVE-2026-109618 and CVE-2026-109619, and together they are nicknamed "PHP2Shell". Both are rated 9.2 out of 10 on the CVSS v4 scale, which is the "critical" range.

• CVE-2026-109618 is a memory corruption: PHP runs out of memory while reading a request, and its memory gets corrupted.
• CVE-2026-109619 is a state left behind: something one request leaves in PHP's memory is reused by the next request, which should never see it.

What makes them serious is how they are reached. An attacker needs no account. They only have to send a form that carries a file, which is something every website with an upload field accepts all day long. PHP reads that request before the code of the website even starts, so the website's own checks never get a chance to say no. Together, these flaws can let an attacker run their own code on the server.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

What we did at Alama

We checked. We went through our logs and our servers looking for any sign of someone getting in, and we found none. Automated probes did hit our sites, about 690 file-upload requests, and every one of them was rejected.

We also acted, in two steps. First we put a protection in place straight away. Then we updated PHP everywhere we run it:

• the shop,
• the game panel,
• our websites,
• the webmail,
• and the eggs: the server templates our customers use to host their own PHP sites. This part matters, because a customer should not have to wonder whether the PHP under their site is the fixed one.

The customer whose own PHP site was affected was told directly.

If you run your own PHP

1. Update PHP to a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the line you are on. If your line has no fixed version, move to one that does.

2. While you wait for the update, turn off one PHP feature in your php.ini, then restart PHP (PHP-FPM or your web server):

   session.upload_progress.enabled = 0
   

This is only a partial protection. It does not replace the update, and it does not make a server safe on its own. Think of it as shutting one window while you get the right lock.

Questions

If you host something with us and you have a question about this, write to us at contact@alama.host.