A practical guide for website owners, WordPress developers, agencies, and server administrators

Updated: 22 October 2026

A critical PHP security announcement has raised an understandable question: Is my website safe?

The issue, widely called PHP2Shell, involves two vulnerabilities that can allow an attacker to execute code on affected servers without logging in. PHP released security updates on 21 October 2026. Website owners should confirm that those fixes have reached the PHP installation actually serving their websites. (php.net)

This incident also deserves a fair discussion about responsibility.

The vulnerabilities are real defects in PHP’s engine. However, keeping a managed hosting environment patched is normally the responsibility of the provider managing that environment.

A security flaw does not automatically make PHP a poor technology choice. Equally, we cannot fairly claim that hosting providers created these particular flaws. Understanding the difference helps us take the right action.

What Is PHP2Shell?

PHP2Shell refers to two critical vulnerabilities:

Vulnerability What goes wrong
CVE-2026-109618 An out-of-memory error can leave PHP’s internal request data in an invalid state, which may subsequently be used during cleanup.
CVE-2026-109619 Internal state can continue pointing to memory that has already been freed, allowing a later request to encounter that stale state.

Both vulnerabilities received a CVSS v4.0 severity score of 9.2 out of 10. The PHP project published technical advisories explaining their causes and impact. (GitHub)

In everyday language, PHP can mishandle certain failures while processing requests. Under exploitable conditions, that memory handling can allow an attacker to run code using the permissions of the PHP web worker.

This does not automatically mean root access. Nevertheless, the web worker may have access to application files, configuration secrets, and database credentials, making the potential consequences serious. The confirmed execution context is the web worker account.

Which Websites Should Be Checked?

PHP’s advisory identifies installations serving web requests as at risk, including:

  • PHP-FPM.
  • Apache with mod_php.
  • PHP-CGI.
  • FrankenPHP.
  • LiteSpeed.

PHP identifies mod_php as the highest demonstrated risk, including an attack that can begin before application code runs. Using a different PHP handler should not be treated as proof of safety. (php.net)

For website owners, this means checking any hosting environment running PHP applications: WordPress websites, WooCommerce stores, Drupal or Joomla installations, Laravel applications, and custom PHP systems.

WordPress has explicitly confirmed that these issues are not specific to WordPress. A separate WordPress update is not required or planned to fix them; the underlying PHP installation needs attention. (WordPress News)

Being potentially affected does not establish that a website has already been hacked. It establishes the need to verify patching and assess exposure.

Is This PHP’s Fault or the Hosting Provider’s Fault?

There are two separate questions:

  1. Where did the vulnerability originate?
  2. Who must apply the fix to a particular server?

The technical defects originated in PHP itself.

The PHP Foundation also acknowledged that signs of the out-of-memory problem had been identified in 2024. It explained that difficult compatibility decisions, limited resources, and its decision process delayed resolution, describing that delay as a structural failure. (thephp.foundation)

Therefore, saying “PHP has no fault; hosting providers caused this” would be inaccurate.

However, once a fix is available, deployment becomes an operational responsibility.

Hosting arrangement Who normally manages PHP patching?
Shared hosting Hosting provider
Managed WordPress hosting Managed hosting provider
Managed VPS or dedicated server Provider or administrator, according to the management agreement
Unmanaged VPS or dedicated server Customer’s server administrator
Self-managed cloud virtual machine Customer’s infrastructure team
Container deployment Team maintaining the image and deployment
Managed application platform Platform provider and customer, according to the service’s responsibility model

This table describes typical arrangements. The actual service agreement determines responsibility.

A hosting provider can be accountable for leaving a managed PHP installation unpatched. That is different from being responsible for creating the vulnerability.

Does This Mean PHP Is an Unsafe Technology?

This incident demonstrates a serious security problem in PHP. It does not, by itself, establish that every PHP application needs to be rewritten.

A useful technology assessment considers:

  • Whether security fixes are available.
  • How quickly those fixes can be deployed.
  • Whether the application uses supported software.
  • Whether the hosting environment is properly maintained.
  • Whether the business has monitoring and recovery arrangements.

Replacing a programming language is a substantial engineering decision. Applying the available runtime security fix is the immediate response to this incident.

A well-maintained application also depends on well-maintained infrastructure. Secure application code cannot repair a defect inside the runtime that executes it.

Who Has Worked on the Fix?

Several groups contributed at different stages.

