PHP2Shell on AWS: Which of Your PHP Versions Are Still Exposed?

PHP2Shell is two unauthenticated remote code execution bugs in the PHP runtime itself, both rated 9.2, fixed on 21 October. The date worth looking at is the earlier one. Amazon Threat Intelligence "identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026", four days before anybody published anything.

So this week's question is not whether to patch. It is whether you can list every PHP version you are running, including the WordPress site on Lightsail and the Beanstalk environment on a platform version from 2024.

Spend the first hour on inventory rather than on patching. Patching what you can see is the easy half. The host that gets taken is the one that was never on the list.

What does PHP2Shell actually break?

The request lifecycle, in two separate places. The php.net advisory of 21 October pairs them: CVE-2026-109618, "RCE via OOM corruption", where "out-of-memory handling can interrupt PHP while internal request data is only partially initialized", and CVE-2026-109619, "RCE via stale global state", where "request-owned internal state can survive after its backing memory has been freed". Both are CVSS v4.0 9.2 in GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

Neither is an application bug, so no framework upgrade helps. The advisory names the exposure as "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", then singles one out: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

Read that last clause twice, because it sets your patch order. Before any application code runs means your login throttle, your session checks and every WAF rule written against an application route sit downstream of the thing being attacked.

Which of your AWS accounts is still running PHP?

More of them than the architecture diagram shows. AWS's bulletin says "AWS services are not impacted by these issues", then lists where your own PHP lives: Elastic Beanstalk, Lightsail, Amazon Linux, WorkMail, and EMR on EC2 releases 4.2.0 to 6.15.0 if anyone ever turned on Ganglia.

Three of those behave differently. Beanstalk environments "with Managed Platform Updates enabled will receive the update automatically", so the ones that will not are the environments somebody switched that off for after an update broke something. Lightsail is the awkward one: AWS says it "cannot update running Lightsail instances in place", so a Lightsail WordPress blog is a rebuild from a blueprint.

Containers are the gap nobody budgets for. A patched host does nothing for a php:8.3-fpm layer baked into an image in July and still running on ECS or EKS. If your task definitions resolve a floating tag at pull time, that is the position we wrote about in the post on the LiteLLM release pipeline, except this week it works in your favour.

What order should you patch in?

Four groups, highest risk first, and the order is the advisory's rather than ours.

• Internet-facing Apache with mod_php. The demonstrated path, and it needs no credentials.
• Internet-facing PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, including anything behind CloudFront or an ALB. A proxy does not remove the request.
• Container images, then the deployments using them.
• Internal and admin-only PHP, plus CLI workers.

Verify in the running process, not the package manager. A host can carry a patched php-cli while an FPM pool nobody restarted serves the old binary out of memory. Restart every worker, then ask the worker its version.

What do you do about PHP 8.1 and older?

Find out who, if anyone, maintains it for you. php.net is direct: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details." Given how bad these two are, the team made an exception and "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor".

That sentence is also your evidence that this reaches well back before the supported branches. On 7.4 you are choosing between a source build, a commercial LTS contract and a real upgrade, and only the third helps you in January. Check where 8.2 lands too: the supported versions page ends security support for that branch on 31 December 2026, so 8.2.35 buys about two months. Give the move to 8.4 a named owner.

What can you turn off while you patch?

Several things, and the advisory is clear they "reduce exposure to specific attack paths but do not make an installation safe".

For the stale state bug, set session.upload_progress.enabled=0 and restart every worker. The advisory is specific about where: "Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini." On PHP 8.5, fatal_error_backtraces=0 closes one more route.

Keep that session setting after you patch. A follow-up advisory on 23 October asks you to leave it in place "until the next regular bugfix release, to fully protect from an unlikely RCE vector", tracked as CVE-2026-115560. It only bites an application that switches session.serialize_handler at runtime before session_start(). One line of ini is cheaper than proving you are not that case.

For the OOM bug, lower post_max_size: the advisory suggests 8M with no file uploads and 32M with them, keeping upload_max_filesize below it. It also recommends memory_limit=-1 through php_admin_value, paired with a cgroup limit as the availability boundary. One warning is easy to miss: "Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure."

