PHP2Shell: Four in Ten Merchant Websites Exposed, and What Acquirers Should Do Next

PHP2Shell: Four in Ten Merchant Websites Exposed, and What Acquirers Should Do Next

When PHP2Shell went public on 21 October 2026, roughly four in ten merchant websites worldwide were running an exposed version of PHP. That is the headline from Onlayer's analysis of around 1.4 million merchants across 20 markets, and it makes PHP2Shell one of the broadest merchant-side security events acquirers have faced in years.

What is PHP2Shell?

PHP2Shell is a pair of critical, unauthenticated remote code execution vulnerabilities in the PHP runtime itself (CVE-2026-109618 and CVE-2026-109619, CVSS v4.0: 9.2). Because the flaws sit in the engine rather than in any one application, the shop software, CMS or framework running on top makes no difference: every PHP release from 5.4 through 8.5.11 is affected, and upgrading is the only complete fix.

How many merchant websites are exposed to PHP2Shell?

At disclosure, 41.2% of all merchant websites in our dataset were running an affected PHP version, but what it takes to fix them differs sharply by region.

Figure 1. Share of merchant websites on an affected PHP version at disclosure, by region and remediation path. Source: Onlayer.

The data separates two very different problems. Merchants on a supported branch (PHP 8.2 to 8.5) need a point release that most hosting panels apply in minutes. Merchants on an end-of-life branch need a migration, with plugin, theme and payment module testing, before they are safe.

Exposure and difficulty do not move together

Africa has the second-highest exposure, yet more than 60% of its PHP-based merchants sit on supported branches, so most of the risk can be removed with routine updates. Europe combines the highest exposure with the oldest stacks: seven in ten PHP-based merchant sites there run end-of-life versions, and PHP 7.4 alone is the most common branch. The Gulf's low exposure reflects how strongly its merchants have moved to hosted commerce platforms that do not run merchant-managed PHP.

The legacy PHP tail is long

Across all markets, PHP 8.3 (21.9% of PHP-based merchant sites) and PHP 7.4 (21.6%) are now neck and neck, even though 7.4 reached end of life in late 2022. One third of PHP-based merchants still run a 7.x release, and around 6% run PHP 5.x, a line retired in 2018. For these merchants PHP2Shell is not a one-off patch; it is the bill for years of deferred maintenance arriving at once.

Case study: how did Türkiye patch fivefold in 24 hours?

Türkiye shows what a coordinated response looks like: among supported-branch merchant sites we re-scanned after the fix shipped, the share running a patched build rose fivefold in under 24 hours.

By the end of 22 October, more than 70% of all patched merchant sites we had detected across 20 markets were Turkish.

Three conditions made this possible. Türkiye started from a better position, with merchant exposure about 10 points below the international average and PHP 8.3, a supported branch, as its most common version. Acquirers and PSPs received the list of affected merchants in their own portfolios within hours of disclosure, so outreach started the same day. And continuous re-scanning turned remediation into a visible, trackable metric rather than an assumption.

The lesson for other markets: speed comes from knowing exactly which merchants are exposed, telling them quickly and verifying the fix, not from the patch alone.

How do the PHP2Shell vulnerabilities work?

Both flaws sit in how the PHP engine manages memory and per-request state, which is why they affect every application layer built on top of it. Neither requires a bug in the merchant's own code.

CVE-2026-109618: out-of-memory corruption

When an out-of-memory condition interrupts certain operations, PHP can leave request data only partially initialized. Cleanup routines then treat that invalid state as valid, and an attacker who can steer the failure can turn it into code execution.

CVE-2026-109619: stale global state

Request-owned state can outlive the memory that backs it. A later request served by the same worker may touch those stale references before normal initialization resets them, producing a use-after-free that researchers have chained into remote code execution.

Three details that matter for risk assessment

• Server API exposure differs. Apache mod_php deployments warrant the most urgent attention, because PHP reports a demonstrated exploit path that triggers before application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also in scope.
• Impact goes beyond code execution. Researchers also demonstrated unauthenticated disclosure of worker memory, which can expose passwords, session tokens and API keys, including payment gateway credentials held by the application.
• Shared workers amplify risk. Because CVE-2026-109619 abuses state carried between requests, shared hosting environments, where many merchant sites are served from pooled workers, deserve particular scrutiny.

