php2shell: the critical PHP vulnerabilities and what to do now

What this means for your business

Systems running affected versions of PHP may be exposed to security risks, including potential unauthorised access or compromise, depending on their configuration and existing security controls:

• Your website being changed, taken offline or used to show fake content
• Customer details, orders or enquiries being copied
• Your server being used to send spam or attack other organisations, which can get your domain blocked
• A foothold for criminals to reach other systems in your business

How it happened, in simple terms

Both flaws come down to PHP not tidying up properly in unusual situations. Think of it like a builder who is stopped mid-job and leaves scaffolding half-built: the next person assumes it is safe and puts weight on it. Or a hotel room that is not cleaned between guests, so the next guest finds the previous guest's keys. In each case, a carefully crafted visit to a website can exploit the mess left behind and trick the server into running the attacker's instructions.

Am I affected?

You may be if any of these apply. PHP is often hidden inside other products, so it is worth asking rather than assuming.

• Your website is built on WordPress, WooCommerce, Magento, Drupal or Joomla
• You have a customer portal, booking system or intranet that runs in a web browser
• You use a hosting control panel, or equipment with a web login page
• You have older web systems that nobody has updated in a while

What to do now

You do not need to fix this yourself. You need to make sure whoever looks after your systems has done it.

• Identify who runs your website and any online systems - a web agency, hosting company, software supplier or your IT team
• Send them the questions below and ask for a written reply
• Where immediate patching is not possible, ask your IT provider to assess the risk and implement appropriate temporary safeguards, which may include restricting access or isolating affected systems
• If you have no idea where to start, contact us and we will help you work it out

Questions to ask your web provider

You can copy and send these as they are:

• Do any of our websites or systems use PHP?
• Have they been updated to the fixed versions released on 21 October 2026 (8.5.12, 8.4.27, 8.3.36 or 8.2.35)?
• When was the update applied, and was the service restarted afterwards?
• Is anything running on an older, unsupported version of PHP, and what is the plan for it?

How Telappliant can help

If you're unsure whether your business may be affected, Telappliant can help you understand your potential exposure, review appropriate security measures and identify the next steps. The scope of any assessment, remediation or ongoing monitoring can be agreed based on your requirements.

Technical details for IT teams

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical issues, each scored CVSS 9.2. PHP 8.1 and earlier are outside the upstream PHP project's supported release branches. Organisations using these versions should consult their software or operating system supplier to establish whether vendor-maintained security fixes are available and consider a supported upgrade path. The PHP team states updating is the only reliable mitigation; there is no complete configuration workaround.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): memory corruption when a request hits memory_limit mid-operation, such as multipart upload parsing. Unauthenticated RCE demonstrated on Apache mod_php with default settings; RCE also confirmed on PHP-FPM via application code paths.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): worker global state left pointing at freed request memory after a fatal error or warning; a later request on the same worker can use it (use-after-free). RCE demonstrated on Apache mod_php; confirmed on PHP-FPM.
• Inventory all PHP, including PHP bundled in third-party products and appliances
• Patch, then restart PHP-FPM and web server processes so the fixed binaries are loaded
• Prioritise internet-facing systems; isolate or VPN-restrict anything that cannot be patched
• A WAF and restricted admin access reduce risk temporarily
• Where appropriate monitoring capabilities are available, review PHP and web server activity for suspicious behaviour, including unexpected process execution or outbound connections