At the edge, AWS has added rules to the PHP application managed rule group: PHP2Shell_BODY from version 2.3 and PHP2Shell_BODY_Extended from 2.4. On the default version "these rules are already active". If you pinned it, as a regulated account often has, move to 2.4.

What should you look for in logs from 17 October?

Start on the 17th, not the 21st. AWS suggests you "look for POST requests with the PHP_SESSION_UPLOAD_PROGRESS string in form uploads", and reports further attempts "from 2026-10-21 0200 UTC to 2026-10-21 0800 UTC". Check for unexpected process execution and file modifications on the PHP hosts too.

Be honest about the limits. The stale state advisory says a server path "may publish stale state or consume it without a predictable log entry", so a clean access log proves very little. If a host shows unexplained worker churn or 500s around a burst of multipart POSTs, work out what its instance role could reach, the arithmetic we walked through for an instance role leaving the box through the SSM Agent. Rotate on the assumption it ran, then narrow with evidence.

What does CERT-In expect if you find a compromise?

A report inside six hours. CERT-In's note CIVN-2026-0510 rates this critical and says "Multiple reports confirm large scale exploitation in the wild", so nobody can argue later that the risk was unknowable. The directions of 28 April 2022 require Annexure I incidents to be reported "within 6 hours of noticing such incidents or being brought to notice about such incidents", and unauthorised access is item iii. What meeting that clock takes is in our post on the six hours.

A commercial bank has a second clock on a different platform. The RBI directions of 31 July 2026 require at paragraph 182 that "the bank shall report cyber incidents within six hours of detection on DAKSH platform". Which clock applies to your entity is in the post on the 2026 directions.

What can you run on Monday?

Two jobs, under two hours. Ask every managed instance what PHP it is serving, fifty at a time:

IDS=$(aws ssm describe-instance-information \
  --query 'InstanceInformationList[?PingStatus==`Online`].InstanceId' \
  --output text)

aws ssm send-command \
  --document-name AWS-RunShellScript \
  --instance-ids $IDS \
  --comment "PHP2Shell version sweep" \
  --parameters 'commands=["for b in php php-fpm php-cgi; do command -v $b >/dev/null 2>&1 && $b -v | head -1; done"]' \
  --query 'Command.CommandId' --output text

Then the two places SSM cannot see, in every region you have ever used:

aws elasticbeanstalk describe-environments \
  --query 'Environments[].[EnvironmentName,PlatformArn]' --output text

aws lightsail get-instances \
  --query 'instances[].[name,blueprintId,state.name]' --output text

Anything on a PHP platform ARN needs its version checked against the current one, and anything on a wordpress or lamp blueprint is a rebuild. For images, run php -v inside the digest actually deployed rather than reading the Dockerfile.

When is the WAF rule enough?

For the hours between finding a host and restarting it, and no longer. AWS says the same of its own control: "Patching is the only complete fix, and you should upgrade PHP as your first priority." A rule inspecting the request body is a good bet against the traffic seen so far and a poor one against the traffic nobody has seen yet.

There is one case where the interim settings are the wrong call. memory_limit=-1 hands a request as much memory as the machine has, so on a small instance with no cgroup limit you trade a risk you cannot measure for one you can. If the patch is hours away rather than days, skip it. We made the opposite choice under pressure once and spent the evening restarting workers for a different reason.

The short version

• Inventory first: SSM for instances, the API for Beanstalk and Lightsail, and the running digest for every image, in every region.
• Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, internet-facing mod_php before anything else, then restart every worker and ask the worker its version.
• Rebuild Lightsail instances from updated blueprints, and set session.upload_progress.enabled=0 in the FPM pool and leave it there past the patch.
• Read access logs from 17 October for multipart POSTs carrying PHP_SESSION_UPLOAD_PROGRESS, and if a host looks touched, rotate what its role could reach first.

If you are on 7.4, 8.0 or 8.1, today's patch is a source build or a vendor contract, and neither is a plan. Put a name and a date against the upgrade this week, while somebody still remembers why it was urgent.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.