Which PHP versions are affected and which releases fix PHP2Shell?

Every PHP release from 5.4 up to and including 8.5.11 is affected; upgrading to the fixed point release of a supported branch is the only complete remedy.

Two caveats apply. Linux distributions often backport fixes while keeping the older upstream version string, so the distribution advisory is authoritative. And the binary reported by php -v on the command line is not necessarily the one serving web requests, so verification must target the running web workers.

PHP2Shell disclosure and exploitation timeline

Attack activity preceded the fix by at least four days, so any PHP-based site that was unpatched on 21 October should be treated as potentially compromised, not merely vulnerable.

How to fix PHP2Shell: steps for merchants and hosting teams

Patch first, verify second, mitigate only where patching is genuinely blocked. For sites on a supported branch the work is usually measured in minutes; for end-of-life branches it is a planned migration measured in days.

1. Inventory every PHP runtime. Include parallel PHP versions, hosting-panel builds, containers and PHP bundled with appliances, and confirm which runtime actually serves web traffic.
2. Upgrade supported branches to the fixed point release. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On distribution packages, match the full package version against the vendor advisory.
3. Restart or replace every worker. Restart PHP-FPM pools and Apache, redeploy containers from rebuilt images, and confirm no worker still runs the previous build.
4. Plan the end-of-life migration now. For PHP 8.1 and older, obtain a vendor-supported fixed build if one exists, or migrate to 8.2 or later after testing plugins, payment modules and themes in staging.
5. Apply interim mitigations only as a bridge. PHP lists configuration measures that remove specific attack paths, for example session.upload_progress.enabled=0 at server level, tighter request and input limits, fatal_error_backtraces=0 on PHP 8.5, and pm.max_requests=1 for FPM where acceptable. A web application firewall with PHP2Shell rules adds a further layer. None of these makes an unpatched runtime safe.
6. Isolate what cannot be fixed quickly. Restrict public access or take the site offline temporarily, in line with CISA's guidance for PHP 8.1 and earlier.
7. Hunt for compromise, not just exposure. Review web server logs from 17 October onwards, check for unexpected files, unfamiliar admin accounts and modified checkout scripts, and rotate database passwords, API keys and payment gateway credentials.
8. Roll back emergency settings after patching. Restore any relaxed limits, review temporary restrictions and re-scan to confirm the fix is live.
   
   

What should acquirers and PSPs do about PHP2Shell?

For an acquirer, PHP2Shell is not one vulnerability but thousands of individual merchant exposures. The institutions that respond best treat it as a portfolio triage exercise with clear tiers, owners and deadlines.

Triage by consequence, not just by version

Connect it to PCI DSS obligations

PCI DSS v4.0.1 expects critical security patches to be installed within one month of release (Requirement 6.3.3) and requires management of payment page scripts and change- and tamper-detection on payment pages (Requirements 6.4.3 and 11.6.1). A merchant running an end-of-life PHP runtime after a critical runtime-level remote code execution flaw is difficult to reconcile with those expectations, and the gap should be reflected in merchant risk ratings and annual reviews.

Watch the second-order signals

A compromised PHP storefront rarely announces itself. Early indicators include injected checkout scripts, new redirect chains, content or product changes inconsistent with the merchant's declared business, and sudden shifts in transaction patterns. These are exactly the signals where e-skimming and transaction laundering surface first.

Make it part of onboarding

New merchant applications presenting an end-of-life runtime after this disclosure should carry a remediation condition before activation, not after the first incident.

Why continuous merchant monitoring made the difference

PHP2Shell compressed the usual patch cycle into hours. Institutions with continuous visibility into their merchants' technology stacks did not need to start with an inventory: within hours of disclosure, acquirers and PSPs on Onlayer's platform received a merchant-level list of exposed sites in their own portfolios, ranked by remediation path. From that point, the work shifted from finding exposure to closing it. In Türkiye, where outreach began the same day, the share of re-scanned supported-branch merchants on a fixed build rose from 5.7% to 29.9% within 24 hours.

