TL;DR

• PHP2Shell is the name for two serious flaws in PHP (CVE-2026-109618 and CVE-2026-109619) that let an attacker run code on a web server without logging in. Fixes came out on 21 October 2026 and attacks have already been reported. The NCSC says to consider taking offline anything you can’t fix straight away.
• Patching is the fix, but it won’t happen everywhere overnight. Some PHP versions no longer get fixes, some systems are forgotten, and attackers were trying it before the flaws were public. Protection at the edge covers you while you patch, as long as attackers can’t skip it by going straight to your servers.
• Akamai App & API Protector filters bad requests before they reach your site, and Site Shield makes sure only Akamai traffic can reach your servers. This piece explains how they work together, and what to ask your team this week.

What Happened

PHP2Shell is a flaw in PHP itself. The PHP core team issued an out-of-band security release for it, and for CVE-2026-109619, on 21 October 2026. Both are rated 9.2 on CVSS v4 and can allow unauthenticated remote code execution. The cause of CVE-2026-109618 is PHP’s use of longjmp() for out-of-memory errors, which can leave request memory uninitialised before cleanup runs.

Detail	What we know
The flaws	CVE-2026-109618 (remote code execution via out-of-memory corruption) and CVE-2026-109619 (remote code execution via stale global state), both rated 9.2 on CVSS v4.0
Fixed versions	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; minimal source backports were also released for PHP 7.4, 8.0 and 8.1
Who is affected	Help Net Security reports every PHP installation serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php at greatest risk
Exploitation	watchTowr reports exploitation in the wild from 21 October; Amazon Threat Intelligence recorded an attempt on 17 October, four days before disclosure. CISA said it had not observed exploitation when it published its alert
Official advice	Patch immediately; the NCSC urges organisations to consider taking offline any system that cannot be fixed right away

Wiz reports the flaws had been in PHP for decades, and that AI tools made it much easier to turn them into working attacks. CISOs, CIOs and CITOs should take note: the gap between a flaw being made public and attacks starting keeps getting shorter. Akamai’s own research on an earlier PHP flaw, CVE-2024-4577, recorded exploit attempts one day after disclosure.

Why Patching Alone Is Not Enough

• Unsupported versions: the PHP project no longer supports 8.1 and earlier. Some distributions and long-term support vendors backport fixes, but not all.
• Forgotten systems: old and embedded applications are the ones that rarely get patched, and security researchers have warned this will cause problems for a long time.
• Testing time: patching a live web server safely takes days, and the first attack attempts came before the flaws were public.
• Third-party code: you can patch your own servers and still depend on a supplier, plugin or hosted application you do not control.

Every source we reviewed treats a web application firewall as a stopgap, not a replacement for patching. We agree. But a stopgap that works is what lets you patch in an orderly way, instead of in a panic.

Protecting Your Site While You Patch: App & API Protector

Akamai App & API Protector, formerly Kona Site Defender, filters malicious requests before they reach your servers. Akamai says its Adaptive Security Engine keeps updating protections against OWASP Top 10 threats, known vulnerabilities and API attacks, using its global threat intelligence. For a flaw that can be exploited with one request and no login, stopping traffic at the edge matters.

• It protects web applications and APIs together, which matters because API endpoints are often the PHP you know least about.
• Protections only help if they are switched on, applied to every hostname and set to block rather than just alert. Check this first.
• Check Akamai’s current advisory for the specific protections covering CVE-2026-109618 and CVE-2026-109619 and confirm they are active in your configuration.

The Bypass Problem: Why Site Shield Matters

An edge firewall only protects traffic that passes through it. If attackers find your origin server’s address, they can send requests straight to it and skip the filtering. Akamai’s own research on this, BreakingWAF, showed how cloud-based WAF protections can be bypassed this way.

Akamai Site Shield closes that door. Akamai traffic reaches your origin from a fixed set of Akamai IP ranges, which you allow on your firewall, so requests from anywhere else are refused. Akamai is clear that this is not a substitute for authentication, and recommends pairing it with controls that let requests from Akamai authenticate to your origin, such as header-based authentication or mutual TLS. Akamai also now offers an Origin IP Access Control List as a more scalable way to manage these IP addresses.

A Layered Response

Step	Action	Where Akamai fits
1. Inventory	Find every PHP instance, including embedded and supplier-hosted applications	Start with the hostnames behind Akamai, then the ones that are not
2. Patch	Update to a fixed version, or apply your vendor’s backport	Patching remains the fix
3. Verify the edge	Confirm PHP2Shell protections are active, applied to all hosts and in deny mode	App & API Protector
4. Lock the origin	Allow only Akamai traffic to reach origin servers and add authentication	Site Shield and origin authentication
5. Monitor	Review logs for exploitation attempts and unexpected requests since 17 October	App & API Protector reporting
6. Retire	Plan to remove unsupported PHP versions	Keep edge protection until retired

Questions to Ask Your Team This Week

• Are the protections for these CVEs active and enforcing on every hostname and API, not just the main site?
• Can anyone reach our origin servers directly from the internet, and is Site Shield in place and enforced?
• Do we have a complete list of PHP versions in production, including supplier-hosted systems?
• Have we reviewed logs from 17 October onwards for exploitation attempts?

What We’re Seeing in Practice

What we see most often when a vulnerability like this lands:

• Edge protection covers the main website, but other hostnames, test sites and APIs sit outside it.
• The origin is still reachable directly, so the firewall in front of it can be skipped by anyone who finds the address.
• Nobody can say within an hour which PHP versions are running where, so a patching job becomes a hunt for what you own.

ITogether’s Independent Verdict

PHP2Shell is a reminder that the gap before you patch is the risky bit, and that edge security and patching work together. Patching removes the flaw. Edge protection and locking down the origin cut your exposure while you do it, and cover anything you can’t patch in time.

As a UK Akamai partner, ITogether implements App & API Protector and Site Shield, and we can review whether yours are configured to protect against this. The same applies to New Zealand organisations, where our Akamai team can help too, and to European teams facing the same timetable. This piece is deliberately Akamai-focused because it is what we implement, but the principles apply whichever edge platform you use.

👉 Not sure your edge protection and origin lockdown would stand up? Get in touch.

📞 UK +44 (0) 113 341 0123

📞 NZ +64 (0)9 802 2444

📧 hello@itogether.com

FAQs

What Is PHP2Shell?

PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. They allow unauthenticated attackers to execute code on servers running PHP and were patched on 21 October 2026.

Does a WAF Replace Patching?

No. A web application firewall reduces exposure while you patch, but every source we reviewed treats it as a stopgap. Patch to a fixed version, or apply your vendor’s backport, as soon as you can.

What Does Akamai Site Shield Do?

Site Shield restricts access to your origin servers to a defined set of Akamai IP addresses, so attackers cannot bypass edge protection by going straight to the origin. Akamai recommends pairing it with authentication to the origin.

Who Should Act on This?

CISOs, CIOs and CITOs responsible for any internet-facing PHP application, including supplier-hosted and embedded systems. Start with an inventory, then patch, verify edge protection and lock down the origin.