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.

The picture has changed since we first wrote. The research is public, and it ships working exploit code. The most serious items are unauthenticated remote code execution, which means an attacker needs no login to run commands on an exposed server. Exploit code being public with no vendor fix is what makes this urgent, even though CVE assignment and full vendor confirmation are still pending.

What the research shows

The work is the researcher acd421's. They took the October patch apart and kept going, and the result is a set of issues that survive the current releases rather than a rehash of the two that were fixed. 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.