PHP2Shell 状态更新：Wordfence 尚未发现被攻陷的 WordPress 站点

TL;DR: As of October 28, 2026, Wordfence is not aware of any WordPress site compromised through PHP2Shell (CVE-2026-109618 and CVE-2026-109619).

We continue to see PHP2Shell-related requests across the more than 5 million sites we protect. Those requests show ongoing scanning and exploitation attempts; they do not show whether an attempt succeeded. Our site-cleaning and incident response teams have not handled a WordPress compromise attributed to these vulnerabilities.

That does not make an unpatched server safe. The fix is still to update PHP on your server to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor package confirmed to contain both fixes) and restart PHP. Updating WordPress does not update PHP.

It has been seven days since the PHP project released emergency fixes for PHP2Shell, two critical vulnerabilities in PHP, the programming language WordPress runs on. Since then, we have been analyzing security data from the more than 5 million WordPress sites Wordfence helps secure, testing the vulnerabilities in our lab and reviewing new reports from researchers and security vendors.

This post gives you the current status in plain terms, followed by short, direct answers to the questions we are hearing most.

→PHP2Shell Status: No Confirmed WordPress Compromises
→What Wordfence Is Seeing
→PHP2Shell FAQ: What WordPress Site Owners Need to Know
→PHP2Shell Sources and Further Reading

PHP2Shell Status: No Confirmed WordPress Compromises

As of October 28, 2026, we are not aware of any WordPress site compromised through PHP2Shell. Our site-cleaning and incident response teams have not handled a WordPress compromise attributed to these vulnerabilities.

From October 23 through October 27, a dedicated monitoring rule recorded roughly 77,600 related requests from more than 2,000 IP addresses. Our review found no traffic that looked like routine use by a visitor or website feature. The matches contained signs of an attack, identified themselves as scanning tools or showed other signs of automated testing.

Recent reports show why we separate exploitation attempts from confirmed compromises. On October 26, Dream reported that an attacker used a PHP2Shell exploit adapted to an unnamed firewall platform, followed by a Linux kernel privilege-escalation vulnerability, to gain full control of 24 internet-facing firewalls and an internal firewall-management server. Dream said the attacker then extracted an LDAP service-account password and enumerated users and groups in what it described as a US government-affiliated environment. The public report does not identify the affected vendor or publish the recovered artifacts, and we have not independently verified the incident. The report does not involve WordPress.

Separately, Palo Alto Networks says it has observed active exploitation targeting internet-exposed PAN-OS management interfaces. Its advisory does not connect that activity to Dream’s report.

On October 27, Wiz reported that none of the attempts it observed had completed successfully. On October 28, Morphisec reported code execution on a customer’s Windows server running IIS and PHP-CGI. The Morphisec post does not connect the incident to WordPress and does not include enough technical detail for us to verify independently that PHP2Shell was the cause.

Our lab testing suggests that a working exploit often has to be adjusted for the target server. The same test ran code in one setup but only crashed PHP in another. Wiz reported similar differences between server setups, and Hacktron found that even a working exploit had to be adapted to a new target. We explain the main factors in the FAQ below.

Attackers are still changing their tools. A successful attack could give them access to your site’s files, database and passwords, so updating PHP remains essential.

Here is how the past week unfolded:

October 20: The PHP project announced an upcoming critical security release, and we published a heads-up for site owners.
October 21: PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with the fixes, and we published our update-now PSA.
October 21: We published Why It’s Urgent to Update PHP on Your WordPress Site: Two Critical PHP Vulnerabilities and What Our Testing Found, sharing our lab result that a test exploit ran code in a specially configured PHP build but only crashed a normal build.
October 22: We followed up with our first analysis of PHP2Shell-related request activity, covering more than 74,000 requests and no known WordPress compromises.
October 23: The PHP project disclosed a separate, unpatched vulnerability, CVE-2026-115560, along with a configuration workaround. More on that in the FAQ below.
October 26: Dream reported that an attacker used PHP2Shell and a Linux kernel vulnerability to gain full control of 24 internet-facing firewalls and an internal management server. Dream did not identify the affected vendor or publish the underlying artifacts, and the report does not involve WordPress.
October 27: Wiz reported that the attempts it observed were unsuccessful and said the strongest public evidence it had reviewed was successful exploitation of honeypots.
October 28: Morphisec reported a Windows/IIS customer incident that it attributed to PHP2Shell. The public report does not involve WordPress and does not provide enough technical detail to verify independently that PHP2Shell was the cause.
October 28: Palo Alto Networks’ updated advisory said it had observed active exploitation targeting internet-exposed PAN-OS management interfaces. The advisory does not connect that activity to Dream’s report.

What Wordfence Is Seeing

