PHP2Shell attacks continue with no confirmed WordPress cases
PHP2Shell exploitation attempts are continuing, but Wordfence says it knew of no confirmed WordPress compromise through the two critical PHP flaws as of October 28, 2026. PHP is the programming language that runs WordPress. The absence of a confirmed case does not make an unpatched server safe: the required response is to install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package confirmed to include both fixes, and then restart PHP.
PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619. Each received a 9.2 out of 10 score under CVSS v4.0, a standard scale for rating vulnerability severity. Both flaws can permit 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 available memory. The other involves a PHP process retaining data from a completed request that a later request can misuse. These are vulnerabilities in PHP itself, not in WordPress, a theme or a plugin.
Wordfence analyzed logs from more than 5 million protected sites and said its site-cleaning and incident-response teams had not handled a WordPress breach attributed to either vulnerability. A dedicated monitoring rule recorded about 77,600 related requests from more than 2,000 IP addresses between October 23 and October 27. Wordfence reviewed every match and found signs of attacks, self-identified scanning tools or other automated testing, rather than normal visitor or website activity. It also observed 27 coordinated IP addresses on October 22, with 26 beginning their requests within a 13-minute period.
The requests attempted to run commands that would show whether exploitation worked, extract database passwords and other secrets from wp-config.php and .env configuration files, and create backdoors in upload, plugin or theme directories. A backdoor is a hidden file or mechanism that lets an intruder return later. Less frequently, requests tried to download and execute more malicious code. These records show attacker intent, not successful execution. Amazon also reported attempts against honeypots, which are decoy systems used to observe attacks, before public disclosure on October 21. Wordfence saw tools built for the flaws about four hours before that disclosure.
Reports outside WordPress remain important but contain unresolved questions. Dream said an attacker adapted PHP2Shell to an unnamed firewall platform, then used a Linux kernel privilege-escalation flaw to take full control of 24 internet-facing firewalls and an internal management server. Dream said the attacker extracted an LDAP service-account password, used for access to a central directory of users, and enumerated users and groups in a US government-affiliated environment. The public account did not identify the vendor or provide recovered artifacts, and Wordfence said it had not independently verified it. Palo Alto Networks separately reported active exploitation against internet-exposed PAN-OS management interfaces, without connecting that activity to Dream's report.
Wiz reported on October 27 that none of the attempts it observed had completed successfully and said the strongest public evidence it reviewed involved successful exploitation of honeypots. On October 28, Morphisec reported code execution on a customer's Windows server running IIS, Microsoft's web-server software, and PHP-CGI, a method of running PHP for web requests. Its public account did not involve WordPress or provide enough technical detail for Wordfence to verify independently that PHP2Shell caused the incident.
Reliable exploitation appears sensitive to the target configuration. Wordfence found that a test exploit ran code in a specially configured PHP build but merely crashed a normal optimized build of the same version. Wiz reported failures at different stages across different server setups, while Hacktron found that an exploit working in one environment needed substantial modification for another. Factors include the PHP build, installed extensions, memory limits, request handling and ASLR, or Address Space Layout Randomization, which changes where a program stores data in memory so an attacker has more difficulty predicting where to target. On Linux, administrators can run cat /proc/sys/kernel/randomize_va_space; a result of 2 indicates full randomization. These obstacles may impede broad exploitation, but they do not replace patching.
According to the PHP security advisory, every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. A current WordPress installation may therefore remain exposed because updating WordPress does not update PHP. In WordPress, Tools, Site Health, Info, Server shows the version actually serving the site, which may differ from the result of php -v at a command prompt. An apparently older version is not always conclusive because Linux distributions and long-term-support vendors sometimes add security fixes without changing the main version number. In that case, the host or vendor must confirm that its package contains both corrections.
On managed or shared hosting, site owners should ask whether the PHP service for their specific account is patched for both CVEs and has been restarted. Administrators of their own server or virtual private server, a rented server environment, should back it up, install the updated packages and restart Apache, PHP-FPM or the relevant PHP service so old processes do not retain vulnerable code. Containers must be rebuilt and redeployed from an updated image. Agencies should check public, staging and older environments rather than inspecting only the main site.
PHP 8.1 and older no longer receive updates from the PHP project, so users need either a vendor-supplied correction or an upgrade. Some Linux distributions and long-term-support vendors have added fixes to older releases, and the PHP security team published minimal source patches for PHP 7.4, 8.0 and 8.1. A supported release is the better long-term choice. PHP 8.2 reaches end of life on December 31, 2026, so PHP 8.3 or newer avoids another near-term migration.
Site owners should inspect for unfamiliar PHP files in wp-content/uploads and plugin or theme folders, especially files created on or after October 17. Other warning signs include unknown administrator accounts, changed configuration files, unexpected cron jobs, which are automatically scheduled tasks, unexplained outbound connections, repeated PHP crashes, unusually large form uploads or a web process starting a command shell. Preserve backups and web-server, PHP, firewall and system logs from at least October 17 until the patched PHP service was restarted. A clean-looking log does not prove that nothing happened.
If suspicious evidence appears, first make a backup of the site's current state to preserve evidence.