PHP2Shell can put a website at risk even when its application code is fully updated. The vulnerabilities sit in PHP itself: the software that runs many websites, online shops and business applications.

For organisations responding, installing a patch is essential. Getting that patch to every affected system requires knowing which applications use PHP, where they run and who maintains them.

Software visibility and vulnerability monitoring need to be part of everyday security and development work. When a critical vulnerability emerges, teams need an inventory they can act on.

What is PHP2Shell?

PHP2Shell is the name given to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated critical at 9.2 out of 10. PHP released security updates on 21 October 2026.

The flaws involve how PHP handles memory and clears information between web requests. Under certain conditions, an attacker can exploit them to execute malicious code without logging in. Sensitive information held in memory may also be exposed.

The consequences can include stolen credentials, altered website content, unauthorised access to application data and interrupted services. The attacker initially gains the permissions of the PHP process; further damage depends on what that process can access.

Exploitation depends on the deployment and configuration. PHP identifies Apache mod_php as the highest-risk setup, but PHP-FPM and other configurations serving web requests also require attention.

Which organisations are affected by PHP2Shell?

Organisations running vulnerable PHP installations are in scope, including:

• Website operators using PHP-based platforms such as WordPress, Drupal and Joomla.
• Retailers and e-commerce businesses running Magento, WooCommerce or custom PHP storefronts.
• Hosting providers and managed service providers responsible for multiple customers’ websites.
• Public-sector bodies, healthcare providers and educational institutions maintaining PHP applications, including legacy services.
• Software companies and other enterprises using PHP in customer applications, internal tools, containers or bundled third-party products.

These categories describe potential exposure, not confirmed breaches. An organisation’s actual position depends on its deployed software and patch status.

Smaller teams may struggle with limited security resources. Larger organisations face a different challenge: finding installations spread across departments, suppliers and older systems. ENISA specifically warns that products can contain PHP without their users realising it.

Check: Establish where you are exposed

Start by identifying the PHP installations that support your live services. Include production, staging and externally accessible development environments.

Your review should cover:

• Servers and applications: identify the PHP version actually handling web requests.
• Containers: check both the images being built and those currently deployed.
• Hosting platforms and appliances: look for separately bundled PHP runtimes.
• Managed services: ask providers whether affected PHP versions are present and what remediation they have completed.

Record the service, runtime or package version, deployment location, internet exposure and responsible owner. Prioritise publicly accessible systems while assessing the remaining installations.

An SBOM can support this work when it includes the relevant components and corresponds to the deployed release. An application dependency list alone may not capture the PHP runtime underneath it.

Meterian’s software composition analysis and container scanning help teams understand components in their codebases and images and identify known vulnerabilities within their scanning coverage. Teams must connect those findings to deployed services and confirm coverage of the relevant runtime.

Patch: Update the runtime and confirm vendor fixes

PHP published the following fixed releases:

PHP branch	First fixed release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Install the appropriate fixed release, a later supported release, or your vendor’s corresponding security package. PHP 8.1 and older no longer receive normal upstream releases. Some vendors provide backported fixes; otherwise, plan migration to a supported branch.

A backported fix may retain an older PHP version number. Confirm remediation through the vendor’s advisory and package details, rather than relying solely on the displayed upstream version.

For containers, rebuild and redeploy affected images. For managed hosting, obtain confirmation covering both websites and any separately maintained control-panel runtime.

If immediate patching is impossible, restrict exposure and consider taking affected public services offline. Firewall rules and configuration changes can reduce particular attack paths, but they do not replace the update.

Verify: Prove the change reached production

After updating, restart affected PHP workers or redeploy containers, then verify the build serving actual web requests. A command-line version check can report a different installation.

Before closing the remediation task:

• Confirm deployment: check every affected instance and replica.
• Test essential workflows: verify logins, checkout, uploads and other critical functions.
• Review suspicious activity: examine unexpected processes, modified application files, outbound connections and unusual errors.
• Retain evidence: record the fixed build, deployment time, checks performed and accountable owner.

Amazon observed an exploitation attempt on 17 October, so investigations should cover at least that date onward. Patching prevents further exploitation through the fixed flaws; it does not remove an existing backdoor or recover stolen credentials.

Keep Monitoring after the incident

PHP2Shell illustrates how AI-assisted research can make longstanding weaknesses practically exploitable. Organisations need a response process that keeps pace with new findings.

Integrate scanning into CI/CD, maintain release-linked inventories and monitor known vulnerabilities after deployment.

Where enabled, Meterian Sentinel performs daily checks against previously scanned components and can alert teams to newly identified vulnerabilities affecting their projects.

Knowing about a vulnerability is the beginning. Security improves when the right people can find affected systems, make the change and verify that it reached production.