Customer Security Advisory: Critical PHP Vulnerabilities

Summary

On 21 October 2026 the PHP project published two Critical security advisories (CVSS 9.2) that allow an unauthenticated attacker to run code on a web server simply by sending crafted web requests. Fixed releases are available now: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Every PHP version below these is affected.

PHP powers a very large share of public websites and internal web applications, including WordPress, Drupal, Laravel and Magento. If your organisation runs any PHP-based system that is reachable from the internet, you should treat this as a priority patching event.

What we are asking you to do: identify every PHP installation you own, update to a fixed version as soon as possible, and apply the interim hardening steps in this advisory where updating is delayed. The PHP project states that updating is the only complete fix.

What the vulnerabilities are

Both issues are memory-safety flaws in the PHP engine itself, not in any one application, so any PHP site can be affected regardless of which framework or CMS it runs.

Which server set-ups are most exposed. Apache with mod_php is the most directly affected for both issues. PHP-FPM (the common nginx set-up) is confirmed exploitable for Advisory 2 and assessed as susceptible for Advisory 1. FrankenPHP and LiteSpeed LSAPI are assessed as likely affected but not fully validated. The PHP project is clear that no deployment type should be considered immune.

Current impact (as of 23 October 2026)

The industry has named these flaws “PHP2Shell”. Exploitation attempts are confirmed, but no public report yet confirms a successful compromise of a live production system. The picture is moving quickly and should be treated as likely to worsen.

• Leaked ahead of schedule. Details including the CVE numbers leaked online before the planned disclosure, forcing the PHP team to bring the release forward to 21 October. Several proof-of-concept exploits circulated before the patch; the PHP security team stated none of them were functional (BleepingComputer, 22 Oct).
• Attack attempts pre-date the patch. Amazon Threat Intelligence observed the first exploitation attempt against its honeypots on 17 October, four days before fixes were released, and later described the flaws as being broadly exploited in the wild. Amazon also said it is unclear how many attempts succeed (BleepingComputer).
• Scanning is widespread; confirmed breaches are not. Cloudflare, watchTowr, Hadrian and Patchstack all reported detecting attempts. Dataminr reported on 22 October that observed activity so far consists of scanning, fingerprinting and non-working exploits with no known compromises. Huntress told CyberScoop it had not confirmed successful exploitation on live customer systems (CyberScoop).
• Governments are treating it as an emergency. The UK NCSC advises organisations that cannot patch or mitigate promptly to consider taking affected systems offline (NCSC alert). The US NSA and FBI issued similar guidance. The Dutch NCSC and several French public-sector sites, including the Paris Police Prefecture, were taken offline as a precaution.
• Exposure is large. VirusTotal reports more than 5.1 million PHP hosts exposed online, roughly 3.8 million with at least one port open (BleepingComputer).
• CISA’s position. CISA stated on 21 October that it had not observed exploitation at the time of publication. As of 22 October neither CVE had been added to the CISA Known Exploited Vulnerabilities catalogue (CyberScoop).

In short: working exploit code has been demonstrated privately by the PHP team, attackers are actively probing for targets, and the window before reliable public exploits appear is short.

South African Context

South Africa is directly exposed. MyBroadband reported that a Shodan search for internet-connected servers in South Africa running PHP returned more than 9,800 results, including almost all of the country’s major hosts, among them Amazon Data Services South Africa, Afrihost, Xneelo and Microsoft (MyBroadband, 21 Oct).

Local hosting providers have moved quickly (MyBroadband, 22 Oct):

• Afrihost and Axxess notified customers, began patching managed and shared servers, and advised that hosted sites run PHP 8.2.35 or later.
• Xneelo applied the interim mitigations before the official patches, then updated all hosting servers once fixes were released. It warned that servers could have been compromised before patching and advised customers to review CMS administrator accounts, plugins and recently modified files, and to change admin and FTP passwords if anything looks unfamiliar.
• 1-Grid is assessing impact across its environment and recommends PHP 8.3 or higher where compatible, for a longer support window.
• Absolute Hosting reported no immediate impact but applied mitigations while waiting for vendor patches.

