What PHP2Shell means for your website

PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. They can allow someone to run malicious code on an affected server without logging in, which puts the website and the customer information it can access at risk. Updating WordPress, a theme, or a plugin does not fix them. Your hosting provider has to move the PHP serving your site to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, or apply a vendor fix that covers both flaws. PHP released the updates on October 21, 2026, and urges users to update immediately. PHP’s security announcement identifies the affected software and available fixes.

Before the PHP2Shell patches were available, I texted and emailed clients whose businesses depend on WordPress for online stores. I asked them to contact their hosting providers about the upcoming security release to ensure a plan to patch was in place. The technical details were still private, so I couldn’t tell them exactly how an attack would work or the impact, but I wanted them to find out when their hosts would apply the fix and request confirmation when the work was complete. That remains the first conversation I would have if my business depended on an affected website.

Will updating WordPress fix PHP2Shell?

No. PHP is the software on the server that runs applications such as WordPress and Drupal. WooCommerce stores depend on it through WordPress. Updating WordPress, a theme, or a plugin does not install the PHP security fix. On managed or shared hosting, the provider usually handles that server software. Cloudflare makes this distinction in its PHP2Shell guidance for site owners, which directs customers to their hosts for the PHP update.

PHP2Shell is also separate from WP2Shell, the WordPress core flaw disclosed in July 2026. A WordPress update fixed WP2Shell. PHP2Shell needs a PHP update from your host, even if WordPress is fully up to date.

The security company Wiz demonstrated attacks against WordPress, Drupal, and Joomla installations using the current container images at the time of testing. Those demonstrations establish that the flaws can affect real website software. The exact exposure still depends on how the host runs PHP and how the application behaves. PHP’s advisories describe different attack conditions for Apache’s PHP module and PHP-FPM, another common way to run PHP. A provider needs to check its own configuration before giving you an answer about your site.

Depending on the website’s permissions, an attacker who can run code could read database credentials or alter site files. Wiz also demonstrated a separate way to read server memory, which can expose passwords and access tokens without a full takeover. These are documented capabilities, not evidence that every vulnerable website has been breached. The Wiz research disclosure explains both the takeover demonstrations and the risk of exposed information.

How do I know if my site is patched?

In WordPress, an administrator can see the PHP version under Tools → Site Health → Info → Server. Treat that as a starting point rather than proof. A host that applies fixes to an older PHP package may still report the older version number, so the number alone cannot tell you whether both fixes are in place.

Ask your hosting provider to confirm privately that the PHP serving your website includes both fixes. Providers can disable PHP version information in public response headers, so an external check may not reveal the installed version. An absent version number tells you nothing about whether the host has applied the patches. PHP lists the first fixed releases as 8.2.35, 8.3.36, 8.4.27, and 8.5.12 in its security advisory. If your host applies fixes to an older PHP package, ask for the vendor advisory confirming that both vulnerabilities are covered.

A support request can stay short and specific. I would ask:

• Is the PHP serving my live site covered by the fixes for CVE-2026-109618 and CVE-2026-109619?
• Has the running service loaded the patched software, including any required restarts?
• If the work is incomplete, when do you expect to finish, and what protects the site until then?

Keep the reply with your website maintenance records so you have a record of what the provider confirmed.

I would give the technical staff room to do the work while still asking for a firm update. They need to apply the patch and check that the website continues to function. For an online store, I would want the checks to include checkout and order emails. If the provider misses its promised update or cannot say who owns the task, escalate through its support process. A general announcement that patching has started leaves your own site’s status unresolved.

Does Cloudflare protect my site from PHP2Shell?

It adds protection while the host patches, but it does not replace the patch. A web application firewall, or WAF, inspects website traffic and blocks activity that matches its security rules. Cloudflare says it deployed PHP2Shell protections for customers using its free and paid WAF services before public disclosure. The company also reports that it observed attack traffic targeting customers. Those statements provide a reason to act promptly without claiming that any particular client’s site was compromised. Cloudflare still recommends patching PHP in its report on the protections.

A firewall can inspect only the traffic that passes through it. If attackers can reach the underlying hosting server directly, they may bypass that protection. Ask your host to confirm that the relevant rules are active and that direct access cannot bypass the WAF. Cloudflare’s guidance on protecting the origin server explains the controls, but the provider needs to apply them to your hosting setup.

