Real insights on building faster, smarter, and more scalable commerce experiences.
Nikki Kumari
GeneralPHP2Shell (CVE-2026-109618) is a critical PHP runtime vulnerability actively exploited in the wild. Know what to check, patch, and verify.
Nikki Kumari
ShopifyShop MCP is Shopify’s live AI shopping server. Learn how AI assistants find your products, build carts, and complete purchases, and what your catalog needs to stay visible.
Nikki Kumari
ShopifyShopify Scripts stopped on June 30, 2026. See how to rebuild discount, shipping, and B2B checkout logic with Functions, UI extensions, and custom apps.
Anusree V Anand
ShopifyGoogle Universal Cart is live in the US. Shopify merchants are already inside it by default. Here is what to configure, what your feed needs, and what GA4 will miss before BFCM.
Nikki Kumari
E-commerce RoundupTwo critical CVEs on CISA’s KEV list, Adobe’s biggest Commerce patch of the year, Shopify’s Fall ‘26 Edition, and an $85B BFCM forecast. The October 2026 eCommerce roundup.
Nikki Kumari
GeneralCVE-2026-111497 (Node2Shell) is actively exploited and on CISA's KEV list with a deadline of November 10. Here is how to audit and patch Node.js, Docker containers, and Python services.
Nikki Kumari
GeneralPolyShell (CVE-2026-48356) is being exploited in Magento and Adobe Commerce stores. See fixed versions, how to check for compromise and what to do now.
Meghna Vinod
GeneralCustom PHP commerce platforms face PHP2Shell too. Find every hidden PHP runtime, patch containers, protect .env secrets and decide whether to modernize.
Meghna Vinod
PimcorePHP2Shell puts Pimcore PIM and DAM at risk. See which Pimcore versions have a fix, how to patch, check product data integrity and secure ERP connections.
Aakash Ashok
magentoPHP2Shell hits every Magento store on PHP. See which versions have no fix, how to patch self-hosted Magento 2, check for skimmers and protect customer data.
Meghna Vinod
AdobePHP2Shell and Adobe Commerce: What Every Store Needs to Patch, Check and Protect Key Takeaways PHP2Shell is two critical PHP flaws (CVSS 9.2) that let attackers run commands on your server without a login. Adobe Commerce patches do not fix it. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every worker. Your deployment model decides who patches: Adobe for SaaS, your team for Cloud Infrastructure, you or your host on-premises. According to Amazon, attacks began on October 17, four days before the fix, so check for new admin users and unknown PHP files. Codilar offers an exposure check with findings in 48 hours, plus patching, a compromise sweep and managed services. On 21 October 2026, PHP shipped emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. This guide answers three questions: Is our store exposed, who fixes it, and what should we check once the patch is on? What PHP2Shell Is and What's at Stake PHP2Shell involves two flaws in the PHP runtime itself, both rated critical with a CVSS score of 9.2 out of 10. When PHP aborts a request mid-task, it can leave memory in a broken state that a later request can abuse: a use-after-free condition (a memory bug where software keeps using memory after releasing it, letting an attacker place their own data there). The result is remote code execution (an attacker runs their own commands on your server from the internet) without a login. PHP processes each request before Adobe Commerce code runs, so clean code and audited extensions often make no difference. Any web-facing PHP setup is at risk, and Apache mod_php carries the highest risk. What an Attacker Can Do With It Run commands on your server without logging in Read passwords and API keys leaked from server memory Plant payment skimmers or hidden admin accounts Inject spam pages on your domain and drag down your search rankings. Create PCI DSS and GDPR exposure if card or customer data is reached "There are no complete mitigations; updating is the only safe choice." PHP Security Team, PHP2Shell advisory. Which Adobe Commerce Stores Are Exposed Adobe Commerce stores on an unpatched PHP build are exposed to PHP2Shell, and your deployment model decides who has to fix it. Adobe Commerce as a Cloud Service (SaaS) Adobe operates the runtime. Confirm with your account team, and check any PHP middleware you host yourself. Adobe Commerce on Cloud Infrastructure (PaaS) Adobe manages the cloud infrastructure, and your team pins the PHP version in the application configuration. We found no Adobe guidance specific to these CVEs as of October 23, 2026, so open a support ticket and ask: Has the patched build reached integration, staging and production? Does each environment need a redeploy? Does the Fastly WAF cover PHP2Shell on every environment? On-Premises, Self-Hosted or Third-Party Hosting You or your hosting provider owns PHP. Update the PHP packages, then restart PHP-FPM or Apache so every worker loads the fixed version. Ask your host for written confirmation of the version now serving your store. Your setup decides who patches. Assign one owner to confirm the fixed PHP version on every environment, staging included. The PHP 8.1 Gap in Older Adobe Commerce Versions PHP released fixes only for 8.2 and newer. PHP 8.1 and older get no official release, so stores on those versions depend on vendor or community backports that someone has to apply and test. Per Adobe's system requirements: On Adobe Commerce 2.4.4 to 2.4.6, plan two moves. First, secure the store on your current PHP version. Apply a vendor or community backport of the fix and the interim hardening settings, and test them before they reach production. Then upgrade Adobe Commerce onto a supported PHP version. According to Adobe’s lifecycle policy, PHP 8.1 reached end of life on December 31, 2025, and Adobe warns that PCI compliance is at risk for stores still running it. How to Patch Adobe Commerce Against PHP2Shell Step 1: Confirm the PHP version actually serving the store Check from a web request. The command-line binary can differ from the one serving pages, so verify through the web server or hosting dashboard. Step 2: Update to a fixed PHP release Patched versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Restart PHP-FPM or Apache, because running workers keep old code in memory. Step 3: Use interim mitigations only as a bridge Settings PHP suggests while you patch: session.upload_progress.enabled = 0, then restart workers A low post_max_size (8M, or 32M with uploads) WAF virtual-patch rules in blocking mode What not to rely on: Maintenance mode and error suppression do nothing here, because PHP handles the request first. A WAF helps but is not a fix. According to Cloudflare, attackers were mutating their payloads to get past its rules. Step 4: Regression-test revenue journeys Test checkout, payments, search, integrations and admin uploads on the patched build. Check for Signs of Compromise After Patching Amazon's honeypots recorded an exploitation attempt on 17 October, four days before the fix existed. As of October 23, 2026, we found no public report of a confirmed breach. A missing confirmation does not prove your store is clean, and the patch does not remove anything that got in before it. Review activity from 17 October for: New or changed admin users Unknown PHP files in pub/, media or upload directories Unexpected cron jobs or scheduled tasks PHP processes launching shells, curl or wget Unusual outbound connections from PHP workers Rotate Credentials That May Have Leaked Rotate API tokens, integration keys, admin and database passwords, and payment gateway keys used during the exposure window. Don't Overlook Search Visibility Check the Security Issues report in Google Search Console and crawl for pages you didn't publish. If spam pages have already hurt your rankings, our SEO team can help you clear them from search results and win back lost traffic. Encrypt Customer Data at Rest to Limit the Damage Patching closes the way in. You also need to know what an attacker could read if they got through. Adobe Commerce hashes customer passwords and encrypts payment credentials, but names, email addresses, phone numbers and street addresses sit in the database as plain text. A leaked backup or a stolen database login exposes all of it. PII Shield, Codilar’s field-level encryption framework built with Libsodium, helps limit that damage: Encrypts customers, carts, orders, invoices, shipments, credit memos and admin users Decrypts in real time for authorised users, so checkout, search and admin work as usual It does not replace patching. A copied database yields encrypted records that stay unreadable without the keys. The video below shows how PII Shield protects customer data at the database level. How Codilar Helps Secure Your Adobe Commerce Store Against PHP2Shell Stabilize in 48 Hours Start with a free PHP2Shell Exposure Check, run read-only and with your written consent, with findings in 48 hours. Where action is needed, our engineers patch PHP or secure the store within its current PHP version through tested backports, hardening and WAF virtual patching. The target is 48 hours for standard environments, with checkout and integration regression-tested. Secure What Matters Compromise sweep, credential rotation, custom hardening and SEO clean-up. Strengthen for The Next One We move stores onto supported PHP and Adobe Commerce releases and add PII Shield for field-level encryption. After the move, our managed services and DevOps teams keep your environment patched and monitored. Secure Your Adobe Commerce Store Today Adobe Commerce security depends on every layer beneath the storefront, and PHP2Shell sits in the lowest one. Update PHP on every environment, check for signs that someone got in before the patch, and set up monitoring so you can act on the next vulnerability the day it is announced. Book a free PHP2Shell Exposure Check, and we will review your PHP version and your Adobe Commerce release together. Running another PHP platform? Read our guides for Magento and Pimcore. Frequently Asked Questions Is Adobe Commerce affected by PHP2Shell? Yes. Adobe Commerce runs on PHP, and PHP2Shell affects every PHP installation serving web requests. Who fixes it depends on your deployment: Adobe for Cloud Service, Adobe images plus your redeploy for Cloud infrastructure, and you or your host for on-premises and third-party hosting. Does an Adobe Commerce security patch fix PHP2Shell? No. The flaws are in the PHP runtime, not Adobe Commerce code. You need PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport for older versions, then a restart of every PHP worker. Updating Adobe Commerce or extensions alone won't close it. We're on Adobe Commerce on Cloud infrastructure. Do we need to do anything? Yes. Ask Adobe Commerce Support whether the patched build has reached every environment, whether a redeploy is needed, and whether WAF protection covers all of them. Then review logs from 17 October for signs of compromise. Can we secure Adobe Commerce without upgrading PHP straight away? Yes, as a short-term measure. A tested backport, configuration hardening, and WAF virtual patching can secure a store within its current PHP version. It's a bridge, not a destination: PHP 8.1 is end of life, so plan an upgrade to 2.4.7 or later on PHP 8.3 or newer. How do we know if our store was compromised before patching? Review activity from 17 October for new admin users, unknown PHP files, unexpected cron jobs, PHP processes launching shells and unusual outbound connections. Rotate credentials used in that window and check Google Search Console for warnings. Treat anything unfamiliar as an incident.
Aakash Ashok
AdobeAdobe Commerce 2.4.9 runs on PHP 8.5. See the support dates for every version, the PHP 8.2 end of life, and how to sequence your upgrade.
Aakash Ashok
With the world's leading digital commerce agency.
