PHP2Shell Vulnerability: How to Protect Your Website

Imagine you run a small online shop.

You have paid for the website, uploaded your products and started receiving orders. You update your plugins, use a strong password and feel reasonably confident that you are doing the right things.

Then your hosting company sends an emergency message: your website may need to go offline while it fixes a serious security problem.

You have not clicked a suspicious link. You have not shared your password.

So how could someone get in?

The PHP2Shell vulnerability affects software that processes requests to a website. In a vulnerable setup, an attacker may be able to run code on the server before anyone logs in. Changing your password or updating a plugin does not fix that underlying problem.[2]

What is the PHP2Shell vulnerability? A simple explanation

Think of your website as a restaurant.

Customers place orders. A helper writes down the details, passes them to the kitchen and clears the working space for the next order.

PHP is one kind of helper that websites can use. In this analogy, its working memory is the counter where it sorts each order.

Now imagine that an unusual order interrupts the helper halfway through writing its notes. During cleanup, it mistakes some unfinished scribbles for proper instructions.

Or it clears an old order away but keeps pointing to the place where that order used to be. The next customer puts something different there, and the helper gets confused.

These are simplified pictures of the two problems behind PHP2Shell: unfinished internal data being treated as valid, and old references being used after their memory is no longer valid.[3][4]

Under the right conditions, an attacker can turn that confusion into instructions the server follows.

That is remote code execution: making another computer run code without being authorized to do so.[4]

What happened during the PHP2Shell security incident?

On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The vulnerable component was PHP itself—not simply one WordPress plugin or one website's login page.[2]

ProjectDiscovery reported widespread maintenance and service shutdowns as organizations responded, including services associated with DeviantArt, Pokémon Home and Wikimedia. Taking a service offline as a precaution does not, by itself, mean it was breached.[1]

The scale matters, but the numbers need care. ProjectDiscovery cites PHP use on roughly 70% of websites whose server-side language is known. That is not the same as saying 70% of every internet-connected system was compromised.[1]

How PHP2Shell can give hackers access to a server

Caleb Writes Code's PHP2Shell explainer focuses on an easily overlooked part of software security: what happens when a program runs out of memory and has to stop processing a request.[11]

In a vulnerable deployment, the failure can develop like this:

A server receives a request and starts building the internal structures needed to process it.
A carefully crafted request can cause memory pressure or interrupt an operation at a dangerous moment.
PHP's error-handling or cleanup code encounters data that is not in the state it expects.
An attacker who can influence the surrounding memory may be able to redirect what the program does.[3][4]

For CVE-2026-109618, an out-of-memory interruption could leave partially initialized data reachable by cleanup code. The official advisory describes several ways to reach this dangerous state, rather than a single request pattern.[3]

For CVE-2026-109619, state belonging to an earlier request could survive after its memory had been released. A later request handled by the same worker could access that stale state.[4]

Successful code execution runs with the web worker's privileges. It does not automatically mean the attacker has administrator or root access. Nevertheless, Wiz demonstrated serious consequences, including code execution against major PHP-based applications and disclosure of sensitive worker-memory contents.[4][5]

For a business, that could put customer information or credentials at risk. The precise damage depends on what the compromised process can access.[5]

A website loading normally is not a security test. Cloudflare's response combined request and response information because the request alone did not always provide enough evidence to distinguish an exploit from legitimate traffic.[12]

The Pegasus connection: how an image became an attack

There is a useful comparison with BLASTPASS, the attack Citizen Lab disclosed on September 7, 2023.

Citizen Lab found an exploit chain delivering NSO Group's Pegasus spyware to an iPhone. It could compromise an iPhone running the then-current iOS 16.6 without the victim interacting with the message.[7]

The attacker sent an iMessage containing a PassKit attachment—the format used for Wallet passes—with malicious images inside it. The victim did not have to open a suspicious website or type a password.[7]

Google Project Zero's later analysis showed that one image was a WebP file disguised with a .png filename. A flaw in image decoding allowed memory corruption. Apple addressed the related ImageIO and Wallet vulnerabilities in iOS 16.6.1.[8][9]

The dangerous step was the phone processing the attachment automatically. PassKit provided a carrier for the malicious images.[7][8]

PHP2Shell and BLASTPASS are different vulnerabilities on different platforms. The connection is the lesson: software can process attacker-controlled data automatically, before the person using the device has a chance to make a decision.[3][7][8]

Being careful about what you click is useful. It cannot prevent every attack.

AI found the flaws. Patching still took time.

Calif and Wiz described AI-assisted research on the PHP bugs, but discovery was only the beginning of the response.[13][5]

Calif's published timeline records an initial report to PHP on August 11, 2026, followed by patched releases on October 21—a span of 71 days, or roughly ten weeks. Wiz independently reported its findings on August 24.[13][5]

That interval deserves scrutiny, but “the bug was ignored for ten weeks” would be an unfair summary.

