R4XNBlog
Visit r4xn.com

Article

PHP2Shell: Two Critical PHP Flaws Are Being Exploited, Patch Your Website Now

Hakim5 min read7 views

PHP2Shell: Two Critical PHP Flaws Are Being Exploited, Patch Your Website Now

If your company website, online shop or customer portal runs on PHP, and most WordPress, WooCommerce, Joomla and Drupal sites do, this week's security news matters to you. The PHP project shipped emergency fixes on 21 October for two critical bugs nicknamed PHP2Shell. Within a day, Amazon's threat intelligence team said attackers were already probing for them at scale.

What happened

The two bugs are tracked as CVE-2026-109618 and CVE-2026-109619. Each is rated 9.2 (Critical) on CVSS v4.0. Both let an attacker who has not logged in run their own code on a web server just by sending it specially crafted HTTP requests. Security teams treat that kind of bug as the worst case, because whoever exploits it can take over the server, plant malware or steal data.

The disclosure did not go smoothly. The PHP team had a coordinated release planned, but two days beforehand some details leaked online, including the CVE numbers and the mitigation advice given to some critical infrastructure providers. The team then brought the release forward. Amazon says it saw the first exploit attempt against one of its honeypots on 17 October, four days before any patch existed. More proof-of-concept exploits appeared within hours of the public release.

Close-up of a computer motherboard CPU socket

The two bugs in plain language

  • CVE-2026-109618 (memory handling during out-of-memory errors): when a request hits PHP's memory limit, for example while a file upload is being parsed, PHP can abort part-way through. The cleanup code may then trust half-built data and touch memory that can still hold attacker-controlled content.
  • CVE-2026-109619 (stale state between requests): after some errors, a PHP worker can keep a pointer to memory that has already been freed. The next request handled by that worker may use it before it is reset, which is a classic use-after-free.
  • Who is exposed: every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php as the riskiest setup, because a demonstrated exploit fires before any of your application code runs.
  • Affected versions: PHP 8.2.0–8.2.34, 8.3.0–8.3.35, 8.4.0–8.4.26 and 8.5.0–8.5.11. PHP 8.1 and older are also vulnerable and get no official update.

How serious is it right now?

Reports differ a little, which is normal this early. Amazon says PHP2Shell is "now being broadly exploited in the wild", but that it is unclear how many attempts succeed. Dataminr's research team said that, so far, the activity it has seen is scanning, fingerprinting and broken exploits, with no confirmed compromises. It added that working attacks are probably only a matter of time. CISA urged organisations to patch immediately, and the UK's NCSC told organisations to update PHP servers or take them offline until they can.

"Defenders should not assume the public disclosure date is the earliest date of exploitation." — CJ Moses, CISO of Amazon Web Services, as quoted by BleepingComputer

Scale is what makes this so serious. PHP powers a large share of the web, and VirusTotal tracks more than 5.1 million PHP hosts exposed online.

MacBook Pro on a brown wooden table

What this means for Malaysian businesses

Many Malaysian SMEs run WordPress or WooCommerce sites on shared hosting or a small VPS, and often nobody owns the server-level updates. Here is a practical checklist for this week:

  1. Find out which PHP version you run. Check your hosting panel (cPanel's "Select PHP Version" or MultiPHP Manager, Plesk or DirectAdmin), or WordPress under Tools → Site Health → Info → Server.
  2. Update to a fixed release: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. On shared hosting, ask your provider in writing whether they have applied the patch. On a VPS, install your Linux distribution's updated PHP packages and restart PHP-FPM or Apache.
  3. Get off PHP 8.1 or older. These versions get no official fix. Move to a supported branch, or use an LTS vendor that provides backported patches. CISA says systems that cannot be patched should be taken offline.
  4. Use temporary shields only while you wait. A web application firewall (for example Cloudflare's) may give some protection. CERT-EU and CERT/CC also list config tweaks, such as disabling session.upload_progress.enabled and lowering post_max_size. These only reduce the risk. Updating is the real fix.
  5. Watch for signs of compromise. CISA suggests looking for PHP worker processes that launch shells or download tools. New unknown admin users, odd files in upload folders or sudden spam redirects are all red flags.
  6. Check your backups. Make sure you have a recent off-server backup you have actually test-restored.

For a longer-term habit, our guide on maintenance plans that prevent 2am emergencies explains how to make updates like this routine rather than a panic.

If you are not sure who looks after your server, or you want a second pair of eyes on your PHP version and patch status, the team at R4XN Tech can help with website maintenance and security updates. Just email hello@r4xn.com.

Sources

This article is our own summary of public reporting and advisories. Credit and more detail: