The PHP security flaw and your online store: what it means for orders and deliveries

On October 21, 2026, PHP fixed two critical flaws that can let attackers run code on unpatched web servers, and stores that could not update quickly were advised to consider going offline. While a store is offline, new orders stop and orders sent to shipping from the store's server wait, but parcels already with a carrier keep moving.

For many online stores, the first cost of this incident was the precaution itself. When a store goes offline to stay safe, checkout stops, and in many setups the orders on their way to the shipping platform stop with it. The warehouse can be fully staffed and the carrier on its way while dispatch slows down because the order information has not arrived.

I lead compliance and information security at nShift, and in my experience an alert like this raises the same questions for most retailers: who owns each system, who can decide to take one offline, and how orders resume afterward. With Black Friday a month away, now is a good time to settle those questions.

What happened to PHP in October 2026

PHP runs roughly 70% of the world's websites, according to Cybersecurity Dive, and it is the language behind store platforms such as WooCommerce, Magento (Adobe Commerce), PrestaShop and OpenCart.

On October 21, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities, registered as CVE-2026-109618 and CVE-2026-109619 in the public Common Vulnerabilities and Exposures (CVE) list. Both score 9.2 out of 10 on CVSS, the standard scale for rating the severity of security flaws, and both can let an attacker run commands on a web server without logging in. Its advice to users: "updating is the only safe choice." The project also reminded users that PHP 8.1 and older no longer receive fixes, and that PHP 8.2 gets its last security fixes on December 31, 2026.

The UK's National Cyber Security Centre (NCSC) told organizations that could not apply the fixes, or temporary workarounds, in time to "consider taking the system offline until it can be fully mitigated." Its Dutch counterpart, NCSC-NL, took its own site down while it assessed the flaws and reported that other organizations, government agencies among them, did the same. On October 26, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its catalog of vulnerabilities known to be exploited, meaning attacks using them have been observed.

How widespread those attacks are is still being measured. Researchers at the security firm Arctic Wolf told Cybersecurity Dive that "the reality has been less dramatic than the headlines," while Charles Carmakal, chief technology officer at Mandiant, said exploitation "may have already begun in a limited fashion." My advice to a store owner is the same either way: update PHP, then check the server for signs of an attack.

Which online stores need to act

The work falls on whoever runs the server. Stores on fully hosted platforms typically rely on their provider to patch PHP; WooCommerce, for example, told merchants on hosting run by Automattic, the company behind WooCommerce and WordPress.com, that their sites "are already protected." Stores that manage their own hosting, or pay a partner to do it, need confirmation that PHP itself has been updated.

WooCommerce also stated that "no WooCommerce or WordPress update is required" for these flaws, because the fix is in PHP, which runs underneath the store software. A store can show every plugin and theme as up to date while the PHP version under it is still unpatched. For self-managed stores on PHP versions older than 8.2, which no longer receive security updates, WooCommerce advised considering taking the server offline during the upgrade.

Other software on the store's server typically runs on the same PHP version, shipping plugins included, so one update usually covers it.

What pauses and what keeps moving when a store goes offline

An online store does more than take payments. In most of our customers' setups, it is also where order details start their journey to the warehouse, the shipping platform and the carrier. When the store goes offline, the effect on deliveries depends on where each of the next steps runs.

• New orders stop at checkout. Customers cannot buy until the store is back, and the delivery options shown at checkout go offline with it.
• Orders sent to shipping from the store's own server wait. Many retailers connect their store to a shipping platform through a plugin installed on the store's server. While that server is off, the plugin cannot pass orders on, so labels and carrier bookings for new orders are not created.
• Orders already handed over can keep moving. When the shipping platform runs in the cloud, outside the store, the orders it already holds can still be booked with a carrier, labeled and packed. Retailers that send orders to shipping from their ERP (enterprise resource planning) or warehouse management system may not depend on the store's server for this step at all.
• Parcels already with a carrier keep moving. Tracking updates continue as long as tracking pages and notifications are not served from the store itself, and the same goes for returns portals, the pages where customers register a return.

Customer service then has to explain an uneven picture: one customer's parcel is on a van, another's order is held between the store and the warehouse, and a third could not order at all. A few hours offline in the morning can also push orders past the day's carrier collection, the scheduled time the carrier picks up parcels from the warehouse. Delivery dates promised at checkout can then slip by a day while the warehouse is running normally.

Peak season raises the cost of a precaution

An alert can arrive at any time, and the cost of a few hours offline rises with order volume. On Black Friday 2025, shipments across the nShift platform ran at more than twice the level of an ordinary Friday in early November. On the Saturday of Black Week, the week around Black Friday, they ran at four times an ordinary Saturday. An afternoon offline during Black Week leaves a much larger backlog than the same afternoon in October, and each held order can prompt a question for customer service.

Stores still on PHP 8.2 need an upgrade plan that fits around the peak code freeze, the weeks before Black Friday when many retailers stop releasing changes to their website.

What to confirm with your IT team and hosting partners before peak

Within a day of the alert, our customers were writing to ask whether any nShift systems they use were exposed, including software installed on their own servers. Put the same question to every supplier that handles your orders. Here is what I would confirm with your own IT team and hosting partners before peak season:

• Has PHP itself been updated, and to which version? Ask your host or developer for the version number on each server that runs your store.
• If the update was delayed, has anyone checked for signs of compromise? The NCSC advises assessing systems for evidence of compromise, including backdoors an attacker may have installed. An update closes the hole, and a separate check shows whether someone used it first.
• What runs on your store's server? List every plugin and integration, including shipping, payment and ERP connectors, with the name of whoever keeps each one updated.
• Can each supplier show independent proof of its security? Ask for a current certificate, such as ISO/IEC 27001 (the international standard for information security management), and agree how the supplier will report what it has checked when the next alert arrives.
• Who can decide to take the store offline, and who hears about it? The warehouse, customer service and your shipping provider should be told at the same time as IT.
• What can customer service say? Prepare messages for three situations: orders not yet dispatched, parcels already with the carrier, and customers who could not order at all.

Plan the restart before you need it

Recovery is complete when the order records and the shipment records match again, which can be some time after the store comes back online. I would add one step to every retailer's incident plan: before switching the order flow back on, match the orders taken before and during the interruption against the shipments already created. Restarting without that check can send the same orders to shipping twice, or skip some entirely. If the team created shipments by hand while the store was down, include those in the same check.

Then work through the backlog by promised delivery date, so the orders closest to their promise leave first. Tell affected customers when dispatch resumes, with dates taken from the reconciled records.

The NCSC's guidance on response and recovery planning recommends exercising plans against realistic scenarios, including incidents that involve suppliers. Take one real order and walk it through a simulated outage that starts an hour before carrier collection, with the people responsible for orders, the warehouse, IT, customer service and returns in the room, and write down every missing contact and every decision nobody has the authority to make.

How we approach security at nShift

An order reaches its customer through a chain of suppliers: the store platform, payment, shipping software, the carrier. An attack, or a precautionary shutdown, at any link in that chain can interrupt the retailer's orders, so each supplier's security is part of the delivery promise. I want nShift to be a logistics partner our customers can trust, and one whose security they can check independently.

DNV, an accredited certification body, certifies our information security management to ISO/IEC 27001:2022, including the applicable controls from ISO/IEC 27017:2021, the companion standard for cloud services. An independent auditor checks our security and privacy measures every year. The standard's catalog of security controls, known as Annex A, lists 93 of them, from access management and supplier security to incident response and business continuity. We also run external penetration tests on our cloud systems and check the security of our own suppliers. Customers can ask us for the ISO certificate, and our status page shows live status for our checkout, shipping, tracking and returns software and our carrier connections.

We sit in the middle of many of our customers' integrations, between their stores, ERP and warehouse systems and more than 1,000 carriers. We secure and monitor our cloud services. Some connections to nShift, such as our WooCommerce plugin, are installed on the retailer's own server and run on that server's PHP. That server is managed by the retailer or its hosting partner, so the PHP update there is theirs to apply. Our help center explains how each type of integration connects.

When the PHP fixes were released on October 21, we reviewed our services and integrations the same day. Our own platforms use PHP only to a limited extent. A small number of third-party integration services were affected; we restricted access to them and switched off a few unused services until they were patched.

The number of known security holes is rising fast, and I expect that to continue as AI tools make them easier to find. The US National Vulnerability Database published nearly 12,700 newly disclosed security flaws, across all severity levels, in August 2026, more than three times the 3,700 it published in August 2025. More disclosures can shorten the time between a flaw becoming public and attackers using it. Retailers that have already agreed who patches each server and who can take a store offline can act on the next alert faster, because the decisions are already made.

Our article on supply chain resilience in 2026 looks at the trade-policy side of the same planning question.