Skip to content
Independent deal discovery • Clear terms • No checkout surprises
TECH GUIDE · October 22, 2026

PHP2Shell Vulnerability: Affected PHP Versions and Fixes

PHP2Shell security alert with a shield, padlock and web servers

Information checked: 23 October 2026 | Category: Tech Guide

The PHP2Shell vulnerability alert concerns two critical flaws in PHP, the software that processes requests for many websites. PHP released emergency security updates on 21 October 2026. Website owners should confirm that their hosting environment has received both fixes, rather than assume a WordPress update has handled the problem.

For a small business owner, blogger or online store manager, the immediate question is practical: is the PHP runtime serving your website patched? Your hosting provider can answer that. A website that still loads normally can require an urgent update.

This guide explains the verified PHP vulnerability news, the difference between exposure and compromise, and the steps owners can take with their hosting provider. It is based on published advisories; TopDiscountCodez has not independently tested exploits or audited individual hosts.

PHP2Shell: the essential facts

QuestionAnswer
What is PHP2Shell?A name used for two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619.
When were patches released?21 October 2026.
What is the severity?Both have a CVSS v4.0 score of 9.2.
What is the main risk?Unauthenticated remote code execution under exploitable conditions.
What should owners do?Confirm a fixed PHP package is running on the web server.

Sources: PHP security announcement and NHS England’s PHP2Shell alert.

PHP vulnerability October 2026: what happened?

The name PHP2Shell is used by Cloudflare and NCSC-NL; php.net refers to the flaws only by their CVE IDs (CVE-2026-109618 and CVE-2026-109619). Affected setups include PHP-FPM, mod_php, CGI, FrankenPHP and LiteSpeed running PHP 5.4 and later.

PHP’s security release brought urgent attention to a problem beneath the application layer. In plain English, a site can have current themes and plugins while still relying on a vulnerable PHP runtime.

There is also evidence of attempted exploitation before the public disclosure. Amazon Threat Intelligence reported a PHP2Shell attempt in its MadPot honeypot telemetry on 17 October, followed by further attempts on 21 October. Amazon said it was unclear whether those attempts would have succeeded against real-world systems.

That distinction matters. An observed attack attempt is evidence of targeting; it is not proof that every exposed website was breached. Likewise, the publication of a fix does not tell an owner whether their particular hosting account has received it.

For readers following the story, separate three questions: what the flaw can do, what activity researchers observed, and what has been confirmed about a specific website. Headlines often blend those questions together.

What is the PHP2Shell vulnerability?

PHP normally accepts a web request, runs application code and returns a response. The two advisories describe failures in how PHP handles internal memory and request state when things go wrong.

CVE-2026-109618: out-of-memory corruption

An out-of-memory error can interrupt work while internal request data is not fully initialized. Request cleanup may then process invalid memory. The PHP project’s advisory documents remote code execution against Apache mod_php, including an attack path before application code runs. Exploit reliability depends on the deployment.

CVE-2026-109619: stale global state

The second PHP advisory concerns request-owned state surviving after its backing memory has been freed. A later request handled by the worker can encounter that stale state.

Remote code execution means an attacker can potentially make the server execute instructions. It does not require the owner to click a phishing link. These are server-side vulnerabilities, so changing a browser setting does not repair them.

Why might a website go offline?

The UK National Cyber Security Centre advises organisations that cannot patch or apply temporary mitigations promptly to consider taking affected systems offline until they can be mitigated.

A precautionary shutdown therefore does not automatically mean a successful cyberattack. It can be a deliberate decision to reduce exposure during remediation.

From outside a website, a maintenance screen rarely explains the whole incident. If a shop or service is unavailable, check its own status page or support announcement. Avoid attributing an outage to PHP2Shell without confirmation from the operator.

Which PHP versions contain the fixes?

The following upstream security releases contain the fixes:

PHP branchFixed release
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12

NHS England’s remediation guidance lists these versions or later fixed releases in each branch. Older unsupported branches require particular attention.

Some operating-system and long-term-support vendors backport security patches. In those environments, a displayed version number alone may not establish patch status. Ask for confirmation that the installed package addresses both CVEs. PHP’s official announcement explicitly directs users to their distribution or LTS vendor for updated packages.

Are WordPress websites affected?

WordPress owners need to assess their hosting environment because PHP runs underneath WordPress. The relevant question is not simply whether the dashboard says WordPress is current.