The PHP Foundation says fixing the underlying problem involved difficult choices around compatibility, denial-of-service risks and third-party extensions. It also acknowledges that earlier work on the problem had stalled, describing shortcomings in its decision-making and resources.[14]

Then the disclosure process became messy. According to the Foundation, CVE identifiers circulated early, Calif mistakenly published a demonstration video, and built images containing fixes appeared before the coordinated release. PHP moved the release forward by a day.[14]

Cloudflare reported observing attack traffic and attackers changing their payloads while protections were being deployed.[12]

What concerns me is the work that still has to happen after a researcher proves an attack is possible.

Finding a flaw, developing a reliable fix, distributing packages and updating a business's actual servers are separate jobs. Faster discovery does not automatically make the other jobs faster.

A small business still needs someone who can answer: Which systems do we own, which are exposed, and who is responsible for updating them?

What business owners and developers should check

For developers, I would turn this incident into practical review questions:

Do we test what happens when processing fails halfway through?
Are internal resources cleaned up safely after errors?
Do we know which runtimes and dependencies each application uses?
Can we prove the patched version is running—not merely downloaded?

For owners, the useful question is not just “Is my website updated?”

Ask: “Has the software underneath my website been checked, and can you show me the result?”

OWASP recommends maintaining an inventory of components and dependencies, monitoring their security notices, testing updates and having an ongoing patch-management process.[16]

ProjectDiscovery's account shows why that inventory needs to include overlooked installations: administration tools, webmail, old sites and other PHP services can be missed when attention stays on the main homepage.[1]

Was ALHarih affected by PHP2Shell?

The main ALHarih application code reviewed for this article uses Next.js and Node.js rather than PHP. This PHP-runtime flaw does not directly apply to that reviewed component.

That finding has limits. A review of the main application does not tell us whether every supporting tool or supplier uses vulnerable PHP, and it is not a forensic investigation into possible compromise.

These checks did not establish an ALHarih compromise or confirm that every connected service was unaffected.

I would rather explain what was checked than turn a limited finding into a promise about the whole platform.

How to fix PHP2Shell and verify the patch

1. Find every PHP installation

Include production, staging, background services, containers and old administrative tools. Confirm the runtime used by the web service; do not rely only on a homepage or an advertised version banner.[1]

2. Update the affected runtime

The first upstream releases fixing the two disclosed vulnerabilities were:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

Use the appropriate supported release or your distribution's verified security package, and check the current vendor advisory for subsequent guidance. Updating a CMS alone is not a PHP-runtime update.[2][3]

3. Review the configuration guidance too

PHP's published guidance also recommends disabling session upload progress with session.upload_progress.enabled=0 to protect against an unusual session-handling RCE path pending a further fix. Have the administrator assess the current advisory and configuration conditions rather than treating one version number as an unconditional all-clear.[2]

4. Restart or redeploy the affected services

Replace the running workers so they use the patched code. Where PHP is packaged inside a container, update the image and redeploy it; do not assume changing a package elsewhere has changed that container.[1]

5. Verify and investigate

Check the actual running build and test important application functions. If exposure or suspicious activity is identified, bring in qualified help to investigate whether secrets or data were accessed; Wiz's demonstrations included disclosure of sensitive worker memory.[5]

6. Keep temporary protections in perspective

A web application firewall can provide additional protection while updates are deployed. Cloudflare specifically advised customers to patch even with its WAF protections in place.[12]

A temporary mitigation is not a reason to abandon the update.

How ALHarih can help you find technical support

For many businesses, the missing piece is not another warning. It is finding someone capable of turning that warning into completed work.

ALHarih provides a marketplace where businesses can browse talent, compare services and post projects.[10]

A business could use those tools to seek a suitably experienced developer or infrastructure specialist for a clearly scoped maintenance project. I would write the brief like this:

Identify our PHP-based services, confirm their exposure, apply approved updates, restart or redeploy the affected runtimes, and provide evidence of the running versions and application checks.

ALHarih's role here is to help businesses look for relevant expertise. The platform itself does not apply these PHP patches, and hiring a specialist still requires checking their experience and agreeing on the work.

Review the specialist's experience, agree on access and scope, and ask for evidence of completed work rather than a message saying “done.”

The goal is not to make every business owner a security engineer.

It is to make sure someone knows what is running, understands the risk and can demonstrate that the necessary work has actually been completed.

When I ask whether a security update is finished, I want more than an installation message. I want to know which services were checked, what they are running now and whether the application still works.

Frequently asked questions

Does updating WordPress fix PHP2Shell?

Not necessarily. PHP2Shell affects the PHP runtime. Your host or administrator needs to update that runtime, even if WordPress and its plugins are already current.[2]

Can a firewall replace the PHP security update?

No. Cloudflare describes its WAF protections as an additional defensive layer and still advises customers to patch PHP.[12]

What if I cannot patch immediately?

Follow the official mitigation guidance and your provider's instructions. Temporary protections can reduce exposure, but they should not become a substitute for updating.[2]