Thursday, October 22, 2026
Patch priority

PHP2Shell: PHP 8.2 to 8.5 are fixed, older builds hang on your distro

The PHP project fixed four branches. Everything else, from Ubuntu 20.04 to the default PHP on AlmaLinux 8, depends on your vendor, and Amazon saw an exploit attempt as early as October 17.

A person in silhouette against multiple computer monitors displaying lines of code

The PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21 to fix CVE-2026-109618 and CVE-2026-109619, the pair now called PHP2Shell. Both are rated 9.2 and let an attacker run code on a web server without logging in. The release was planned for October 22 and moved up a day after a public leak, Ubuntu says. The PHP announcement says there are no complete mitigations and updating is "the only safe choice."

PHP sits under WordPress, Drupal, Joomla, Magento and Laravel, often inside a hosting panel or a container image that nobody on the app team owns. Calif, which found the flaws with Wiz and OpenAI researchers, confirmed pre-login code execution against specific versions of the first four, Tenable reports. Updating the application does nothing here. The fix has to reach the PHP runtime itself, which comes from the server package, the host or the image, as The Hacker News points out. The flaws also let an attacker read worker memory, which can hold other requests' passwords, tokens, API keys and certificates.

Is it being exploited?

Amazon Threat Intelligence saw an exploit attempt against its honeypots on October 17, four days before disclosure, according to Tenable, and recommends that investigations start from at least that date. watchTowr reported active exploitation attempts against both flaws at 14:19 UTC on October 21. As of The Hacker News's latest update, no source had confirmed a break-in. As of 11:26 UTC on October 21, neither flaw was in CISA's Known Exploited Vulnerabilities catalog. The UK's NCSC told organizations to patch immediately or take systems offline. BambooHR pulled its service in the US, Canada and Ireland as a precaution.

Where your fix comes from

Upstream PHP 8.2 to 8.5

Install the matching fixed release. Plan for 8.2 separately, because its support ends on December 31, 2026.

Upstream PHP 7.4, 8.0 and 8.1

There is no official release. For these three branches the project's security team put out small source patches, meant for teams that compile PHP themselves. Versions 5.4 to 7.3 get nothing from the project, Tenable says.

Ubuntu

Fixed packages are out for 22.04 (php8.1 8.1.2-1ubuntu2.28), 24.04 (php8.3 8.3.6-0ubuntu0.24.04.13), 26.04 and 26.10. Ubuntu 20.04 and older get the fix only through Ubuntu Pro, which is free for up to five machines. Distributions got the patches early, so a fixed package can carry what looks like an old version number. Debian's advice is to look for the CVE number in the package changelog.

AlmaLinux and RHEL

AlmaLinux is backporting to php:7.4 and php:8.2 on AlmaLinux 8, PHP 8.0, 8.2 and 8.3 on AlmaLinux 9, and PHP 8.3 and 8.4 on AlmaLinux 10, through its testing repository first. Retired streams are not in the first round, and that includes php:7.2, the default on AlmaLinux 8. When AlmaLinux posted, Red Hat had not published fixed PHP packages.

Remi repository

CERT-EU warned that rpms.remirepo.net had nothing ready on the day of the fix. Move those servers to the distribution's own packages, or compile PHP yourself.

AWS

Amazon Linux has updated packages in commercial regions. Elastic Beanstalk released PHP platform v4.13.12 on October 21, with a follow-on release carrying the upstream fix targeted for October 22. It reaches environments with Managed Platform Updates at their next maintenance window, and the rest need a manual platform update. Lightsail is different: AWS says it cannot patch running instances in place, so those need new instances from the updated blueprints and a migration.

Containers, panels and hosts

Rebuild every image that carries PHP and redeploy it. Chainguard published patched images on October 21. AlmaLinux notes that PHP from a control panel, host or third-party repository is that vendor's to fix, so ask them for a date.

Cloudflare's firewall rules help only for traffic that passes through Cloudflare, and its CTO, Dane Knecht, called them "a STOPGAP only."

What IT teams should do

  1. List every server, image and hosted site that runs PHP, including vendor appliances. CERT-EU points to the NCSC-NL php2shell repository on GitHub for third-party products that embed PHP.
  2. Patch internet-facing Apache with mod_php first. CERT-EU says the demonstrated exploit needs one unauthenticated request.
  3. Restart Apache, PHP-FPM and every long-running PHP worker after patching. Ubuntu notes that applications using PHP typically need a restart to pick up the fix.
  4. Where you cannot patch today, set memory_limit=-1 so applications cannot override it, cap post_max_size at 8M (32M if you need uploads), set session.upload_progress.enabled=0, and set fatal_error_backtraces=0 if you run 8.5. Avoid RLIMIT_AS and RLIMIT_DATA, which AlmaLinux says can trigger the bug. CERT-EU says these steps "do not make an installation safe," so isolate those systems from the internet if you can.
  5. After patching, check memory_limit and post_max_size against what the application needs. The fix adds a hard memory limit that ends the process when reached.
  6. Search logs back to October 17. The Hacker News lists the signs: odd multipart uploads that end in memory-limit errors, runs of HTTP 500s, very large PHPSESSID cookies and PHP workers restarting for no clear reason.
  7. Book the move off PHP 8.1 and older, and plan 8.2's exit before December 31.

Related: Oracle's October patch: what to patch first and October 2026 Patch Tuesday priority.

Sources