A security headline lands in your inbox. Someone forwards it to your team with a simple question: "Does this affect our store?"
On October 21, 2026, that headline was PHP2Shell. Researchers at Wiz and Calif disclosed two critical flaws in PHP, the programming language behind WordPress, Drupal, Magento and much of the web. Wiz estimates PHP powers about 70% of all websites. Governments and security agencies urged site owners to patch immediately, and several organizations took sites offline as a precaution (BBC).
Answering that question takes more than knowing which ecommerce platform you use. Your business may depend on a storefront, apps, custom integrations, a content management system and several external services. A vulnerability could hit one part of that environment and leave the rest untouched.
These alerts deserve a fast, structured response. Verizon's 2025 Data Breach Investigations Report found that exploitation of vulnerabilities was the initial access point in roughly 20% of the breaches it analyzed, close behind stolen credentials.
The first step is to establish where the affected technology appears in your business, who maintains it, and what action is required. Here's where to start.
1. Identify What the Advisory Actually Affects
"PHP vulnerability" and "WordPress plugin vulnerability" describe different problems. A headline may refer to the underlying programming language, a particular application, or an extension that only some stores use.
Most serious vulnerabilities receive a CVE identifier, and the record is published in the CVE List and enriched in NIST's National Vulnerability Database. Start there or with the vendor's own advisory. Before making changes, have your technical team check:
- The affected product or component.
- The affected versions.
- Any conditions required for exploitation.
- The recommended fix or mitigation.
- Whether your deployment matches those conditions.
Two signals help with prioritization. The severity score, calculated with the Common Vulnerability Scoring System (CVSS), indicates how serious the flaw is in general. CISA's Known Exploited Vulnerabilities Catalog tells you whether attackers are already using it. A listing there should move the issue to the top of the queue.
PHP2Shell as an example
The NCSC advisory lists the two tracking IDs (CVE-2026-109618 and CVE-2026-109619) and the condition behind them: an out-of-memory error that, under certain conditions, allows unauthenticated remote code execution. Wiz put the severity as high as 9.2 out of 10 and found every PHP version released in the last decade affected by at least one of the flaws. Because the flaw sits in PHP itself, updating WordPress or its plugins does nothing to fix it, as the BBC noted. The update has to be applied to PHP on the server.
2. Look Beyond Your Main Storefront
Your ecommerce platform is only one part of your technology environment. A brand might run its storefront on Shopify while using a separate content site, a custom integration or an older application elsewhere. Those systems can have different hosting arrangements and maintenance responsibilities.
The same Verizon report found that a third party was involved in about 30% of breaches, double the previous year's share.
Ask your team to check the systems connected to your commerce operation, including:
- Content sites and campaign landing pages.
- Custom apps and middleware.
- Inventory, fulfillment and customer data integrations.
- Older systems that still have access to current services.
The goal is an accurate inventory of relevant systems and their owners. For custom software, a software bill of materials (SBOM) lists the components and libraries inside each application, which makes it much faster to confirm whether a newly announced flaw is present.
The NCSC's first priority action for PHP2Shell was exactly this: identify every system running PHP, starting with internet-facing ones, and don't limit the search to outdated versions (NCSC). Experts also warned that PHP turns up in less obvious places, such as the management interfaces of network appliances and load balancers (BBC).
3. Confirm Who Owns the Fix
Knowing a system is affected does not resolve the issue. Someone needs to own the response.
Depending on the component, that responsibility may sit with your platform provider, hosting company, app developer, agency or internal engineering team. On a hosted platform like Shopify, the provider secures and patches the core platform (see Shopify's security overview). Third-party apps, custom code and external systems remain the responsibility of whoever built and maintains them.
Self-hosted platforms shift more of that work onto the merchant. Magento (Adobe Commerce) is built on PHP, so Magento stores were directly in scope for PHP2Shell. The store owner or their agency typically applies the patches to PHP, the platform, its extensions and the server. Slow patching has hurt Magento stores before: in 2024, a flaw known as CosmicSting (CVE-2024-34102) was exploited against thousands of stores that had not yet installed Adobe's fix.
For Magento teams, PHP2Shell sits outside the usual patch cycle. The flaw is in PHP itself, so there is no Adobe bulletin or Magento patch that fixes it. The fix is a PHP update on the server, and how easy that is depends on your Magento version (as of October 26, 2026):
| Magento version | PHP2Shell status |
|---|---|
| 2.4.7 to 2.4.9 | Fixable now: update PHP and restart |
| 2.4.6 | High risk: must run PHP 8.2 to get the fix |
| 2.4.4 and 2.4.5 | Critical: PHP 8.1 has no official fix |
On Adobe Commerce Cloud, your PHP version is still your responsibility under Adobe's shared responsibility model. Confirm your status with Adobe support.
Shopify's core platform isn't built on PHP and is maintained by Shopify. That doesn't make a Shopify brand automatically safe, though. A WordPress content site, a PHP-based integration or middleware hosted elsewhere would still need checking.
Confirm who will assess exposure, apply the recommended action and verify the result. Where a supplier manages the affected service, ask them to confirm your account's status and any steps your team must take. If you accept card payments, the PCI Data Security Standard already expects you to know which security requirements each service provider manages on your behalf, so this list may exist in your compliance records.
Don't assume a managed service covers every custom integration connected to it.
4. Separate Exposure From Evidence of Compromise
An affected version needs attention. It does not, by itself, prove that someone accessed your systems or customer information.
Your technical or security team should review logs and other available evidence for activity linked to the vulnerability. Depending on what the affected component could reach, that review may need to cover connected services too.
For PHP2Shell, Wiz noted that application logs may show little, because the flaws run below the application layer. It suggested watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker churn. The NCSC also advised checking for backdoors on any system that couldn't be updated right away.
Patching won't remove an attacker who is already in. On Magento, the review should include checking for rogue admin accounts, injected CMS blocks and backdoors.
If there are signs of compromise, move into your incident response process. Preserve relevant evidence and involve the appropriate specialists before making changes that could complicate the investigation. If your team doesn't yet have a documented process, NIST's incident response guidance (SP 800-61 Rev. 3) is a good reference.
5. Verify Both the Fix and the Customer Experience
Applying an update doesn't prove it closed the exposure.
Have the responsible team verify the installed version or mitigation and check that the affected service still works. For ecommerce systems, validation should also cover the business processes the change touches. Depending on the system, that could include:
- Checkout and payment processing.
- Order creation and confirmation emails.
- Inventory updates.
- Fulfillment and 3PL handoffs.
For PHP2Shell, the fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Installing the update isn't enough on its own: PHP-FPM or the web server has to be restarted before the patched version is actually running.
A response is complete when the security action has been verified and the relevant commerce workflows work as expected.
Turn the Headline Into a Better Maintenance Process
Security headlines often reveal an operational gap: nobody has a complete picture of the systems the business depends on.
An inventory of applications, integrations, owners and maintenance responsibilities makes the next advisory easier to assess. That's why asset inventory is one of the first steps in NIST's Cybersecurity Framework 2.0. It also helps teams spot unsupported software and unnecessary access before either becomes an urgent problem.
Frequently Asked Questions
What was PHP2Shell?
PHP2Shell is the name for two critical flaws in the PHP programming language (CVE-2026-109618 and CVE-2026-109619), disclosed on October 21, 2026. Under certain conditions they allow attackers to run code on a web server without logging in. PHP released patched versions the same day.
Does a vulnerability in PHP or WordPress affect my Shopify store?
Not directly. Shopify's core platform isn't built on PHP and is maintained by Shopify. Separate sites, apps or integrations you run outside Shopify may still be affected and should be checked.
How is patching different on Magento compared to Shopify?
Shopify patches its hosted core platform for merchants. On Magento (Adobe Commerce), the merchant or their agency is usually responsible for applying PHP, platform, extension and server patches, so a slow update cycle can leave the store exposed.
Does a Magento security patch fix PHP2Shell?
No. The flaw is in PHP itself, so no Adobe bulletin covers it. Your team or agency needs to update PHP on the server and restart it.
Where can I find reliable details about a specific vulnerability?
Use the vendor's official advisory, the CVE List and the National Vulnerability Database. News coverage is useful for awareness, but it won't tell you whether you're affected.
How do I know if a vulnerability is urgent?
Check its CVSS severity score and whether it appears in CISA's Known Exploited Vulnerabilities Catalog. Active exploitation is the strongest signal to act immediately.
Who is responsible for patching third-party Shopify apps?
The app developer maintains the app itself. Your team or agency confirms the update was applied and that connected workflows still function.
Does being affected mean we were breached?
No. An affected version means you're exposed. Only a review of logs and other evidence can show whether anyone exploited it.
What should we test after applying a fix?
Confirm the patched version is installed, then test the commerce workflows the system touches, such as checkout, payments, order creation, inventory and fulfillment.
