Attackers began probing the two critical PHP flaws known as PHP2Shell within hours of their disclosure, and the public exploit code meant to help defenders test their exposure is turning into a hazard of its own. Recorded Future's Insikt Group says exploitation attempts against CVE-2026-109618 and CVE-2026-109619 were reported before PHP's fixes shipped, while AhnLab's ASEC counted close to a hundred GitHub repositories named after the bugs, nearly all of them created on a single day.
Both flaws sit in the PHP engine itself and carry a CVSS v4.0 score of 9.2, so a fully updated WordPress, Drupal or Joomla site can still be exposed if the PHP underneath it is old. We covered the release itself in PHP patches php2shell flaws as exploit code circulates.
Exploitation reports arrived before the patch
According to Recorded Future's timeline, an archive containing leaked vulnerability information was first submitted to VirusTotal at 02:29 UTC on October 21, and Patchstack received reports of multiple active exploitation incidents from hosting partners by 07:34 UTC, more than six hours before PHP published its fixes at 13:52 UTC. Recorded Future also cites Cloudflare CTO Dane Knecht reporting early attacks. ASEC adds that watchTowr said it observed actual exploitation on its honeypot network on October 21. Hong Kong's HKCERT now rates the pair "Extremely High Risk" and states that both are being exploited in the wild.
Recorded Future is careful about what this proves: the available reporting does not establish how many attacks succeeded, and confirmed indicators of compromise remain limited.
A GitHub gold rush of unknown quality
ASEC examined the top 100 GitHub results for "php2shell". Ninety-nine dealt with these CVEs, 46 were defensive (assessment, mitigation and detection) and 36 were offensive, such as PoCs and reproduction labs. Proof-of-concept repositories drew 1,158 of 1,394 total stars, or 83%, and just two repositories held 68% of all stars. ASEC classified the repositories from their names, descriptions and topics and did not examine the code itself.
Whether that code works is an open question. Recorded Future notes that researcher J4ck3LSyN published two alleged PoCs and then invalidated the cached-pointer theory they relied on, and ASEC found repositories that document failed reproduction attempts. One repository copies the description of the most popular PoC word for word, which ASEC says suggests someone may have cloned it, modified the code and redistributed it, a familiar route for planting malware on security researchers. ASEC also warns that one-line "mitigation" scripts run with root privileges and could become attack paths dressed up as security tools.
Vendor lab testing shows the risk is real but uneven. Wordfence's Alex Thomas reports that the team achieved code execution for CVE-2026-109619 in a specially configured PHP 8.5.11 lab, while the same test only crashed a normal optimized build. Wordfence's view is that an attack may need tailoring to a particular server, but that this does not make an unpatched server safe.
Most exposed PHP runs on unsupported branches
Recorded Future cites a Modat scan of 4,384,302 PHP services, about 79% of which, among those showing a readable version, run a branch PHP no longer supports. Zscaler ThreatLabz's Jithin Prajeev Nair notes that no official binary patches will be released for PHP 8.1 and older.
Patch PHP, then hunt back to October 20
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution packages may carry the fixes under older version numbers, so check your vendor's notice, and restart PHP after updating. Because exploitation reports predate the patch, Recorded Future advises reviewing activity from October 20 onward, and Wordfence recommends preserving web server, PHP and firewall logs from at least 48 hours before the release. ASEC suggests looking for abnormal multipart requests, unexpected files in the web root and unusual processes running under the web server account. If you must run a public PoC, read its code first and run it only in an isolated environment.
PHP2Shell's first day shows how quickly the noise outruns the signal: the most popular code on GitHub is not the most trustworthy, and the official PHP release remains the one fix every source agrees on.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.