Cybersecurity Reach Foundation
Back to News
Website security

PHP2Shell fix is out: what to do now if your site runs WordPress or other PHP software

October 21, 2026

PHP2Shell fix is out: what to do now if your site runs WordPress or other PHP software

PHP2Shell: PHP released fixes for two critical flaws. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today; WordPress updates alone do not fix it.

Updated Wednesday, October 21, 2026, 9:53 AM ET.

What happened

PHP is the software behind most small business, church and nonprofit websites, including every WordPress site. This morning PHP released a fix for two critical flaws. The two flaws, being called PHP2Shell, can be used by an attacker on the internet to take over a website's server without logging in. Details leaked before the fix, so attackers already know about them.

If your site runs on PHP, it needs this update today.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Any version older than these is affected.

Step 1: Ask your host or web person to confirm

Copy and send this:

Hi, PHP released a critical security fix today (CVE-2026-109618 and CVE-2026-109619). Can you confirm:

  1. Is our site now on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor package with the fix)? Which one?
  2. If not, when today will it be updated?
  3. If we are on PHP 8.1 or older, can you move us to a supported version or install a vendor fix?
  4. Did you take a backup before updating?
  5. Have you seen anything unusual on our site or server in the last two days?

Step 2: Check it yourself

  • WordPress and WooCommerce: Tools, then Site Health, then Info, then Server. Check the PHP version against the list above. Updating WordPress or plugins does not fix this; PHP on the server must be updated. Security plugins cannot stop it, because the attack reaches PHP before WordPress runs.
  • Drupal, Joomla and Magento: Same as WordPress. Ask your web person to confirm the PHP version on the server.
  • Nextcloud and other self-hosted PHP tools (Moodle, CiviCRM, phpBB): Whoever installed it must update PHP on that server, then restart PHP and the web server.
  • Shared hosting and cPanel: Your host updates PHP for the server. In cPanel ("Select PHP Version" or "MultiPHP Manager") or Plesk, make sure your site is set to PHP 8.2 or newer.
  • Hosted website builders (Squarespace, Wix, Shopify, WordPress.com): The provider runs the servers, so you likely have nothing to install. Check their status page or ask support to confirm.

On PHP 8.1 or older: upgrade, get a vendor fix, or go offline

PHP no longer releases updates for 8.1 and older. Ask your host or web person to do one of these today:

  • Move the site to PHP 8.3 or 8.4 (best). Test the site afterward, because old plugins or themes can break.
  • Install a fix from their Linux vendor, if their vendor offers one for older versions.
  • Take the site offline until one of the above is done. WordPress maintenance mode does not protect you, because the attack reaches PHP first.

Note: PHP 8.2 also stops getting security fixes on December 31, 2026. If you are on 8.2, plan a move to 8.3 or newer.

Signs your site may have been hit

  • Pages you did not create, strange links, or redirects to other sites
  • New admin users you do not recognize
  • Your host warns about malware, spam sending or high resource use
  • Google or your browser shows a "deceptive site" warning
  • Visitors report pop-ups or fake payment pages

Who to call: Your host's support first, then your web person or IT provider. After the server is fixed, change your website and hosting passwords. If you take card payments or store member data, tell your payment provider and keep notes of what you found.

Watch out for fake "PHP update" messages

As a precaution: big security news is often followed by scam emails and calls. Be careful with any message that claims to be "your host" or "WordPress security" and asks you to click a link, log in, pay, install a plugin, or give remote access to "apply the PHP fix." Contact your host using the phone number or website you already have, not the one in the message.

For your web person or IT

The flaws (official, PHP security team):

Who is at risk: All PHP installations serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest for Apache mod_php, where PHP confirmed full RCE over HTTP with default PHP settings, triggered before any application code runs. For FPM, PHP's source analysis shows it is susceptible; the confirmed FPM path depends on a suitable application operation.

Affected and fixed: All versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older get no official release. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people building from source; distributions and LTS vendors received patches in advance, so check your vendor.

Update:

  • Install the fixed version or your vendor's patched package, then restart every PHP worker (PHP-FPM or Apache). Confirm the version in a request served by the web server, not only on the command line.
  • Remi's repository (rpms.remirepo.net) will not have updates today. Switch to distribution packages or build from source.
  • Check for bundled PHP in appliances and Windows software (php.exe, php-cgi.exe), and on cPanel and Plesk servers.

If you cannot update right away (PHP says these reduce exposure but do not make you safe):

  • For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server config (not ini_set() or .user.ini), then restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. PHP suggests keeping upload progress off even after patching if you do not use it.
  • For CVE-2026-109618: set memory_limit=-1 administratively, keep post_max_size low (8M without uploads, 32M with), and limit request size, field count, multipart parts and headers at the web server or proxy. Do not use RLIMIT_AS or RLIMIT_DATA.
  • Remove invalid or deprecated per-request INI settings that produce warnings. Hiding errors with error_reporting, display_errors or @ does not help.

After patching: Remove temporary blocks you added (for example multipart blocks or read-only rules) once verified. Look for signs of compromise: PHP workers launching shells or download tools, new files in web directories, new cron jobs, unexpected outbound connections. Public exploit code is circulating; do not run unverified code on production systems.

Sources

Cybersecurity Reach Foundation (CSRF). Free scam protection and cyber safety help for everyday people, small businesses and community organizations. cybersecurityreach.org

Back to All News