PHP2Shell: what small businesses need to know and do

Your website might be up to date while the software running underneath it remains vulnerable.

That is the key concern with PHP2Shell, the name given to two critical security vulnerabilities in PHP, a technology used by many business websites and online applications. Successful attacks could allow criminals to run commands on an affected server or read sensitive information from its memory, potentially without logging in.

For small and medium-sized businesses, the immediate priority is straightforward: establish whether your services use PHP, confirm that the relevant security updates have been installed, and make sure somebody owns that task.

Information accurate as of 28 October 2026.

What is PHP2Shell?

PHP is software that runs behind the scenes, helping websites process forms, display content and deliver online services. It supports platforms including WordPress, Drupal and Joomla, alongside many custom business applications.

PHP2Shell covers CVE-2026-109618 and CVE-2026-109619. Both involve problems with how PHP handles memory and internal information during web requests.

The important distinction is that these weaknesses are in PHP itself. A website does not need a vulnerable plugin or a mistake in its own code to be affected. Researchers demonstrated attacks against several popular website platforms.

What could this mean for your business?

Successful exploitation could give an attacker the permissions of the account running the affected PHP service. Depending on what that account can access, the consequences could include website changes, stolen information or further compromise. It does not automatically mean the attacker gains full administrative control of the server.

Researchers also demonstrated that sensitive information could be read from PHP’s memory, including passwords, authentication tokens and API keys. An attacker would not necessarily need to install malicious software to steal that information.

For an SME, the practical impact could be interrupted sales, an unavailable customer portal, recovery costs or loss of customer confidence.

Are attackers using it?

There is evidence of real attack activity. Wiz’s update on 27 October described exploitation attempts and recognised evidence of successful attacks against deliberately exposed monitoring systems known as honeypots.

However, success depended on the target environment. The evidence does not establish that every vulnerable installation can be compromised reliably using the same publicly available exploit.

That uncertainty is no reason to delay: Wiz expects the barriers to exploitation to diminish as attackers improve their tooling.

What should SMEs do now?

1. Find out where PHP is used

Ask your hosting provider, web developer or IT support company to check your websites and business applications.

Include old websites, subdomains, development systems and customer portals. A forgotten application can still expose your business.

Make responsibility explicit. The company maintaining your website’s content may be different from the company responsible for the server and PHP updates.

2. Confirm that PHP itself has been patched

The first upstream PHP releases containing fixes for both vulnerabilities were:

These are the initial fixed releases, rather than a reason to avoid subsequent security updates.

Some Linux distributions and commercial support providers apply security fixes to their existing packages without adopting the same upstream version number. Your supplier should check the relevant vendor advisory and installed package revision.

PHP 8.1 and older no longer receive routine security updates from the PHP project. Where these versions remain in use, establish whether a supported vendor has supplied a fix and arrange a move to a supported release.

3. Check that the update is actually running

Updating WordPress, its plugins or another application does not necessarily update PHP underneath it.

Ask your supplier to confirm that every affected PHP environment has been updated and that the relevant services and workers have been restarted. Where applications run in containers, those deployments also need attention.

A downloaded update is not sufficient if the website is still being served by an older running process.

4. Include PHP’s follow-up advice

On 23 October, PHP published additional advice about an unusual combination of session configuration and application behaviour that could still permit remote code execution.

PHP recommends disabling session upload progress with session.upload_progress.enabled=0 until the next regular bugfix release. Applications that never change their session serialisation handler at runtime can keep the feature enabled.

Ask your supplier to review this follow-up alongside the original updates.

5. Investigate anything suspicious

Ask your provider to review unexpected PHP crashes, repeated server errors, unusual requests and unexplained website changes.

These symptoms do not prove an attack, and their absence does not prove that a system is safe. Some exploitation paths can expose information without leaving an obvious malicious file. Patching also does not undo a compromise that has already happened.

If there are signs of compromise, preserve the available logs and seek incident response support.

Can a firewall protect us?

Some web application firewall providers have introduced protections, but coverage varies. These controls can help reduce exposure while updates are arranged; they should not replace the PHP security update.

A useful question to send your provider

“Please confirm whether any of our websites or applications are affected by PHP2Shell, whether vendor fixes are installed and running across every environment, and whether you have addressed PHP’s follow-up session upload progress advice.”

Request a clear answer with evidence of the checks completed.

At Plainsight Security, we help businesses identify exposed systems, assess vulnerabilities and verify remediation. If you are unsure what sits behind your website, contact us to discuss a practical review, vulnerability scan or full penetration test.