Amazon saw PHP2Shell exploit attempts before patch; new checker verifies Debian PHP versions

Attackers were probing for the two critical PHP vulnerabilities known as PHP2Shell days before fixes were released, according to an Amazon Threat Intelligence report described by The Verge, which notes the findings were earlier reported by Wired and Bleeping Computer. The discovery tightens the timeline on a security scramble that saw websites across the internet, including many built on WordPress, rushing to update on October 21.

Exploitation attempts preceded disclosure

According to The Verge, Amazon chief information security officer CJ Moses writes that the company's security team detected a PHP2Shell exploit attempt on October 17 through a honeypot, a monitoring system designed to attract attackers. Further attempts appeared on October 21, in the hours before the patch went out. Moses writes that because the targeting came from an anonymized IP address while the vulnerability was still under embargo, it points to threat-actor activity, though how the actor learned of the flaw before disclosure "remains unclear."

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect a programming language that powers a large share of the web. A post on dev.to summarising the official advisory describes them as enabling unauthenticated remote code execution. PHP Foundation executive director Elizabeth Barron tells The Verge that, to the foundation's knowledge, there has been "no successful attempt at remote code execution," while stressing that updating affected systems is "imperative."

A fix two years in the making

The Verge reports that the PHP Foundation first theorised the bug in 2024. Its security team drafted fixes, but shipping them risked breaking backward compatibility, opening new denial-of-service problems, or forcing changes across so many third-party extensions that coordination looked unworkable. As this week's release approached, details leaked onto forums and social media, and some security firms published information ahead of the official advisory, creating a window in which the flaws were partly public but still unpatched. The foundation says it is changing processes so leadership hears about similarly stuck fixes sooner and can steer them to a faster resolution.

Checking what actually serves traffic

Applying an update only helps if it reaches the PHP runtime answering requests, which is where new tooling enters the picture. The dev.to post introduces PHP2Shell Checker, a read-only open-source script for Debian 12 and 13 that inventories every recognised PHP installation, including CLI, FPM, CGI and Apache mod_php, and compares package versions against known fixed thresholds.

Per the post, the fixed package versions are 8.2.35-1deb12u1 for PHP 8.2 on Debian 12 (bookworm) and 8.4.27-1deb13u1 for PHP 8.4 on Debian 13 (trixie), matching Debian advisories DLA-4848-1 and DSA-6574-1. The advisory also covers web-serving setups such as PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed.

The tool reports one of three statuses: FIXED, UPDATE or UNKNOWN. UNKNOWN is deliberate, since vendors sometimes backport security fixes without adopting the latest upstream version number, and guessing either way would mislead. The checker also flags held packages that could block updates, shows candidate versions available through APT, and can scan arbitrary directories for PHP runtimes outside the packaged set. It runs on the Python standard library alone, makes no network requests and changes nothing on the host.

The author notes two limits worth heeding. Package metadata does not prove that running workers were restarted, so PHP-FPM services, Apache under mod_php and long-running PHP workers need a restart after updating. And containers, chroots, custom builds and application code require separate checks; a FIXED result describes assessed packages, not the whole server.

Why it matters

The Amazon report shows that an embargoed vulnerability can move from private knowledge to active exploitation attempts before a patch exists, compressing defenders' response time from days to hours. The checker addresses an equally practical gap: a server can carry several PHP branches, and a current CLI binary says nothing about the older PHP-FPM pool still serving a site. For Debian administrators, verifying every runtime that handles traffic, and restarting workers afterward, is the difference between assuming a patch landed and knowing it did.