# PHP2Shell flaws were targeted four days before disclosure

> AWS saw one actor probing a honeypot four days before the PHP2Shell bugs were disclosed, and the flaws are now broadly exploited. Here is what that means.

- Published: 2026-10-22
- Topic: [Security](https://futuretechnologyhq.com/topic/security/)
- URL: https://futuretechnologyhq.com/article/php2shell-exploited-before-patch/
- Publisher: [Future Technology](https://futuretechnologyhq.com/), free to read. Quote as "Future Technology" with a link to the article.

## Key points

- Two critical PHP vulnerabilities are known collectively as PHP2Shell
- AWS spotted an exploitation attempt on a honeypot four days before public disclosure
- The bugs are now being broadly exploited across the internet
- Researchers at Wiz, Calif and OpenAI found and reported the flaws

## Article

Two critical vulnerabilities in PHP, collectively known as PHP2Shell, sent administrators scrambling on Wednesday. Some governments and other groups even took key websites down in anticipation of the release, so that they would not be targeted before they could apply the patches.

## The part that should worry you

Newly released details from Amazon Web Services show the rush to patch was already too late to stop every attack. AWS analysts, looking back at activity on one of their honeypots (intentionally vulnerable servers that help researchers study attack methods), spotted an exploitation attempt on 17 October, four days before the public revelations. It came from an IP address linked to a commercial anonymisation network, in other words a proxy network or VPN.

AWS's chief information security officer, CJ Moses, wrote that the targeting of a honeypot from an anonymised address while the flaw was under embargo suggests a threat actor was behind it. He also said it remains unclear how that actor acquired exploit information before disclosure. In the hours before disclosure, AWS honeypots were hit with several more exploitation attempts, anonymised through various providers and seemingly with different goals, which likely points to multiple actors. Moses cautioned that it is unclear whether any of these attempts would have succeeded against real-world systems, but added that PHP2Shell is now being broadly exploited in the wild.

PHP is not some obscure corner of the web. It is a widely used web scripting language, and applications such as WordPress and Laravel run on top of it. The flaws sit in the PHP runtime itself rather than in any application, so a site can be exposed even when its own code is secure. Both are rated 9.2 on the CVSS v4.0 scale and let an attacker without an account run code on a web server. They affect nearly every PHP version back to PHP 5.4, and researchers at Wiz, Calif and OpenAI found and reported them.

## Why the AI angle matters

AWS says the findings underline how coordinated vulnerability disclosure must evolve and speed up, given global access to AI tools that can accelerate vulnerability analysis and help less technically proficient actors develop exploits quickly.

Moses put it bluntly: the time from patch to working exploit is shrinking for structural reasons. In the past, most exploitation AWS observed came after a public proof of concept was released, with a small number of capable actors building exploits and everyone else waiting for them. That dependency is weakening. AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit, so more actors can act within hours or even minutes once technical details are disclosed.

That has an uncomfortable implication for defenders. They have to patch everything, everywhere, and keep it patched, while the window in which others can build exploits keeps narrowing.

## What you should actually do

Only updating the PHP runtime is a complete fix. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. After updating, restart Apache, PHP-FPM and any long-running PHP workers.

Updating an application such as WordPress or Laravel does not update the PHP runtime beneath it. That comes from the server package, the host or the container image, so if you use managed hosting, ask your provider about the PHP runtime directly.

Linux distributions and long-term-support vendors received the patches in advance, so a distribution package can carry the fix under an old-looking version number. Check the package changelog for the CVE, as Debian advises, rather than relying on the version string. The identifiers are CVE-2026-109618 and CVE-2026-109619.

PHP 8.1 and older no longer receive updates from the PHP project, and PHP 8.2 reaches end of life on 31 December 2026. For the older branches, the PHP security team has published source backports for PHP 7.4, 8.0 and 8.1 to help people building from source or waiting on a vendor.

Configuration changes can reduce exposure to specific attack paths, but they do not make a server safe. One setting circulated as a workaround before the patch, and the release confirms it was never a complete fix.

## My take

The uncomfortable lesson is that the gap between a fix and working exploits is closing. When AWS can see an attempt four days before disclosure, and more actors can act within hours of details emerging, speed of response matters more than ever. Treating patching as a continuous, well-funded habit rather than an emergency is the sensible response. Boring, in security, is exactly what you want.

## Sources

- [Wired](https://www.wired.com/story/hackers-exploited-the-php-vulnerabilities-days-before-they-were-patched/)
- [thehackernews.com](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html)