PHP security vulnerabilities and emergency patching

Two critical, unauthenticated remote-code-execution flaws in PHP itself (not WordPress or any app built on it) were leaked before a patch existed. Details and a tool called PHP2Shell spread online on October 20. PHP shipped an emergency fix on October 21, slightly ahead of schedule. Governments and universities in some European countries and elsewhere pulled sites offline as a precaution. Cybersecurity agencies in Europe, Australia, Japan and the UK urged people to patch immediately or take sites offline.

The flaws

• CVE-2026-109618: An out-of-memory condition can be forced through crafted multipart file uploads (which PHP processes before app code runs). When PHP bails out mid-setup, cleanup runs on invalid data, which can lead to attacker code execution.
• CVE-2026-109619: A fatal error can skip wiping per-worker state, leaving a dangling pointer. The next request then hits a use-after-free, which can also lead to code execution.
• Both are rated 9.2/10. The first was proven on Apache mod_php; the second reached code execution on both mod_php and PHP-FPM, so FPM is not safer.
• The weakness has a history: related issues surfaced in 2004, 2020 and 2024.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older is vulnerable. PHP 8.1 and below no longer get official updates (only minimal source backports exist for 7.4, 8.0 and 8.1), and about 884,000 internet-facing servers were on those versions. PHP 8.2 reaches end of life on December 31, 2026.

Scale: PHP powers about 69% of sites with an identifiable server-side language, including WordPress. Scans estimate anywhere from 5.1 million to 22.6 million exposed instances, depending on the scanner.

What to do

• Updating WordPress or plugins does nothing; the host must update PHP.
• Check your version (php -v shows the command-line version, which may differ from the site’s, so check the web-facing one, e.g. php-fpm8.3 -v or a phpinfo page).
• Restart PHP-FPM or Apache after updating, since running workers keep the old code.
• Distributions often backport fixes without changing version numbers, so check the changelog for the CVE IDs (apt changelog php8.3-cli or rpm -q --changelog php).
• On shared hosting, ask your provider whether they’ve applied the October 21 release.
• Config workarounds, like disabling session upload progress, block only one path and aren’t a real fix.

Exploitation status: As of October 21, no confirmed breaches. Cloudflare and hosts saw attack attempts, the Dutch NCSC saw no active abuse, and neither CVE was on the US known-exploited list. Public proof-of-concept code exists, so mass scanning is likely.

What Should Website Administrators in Cambodia Do?

• Find out where your site is hosted. Many Cambodian sites run on shared hosting or on overseas providers. Contact yours today and ask: “Have you applied the October 21 PHP security release?”
• Self-managed server: update PHP to a fixed version, then restart PHP-FPM or Apache.
• Can’t patch yet: consider taking the site offline or restricting public access until you can. Government and business sites handling sensitive data should be especially cautious.
• Don’t trust version numbers alone. Linux distributions often backport fixes without changing the version. Check the changelog for the two CVE IDs (apt changelog php8.3-cli or rpm -q --changelog php).
• Old PHP (8.1 or below)? Plan an upgrade now, since there are no official fixes.
• Watch for signs of compromise: unfamiliar files, new admin accounts, or unusual traffic. Keep backups.
• Follow your national CERT. CamCERT is Cambodia’s national cybersecurity team, so check its channels for local advisories.
• Don’t rely on workarounds like disabling session upload progress. They block only one attack path.