PHP maintainers and the PHP Foundation

PHP’s maintainers led the fixes and release. The Foundation supported security engineering and coordination, while release managers and package maintainers helped make updates available. (OpenAI)

Security researchers and supporting organisations

The Foundation credited Calif, Wiz, OpenAI Codex Security, OSTIF, and Quarkslab for research and responsible disclosure.

OpenAI described its role in coordinating a wider response involving maintainers, researchers, and security providers, including Cloudflare. Its account identifies Calif’s AI-assisted discovery and Wiz’s independent reporting.

Hosting software vendors

cPanel published patched EasyApache PHP packages and guidance for updating its products. Its advisory also includes vendor packages carrying backported fixes for older PHP branches. (CVE-2026-109618 and CVE-2026-109619 – cPanel)

Plesk published affected-version tables and updates for its PHP packages and panel components. For certain older Linux PHP packages, the build date distinguishes patched packages from earlier packages sharing the same PHP version number. (Plesk)

An available vendor update does not prove that an individual hosting company has installed it on your server. Ask for confirmation.

Which PHP Versions Contain the Fix?

The upstream security releases are:

PHP branch Fixed release
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

Install the applicable fixed release or a later supported release. (php.net)

Why an older-looking version might already be patched

Some vendors apply security fixes to their existing packages without changing the upstream version number. This is called backporting.

For example, cPanel lists patched packages with vendor release suffixes, while Plesk documents older PHP packages distinguished by their build dates. A version number alone may therefore be insufficient; check the vendor’s package advisory or obtain written confirmation. (CVE-2026-109618 and CVE-2026-109619 – cPanel)

A backported fix addresses the identified vulnerabilities. It should not replace a longer-term plan to move away from unsupported software.

How to Fix It on Shared or Managed Hosting

Step 1: Check your website’s PHP version

For WordPress, go to:

Dashboard → Tools → Site Health → Info → Server

The hosting control panel may also display the PHP version. WordPress identifies both routes as useful checks.

Record the version for each website. Different domains on the same account may use different PHP configurations.

Step 2: Contact the hosting provider

Send a specific request:

Please confirm whether the PHP installations serving my websites have been patched against CVE-2026-109618 and CVE-2026-109619.

Please provide the active PHP version or patched vendor package build for each domain, confirm that the relevant PHP workers have been restarted, and advise whether any action is required from my side.

“Your server is secure” is less useful than confirmation naming both vulnerabilities and the installed package.

Step 3: Confirm the PHP version assigned to each domain

If the provider offers a patched version through its PHP selector, confirm that your domains actually use it.

Check:

  • Main website.
  • Subdomains.
  • Staging websites.
  • Older applications.
  • Customer portals.
  • Separate installations under the same hosting account.

Do not assume changing one domain changes all the others.

Step 4: Test the business functions

After patching, check:

  • Homepage and important pages.
  • Administrator and customer login.
  • Contact forms and file uploads.
  • Checkout and payment callbacks.
  • Order processing.
  • CRM workflows.
  • Scheduled jobs.
  • Email delivery.

These checks confirm application operation. They do not replace verification of the security patch.

How to Fix It on a Self-Managed Server

If you manage the server, treat this as a runtime update and deployment task.

Step 1: Identify every PHP installation

Inventory the PHP versions used by web services, control panels, containers, and applications.

A terminal check such as:

php -v

shows the PHP executable used by that shell. It may differ from the PHP version serving a website.

Step 2: Install the appropriate vendor update

Use the supported update route for your operating system, control panel, or deployment platform.

For cPanel and Plesk environments, follow their respective advisories. Their instructions account for vendor packages and components that may need separate updates.

Avoid applying a generic package command without first identifying how PHP was installed.

Step 3: Restart the affected processes

Ensure old PHP workers are replaced so that running services load the updated software. PHP’s technical guidance explicitly includes restarting workers. (GitHub)

For containers, rebuild or obtain a patched image, redeploy it, and replace the old running instances.

Step 4: Verify the deployed result

Record:

  • Installed package version and vendor release.
  • Confirmation that both CVEs are covered.
  • Active PHP version for each website.
  • Restart or redeployment completion.
  • Functional test results.

Checking an updated package on disk alone does not establish that every running application uses it.

Will Updating WordPress or Installing a Security Plugin Fix It?

Updating WordPress alone does not patch the PHP runtime.

