Two unauthenticated remote-code-execution flaws in PHP 8.2–8.5, exploited in the wild before they were disclosed. The fixed versions, what to do on Elastic Beanstalk, Lambda, Lightsail and containers, and why the config workarounds circulating are not enough.
On October 21, 2026 the PHP project published fixes for two critical vulnerabilities, now known as PHP2Shell. Both are rated 9.2 (CVSS v4.0) and both let an unauthenticated attacker run code on a web server by sending it a crafted request. No login, no plugin, no unusual application code required: the bugs are in how PHP itself processes incoming requests.
CVE-2026-109618 — when PHP runs out of memory part-way through setting up request data, it leaves half-initialized data behind, and the cleanup routine later treats it as valid. That path leads to code execution.
CVE-2026-109619 — PHP keeps request-specific state after the memory behind it has been freed, so a later request can reach it. File-upload processing and session upload progress are among the paths that trigger it.
Almost certainly, if you serve PHP to the internet and have not upgraded since October 21. Every web deployment model is affected — Apache mod_php, PHP-FPM behind Nginx, php-cgi, FrankenPHP and LiteSpeed — at default configuration. WordPress, Laravel, Drupal, Magento and every other PHP application inherit the exposure from the runtime underneath them.
Fixed versions from the PHP project, October 21, 2026.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
AWS has released patched PHP platform versions for 8.2 through 8.5. Environments with Managed Platform Updates enabled pick them up in their next maintenance window — which may be days away. Do not wait for it: apply the platform update now from the console or with eb upgrade, and confirm the new platform version on every environment, including staging environments that are still public.
Lambda has no managed PHP runtime, so nobody is patching this for you. If you run PHP on Lambda through Bref layers or your own container image, update to a Bref release built on a fixed PHP version — the Bref project has published security releases — or rebuild your image on a patched base, then redeploy every function. A function you have not redeployed is still running the old layer.
Updated php8.x packages are available for Amazon Linux 2023. Run the update, then restart PHP-FPM or Apache — the old binary stays in memory until the worker processes are replaced. The same applies to every other distribution: a package upgrade without a service restart has fixed nothing.
Rebuild every image that contains PHP on a patched base image, push it, and roll the service. Pinned base-image digests mean you are still on the vulnerable build until you change them. Amazon Inspector and ECR enhanced scanning will flag the vulnerable package across your registry, which is the fastest way to find images nobody remembers owning.
AWS cannot update running Lightsail instances in place. Either patch PHP on the instance yourself, or create a new instance from an updated blueprint and migrate to it. The many WordPress sites launched from Lightsail blueprints and then left alone are exactly what attackers are scanning for.
The AWS WAF PHP application managed rule group is being updated for these attacks. If you use its default version you get updates automatically; if you pinned a version, move to the latest. WAF buys you time while you patch — it does not replace patching.
You will see configuration-only mitigations recommended on social media — chiefly setting session.upload_progress.enabled=0, raising or removing memory_limit, and capping request body sizes. They narrow some attack paths. They do not close them, and both the PHP project and AWS are explicit that only upgrading fixes these vulnerabilities. Use them only to reduce risk for the hours until you can patch.
Two days after the fixes, PHP warned of a further issue, CVE-2026-115560, which may allow code execution in unusual session configurations; the interim advice there is also to disable session upload progress until a routine fix ships. Watch php.net for that release.
Web logs: POST requests carrying PHP_SESSION_UPLOAD_PROGRESS fields, multipart bodies with hundreds of parts in under a megabyte, or extremely long single field names.
PHP error logs: bursts of "Allowed memory size exhausted ... in Unknown on line 0".
Web server logs: bursts of worker segmentation faults (Apache: "AH00052 ... exit signal Segmentation fault").
Processes: your web server user (www-data, apache, nginx) spawning a shell — sh -c under a PHP worker is never normal.
Outbound traffic from web tiers to destinations they have never talked to — VPC Flow Logs and GuardDuty are the place to look.
If you find any of these, treat the host as compromised: rotate every credential the PHP application could read (database passwords, API keys, the instance role's sessions), rebuild rather than clean, and review CloudTrail for activity from those credentials since October 17.
Inventory every PHP runtime you run — Beanstalk environments, EC2 fleets, container images, Lambda layers, Lightsail instances. Inspector helps; so does searching your IaC for php.
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and restart or redeploy so the new binary is actually running.
For anything on PHP 8.1 or older: upgrade the branch, or isolate it from the internet until you can.
Turn on or update the AWS WAF PHP managed rule group in front of anything you cannot patch today.
Hunt for the indicators above from October 17 onward, and rotate credentials anywhere you find them.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
AWS WAF or Cloudflare vs Filtering Bad Traffic in Your Code: What a Bot Flood Costs on Serverless
One post gets shared, the bots arrive, and every request runs your code: API Gateway charges for it, Lambda bills the time, and the whole Region shares 1,000 concurrent executions. Worked numbers for a six-hour flood with no firewall, with filtering in code, and with AWS WAF or Cloudflare in front, and why the third is about availability more than money.
Read
SEC Cybersecurity Disclosure: Four Business Days After Materiality, and What Engineering Must Be Able to Answer
Public companies must disclose a material cybersecurity incident on Form 8-K Item 1.05 within four business days of determining it is material, and describe their risk management and governance each year in the 10-K. The legal team owns the disclosure; engineering owns the facts it needs, fast. What those facts are and how to have them ready.
Read
As of October 24, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.