The lesson extends beyond this incident. Runtime versions, payment page scripts and website content change constantly, mostly outside an acquirer's line of sight. A point-in-time review at onboarding cannot catch these changes; continuous monitoring can. It turns the next critical disclosure into a list, a deadline and a verified fix, rather than an open question.

What this looks like in practice

• Exposure at portfolio level. The externally visible technology footprint of every monitored merchant website, including server-side runtimes and versions, is mapped continuously.
• Verified remediation. Affected merchants are re-scanned and progress is reported back to each institution, separating merchants that have patched, are migrating or need escalation.
• Risk context. Runtime exposure is read alongside content and script changes, business model consistency and compliance status across the merchant lifecycle.

Onlayer is a Mastercard Technology Provider and a certified Mastercard Merchant Monitoring Service Provider (MMSP), serving more than 200 acquirers, PSPs, card schemes and fintechs across 20+ countries.

Frequently asked questions about PHP2Shell

What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both are rated 9.2 (CVSS v4.0) and allow an unauthenticated attacker to execute code remotely on a server that runs PHP for web requests.

Which PHP versions are affected by PHP2Shell?
Every PHP release from 5.4 through 8.5.11 is affected. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end of life and receive no regular upstream fix.

How many merchant websites are exposed to PHP2Shell?
According to Onlayer data covering around 1.4 million merchants in 20 markets, 41.2% of merchant websites ran an affected PHP version at disclosure. PHP is used by 41.7% of merchant sites, and 98.8% of those were on an affected version.

Is PHP2Shell being exploited in the wild?
Yes. The earliest reported exploitation attempt dates to 17 October 2026, four days before the fix, and honeypot networks confirmed active exploitation on 21 October 2026.

Can PHP2Shell be mitigated without upgrading?
Only partially. PHP lists configuration changes that block specific attack paths, such as disabling session upload progress, but states that updating is the only complete fix. Mitigations should be treated as a short bridge to patching.

What should merchants on PHP 8.1 or older do?
They should migrate to a supported branch (PHP 8.2 or later) or obtain a vendor-supported fixed build. Until then, CISA advises restricting access to or temporarily taking offline PHP systems that cannot be updated.

Are merchants on hosted e-commerce platforms affected?
Merchants on hosted commerce platforms that do not run merchant-managed PHP are not directly exposed. The platform operator is responsible for patching its own infrastructure.

What should acquirers and PSPs do about PHP2Shell?
Identify exposed merchants in the portfolio, prioritize them by end-of-life status and payment page setup, contact them with clear deadlines, verify fixes by re-scanning, and reflect unresolved exposure in merchant risk ratings in line with PCI DSS patching requirements.
 

Methodology

Findings are aggregated across around 1.4 million merchants in 20 markets monitored by Onlayer, based on the latest scan of each merchant as of 22 October 2026, and do not identify any merchant or client institution. Only merchants with an active, reachable website are included; social media and marketplace storefront pages are excluded, and each domain is counted once per market. Version distributions are calculated from sites where the PHP version is externally detectable and applied to all PHP-based sites to estimate overall exposure. Regional groupings: Europe, the Gulf, Africa and Türkiye. Patch velocity figures cover sites re-scanned between 21 October 17:00 and 22 October 18:00 (Türkiye time). Because Linux distributions sometimes backport fixes without changing the reported version, actual exposure on some servers may be lower than version signals suggest.

Sources

• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026)
• PHP 8.4.27 release notes
• Qualys Threat Research: PHP2Shell analysis and temporary mitigations
• Google Cloud and Wiz: Responding to CVE-2026-109618 and CVE-2026-109619
• watchTowr: PHP2Shell FAQ

About the Onlayer Research Team

The Onlayer Research Team analyzes merchant risk, payment security and compliance trends using data from Onlayer's merchant lifecycle platform, which helps acquirers, PSPs, card schemes and fintechs discover, onboard and continuously monitor merchants across more than 20 countries.