PHP2Shell attacks continue with no WordPress breach found
PHP2Shell attacks are continuing, but as of October 28, 2026, Wordfence knew of no WordPress site compromised through CVE-2026-109618 or CVE-2026-109619. Its site-cleaning and incident-response teams had not handled a WordPress case attributed to either flaw. That finding does not mean an unpatched server is safe: the required action is still to update the PHP programming language used by the site and restart the service running it.
The two critical PHP vulnerabilities each received a 9.2 out of 10 score under CVSS v4.0, a standard scale for rating security flaws. Both can enable unauthenticated remote code execution, meaning someone who has not logged in may be able to run their own code on the server. One flaw concerns PHP's handling of a request that exhausts its available memory. The other can leave data from a completed request in a PHP process, allowing a later request to misuse it. These are flaws in PHP itself, not in WordPress, plugins or themes.
Wordfence said a dedicated monitoring rule recorded about 77,600 related requests from more than 2,000 IP addresses between October 23 and October 27 across the more than 5 million sites it helps secure. Its review found no matches that resembled normal visitor or website activity. Requests carried attack indicators, identified themselves as scanning tools or appeared to be automated tests. A coordinated set of 27 IP addresses was also observed on October 22, with 26 beginning their requests inside a 13-minute period. Such requests reveal attempted activity, not whether code actually ran.
The requests tried to check whether commands could run, extract database passwords and other secrets from wp-config.php and .env files, install backdoor files for continued access in upload, plugin or theme directories, and, less frequently, download and execute more malicious code. Wordfence also saw tools built for the vulnerabilities about four hours before public disclosure on October 21. Amazon reported attempts against its honeypots, which are decoy systems used to observe attacks, before disclosure as well.
Reports outside WordPress remain mixed. Dream said an attacker adapted a PHP2Shell exploit to an unnamed firewall platform and then used a Linux kernel privilege-escalation flaw, which lets an attacker obtain greater system permissions. According to Dream, the attacker took full control of 24 internet-facing firewalls and an internal management server, extracted an LDAP service-account password and listed users and groups in a US government-affiliated environment. Dream did not identify the vendor or release the recovered artifacts, and Wordfence had not independently verified the incident. It did not involve WordPress.
Palo Alto Networks separately reported active exploitation aimed at internet-exposed PAN-OS management interfaces, without connecting that activity to Dream's account. Wiz said on October 27 that none of the attempts it observed succeeded and that the strongest public evidence it had reviewed involved successful attacks on honeypots. Morphisec reported code execution on October 28 at a customer running Windows, IIS and PHP-CGI, a setup in which PHP processes web requests through the Common Gateway Interface. Its public account did not involve WordPress or contain enough technical detail for Wordfence to verify independently that PHP2Shell was responsible.
Reliable exploitation appears to depend heavily on the target. In Wordfence's laboratory, test code executed against a specially configured PHP build but merely crashed a normal optimized build of the same version. Wiz reported failures at different stages on different configurations, while Hacktron found that an exploit working in one environment required substantial changes for another. PHP builds, extensions, memory limits and request handling can all affect the outcome. Address Space Layout Randomization, or ASLR, also changes where a program stores data in memory, making an attacker's target harder to predict. Linux administrators can run cat /proc/sys/kernel/randomize_va_space; a result of 2 means full randomization. These obstacles may impede an attack, but they do not repair either vulnerability.
The fixed PHP releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP advisory says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP-FPM is a service that manages PHP processes for websites. A vendor package is also acceptable if its provider confirms that both fixes were added. Updating WordPress itself will not update PHP.
On managed or shared hosting, site owners should ask whether the PHP service for their account is patched for both CVEs and has been restarted. Administrators of their own server or virtual private server, commonly called a VPS, should back it up, install updated packages and restart Apache, PHP-FPM or the relevant PHP service so an old process cannot continue using vulnerable code. Containers must be rebuilt and redeployed from an updated image. Agencies should check production, staging and older environments rather than only the main public site.
WordPress shows the PHP version under Tools, Site Health, Info, then Server. That value can differ from the output of php -v at a command prompt. A version number alone may not settle the question because Linux distributions and long-term-support vendors sometimes add security patches without changing the main version. Owners seeing an older number should ask whether that exact package contains both fixes.
Warning signs include unfamiliar PHP files in wp-content/uploads or plugin and theme folders, particularly files created on or after October 17, unknown administrator accounts, unexpected scheduled tasks, unexplained outbound connections, repeated PHP crashes, unusually large form uploads, or a PHP or web-server process starting a command shell. Preserve backups and web, PHP, firewall and system logs from at least October 17 until PHP was patched and restarted. A normal-looking log does not prove that nothing happened. If suspicious evidence appears, preserve the current site as a backup, change the database password and secrets stored in wp-config.php or .env, and begin a full cleanup.
PHP 8.1 and earlier no longer receive releases from the PHP project, so affected users need a vendor-supplied fix or an upgrade. Minimal source patches were published for PHP 7.4, 8.0 and 8.1, and some long-term-support vendors may add them to older packages. PHP 8.2 reaches end of life on December 31, 2026, making PHP 8.3 or later the longer-term upgrade path described by Wordfence.
A separate unpatched flaw, CVE-2026-115560, was disclosed on October 23. It applies only when an application changes PHP's session data format while running and then starts a session while session upload progress is enabled.