Our Wordfence Threat Response Team has been analyzing PHP2Shell-related activity in security logs from the more than 5 million sites we protect. We compare that activity with public reports and known signs of attacks to understand what threat actors are trying, how their tools are changing and whether any WordPress compromise has been confirmed.

The requests included attempts to:

Run commands to check whether an attack worked
Steal database passwords and other secrets from wp-config.php and .env files
Place backdoor files in upload, plugin or theme folders to give attackers continued access
Download and run additional malicious code, which we saw less often than the other three types

These requests show what attackers were trying to do. They do not establish whether an attack succeeded.

On October 23, we deployed a monitoring rule specifically for this activity. Through October 27, it recorded roughly 77,600 related requests from more than 2,000 IP addresses.

We reviewed all of the rule’s matches and found no traffic that looked like routine use by a visitor or website feature. The requests contained signs of an attack, identified themselves as scanning tools or showed other signs of automated testing.

We also observed a coordinated group of 27 IP addresses on October 22. Of those, 26 began sending related requests within a 13-minute window. Patterns like this help our team separate coordinated automated activity from ordinary website traffic.

Our October 22 analysis has the full breakdown of attack requests and the most active IP addresses.

PHP2Shell FAQ: What WordPress Site Owners Need to Know

Have any WordPress sites been compromised through PHP2Shell?

As of October 28, 2026, Wordfence is not aware of any WordPress site that has been compromised through PHP2Shell (CVE-2026-109618 or CVE-2026-109619). Our site-cleaning and incident response teams have not handled a WordPress compromise attributed to either vulnerability.

Outside WordPress, successful exploitation has been documented on honeypots, which are decoy servers used to study attacks. Dream reported that an attacker used a tailored PHP2Shell exploit and a Linux kernel vulnerability to compromise 24 internet-facing firewalls and an internal management server. Morphisec also reported code execution on a customer’s Windows/IIS server. We have not independently verified either incident, and neither report involves WordPress.

Palo Alto Networks separately says it has observed active exploitation targeting internet-exposed PAN-OS management interfaces. Its advisory does not connect that activity to Dream’s report.

No WordPress case has been confirmed, but new reports are still appearing. Continue to update PHP promptly: the absence of a confirmed WordPress case does not make an unpatched server safe.

Why has reliable exploitation been difficult?

Our testing suggests that ASLR is one factor, but it is not the only one. ASLR (Address Space Layout Randomization) changes where programs keep data in memory, making it harder for an attacker to predict where to aim. The PHP build, enabled extensions, memory limits and the way a server handles requests can also affect whether an exploit works.

In our lab, a test exploit ran code in a specially configured PHP build but only crashed a normal optimized build of the same PHP version. That result confirms that the risk is real while also showing why one working exploit may not transfer directly to another server.

Wiz reported that public exploit attempts failed at different stages on different server setups. Hacktron also found that a working exploit for one setup needed substantial changes before it worked against another. These obstacles may slow broad exploitation, but they are not a fix. If you manage your own Linux server, you can check that ASLR is fully on by running cat /proc/sys/kernel/randomize_va_space. A result of 2 means full randomization. Either way, update PHP.

Are attackers actively trying to exploit PHP2Shell?

Yes. Our dedicated monitoring rule recorded roughly 77,600 related requests from more than 2,000 IP addresses between October 23 and October 27. Amazon reported attempts against its honeypots before the vulnerabilities were publicly disclosed on October 21. In our own data, requests using tools built specifically for these vulnerabilities appeared on October 21, about four hours before the public disclosure.

Public demonstration code is circulating, but the examples reviewed by Wordfence, Wiz and Hacktron generally needed changes for the server being targeted.

What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619. Each scored 9.2 out of 10 on the CVSS v4.0 severity scale. Both can allow remote code execution without authentication, which means an attacker who has not logged in could run their own code on your server.

They are flaws in PHP itself, not in WordPress, a plugin or a theme. One involves how PHP handles a request that runs out of memory. The other involves a PHP process holding onto data from a finished request that a later request can then misuse.

Is my site affected?

Your site is likely affected if the PHP version serving it is older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and your host or vendor has not confirmed that it added both fixes. According to the PHP security advisory, every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

A fully updated WordPress site can still be exposed, because WordPress updates do not change the PHP version on your server.

What should I do right now?

Make sure the PHP running your site is updated to a fixed version, then make sure PHP has been restarted. What that looks like depends on how you host your site:

Managed or shared hosting: Your host controls PHP. Ask them: “Is the PHP service serving my site patched for CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted?” Get a direct answer for your account.
Your own server or virtual private server (VPS): Make a backup, install the updated PHP packages, then restart Apache, PHP-FPM or whatever runs PHP so no old process keeps running the vulnerable code.
Containers: Rebuild and redeploy from an updated image.
Agencies and anyone managing many sites: Check every environment, including staging sites and older servers, not only the main public site.

