PHP2Shell: Why Websites Went Offline and How to Protect Yours

When a website disappears overnight, the obvious explanation is that someone broke in. During October's PHP security emergency, the story was often stranger: the people responsible for keeping a site online were the ones pulling the plug.

They were buying time to patch PHP2Shell, two serious flaws in the software beneath many familiar websites. For a business owner watching an empty shopfront or a broken booking page, that distinction might feel academic. But it changes what you should do next.

If you only do one thing today: ask your hosting provider to confirm that the PHP runtime serving your website has fixes for CVE-2026-109618 and CVE-2026-109619, and that the running workers were restarted. Updating WordPress alone does not fix this problem.

Reporting checked on 4 November 2026. Version numbers below identify the October fixes, not a permanent recommendation to stay on those builds. Check current vendor advisories before making changes.

Table of contents

1. What actually happened?
2. Why a site going offline does not prove a hack
3. What the attack reports really tell us
4. How to check your own website
5. The message to send your hosting provider
6. What helps while you arrange the update
7. What to do if someone may already be inside
8. The maintenance habit this incident should change
9. Frequently asked questions

What actually happened?

On 21 October 2026, PHP released emergency fixes for two vulnerabilities collectively known as PHP2Shell. Both can allow remote code execution without a login. In plain English, a remote attacker may be able to make a vulnerable server run instructions of their choosing. [1]

One flaw concerns what happens when PHP runs out of memory during a request. Certain internal data can be left unfinished and then handled as if it were valid. The other involves references to memory from an earlier request surviving into later processing. These are engine problems, underneath the application you recognise as your website. [2] [3]

That is why a well-maintained CMS could still need urgent attention. The vulnerable software sits beneath the website itself. CERT-EU lists several affected ways of running PHP, including PHP-FPM, Apache with mod_php and LiteSpeed. The attack conditions vary, but keeping the application up to date does not remove the need to patch its runtime. [5]

There is an uncomfortable detail behind the emergency. The PHP Foundation says signs of the memory problem emerged during work following a 2024 audit. Finding a safe fix involved difficult compatibility and engineering decisions, and the Foundation acknowledged failures in the process that delayed resolution. This was a long-standing problem whose practical danger became much clearer. [4]

Why a site going offline does not prove a hack

CERT-EU advised immediate patching and said organisations unable to patch should consider isolating exposed applications until the fix was applied and verified. Taking a vulnerable service offline can therefore be a sensible response, even when it costs bookings or sales. [5]

That distinction matters when reading dramatic headlines. An outage can be planned containment, an update that went wrong, an overloaded server or an intrusion. A maintenance page alone cannot tell you which. Ask the operator whether the interruption is a protective measure, a technical failure or a confirmed security incident.

What the attack reports really tell us

A vulnerability warning, an attempted attack and a confirmed compromise tell you different things. The warning describes a weakness that needs fixing. An attempt shows that someone tried to use it. Establishing a compromise requires evidence that the attacker gained access or caused an unauthorised action.

By 3 November, Singapore's Cyber Security Agency was warning about reported active exploitation targeting exposed management interfaces on affected Palo Alto Networks firewalls. Palo Alto's own advisory also records active exploitation. That is a more specific claim than saying that every PHP website was hacked, and a good reason to keep checking updated advisories. [6] [7]

For your own business, the useful question is whether your systems were exposed and whether the fix is now running. A large number of blocked requests is evidence of activity. It is not a count of stolen databases.

How to check your own website

Start with the server running the live website. A PHP version shown in your laptop's terminal may have nothing to do with it. Hosting accounts can also run different PHP versions for separate domains.

The October releases containing fixes for both original PHP2Shell flaws were: [2] [3]

Choose a current supported build containing these fixes. Some hosting and operating-system vendors backport security patches into packages with older-looking version numbers. Ask for the vendor advisory and package build proving that both CVEs are fixed, rather than judging from a banner alone. Older branches need particular care: a backport can close these holes without making an obsolete branch a sustainable choice. [1]

Include staging sites, forgotten subdomains, old customer portals and products that bundle PHP. NCSC-NL's response guidance specifically calls out third-party images, appliances and embedded runtimes. A current production homepage does not tell you what is running behind an old test URL. [8]

Plan beyond the immediate fix, too. PHP 8.2 reaches the end of upstream security support on 31 December 2026. If you are already arranging upgrade work, check the support lifetime of the destination branch. [9]

The message to send your hosting provider

You do not need to become a server administrator to ask for a clear answer. Send this, replacing the domain:

Please confirm that the PHP runtime serving [your domain] is patched against CVE-2026-109618 and CVE-2026-109619.

Which PHP package version and build is active for this domain? If you use backported patches, please link the relevant vendor advisory.

