Attackers Probed Two PHP Flaws Four Days Before Public Disclosure
Amazon Threat Intelligence has identified exploitation activity against two critical PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 (a CVE is a public identifier for a specific security flaw). The activity dates to October 17, 2026, four days before public disclosure. Amazon captured it in MadPot, its honeypot monitoring system, which places decoy services online to lure attackers into interacting with them. Amazon's security blog reports the PHP2Shell attempt in MadPot telemetry.
The October 17 attempt targeted a MadPot honeypot from an anonymized IP address. Amazon's findings point to activity by a threat actor rather than automated scanning alone. Amazon Threat Intelligence also recorded several further PHP exploitation attempts on October 21, in the hours before the patch release.
Amazon later detected additional PHP2Shell exploitation attempts after patches were released. The Hacker News reported those post-patch attempts. Wired reports that the PHP2Shell vulnerabilities are being broadly exploited in the wild.
The flaws could allow attackers to run malicious code remotely on vulnerable devices. Elizabeth Barron, executive director of the PHP Foundation, said that to her knowledge there has been no successful remote code execution. The two statements describe different things: attempts recorded by sensors, and confirmed compromises reported by the project. Coverage of the findings by The Verge names Amazon's chief information security officer, CJ Moses, in connection with the disclosure.
The PHP Foundation first theorized the underlying bug in 2024. It delayed a fix because the change would break backward compatibility, meaning existing code that relies on current behavior could stop working. The fix would also introduce new denial-of-service potential, a path that could knock a service offline, and it would require changes to many third-party extensions. A Reuters video report states the flaw had existed for more than a decade and was discovered by AI.
On October 21, Reuters reported that an EU agency had warned websites may need to be taken offline while PHP prepared patches. Cybersecurity agencies in several regions urged PHP users to update immediately, or to take websites offline until patches could be applied. Reuters carried the EU agency warning.
In my view, the 2024 decision to defer the fix is the detail operators should weigh most carefully. The delay reflected real engineering costs. A compatibility break touches every application and extension that depends on existing behavior, and a fix that trades one exposure for a denial-of-service path is not a clean substitute. Those costs fell on the same ecosystem now being told to patch or go offline, often on short notice. For anyone running PHP in production, the gap between the disclosure timeline and the observed activity is the part that matters most.
The broader context here is what visibility means for defenders. MadPot caught activity that predated public knowledge of the flaws by four days. That is useful to defenders who can read the telemetry and of limited use to those who cannot. For a hosting provider or platform team, the practical question has been narrower: whether the PHP runtime and the third-party extensions they depend on can be updated on the first day of the window, or whether the site must come down until they can.