WordPress’s official announcement confirms that the vulnerabilities affect the underlying PHP environment and require no dedicated WordPress release.

Continue normal WordPress, theme, and plugin maintenance, but do not confuse those updates with this fix.

A security plugin also cannot replace the vulnerable PHP engine.

For the out-of-memory issue, PHP’s technical advisory describes an Apache attack path that occurs before application code starts. That limits what application-level protections can accomplish against that path.

Can a Firewall Protect the Website?

A web application firewall may help reduce exposure while updates are being deployed. WordPress notes that hosting providers may be implementing WAF rules as part of their response.

However, firewall coverage depends on the rules, deployment, and traffic paths.

Ask the provider:

  • Are relevant rules enabled?
  • Do they cover every affected domain?
  • Can traffic reach the origin server directly?
  • Has PHP also been patched?

Treat firewall protection as an additional layer. PHP’s advisory states that updating is the complete solution.

What If You Cannot Update Immediately?

Escalate to the provider or server administrator immediately and obtain a clear remediation plan.

PHP has published temporary configuration measures, but explicitly states that they do not make an installation fully safe. Some also have significant operational trade-offs. Apply them only through an administrator following the current official guidance.

If remediation cannot be completed promptly, consider temporarily removing the affected PHP service from public access. WordPress’s security announcement relays national cybersecurity guidance to consider taking affected systems offline when immediate remediation is not feasible.

A maintenance page helps only if its implementation actually prevents untrusted requests from reaching the vulnerable PHP service.

Does Patching Remove an Existing Infection?

Patching closes the identified vulnerability. It does not establish that a previously exposed server is clean.

If compromise is suspected, use a separate incident-response process:

  1. Preserve relevant logs and evidence.
  2. Restrict access to the affected system.
  3. Investigate unexpected files, users, processes, and scheduled tasks.
  4. Review application and server configuration changes.
  5. Rebuild or restore from a trusted source where necessary.
  6. Rotate affected credentials after securing the environment.
  7. Assess whether customer information or other sensitive data was accessed.

These are general incident-response recommendations. Being exposed is not proof of compromise, and an apparently normal homepage is not proof that no compromise occurred.

How to Evaluate Your Hosting Provider’s Response

The useful question is:

Can the provider demonstrate that the environment it manages has been patched and verified?

Look for:

  • A clear security advisory or support response.
  • Confirmation covering both CVEs.
  • Specific package or build information.
  • Confirmation that running services were updated.
  • Guidance for older PHP applications.
  • Clear ownership of any remaining customer actions.

There is insufficient evidence to accuse a particular hosting company simply because it runs PHP.

However, a provider managing PHP should be able to explain its response. A developer or customer cannot install server packages when the provider retains that control.

Website Owner’s Checklist

  • Identify every website and application using PHP.
  • Check the PHP version serving each domain.
  • Obtain confirmation covering both CVEs.
  • Verify the fixed release or vendor backport.
  • Confirm relevant workers were restarted or containers replaced.
  • Check staging sites and older installations.
  • Test important application functions.
  • Review suspicious activity where exposure warrants investigation.
  • Plan upgrades for unsupported PHP branches.
  • Document who owns future runtime updates.

Frequently Asked Questions

  • Is every PHP website already hacked?
    No. A vulnerability announcement establishes risk, not proof that every installation has been compromised.
  • Is a website safe because it has SSL?
    HTTPS protects data in transit. It does not apply a PHP security patch.
  • Is PHP 8 automatically safe?
    No. The exact release or vendor package matters. Check for the relevant fix.
  • Is PHP-FPM automatically unaffected?
    No. PHP includes PHP-FPM in its advisory.
  • Can I fix it by editing wp-config.php?
    Editing WordPress configuration does not replace or patch the server’s PHP runtime. WordPress directs owners to update PHP. (WordPress News)
  • Should I move away from PHP?
    This incident alone is insufficient reason to rewrite a working application. First patch the runtime, verify the deployment, and assess your maintenance arrangements.

A Fair Conclusion About PHP and Hosting Responsibility

PHP2Shell is a serious PHP engine security incident, and the upstream project has acknowledged shortcomings in resolving part of it.

Hosting providers have a separate responsibility: applying available fixes to environments they manage. Owners of self-managed infrastructure must arrange that work themselves.

The practical lesson is to choose technology with an active security response—and hosting with a reliable process for delivering those fixes to your running website.

Official References