PHP2Shell on AWS: Start on October 17, and Mind the 8 KB WAF Gap
Quick summary: AWS MadPot saw a PHP2Shell attempt on October 17, 2026, four days before the October 21 patch. Behind an ALB, AWS WAF reads only the first 8 KB of a request body, so the interim rule can miss an upload attack or block real uploads.
Key Takeaways
- AWS MadPot saw a PHP2Shell attempt on October 17, 2026, four days before the October 21 patch
- Behind an ALB, AWS WAF reads only the first 8 KB of a request body, so the interim rule can miss an upload attack or block real uploads
- On October 21, 2026, CJ Moses published Amazon Threat Intelligence's PHP2Shell timeline
- The MadPot honeypots logged the first exploitation attempt on October 17, from an IP in a commercial anonymization network
- The patch and the end of the embargo came at 14:00 UTC on October 21, four days later
Table of Contents
On October 21, 2026, CJ Moses published Amazon Threat Intelligence’s PHP2Shell timeline. The MadPot honeypots logged the first exploitation attempt on October 17, from an IP in a commercial anonymization network. The patch and the end of the embargo came at 14:00 UTC on October 21, four days later. The earliest working proof of concept AWS found appeared at 02:00 UTC that day, about 12 hours before the patch.
The bugs are CVE-2026-109618 and CVE-2026-109619 in PHP. Upgrade to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. That part is simple. Two things on AWS are less simple. Your log review starts on the wrong day if you anchor it to the advisory. And an AWS WAF web ACL on an Application Load Balancer reads only the first 8 KB of a request body, which shapes everything the interim rule can and cannot do.
Security bulletin: 2026-143-AWS. For a broader patch-priority model, see vulnerability management with CVSS and KEV.
What happened, in UTC
| When | Event | Source |
|---|---|---|
| Oct 17 | First exploitation attempt against MadPot, from an anonymization-network IP | AWS |
| Oct 20 | PHP announces a patch for Oct 21, 14:00 UTC | Akamai |
| Oct 21, 02:00 | Earliest of several public proofs of concept | AWS |
| Oct 21, 02:00 to 08:00 | More attempts from other anonymized infrastructure, with varied payloads | AWS |
| Oct 21, 14:00 | Embargo ends, patch released | AWS |
| Oct 21, after 14:00 | More proofs of concept within hours, used against sensors almost immediately | AWS |
AWS lists six source IPs and warns that they belong to shared anonymization networks. Investigate traffic from them. A blocklist built from them will catch some unrelated users and miss the next attacker. AWS also says it is unclear whether any of the attempts would have worked against a real system.
Cloud Sleuth lists both CVEs at 9.2. Akamai and AWS do not publish a score.
How the two bugs work
Akamai’s October 22 analysis gives the mechanics.
CVE-2026-109619, use-after-free. During a multipart upload, PHP’s upload progress feature keeps two raw pointers into the session data. The attacker pauses the stream for longer than session.upload_progress.min_freq (1 second by default), which forces the session to be rewritten and the old copy freed. The pointers now point at freed memory. Form fields sized to refill that memory carry a fake structure, and a second file in the same POST makes PHP write through the stale pointers and call the attacker’s function.
CVE-2026-109618, out-of-memory. The attacker pushes the request to memory_limit. PHP unwinds straight to request shutdown and skips normal cleanup. Shutdown then reads forged structures left in memory.
For scoping, two facts matter. session.upload_progress.enabled is On by default, and the session layer processes the upload before your code runs. Akamai says any endpoint that accepts file uploads is relevant, even one that ignores them. The attacker also needs a build-specific memory offset, which Akamai says can be leaked at runtime or worked out from the exact PHP build.
Where PHP runs on AWS
Most teams know about the PHP app. The hosts that get missed are the ones nobody thinks of as PHP.
| Place | How to find it | What to watch |
|---|---|---|
| EC2 with SSM agent | SSM Inventory, application name starting with php | Hosts without the agent are invisible to it |
| Elastic Beanstalk | Environments on a PHP platform | Check the platform release notes for the fixed PHP build before you redeploy |
| Lightsail | WordPress, LAMP, Drupal, Joomla, Magento blueprints | PHP comes with the blueprint image |
| ECS, EKS, Fargate | Inspector image scans, ECR tags | A running task keeps the old PHP until you rebuild and redeploy |
| Lambda | Custom runtimes (provided.*) and container images | PHP on Lambda always arrives as a custom runtime or image |
Amazon Inspector may report the CVEs. An empty Inspector result tells you nothing about hosts it does not scan.
The 8 KB gap in the interim WAF rules
AWS Security Bulletin 2026-143-AWS gives two AWS WAF mitigations, one per CVE. Classmethod tested both on an ALB on October 22.
For CVE-2026-109619, a custom rule blocks a POST that carries a PHPSESSID cookie (or the string in the body) and has PHP_SESSION_UPLOAD_PROGRESS in the body. Both body checks inspect only what AWS WAF receives.
For CVE-2026-109618, SizeRestrictions_BODY from the Core Rule Set blocks bodies over 8 KB.
The limit comes from the load balancer. Per the AWS WAF docs, Application Load Balancer and AppSync forward at most 8 KB (8,192 bytes) of a body to AWS WAF, and that limit is fixed. CloudFront, API Gateway, Cognito, App Runner, and Verified Access default to 16 KB and can go to 64 KB.
Classmethod’s results on an ALB:
| Request | Result |
|---|---|
| Attack strings ending at byte 8,191 | 403 from the custom rule |
| Attack strings ending at byte 8,193 | 200, passed through |
| 1,056,388-byte PoC-style upload, strings at about 56 KB | Blocked, by the size rule only |
| 102,710-byte image upload | Blocked by the size rule |
| 20,013-byte JSON POST | Blocked by the size rule |
So the custom rule stops an attacker who puts the strings near the start of the body. The size rule stops everything else above 8 KB, including your users’ uploads. On a PHP app that takes uploads behind an ALB, you can block real uploads or leave the gap open. Neither fixes the problem.
Our recommendation: patch the same day, and use the WAF only to cover the hours until you do. If you need the WAF for longer, put CloudFront in front of the ALB and raise the inspection limit to 64 KB. At 64 KB, the custom rule would reach the strings that sat at about 56 KB in Classmethod’s PoC-style request. An attacker who pushes them past 64 KB gets through again, and you pay extra for inspecting bodies over 16 KB. AWS puts it this way: the WAF is “a defense-in-depth control in this situation, not a replacement for the PHP upgrade.” It also does nothing for a host that can be reached without going through the web ACL.
Per Classmethod’s October 23 addendum, AWS has since added PHP2Shell countermeasures to the managed rule group for PHP applications. Check which version your web ACL pins before you count on them.
Look back from October 17
ALB access logs record the request line and status, not the body. You cannot search them for PHP_SESSION_UPLOAD_PROGRESS. Use WAF logs from a rule that matched, application or PHP-FPM logs, or packet captures if you keep them.
On each PHP host, from October 17 forward:
- Unexpected child processes of
php-fpm,httpd, ornginx - New or changed files in web roots and upload directories
- New cron entries and new local users
- Outbound connections from the web tier to addresses it has never called
AWS’s broader point applies beyond this CVE. Exploitation can start before the advisory, and detections tied only to a CVE signature arrive after the first attempts. If your team runs a 7-day or 30-day patch window for internet-facing critical bugs, AWS now argues for hours. Our incident response runbooks post has the containment steps.
The same week also brought fixes for GitLab, Node.js, and a malicious LiteLLM release, all on October 21 (per Cloud Sleuth). They need their own inventories and are out of scope here.
What to do this week
- Run
find-php-on-aws.shin every account. Add hosts it cannot see. - Patch to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Rebuild container images. Plan upgrades for 8.1 and older.
- Check your WAF body inspection limit before trusting any body rule. On an ALB it is 8 KB.
- Deploy the Count-mode rules on hosts you cannot patch today. Read the counts before switching anything to Block.
- Review host and app logs from October 17. Follow the checklist.
Want a second pair of hands on the sweep, the WAF rollout, or the log review? FactualMinds is an AWS Select Tier Services Partner. Start at AWS cloud security, managed SOC and MDR, or contact us.
What this post doesn’t cover
- A working exploit or test payload. We do not publish one.
- Elastic Beanstalk and Lightsail patched-image dates. Check each platform’s release notes. We have not confirmed them.
- Whether Inspector and GuardDuty detect these CVEs. None of the sources say. Test with your own findings.
- AWS WAF pricing for raising the CloudFront body limit. See the AWS WAF pricing page.
- GitLab CVE-2026-110264, the Node.js Brotli fix, and LiteLLM 1.107.0. Same week, different response.
Related reading
- AWS WAF production guide
- AWS WAF API protection beyond the basics
- Amazon Inspector v2 for containers and Lambda
- Vulnerability management with CVSS and KEV
- AWS security incident response runbooks
Frequently asked questions
What is PHP2Shell?
Which PHP versions fix it?
When should we not rely on the AWS WAF rule?
What goes wrong if we turn on SizeRestrictions_BODY in Block mode?
Why start the log review on October 17?
Can we search ALB access logs for the exploit string?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
Nash Ogden