Think of the responsibility in layers: WordPress maintains the application; theme and plugin developers maintain their code; the host or server administrator maintains the PHP runtime. For managed hosting, start with support. For a self-managed server, involve whoever maintains packages, containers and running services.

Do not interpret this as proof that your site has been hacked. Exposure requires remediation; confirmed compromise also requires investigation and cleanup. Keeping those tasks separate makes support requests more useful.

How to check and protect your website

1. Record the PHP version used by WordPress

Open Tools → Site Health → Info → Server in the WordPress dashboard and find the PHP version. WordPress’s PHP update guide documents this path.

Record the full version, your hosting account and the affected domain. If you manage several sites, create one row per site so that one successful update does not get mistaken for completion across the account.

2. Ask your host for explicit patch confirmation

An effective support request is specific:

Please confirm whether the PHP runtime serving my domain is patched for CVE-2026-109618 and CVE-2026-109619. Please identify the running PHP version or vendor-patched package, confirm that the update is active, and advise whether any other action is required for my account.

Keep the response with your maintenance records. An answer about an available upgrade is different from confirmation that your website is already using it.

3. Prepare the update without unnecessary delay

Back up files and the database, check compatibility, and involve your host in changing PHP. WordPress recommends preparation because themes and plugins can behave differently across PHP versions. Where practical, test a staging copy while the host addresses the urgent exposure.

Afterwards, test the tasks visitors actually perform: opening pages, signing in, submitting forms and completing checkout. A homepage loading successfully is only one check.

4. Confirm the running environment

Ask the administrator to confirm that the patched runtime is active, including any required worker or service restarts. Check other domains and separately managed environments too. A package update record is useful, but owners need assurance about the service processing live requests.

5. Investigate suspicious activity

If there are signs of compromise, preserve logs and document when symptoms appeared before starting cleanup. WordPress’s hacked-site guidance recommends recording symptoms, contacting the host and investigating the infection.

Unknown administrators, unexpected redirects, altered files or malware warnings deserve investigation. They are not, by themselves, proof that PHP2Shell was the entry point. Ask your responder to establish the cause rather than attach a familiar vulnerability name to every incident.

Can a firewall or security plugin fix PHP2Shell?

A security product may provide useful detection or reduce exposure to some attack paths. It should not be treated as a replacement for the PHP fix.

PHP’s advisory says configuration changes provide incomplete protection. Amazon likewise identifies updating as the complete remediation for both flaws. Ask your provider what its temporary controls cover, what remains exposed, and when patching will be completed.

Avoid copying isolated configuration changes into production without understanding their effect. Controls can affect uploads, memory behaviour and availability. If a server cannot be patched promptly, the host or administrator should assess the official mitigation guidance and whether temporary isolation is necessary.

What should ordinary website visitors do?

Visitors cannot patch a merchant’s server. If a service announces disruption, follow its official updates and use its established support channels. Avoid entering credentials into replacement login pages advertised through unexpected messages.

Do not assume that visiting an affected website means your password or payment details were stolen. A claim of a data breach needs evidence about that service. If its operator issues a verified notice, follow the specific instructions provided.

Frequently asked questions

Is PHP2Shell a WordPress plugin vulnerability?

No. The reported flaws are in PHP itself. A WordPress site needs its PHP environment checked even when its plugins are current.

Does an online website mean it is safe?

No. Availability does not establish patch status. Get confirmation from the hosting provider or administrator.

Does patching remove an existing infection?

Do not assume so. Closing a vulnerability and removing changes made during an intrusion are separate tasks. Suspected compromise requires investigation.

Should I take my website offline immediately?

Ask your host whether the running environment is patched. NCSC recommends considering offline isolation when updates or temporary mitigations cannot be applied promptly; the decision should reflect the actual exposure.

Can a clean malware scan prove PHP is patched?

No. Malware detection and vulnerability remediation answer different questions. Obtain package or runtime patch confirmation as well.

What is the first action for a nontechnical owner?

Send your host the two CVE identifiers and request confirmation for your domain. Keep the answer, the update time and your post-update checks together.

Your next step

Make one clear request today: confirm that the PHP runtime serving your site contains both PHP2Shell fixes. Then record the result, check the site’s essential functions and investigate any suspicious activity separately. That gives you a usable maintenance record instead of relying on a reassuring headline or a green dashboard indicator.

Continue protecting your WordPress website

Use our WordPress security checklist for prevention, the WordPress malware removal guide for recovery, and our WordPress security plugins comparison when evaluating tools.