Shared hosting needs a closer look at isolation

Some of my clients use shared hosting, where several customers’ websites use the same server resources. That arrangement can be reasonable for a small business, but the separation between customers matters. WordPress’s security guidance warns that a compromised neighboring site can create risk on a shared server. Sharing an IP address alone does not establish that websites can access one another’s files or data. Ask the provider how it prevents a compromised customer account from reaching yours.

I would judge the answer against what the website does for the business. A site that publishes opening hours has different recovery needs from a store that takes every order online. Both need security updates, but an interruption to the store can stop sales immediately. For that store, I would expect a clear explanation of customer isolation and a tested recovery process. If the provider cannot explain those arrangements, I would review the hosting choice once the immediate patching work is complete.

Which passwords should I change after patching?

Patching closes the vulnerabilities, but it does not remove malicious files or accounts an attacker may already have created. I would ask the host to review the period before patching for suspicious activity. That review should include unexpected administrator accounts and changes to website files. The host should also examine server logs because attacks against PHP may leave little detail in WordPress’s own records. Wiz’s investigation guidance identifies unusual requests accompanied by memory errors or repeated server errors as signals to examine, rather than proof of compromise.

For an exposed site, my precautionary recommendation is to plan credential changes with the provider after patching and checking for compromise. Start with the database password and the passwords used by administrators and editors. The provider must update the website’s database configuration at the same time so the site keeps working. In WordPress, replacing the authentication keys and salts also forces existing users to log in again. WordPress’s recovery guidance covers password changes and clearing active logins after a compromise.

The review should also cover credentials the site holds for other services, such as email delivery or a payment provider. I recommend this precaution because the memory disclosure research strongly suggests that secrets can escape without an obvious website takeover. It does not establish that your site’s credentials were stolen. If the investigation finds a compromise, have the provider preserve evidence and remove the attacker’s access before treating recovery as complete. Credentials changed during the incident need changing again after cleanup, as the WordPress recovery guidance recommends.

What if my site runs an old PHP version?

An older version does not put a site out of reach. Cloudflare’s analysis says the vulnerabilities affect web servers running PHP 5.4 or later. If your host says your PHP version cannot receive the standard update, ask what supported alternative it can provide. PHP 8.1 and older no longer receive regular updates from the PHP project, though some vendors provide backported fixes. PHP also supplied minimal source patches for PHP 7.4, 8.0, and 8.1 to help vendors and administrators respond.

Until the fix is installed, PHP’s release announcement lists temporary settings that block specific attack paths:

• memory_limit=-1 for CVE-2026-109618. This removes PHP’s per-request memory cap, so the host needs to watch for requests that use too much memory.
• session.upload_progress.enabled=0 for CVE-2026-109619.
• fatal_error_backtraces=0 on PHP 8.5.

The host has to apply these settings at the server level and restart PHP. On shared hosting, the owner usually cannot change them, and a setting added through a WordPress plugin or a per-folder file does not count. Each setting blocks only the attack paths PHP confirmed. None makes an unpatched installation safe, so the host still needs a plan to install the fixes.

Moving an old website to a supported PHP branch can require changes to its themes, plugins, or custom code. WordPress recommends backups and compatibility checks in its PHP update guidance. I would have the provider test the upgrade on a separate copy of the site and confirm that a usable backup exists. For a store, that testing needs to cover purchases and the connections to payment and shipping services. The amount of work depends on the site, so I would not promise an upgrade time before someone has inspected it.

Prepare the next response while this one is fresh

Part of my work involves reviewing source code for vulnerabilities, and AI helps with that research. Wiz says AI models helped its team discover these PHP flaws, develop working exploits, and validate the fix. I expect more disclosures as researchers apply those tools to older software, although the timing and volume remain uncertain. For business owners, that makes the provider’s response process worth examining now. Ask who monitors security announcements and how the provider identifies which customers need urgent updates.

Write down who can authorize emergency maintenance. Include how to reach that person outside normal hours. Record where the backups are and who can restore the site if an update or an attack interrupts service. My guide to keeping control when someone else runs your website covers the accounts and backups an owner should hold before that moment arrives. Agree on how the provider will report completion and which business functions someone will test afterward. Start by getting written confirmation that the PHP serving your website includes both fixes.