PHP2Shell: Your aoitcloud Website Is Already Patched

Seen the PHP2Shell headlines and wondering if your website is at risk? If it’s hosted with aoitcloud, it’s already protected. Every hosting server on our platform was patched within 12 hours of PHP releasing its fixes on 21 October 2026, with nothing for you to do and nothing extra to pay.

Here’s what happened, how the flaws work, and what to check if you run older software.

What Is PHP2Shell?

PHP2Shell is the name given to two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. This isn’t a WordPress or plugin problem: the flaws sit in the PHP engine that runs WordPress, WooCommerce, Joomla, Drupal, Laravel and most other PHP applications.

Both are rated 9.2 out of 10 for severity. Both allow remote code execution without logging in, which means an attacker can send crafted requests to a website and end up running their own commands on the server behind it.

Every PHP setup that serves web pages is in scope, including PHP-FPM, LiteSpeed and Apache. PHP’s security team considers the risk highest on Apache’s mod_php, where an attack can succeed before your application’s own code even runs.

How the Flaws Work

If you’re a developer, here’s the short version.

CVE-2026-109618 (out-of-memory corruption). When a request hits PHP’s memory limit, PHP jumps straight out of whatever it was doing. If that happens while a request is still being set up, for example while a multipart form upload is being parsed, some internal data is left half-built. PHP’s clean-up code then trusts that data, which leads to a use-after-free that can be turned into code execution.

CVE-2026-109619 (stale state between requests). PHP workers can keep hold of state, such as error, session and extension data, that points at memory belonging to a previous request. If the next request handled by the same worker touches it before it’s reset, an attacker can use the freed memory. Triggers include fatal errors, execution timeouts and session upload progress handling.

PHP has confirmed that no configuration change fully protects against either flaw. Updating PHP is the only complete fix.

Update, 23 October 2026. PHP has published a short follow-up about a separate, much less likely issue (CVE-2026-115560) in session upload progress handling. It only affects applications that change PHP’s session serialize handler at runtime, which is rare. If your code does this, PHP recommends setting session.upload_progress.enabled=0 until its next regular release. Most sites, including standard WordPress installs, don’t need to do anything.

Who Found the Flaws

The flaws were reported privately to PHP’s security team by researchers credited from Calif, Wiz and OpenAI.

Ryan Austin at Calif began auditing PHP on 30 July 2026 as part of OpenAI’s Patch the Planet initiative, which funds security research on widely used open-source software. Calif used generally available AI models, but says the breakthrough came from knowing PHP’s history: a similar memory-limit bug was found back in 2004. That history told the researcher exactly where to point the AI: what happens when PHP runs out of memory at the wrong moment. Wiz later found the same problems independently.

Key Dates

• 30 July 2026: Calif starts its PHP audit.
• 11 August 2026: The first flaw is reported privately to PHP.
• 15 August 2026: PHP confirms the researchers’ proof-of-concept attack works.
• 21 August 2026: The second flaw is reported.
• 20 October 2026: Details leak online ahead of the planned disclosure on 22 October.
• 21 October 2026: PHP brings its release forward and publishes PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The UK’s National Cyber Security Centre tells organisations to patch immediately or take vulnerable systems offline.

What We’ve Done

Every hosting server on our platform was patched within 12 hours of PHP’s release, across every PHP version we offer. That includes older versions such as PHP 7.4, 8.0 and 8.1, which no longer get official PHP releases. For those, we applied the backported security fixes, so your site is protected whichever version it uses.

You don’t need to restart anything, change any settings or contact us. It’s the kind of thing website security should mean: handled for you, quickly, without you having to read the news first.

Running Older Software?

Some websites are built on older code that could break if PHP is updated to a newer version. If your site falls into that group, our UK support team will contact you directly and work with you one to one to make sure it’s secured.

Even with the backported fixes in place, it’s worth planning a move to a supported PHP version. PHP 8.1 and older no longer receive security updates from PHP, and PHP 8.2 reaches end of life at the end of 2026, so PHP 8.4 or 8.5 is the best choice if you’re changing. You can switch PHP version in your Hosting Control Panel, and it’s always worth testing on a copy of your site first. If you’re on WordPress hosting, check your theme and plugins support the new version before you switch.

Running Your Own VPS?

If you have a VPS, you manage the software installed on it, including PHP, so the update is in your hands. It takes a few minutes. Connect to your server over SSH and follow the steps for your operating system.

1. Check Which PHP You’re Running

php -v
systemctl list-units --type=service | grep -i -E 'php|apache2|httpd|nginx|lsws'

The first command shows the PHP version on the command line. The second lists the PHP-FPM and web server services you’ll need to restart later. Your website can use a different PHP version from the command line, so make a note of every PHP service you see.

2. Install the Update

Ubuntu and Debian:

sudo apt update
sudo apt upgrade

AlmaLinux, Rocky Linux and other RHEL-based systems:

sudo dnf upgrade --refresh 'php*'

FreeBSD:

sudo pkg update
sudo pkg upgrade

3. Restart PHP and Your Web Server

This step matters. PHP keeps running the old code until its processes restart, so an update without a restart leaves you exposed. Use the service names you found in step 1. For example, on Ubuntu 24.04 with PHP-FPM and Nginx:

sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

On AlmaLinux or Rocky Linux with Apache, it’s sudo systemctl restart php-fpm httpd. If you use Apache with mod_php, restarting Apache (apache2 or httpd) is enough, and it’s the setup PHP considers most at risk, so don’t skip it. If you’re not sure, a server reboot restarts everything.

4. Check the Fix Is Installed

Operating systems often fix older PHP versions without changing the main version number, so php -v alone won’t always tell you. Check the package instead.

Ubuntu and Debian:

dpkg -l | grep -E 'php[0-9.]+-(cli|fpm|cgi)|libapache2-mod-php'

Compare the versions with these fixed releases:

• Ubuntu 24.04 LTS: 8.3.6-0ubuntu0.24.04.13 or later
• Ubuntu 22.04 LTS: 8.1.2-1ubuntu2.28 or later
• Ubuntu 26.04 LTS: 8.5.4-0ubuntu1.5 or later
• Debian 13 (trixie): 8.4.27-1~deb13u1 or later
• Debian 12 (bookworm): 8.2.35-1~deb12u1 or later

AlmaLinux and Rocky Linux:

rpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]'

If both CVE numbers appear, you’re patched. Red Hat says some fixed packages are out and more are on the way, so if nothing shows yet, check again later today and use the temporary measures in PHP’s advisory (linked below) in the meantime.

Installed PHP from an extra repository, such as a third-party PPA on Ubuntu or the Remi repository on AlmaLinux? Those packages follow PHP’s own version numbers, so php -v should show 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. The same update commands above apply.

Still on PHP 8.1 or older from an extra repository? PHP no longer releases updates for those versions, so check whether your repository has published a backported fix. If it hasn’t, this is the moment to move to PHP 8.4 or 8.5.

Stuck, or not sure which applies to your server? Our support team is happy to help.

More Information

For the full technical detail, go straight to the source:

• PHP’s official security advisory (21 October 2026), including temporary mitigations if you can’t update straight away
• PHP advisory for CVE-2026-109618 (out-of-memory corruption)
• PHP advisory for CVE-2026-109619 (stale global state)
• PHP’s follow-up advisory on session upload progress (23 October 2026)
• PHP’s supported versions and end-of-life dates
• The NCSC’s alert on the critical PHP security issue
• Calif’s research write-up

Questions About Your Site?

If you’d like us to confirm which PHP version your site runs, or you’re not sure whether an older application could be affected, contact our UK support team. A real person will get back to you.