How do I check which PHP version my site uses?

In your WordPress dashboard, go to Tools > Site Health, open the Info tab and expand the Server section. That shows the PHP version your website is actually using, which can differ from what php -v shows at a command prompt.

The version number may not tell the whole story. Linux distributions and long-term-support vendors often add security fixes without changing the main version number. If you see an older version, ask your host or vendor whether that specific package contains both fixes.

How do I know if my site has been compromised?

Look for changes you did not make, especially new PHP files, new administrator accounts and edited configuration files. Specifically:

Unfamiliar .php files in wp-content/uploads, or in plugin and theme folders, especially any created on or after October 17
Administrator accounts you do not recognize
Unexpected scheduled tasks (cron jobs) on the server or in WordPress
Unexpected outbound connections from your server
Server or PHP logs showing repeated crashes, unusually large form-upload requests, or a PHP or web server process starting a command shell

Run a Wordfence scan to look for malware and changed core, plugin and theme files. Keep your backups and web server, PHP, firewall and system logs from at least October 17 through the time PHP was patched and restarted. If your PHP update was delayed, review those logs for anything unusual. A clean-looking log does not prove nothing happened.

If you find signs of compromise, treat the site as compromised. First, make a backup of the site as it is now so evidence is preserved. Then change your database password and any secrets stored in wp-config.php or .env files, and begin a full cleanup. Our guide to removing malware from a hacked WordPress site walks through the process.

Do I need to update WordPress?

No WordPress update is needed for PHP2Shell, and installing one will not fix it. The fix is a PHP update on your server. Keeping WordPress, plugins and themes updated is still good practice for other reasons.

I am on PHP 8.1 or older. What now?

The PHP project no longer releases updates for PHP 8.1 and older, so you need either a vendor-supplied fix or an upgrade. Some Linux distributions and long-term-support vendors add the fixes to older versions, and the PHP security team published minimal source patches for PHP 7.4, 8.0 and 8.1. Upgrading to a supported version is the better long-term choice. PHP 8.2 reaches end of life on December 31, 2026, so choosing PHP 8.3 or newer avoids another near-term upgrade.

What about the new PHP vulnerability, CVE-2026-115560?

CVE-2026-115560 is a separate PHP vulnerability, disclosed on October 23, that has no patch yet but only applies to a narrow configuration. It requires an application to change PHP’s session data format while running and then start a session, with PHP’s session upload progress feature turned on (it is on by default).

The PHP project’s workaround is to set session.upload_progress.enabled = 0 in php.ini or your PHP-FPM pool configuration, then restart PHP. Setting it from inside an application or a .user.ini file is too late to help. For most site owners this is a conversation to have with your host. For PHP2Shell itself, the PHP project says updating is the only safe choice.

Where can I get help?

Start with your hosting provider for anything about the PHP version on your server. If you believe a site has been compromised, Wordfence Care and Wordfence Response customers can contact our incident response team.

Think Your Site Was Compromised?

Wordfence Care includes incident response during business hours, and Wordfence Response provides 24/7/365 availability with a one-hour response time.

Get Incident Response Help

Seeing PHP2Shell activity or signs of a compromise? Report it to the Wordfence Threat Response Team at threat-response@wordfence.com.

Emails to that address go straight to the team, not a general support queue. Include what you are seeing and when it started, the PHP version involved, any indicators such as suspicious files, unknown admin accounts, IP addresses or log entries, and how we can reach you.

If you know someone who manages WordPress sites, please share this post and ask them to confirm the PHP version behind each site.

PHP2Shell Sources and Further Reading

PHP security release announcement (October 21, 2026)
PHP advisory: CVE-2026-109618
PHP advisory: CVE-2026-109619
PHP announcement: CVE-2026-115560 workaround (October 23, 2026)
Wordfence: What our PHP2Shell testing found
Wordfence: Attacks on PHP2Shell continue, but no known compromises yet
Amazon: Attempts observed before public disclosure
Dream: Reported compromise of 24 firewalls and an internal management server (October 26, 2026)
Wiz: Exploitation attempts and remediation trends (October 27, 2026)
Hacktron: Adapting a working exploit to a new target
Morphisec: Reported Windows/IIS customer incident (October 28, 2026)
Palo Alto Networks: PAN-OS impact and active exploitation status (updated October 28, 2026)

The post PHP2Shell Update: Still No Confirmed WordPress Compromises, and Answers to the Questions We’re Hearing Most appeared first on Wordfence.