PHP2Shell on AWS: find every PHP runtime, patch or isolate end-of-life versions, and use AWS WAF as a stopgap after CERT-In's critical alert

• 17 October 2026: Amazon Threat Intelligence records an exploitation attempt against its MadPot honeypots.
• 21 October 2026: PHP releases fixed versions; AWS says the embargo lifted at 14:00 UTC.
• 21 October 2026: CERT-In issues CIVN-2026-0510, severity critical.
• 22 October 2026: CDSL issues its communique to depository participants.
• 22 and 23 October 2026: AWS adds PHP2Shell rules to its WAF managed rule group (versions 2.3, then 2.4).
• 23 October 2026: PHP flags a third flaw, CVE-2026-115560, not fixed by the 21 October releases.

CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request. CVE-2026-109619 lets one request leave stale data that a later request on the same worker reuses. Both are reached through multipart (file upload) request handling before application code runs, says AWS; PHP rates the risk highest for mod_php.

PHP says every installation serving web requests is at risk: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. AWS Security Bulletin 2026-143-AWS lists 8.2.0 to 8.2.34, 8.3.0 to 8.3.35, 8.4.0 to 8.4.26 and 8.5.0 to 8.5.11 as affected, and 5.4 to 8.1 as end of life with no upstream release.

Sound application code does not help; the flaws are in PHP. That includes platforms built on PHP such as WordPress, Drupal, Joomla and Magento, and, as The Times of India notes, commercial applications and embedded software components that use PHP.

AWS says its own services are not impacted, but customers' PHP on them can be.

On scale in India, CloudSEK, as reported by The Times of India, counted about 19,500 Indian internet-facing services showing end-of-life PHP versions on Shodan. These are counts of services that expose a PHP version, not confirmed vulnerable sites, and distribution backports can leave an old version number in place.

1. EC2. Turn on Systems Manager Inventory for all managed nodes and filter the Applications list for php packages. Also run php -v through Run Command, because source builds may not show as packages.
2. AWS Config. Record managed instance inventory to keep that history.
3. Amazon Inspector. It lists PHP among supported languages for EC2 and Amazon ECR image scanning.
4. ECS, EKS and Fargate. Check base images and rebuild on a fixed PHP.
5. Lambda. There is no managed PHP runtime, so check every custom runtime and container image. Bref users should follow Bref's security release.
6. Elastic Beanstalk. Fixed PHP platforms for 8.2 to 8.5 apply in the next weekly window if managed platform updates are on.
7. Lightsail. AWS cannot update running instances in place; create new ones from updated blueprints and migrate.
8. Amazon Linux has updated packages, says AWS. Elsewhere, check changelogs: Kaspersky notes distributions may ship fixes without changing the version number, as reported by The Economic Times.
9. Easy to miss: Amazon EMR on EC2 clusters with Ganglia on releases 4.2.0 to 6.15.0, vendor appliances and Marketplace AMIs that bundle PHP.

Record account, Region, resource, version, exposure, owner and action (patch, isolate, retire) for each.

Supported branches: upgrade, then restart every worker.

End-of-life PHP, 8.1 and older, has no upstream release. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people building from source; some distributions and LTS vendors offer backports. PHP does not say which flaws its source backports cover, and AWS says no fix for CVE-2026-109618 is available on end-of-life branches. Treat them as exposed and migrate. PHP 8.2 security support ends on 31 December 2026, so 8.2 buys only about two months. Choose the target branch now; if the upgrade means changing or moving the application, see Cloud Migration & Modernization.

Isolate what you cannot upgrade yet: security groups, private subnets, or an authenticated proxy or VPN. CERT-EU advised isolating internet-facing PHP applications from public networks if needed, as reported by The Economic Times.

Interim settings from PHP and AWS: session.upload_progress.enabled=0, which also covers CVE-2026-115560; fatal_error_backtraces=0 on PHP 8.5; memory_limit=-1, set so applications cannot override it, with an external memory cap in place, such as a container or cgroup limit or ECS task memory, because -1 removes PHP's own limit; a low post_max_size; and pm.max_requests=1 if performance allows. PHP says these reduce exposure to specific attack paths but do not make an installation safe.

AWS says patching is the only complete fix; AWS WAF reduces exposure meanwhile. From the AWS WAF guidance for PHP2Shell:

• Add the PHP application managed rule group, AWSManagedRulesPHPRuleSet, to the web ACL in front of each PHP workload on CloudFront, Application Load Balancer or API Gateway.
• The default version has both rules: PHP2Shell_BODY for CVE-2026-109619 and PHP2Shell_BODY_Extended for CVE-2026-109618. If pinned, move to Version_2.4 or later. Check the group is not overridden to Count.
• Add Core rule set SizeRestrictions_BODY (blocks bodies over 8 KB), scoped so it stays off endpoints that legitimately take larger uploads.
• Block multipart/form-data where the application takes no uploads, and rate-limit POST requests.
• Turn on WAF logging, start new rules in Count, then Block.

Limits: AWS WAF cannot see PHP worker memory or server configuration. Body inspection stops at 8 KB on Application Load Balancer, and at 16 KB by default (up to 64 KB) on CloudFront and API Gateway. Header amplification inside multipart parts can stay under size caps, so upload endpoints remain at risk.

Amazon Threat Intelligence says to investigate from at least 17 October. Look for:

• POSTs carrying PHP_SESSION_UPLOAD_PROGRESS, and repeated multipart POSTs.
• PHP fatal errors, out-of-memory errors and timeouts on upload routes.
• Unexpected process execution or file changes on web servers.

Use AWS WAF, load balancer, CloudFront, web server and PHP-FPM logs in Amazon CloudWatch Logs. AWS says the IP addresses it published are shared anonymisation infrastructure, so investigate matches rather than just blocking them. If a worker may be compromised, rotate secrets it could reach; see CERT-In's AI-agents advisory on AWS.

In India, CERT-In's Directions require logs kept for a rolling 180 days and specified incidents reported within 6 hours; see CERT-In log retention on AWS. Depository participants and stockbrokers also report to their depository or exchange; see SEBI CSCRF on AWS.

CDSL communique CDSL/IS/DP/POLCY/2026/742 asks depository participants, in its words:

• "Please confirm in case your systems have experienced any related active exploits, anomalies, or security incidents to dpinfosec@cdslindia.com"
• "Indicate if any End-of-Life (EOL) PHP versions are currently in use within your organization and outline the remediation measures being taken to upgrade or isolate them"

A practical reply structure (our suggestion, not a CDSL template):

1. Inventory scope and date.
2. PHP instances by branch.
3. End-of-life instances, each with action and target date.
4. Interim controls: WAF rule group version, server settings.
5. Log review from 17 October and its outcome.
6. Owner.

CDSL set no deadline. This is not legal advice. Banks and NBFCs can reuse the structure for their own auditors; for commercial banks, see RBI cyber security directions on AWS.

Upvantix is an AWS Select Tier Services Partner providing AWS-focused consulting and managed services. Our AWS security review covers security posture and architecture, and configuration, logging and detection, producing a risk-ranked remediation and optimization backlog, then approved implementation and validation. See also ongoing AWS operations and patching. We do not provide emergency incident response, forensic investigation or legal advice, and we do not file with CDSL or CERT-In for you.

Talk to us about a PHP exposure review of your AWS accounts.