CrowdStrike, quoted in the same report, noted that successful exploitation gives command execution as the web-server user rather than full server control, but that this alone is enough for credential theft, web-shell installation and lateral movement.

What this means for you

If your website or application is hosted with a South African provider, confirm with them in writing that the PHP runtime serving your site has been updated. If you manage your own servers in local data centres or cloud regions, the actions in this advisory apply to you directly. We have not located a published alert from South Africa’s national CSIRT (the Cybersecurity Hub) at the time of writing; the UK NCSC, CISA, CERT-EU and the Canadian Cyber Centre guidance referenced here is the most authoritative available.

Are you affected?

Assume yes until proven otherwise. The NCSC advises organisations using any version of PHP to treat themselves as affected and not to limit discovery to old versions. Check for PHP in these places:

• Public websites and customer portals, especially WordPress, Drupal, Joomla, Magento, Laravel or Symfony sites.
• Internal web applications, intranets, wikis and admin consoles.
• Containers and cloud workloads built on official or vendor PHP images.
• Third-party appliances and products that bundle PHP (monitoring tools, ticketing systems, network devices, mail gateways). NCSC-NL maintains a public inventory of affected products.
• Managed hosting and PaaS platforms: confirm with your provider that their PHP runtime has been patched.

Older branches (PHP 8.1 and earlier) are out of standard support and do not receive routine official releases. If you run these, the NCSC recommends upgrading to a fully supported version rather than relying on third-party backports.

Recommended actions

The only complete fix is to update PHP. Everything else reduces risk but does not remove it. Work through these in order.

Priority 1: Update now

• Update every PHP installation to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or the equivalent patched package from your Linux distribution, container image or hosting provider), prioritising internet-facing systems.
• Restart all PHP worker processes (Apache, PHP-FPM, containers) after updating, and confirm the running version.
• Where you cannot update or mitigate promptly, follow NCSC guidance and consider taking the system offline until you can.

Priority 2: Interim hardening where updating is delayed

(taken directly from the PHP advisories; each only partially mitigates)

• Set memory_limit=-1 at server level so no pool, directory or application can restore a finite limit, then restart every worker. Do not use RLIMIT_AS or RLIMIT_DATA; these make the problem worse.
• Set session.upload_progress.enabled=0 and restart every worker. The PHP team suggests leaving this off even after patching if you do not use the feature.
• On PHP 8.5 only, also set fatal_error_backtraces=0.
• At your firewall, WAF or reverse proxy: keep post_max_size conservative, enforce request size limits, and block multipart form uploads entirely for applications that do not need them.
• Remove invalid or deprecated per-request PHP settings (for example in .htaccess or PHP_VALUE headers) that generate warnings before a request starts.
• If performance allows, set pm.max_requests=1 on PHP-FPM so each worker handles a single request.

Priority 3: Check for compromise

• If a system was exposed and unpatched after 17 October, the NCSC advises assessing it for backdoors before or alongside upgrading. Look for unexpected files in web directories, unusual child processes spawned by the web server, and unexpected outbound connections.
• Enable log_errors=On with error_reporting=E_ALL during an audit and review for repeated warnings, fatal errors or “Maximum execution time exceeded” on attacker-reachable routes.

Priority 4: Ongoing

• Monitor vendor advisories for appliances and third-party products that embed PHP and apply their updates as they are released.
• Plan migration off PHP 8.2 before its end of support on 31 December 2026.

Sources

• PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): RCE via OOM corruption
• PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): RCE via stale global state
• UK NCSC: Critical security issue affecting PHP
• NCSC-NL: inventory of products embedding PHP
• BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches
• CyberScoop: PHP releases emergency fixes for 2 critical vulnerabilities
• Help Net Security: PHP2Shell critical PHP vulnerabilities patched
• MyBroadband: Thousands of Internet servers in South Africa at risk of being taken over
• MyBroadband: South African companies scrambled to protect customers from critical PHP security flaw

The information reflected in this advisory has been created from information at the time of its writing. It is recommended that any recommendations be evaluated before any implementation as the impact of these changes are environment dependent.