Feed Item
IMREAL.LIFE
Added a post 
PHP2Shell: two critical PHP bugs let anyone take over your server, no login needed. Here's how to patch today

If your website runs on PHP, and roughly seven in ten websites do, this one needs your attention today. On 21 October (just after 1am on 22 October, Melbourne time) the PHP project released emergency fixes for two critical flaws, nicknamed PHP2Shell, that can let an attacker run their own code on your web server without logging in to anything. Details leaked online the day before the fix, and attack attempts were already being seen before the patch was out. The Australian Government's Australian Cyber Security Centre (ASD's ACSC) has issued a Critical alert and recommends organisations apply available security updates and other appropriate mitigations.

The good news: the fix is a normal package update and a restart. Here's what it is, how to check your server, and exactly what to do on Ubuntu.

What it is and who's affected

PHP2Shell is two memory-safety bugs in PHP itself, not in WordPress or any particular app:

  • CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory part-way through setting up a request, the clean-up code can treat half-built data as valid, which can be turned into remote code execution.
  • CVE-2026-109619, "RCE via stale global state". Internal data from one request can survive after its memory has been freed, and a later request handled by the same PHP worker can use it. The confirmed attack path goes through PHP's session upload progress feature (session.upload_progress.enabled), which is switched on by default and kicks in before any of your own code runs.

The Australian Government alert. ASD's ACSC published its alert on 21 October 2026 and last reviewed it on 22 October, with Alert Status: Critical. It says "all PHP versions from PHP 5 onwards may be affected" and that it "is not aware of successful active exploitation within Australia, related to these vulnerabilities". ASD's ACSC recommends organisations:

  • Identify PHP within their environments
  • Review the latest PHP guidance at php.net
  • Apply available security updates and other appropriate mitigations
  • Monitor PHP applications and related systems for suspicious activity

If your organisation has been affected, suspects it has, or needs advice, the Australian Cyber Security Hotline is 1300 CYBER1 (1300 292 371).

The PHP project rates both 9.2 out of 10 (CVSS v4.0) and says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest risk, because a single unauthenticated request can trigger the attack.

Because the bug is in PHP, it doesn't matter how secure your application is. WordPress, Drupal, Joomla, MediaWiki, Magento, Laravel and plain custom PHP sites are all exposed if the PHP underneath is unpatched. The researchers demonstrated it on WordPress, Drupal and Joomla, and even a "Hello World" page on an affected PHP version is vulnerable. Updating WordPress or your plugins does not fix it.

The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get official releases, although the PHP team published source backports for 7.4, 8.0 and 8.1, and Linux distributions have patched their own packages.

How big is it? Censys counted about 1.57 million internet-facing hosts on unpatched PHP versions on 21 October. CISA, the NSA, the FBI, the UK's NCSC and CERT-EU all urged immediate patching, and said that systems which can't be patched or mitigated should be taken offline until they are. Japan's Prime Minister posted the same advice on X. Plenty of organisations did exactly that: the Dutch parliament's website, the Port of Rotterdam's website, Dutch government portals, Finnish government web services, French prefecture sites, parts of Wikimedia's tools, the Internet Archive and forums such as Something Awful all went offline for a while as a precaution. Those were precautions, not confirmed hacks.

Check your server in five minutes

1. Check your PHP version.

php -v

2. On Ubuntu, check the package version too. This matters, because Ubuntu backports security fixes without changing the headline version number. A fully patched Ubuntu 24.04 server still says "PHP 8.3.6" in php -v, so look at the package release instead:

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

Ubuntu's fixed package versions (USN-8948-1) are:

  • Ubuntu 24.04 LTS: php8.3 8.3.6-0ubuntu0.24.04.13 or later
  • Ubuntu 22.04 LTS: php8.1 8.1.2-1ubuntu2.28 or later
  • Ubuntu 26.04 LTS: php8.5 8.5.4-0ubuntu1.5 or later
  • Ubuntu 20.04 LTS: php7.4 7.4.3-4ubuntu2.29+esm5, available only with Ubuntu Pro (free for personal use)

If you installed PHP from a third-party repository, such as a PPA, check that its version is at least the fixed upstream release for your branch (8.2.35, 8.3.36, 8.4.27 or 8.5.12).

3. Check the upload progress setting your web server actually uses. The command-line php can read a different php.ini from Apache or PHP-FPM, so check the web server's own config files:

grep -H "session.upload_progress.enabled" /etc/php/*/fpm/php.ini /etc/php/*/apache2/php.ini 2>/dev/null

A commented-out line, or no line at all, means it's on (the default). For a definitive answer, put a phpinfo() page on the site for a minute, search it for session.upload_progress.enabled, and then delete the page straight away. Never leave a phpinfo page online.

Patch it on Ubuntu (Apache and PHP-FPM)

1. Back up first. Take a snapshot or backup of the server and the site's database.

2. Install the updates.

sudo apt update
sudo apt upgrade

On Ubuntu 20.04, attach Ubuntu Pro first (sudo pro attach <your-token>), then run the same two commands.

3. Restart every PHP process. The fix doesn't take effect until the old workers are gone. Use the version number that matches your server:

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

If you run mod_php, restarting Apache is the step that matters. Restart any other long-running PHP workers too, such as queue workers and Docker containers. A PHP container image must be rebuilt or re-pulled on a fixed version, not just restarted.

