PHP2Shell, Part Two

On October 21, PHP shipped an emergency release that closed the two critical remote-code-execution flaws known as PHP2Shell, CVE-2026-109618 and CVE-2026-109619. A third path, CVE-2026-115560 in the session upload progress feature, was acknowledged and left without a fixed release. We wrote about that gap and said part two was coming. This is it.

PHP is not done. The picture has changed hard since we first wrote: a new wave of zero-days has dropped, the research is public, and it ships working exploit code that anyone can pick up today. The most serious items are unauthenticated remote code execution, which means an attacker needs no login, no credentials, and no foothold to run commands on an exposed server. That is as bad as a web flaw gets. With exploit code in the open and no vendor fix to apply, the window to get ahead of this is already closing, even though CVE assignment and full vendor confirmation are still pending. If you run PHP anywhere on the internet, assume you are in scope until you have proven otherwise.

What the research shows

The work is the researcher acd421's. They took the October patch apart and kept going, and the result is not a rehash of the two bugs that were fixed, it is a fresh set of zero-days that survive the current releases across four fronts at once. The findings fall into four groups:

• PHP core. Further weaknesses in how PHP handles sessions and how it serializes and unserializes objects, reachable on builds that are otherwise current.
• Windows PHP. A file-handling path specific to PHP on Windows.
• NativePHP. A framework-level path in NativePHP mobile apps, independent of the PHP-level settings above, because it sits in the app framework rather than in PHP itself.
• Ubuntu 22.04 LTS. A PHP package on that release that never received the October fixes, so hosts on it remain exposed to the original class regardless of the upstream patch.

These are researcher-reported and, at the time of writing, not all vendor-confirmed. The full technical detail sits with the researcher's own disclosure: acd421's public disclosure. We are not reproducing exploit detail here.

What to do while fixes land

• Keep the October 21 PHP fixes (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) in place. Nothing here is a reason to roll them back.
• Treat session.upload_progress.enabled=0 as a stopgap on one path, not a complete mitigation, and plan to apply the upstream fixes when they ship.
• If you run Ubuntu 22.04 LTS, check your PHP package level. Hosts still on the pre-fix package are exposed to the original class, so prioritize that update.
• If you ship a NativePHP mobile app, review how the app bridge exposes privileged operations and where it unserializes data it did not produce.
• As a general measure, do not unserialize data from an untrusted source, and watch for PHP, Canonical, and NativePHP security updates over the coming days.

Where RedEye stands

We reported these to PHP, Canonical, and the NativePHP maintainers in good faith ahead of public disclosure, so the people who can fix them had notice first. We are not assigning CVE IDs for these; our CNA scope is our own product, and assignment belongs to each vendor. We did not do the discovery, and we are crediting the research to acd421. We will update this page as fixes ship and as advisories publish.