The Critical PHP Vulnerabilities "php2shell"How to check and update PHP on Amazon Linux, and what to do until you can

1. What is happening

• Unauthenticated remote code execution. The PHP team rates both at CVSS v4.0 9.2 (Critical). Arbitrary code runs with the web server process's privileges, and files such as database credentials may be read.
• Exploited before application code runs. It happens while the request is being accepted, so applications such as WordPress or Laravel cannot prevent it. With Apache mod_php, a successful attack has been demonstrated with default settings.
• Exploitation attempts are already reported. The CVE IDs leaked the day before disclosure, so the PHP fixes were released a day early, on October 21. The same day, Cloudflare and watchTowr reported observing exploitation attempts. Security vendors around the world are warning about it under the name "php2shell."

PHP is said to run nearly 70% of websites, so the impact is very broad. Treat internet-facing PHP servers as top priority.

2. Affected versions

Every form that handles web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older are end of life, so only minimal patches for source builds are available. PHP 8.2 also reaches end of life on December 31, 2026.

3. Amazon Linux package status

According to the AWS security bulletin (2026-143-AWS), updated Amazon Linux packages are targeted for October 22, 2026. The status of each package in the Amazon Linux Security Center is as follows (as of October 22).

PHP marked "No Fix Planned" (php8.1 on AL2023 and the default PHP 5.4 on AL2) will not get fixed packages. Apply the interim mitigations in section 6, then switch to php8.3 or later or migrate to Amazon Linux 2023. Our record of migrating WordPress from Amazon Linux 2 to 2023 is in this article.

4. Check your environment

PHP version and packages

# PHP version (CLI)
php -v

# installed PHP packages
rpm -qa 'php*' | sort

# how the web server runs PHP (php-fpm or Apache mod_php)
systemctl status php-fpm httpd --no-pager | grep -E 'Loaded|Active'
httpd -M 2>/dev/null | grep -i php

The CLI and the web server may run different PHP builds. Check the web-side version by temporarily placing phpinfo(), or with php-fpm -v for PHP-FPM.

Are fixed packages available? (Amazon Linux 2023)

# is a newer release version available?
sudo dnf check-release-update

# check security updates by CVE
sudo dnf updateinfo list --cve CVE-2026-109618 --releasever=latest
sudo dnf updateinfo list --cve CVE-2026-109619 --releasever=latest

Are fixed packages available? (Amazon Linux 2)

# any PHP security updates?
sudo yum updateinfo list security all | grep -i php

# PHP enabled via amazon-linux-extras
amazon-linux-extras | grep -i php

Check many instances at once

For EC2 instances with Systems Manager, Run Command can collect the PHP version from every instance in one go.

aws ssm send-command \
  --document-name AWS-RunShellScript \
  --targets Key=tag:Role,Values=web \
  --parameters 'commands=["php -v | head -1","rpm -qa php* | sort"]' \
  --comment "php2shell check"

aws ssm list-command-invocations --command-id <COMMAND_ID> --details \
  --query 'CommandInvocations[].[InstanceId,CommandPlugins[0].Output]' --output text

5. Apply the fixed packages

Once the fixed packages are available, update and then restart every PHP process. Without a restart, the old PHP keeps running.

Amazon Linux 2023

# update only the PHP packages from the latest release
sudo dnf upgrade --releasever=latest 'php8.3*'

# or move the whole OS to the latest release
sudo dnf upgrade --releasever=latest

# restart (both php-fpm and Apache)
sudo systemctl restart php-fpm
sudo systemctl restart httpd

# verify (8.3.36 or later for 8.3)
php -v

If you use php8.4 or php8.5, adjust the package name accordingly.

Amazon Linux 2 (php8.2 from Extras)

sudo yum update 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd
php -v   # 8.2.35 or later

Containers and AMIs

• For containers such as ECS, rebuild your image on a base image that includes the fixed PHP and replace the tasks.
• If Auto Scaling launches from an AMI, build an updated AMI and switch the launch template. Updating only the running instances means the next scale-out launches the old PHP.

6. Interim mitigations

Until the fixed packages arrive, or if you run a PHP with no planned fix, the following lower the chance of a successful attack. None of them is a complete fix. Update as soon as you can.

CVE-2026-109619: disable upload progress

; /etc/php.ini (or a file under /etc/php.d/)
session.upload_progress.enabled = 0

; on PHP 8.5, also
fatal_error_backtraces = 0

Put this in php.ini, a PHP-FPM pool or the Apache config, and restart every worker. ini_set() and .user.ini don't work. If you don't use the upload progress feature, keeping it disabled even after patching is recommended.

CVE-2026-109618: limit request size

; no file uploads
post_max_size = 8M
; with file uploads (keep upload_max_filesize below this)
post_max_size = 32M

• If your site doesn't use multipart requests, reject them in front of PHP at the load balancer or web server.
• Limit request size, header count and input field count at the web server or proxy, including requests without Content-Length.
• The PHP team also lists memory_limit = -1 (set so applications can't override it), but this risks exhausting memory, so combine it with a container or cgroup memory limit. Don't use process memory limits such as RLIMIT_AS, which can trigger the vulnerability.

Block with AWS WAF

If AWS WAF is attached to your ALB or CloudFront, AWS recommends the following two measures.

• CVE-2026-109618: enable SizeRestrictions_BODY in the Core rule set (CRS), which blocks request bodies over 8 KB. It also blocks uploads such as those from the WordPress admin screen, so check the exclusion conditions before enabling it.
• CVE-2026-109619: add a custom rule that blocks POST requests whose body contains PHP_SESSION_UPLOAD_PROGRESS and whose body or cookie contains PHPSESSID (AWS shows an example named "PHP2Shell").

AWS also plans to update the "PHP application" managed rule group.

7. Elastic Beanstalk and Lightsail

AWS services themselves are not affected. What is affected is the PHP that you run on top of these services.