Were all relevant PHP services and workers restarted after patching? Does this also cover our subdomains and staging sites?

Please also confirm whether the 23 October session upload progress advisory, CVE-2026-115560, requires any action on our configuration.

Ask your developer to verify the response against the live environment. An answer about the hosting company's general rollout is helpful, but you need confirmation for your account.

If an older WordPress site cannot run on a supported PHP version, the upgrade may also need theme or plugin repairs. Our WordPress development and support service covers that application work alongside coordination with the host.

What helps while you arrange the update

The PHP security team published temporary configuration measures to reduce exposure to specific attack paths. Its warning is explicit: these measures do not make an unpatched installation safe. Ask the administrator to review the official guidance against your server configuration while arranging the runtime update. [1]

There was also a follow-up advisory on 23 October for CVE-2026-115560. It concerns an unusual combination of session configuration and application behaviour, and is separate from the two original flaws. PHP advised disabling session.upload_progress.enabled until the next regular bugfix release, with an exception for applications that need the feature and never change the session serialisation handler at runtime. Have the administrator check the latest advice and apply any necessary setting before request parsing, then restart the relevant workers. [1] [8]

If a system cannot be patched promptly, involve the host in restricting access or temporarily isolating it. Treat configuration changes and firewall rules as interim controls. Keep a written list of what changed so a temporary workaround does not become a forgotten permanent setting.

What to do if someone may already be inside

A patch closes a vulnerability. It does not remove a backdoor planted yesterday.

If you find unknown administrator accounts, unexpected redirects or unexplained file changes, involve your host and developer. These symptoms deserve investigation, but do not identify PHP2Shell as the cause on their own.

1. Contain the affected service. Coordinate access restrictions with the host and preserve evidence before cleanup.
2. Record what happened. Note symptoms, timestamps, recent changes and actions taken. Preserve relevant logs and a snapshot of the affected environment.
3. Investigate beyond the visible page. Check files, accounts, scheduled tasks and connected systems for persistence and unauthorised changes.
4. Recover from trusted material. Validate backups and replacement files. Close the entry point before reopening the service.
5. Replace exposed access. Reset affected credentials and invalidate sessions from a trusted environment. Verify that the replacement secrets are not being handed back to an attacker.

WordPress's own recovery guidance stresses documenting the incident, working with the host, keeping a snapshot before cleaning and resetting access. The exact recovery work depends on the evidence and the reach of the intrusion. [10]

The maintenance habit this incident should change

Write down who owns the next emergency update. The host may manage PHP, your developer may manage the application, and someone else may control the firewall. Everyone can complete their usual checklist while one exposed system remains untouched.

A useful maintenance record names the live runtime, its support deadline, the person responsible for urgent patches, where backups are stored and when a restore was last tested. Keep the same record for staging and secondary domains.

For a custom PHP website, include the framework and dependencies in that plan. If the application needs changes before a runtime upgrade, scope those changes with your web development team, then test the booking, checkout and enquiry flows before release.

If you need help establishing that process, our website security and website maintenance services are a place to start. Bring the hosting provider's answer with you. It gives the investigation a much better starting point than a screenshot of a frightening headline.

Frequently asked questions

Does updating WordPress fix PHP2Shell?

No. These vulnerabilities are in the PHP runtime. Update the affected PHP installation as well as maintaining WordPress, themes and plugins. The PHP project's security advisory identifies the fixed runtime releases. [1]

My website works normally. Can it still need the patch?

Yes. A working homepage does not establish whether the underlying runtime has the security fix. Check the active package or get written confirmation from the host.

Are sites using PHP-FPM unaffected?

No. CERT-EU includes PHP-FPM among the affected web-serving setups. The demonstrated attack paths and conditions vary, but switching the server API is not a substitute for applying the fix. [5]

Does a blocked attack mean customer data was stolen?

No. A blocked request records an attempted action. Establishing a compromise or data theft requires additional evidence from the affected environment.

Sources

Official project advisories, government cybersecurity guidance and developer documentation. Incident reporting was checked on 4 November 2026; the source list was reviewed on 5 November 2026.

1. PHP: October security releases and the 23 October session upload progress advisory.
2. PHP security advisory: RCE via OOM corruption, CVE-2026-109618.
3. PHP security advisory: RCE via stale global state, CVE-2026-109619.
4. The PHP Foundation: the security release, discovery and response.
5. CERT-EU: Security Advisory 2026-018.
6. Singapore CSA: reported active exploitation affecting network and security products, 3 November.
7. Palo Alto Networks: product impact and exploitation status.
8. NCSC-NL: operational guidance and affected-product inventory.
9. PHP: supported versions and security support deadlines.
10. WordPress: responding to a suspected hacked site.