WordPress PHP Vulnerability PHP2Shell: What Site Owners Need to Do

In short: The WordPress PHP vulnerability currently being reported is not in WordPress but in the PHP on the server underneath. A WordPress update therefore does not close PHP2Shell. What matters is the PHP patch level, the restart of all PHP processes and a check of typical hiding places such as wp-content/uploads and mu-plugins.

Why a WordPress update does not fix PHP2Shell

WordPress is an application written in PHP. The flaws CVE-2026-109618 and CVE-2026-109619 sit one layer deeper, in the PHP interpreter itself. According to the PHP team, they allow remote code execution without authentication. With Apache and mod_php, an exploit was demonstrated before any WordPress code even runs.

A website with an up-to-date core, up-to-date plugins and strong passwords can therefore still be vulnerable if the PHP underneath is old. Conversely, patched PHP does not prove that nothing happened before. We explain the background under What is PHP2Shell?.

WordPress PHP vulnerability: checking the PHP version

In the dashboard, under Tools > Site Health > Info, the "Server" section shows the PHP version your website is actually running on. That is more meaningful than php -v on the command line, because the command line often uses a different PHP installation than the web server.

The displayed number alone is still not enough. Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. However, many hosts apply the fixes as a backport; the older number then remains although the system is patched. How to determine the real status is described in Checking the PHP version and patch level correctly. Which PHP versions your WordPress version supports can be found in the system requirements on wordpress.org.

Where malicious code likes to hide in WordPress

After a successful attack, perpetrators usually leave a backdoor so they can return even after the patch. WordPress has well-known places for this:

• wp-content/uploads/: meant for images and PDFs, not for PHP files.
• wp-content/mu-plugins/: "must-use" plugins load automatically and cannot be deactivated in the dashboard.
• wp-config.php: contains the database credentials and security keys; an inserted line hardly stands out here.
• .htaccess in the main directory and in subfolders: redirects only for search engines, or execution of unusual file extensions.
• Themes, above all functions.php, as well as deactivated, forgotten plugins.
• Database: new administrators in wp_users, foreign JavaScript in wp_options or in posts.

Harmless first checks with WP-CLI and built-in tools:

# Compare core files against the official checksums
wp core verify-checksums
# Check plugins from the wordpress.org directory
wp plugin verify-checksums --all
# List PHP files in the uploads folder
find wp-content/uploads -type f -name "*.php"
# Show all administrators
wp user list --role=administrator

A hit is a reason for a closer examination, not yet proof. Commercial plugins cannot be checked this way. The guide Finding backdoors in WordPress goes into more detail.

Plugins, themes and admin access as an additional risk

PHP2Shell does not need a plugin flaw. In everyday operation, however, plugins and themes remain the most common entry point into WordPress websites. Every plugin brings its own code, its own upload functions and its own update cycle. You should delete unused plugins rather than just deactivating them, because deactivated files remain on the server.

For wp-login.php and wp-admin, the following applies: few administrators, personal accounts instead of shared logins and two-factor authentication. If you do not need XML-RPC, it can be blocked. After a suspicion, all passwords and the security keys in wp-config.php should be renewed. You can also switch off the file editor in the dashboard there:

define( 'DISALLOW_FILE_EDIT', true );

What you should do now as a WordPress site owner

1. Have your host confirm the PHP patch level and the restart of all PHP processes in writing.
2. Have server logs from 20 October 2026 onward retained.
3. Carry out the checks above, or have them carried out.
4. Update WordPress, plugins and themes. This is the right thing to do, but no substitute for step 1.
5. If anything looks unusual, do not simply keep operating the website; have it cleaned up.

A platform update can close known flaws in WordPress and plugins. It can neither repair PHP nor remove injected files that are not part of the core.

How does PHP SOS help?

• Together with you or your host, we establish the actual PHP status of your WordPress website, including backports and restart.
• We secure logs, files and database before anything is changed.
• We check core, plugins, uploads, mu-plugins, .htaccess and user accounts for backdoors.
• If we find something, our malware removal takes care of the cleanup until the incident is closed and documented; if we find nothing, we harden the installation as part of the PHP2Shell emergency help.

Frequently asked questions

Sources

• php.net: Security announcements
• PHP 8 ChangeLog
• WordPress.org
• BSI (German Federal Office for Information Security)