4. Turn off session upload progress, whether you've patched yet or not. Few sites use upload progress bars, and the PHP project suggests leaving it off after patching if you don't need it. Edit /etc/php/8.3/fpm/php.ini and, if you use mod_php, /etc/php/8.3/apache2/php.ini, and set:

session.upload_progress.enabled = 0

Or set it in your PHP-FPM pool file (for example /etc/php/8.3/fpm/pool.d/www.conf) so applications can't override it:

php_admin_flag[session.upload_progress.enabled] = off

Then restart PHP-FPM and Apache again. Setting it with ini_set() or a .user.ini file doesn't work, because those apply too late.

Be clear about what that setting does and doesn't do. It blocks the confirmed session-upload path for CVE-2026-109619, but not other variants of that bug, and it does nothing for CVE-2026-109618. On PHP 8.5, also set fatal_error_backtraces = 0. The PHP advisory lists further stopgaps for the memory bug, such as memory_limit = -1 with container memory limits and a lower post_max_size, but they have side effects and are only partial. Hiding errors with display_errors or @ doesn't help either. Patching is the only complete fix. If you can't patch or mitigate today, do what the agencies advise and take the site offline until you can.

5. Check it worked. Re-run the dpkg -l command and confirm the fixed package version, confirm the setting is off with a temporary phpinfo page (then delete it), and load your site and its forms to make sure everything still works.

6. Look for signs of trouble. If the server was unpatched and online over the past week, look for unexplained PHP worker crashes or restarts, bursts of HTTP 500 errors or memory-limit errors after unusual upload requests, PHP processes starting shells or downloading files, and new cron jobs, users or files you didn't create. The bug can also leak memory, so if anything looks off, rotate the passwords, API keys and database credentials the site uses. One more warning: JFrog reports fake "PoC exploit" code and prank malware for PHP2Shell circulating on GitHub. Don't run exploit code of unknown origin on your own machines.

If you self-host AI tools as well, our earlier checklist covers firewalls, binding services to localhost and patching on a schedule: Lock down your self-hosted AI in an afternoon.

It's not just PHP: a rough week for anyone running their own servers

Several other serious issues landed in the same week. Briefly, and only the ones we could confirm:

  • GitLab. GitLab released a critical patch for a flaw rated 10.0 out of 10 (CVE-2026-110264) that allows remote code execution and affects self-managed GitLab going back to version 7.0 from 2014. If you self-host GitLab, upgrade now.
  • LiteLLM. LiteLLM's 1.107.0 release was compromised on 21 October: the PyPI wheels and the official Docker images, including latest, carried a credential stealer and a remote code loader. If you installed or pulled it, treat that machine as compromised, rebuild it, pin a clean version and rotate every key it could reach. It's the second time this year LiteLLM's releases have been hijacked.
  • Railway and Zeabur. Railway paused builds and deployments after possible unauthorised access to environment variables and has asked users to rotate the secrets stored there. Zeabur disclosed its second breach in two months and says it's shutting down by the end of the year.
  • TiDB Cloud. PingCAP says stolen credentials gave someone access to internal systems from 9 September to 7 October. An extortion group claims it took 10.6 TB, which PingCAP hasn't confirmed.
  • Node.js and Plex. Node.js shipped fixes for a remote code execution bug and TLS certificate checking bypasses, and CISA has listed Plex Media Server flaws as actively exploited. Update both.
  • Tor. More than 300 Tor exit relays were reportedly hijacked earlier this month to intercept SSH logins and capture passwords. Use SSH keys, not passwords.
  • eMudhra. Eight intermediate certificate keys at Indian certificate authority eMudhra turned out to be tiny numbers that were trivial to recover, one of them literally "4". The certificates have been revoked.

The common thread is the one from our self-hosted AI checklist: know what's running, patch on a schedule, keep secrets out of places that can leak, and have a plan for when a supplier gets hit.

The takeaway

Patch PHP today, restart every PHP process, turn off session upload progress if you don't use it, and check you're really on the fixed package version. If a site can't be patched today, take it offline until it can. A few hours offline is a lot cheaper than a compromised server.

Need help? IRL can patch and harden your server

If you'd rather not do this yourself, or you're not sure what's running on your server, IRL can do it for you. Our server patching and hardening service includes:

  • A version audit of every PHP runtime on the server, including PHP-FPM pools, Apache modules, containers and bundled control panels
  • Patching PHP and the rest of the system to fixed versions, with a backup taken first and every PHP process restarted
  • A config check of session.upload_progress and the other PHP2Shell stopgaps, set in the right place so applications can't override them
  • A firewall and hardening review covering open ports, SSH, Fail2ban, TLS and the services you don't need exposed
  • A post-patch check to confirm the fixed versions, test that your site still works and look for signs of compromise

There's no fixed price, because every server is different: it depends on the server and what's running on it. Tell us about your setup and we'll give you a quote. Get in touch here.

Rather learn to do it yourself? The 30-Day Sovereign Builder Challenge takes you from little or no technical background to running and hardening your own Linux servers, including patching, firewalls and Fail2ban, alongside other builders in the IRL community.

Got a question about patching your own setup? Post it in the comments below.

General information only, not professional security advice. Always back up before making changes to a live server.

Sources

IMREAL.LIFE

Close