Your website is a business system, not a plugin collection

When an ecommerce website goes down, the technical problem is only the beginning.

Every minute offline can mean abandoned carts, missed enquiries and staff unable to process the next order. A serious compromise can expose customer information, interrupt fulfilment and force a business to spend days investigating, restoring and explaining what happened. Even when nothing is breached, emergency updates, plugin conflicts and unplanned testing all carry a cost.

That cost rarely appears in the price of a website build. It arrives later as maintenance, downtime and lost trust.

This is why platform choice matters to me. A website is not just a marketing asset. For many businesses it is part of the sales floor, the customer service desk and the operating system. The more extensions it depends on, the more suppliers, update cycles and failure points the business inherits.

The disclosure of CVE-2026-109618 and CVE-2026-109619 is a timely example of that wider risk. These are serious vulnerabilities, but an important distinction is being lost in some of the headlines:

These are PHP vulnerabilities, not vulnerabilities in WordPress core.

WordPress is relevant because it runs on PHP. So do many other applications and products. A vulnerable PHP installation can place the applications above it at risk, even when the application itself did not introduce the flaw.

What the two vulnerabilities do

The PHP project published emergency security updates on 21 October 2026 for two critical remote code execution vulnerabilities. Both were scored 9.2 under CVSS v4.0 in the official advisories.

CVE-2026-109618: remote code execution through out-of-memory corruption

CVE-2026-109618 involves PHP’s handling of out-of-memory conditions. In affected versions, a failed memory allocation can leave request data in an invalid or partly initialised state. Request shutdown may then process that invalid state.

The PHP advisory says multiple strategies can trigger the condition and lead to remote code execution. A working unauthenticated exploit was demonstrated against Apache mod_php before application-specific code runs. Other ways of running PHP may also be susceptible, although the route and reliability can differ.

CVE-2026-109619: remote code execution through stale global state

CVE-2026-109619 concerns PHP state retained by a worker while pointing to memory owned by an earlier request. If that state is not reset correctly, a later request can access memory after it has been freed.

The result is another use-after-free condition that can be developed into remote code execution. In business language: an unauthenticated attacker may be able to run malicious code under the website worker’s account.

What businesses should do now

The complete fix is to update PHP. The PHP project lists these patched releases:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

PHP 8.1 and older are outside regular upstream security support. For this incident, PHP has also published minimal source backports for PHP 7.4, 8.0 and 8.1 to help vendors and people building from source. This does not restore ongoing support. Some operating-system distributors and long-term-support vendors also provide backported fixes. Confirm your actual package with your host or vendor, or upgrade to a supported branch.

The official guidance is direct: identify internet-facing PHP systems, update them immediately and restart the relevant PHP workers. ENISA and its European partners also recommend prioritising public-facing systems and isolating exposed applications if they cannot be fixed promptly.

For a WordPress site, ask the person responsible for hosting to confirm:

1. the PHP version actually serving the site;
2. whether the vendor’s package contains the fix;
3. whether all PHP workers were restarted after updating;
4. whether logs have been reviewed for unexpected processes, files, accounts or outbound connections; and
5. whether a tested backup and recovery path exists.

A green tick beside the WordPress version is not proof that the PHP runtime beneath it is safe.

The bigger WordPress problem is the operating model

WordPress itself can be run securely. It has a capable security team, a mature update system and an enormous community. Blaming WordPress core for every compromised WordPress site would be inaccurate.

My concern is the operating model that often grows around it.

A typical business site may combine WordPress core, a theme, a page builder, an ecommerce package, payment integrations, form tools, SEO tools, caching, security software and a handful of small plugins added to solve one-off problems. Each component brings another developer, release cycle, support policy and compatibility question.

One dodgy, abandoned or simply slow-to-patch extension can become the weakest part of the entire site.

The Patchstack State of WordPress Security in 2026 reported 11,334 new vulnerabilities in the WordPress ecosystem during 2025, a 42% increase on the prior year. It attributed 91% of newly reported vulnerabilities to plugins and 9% to themes, while reporting only six low-priority issues in WordPress core. Patchstack is a commercial WordPress security vendor, so its figures should be read as vendor research, but the distribution is the important part: the large attack surface is overwhelmingly in the surrounding ecosystem, not the core product.

WordPress’s own security guidance reinforces the maintenance burden. It says keeping core, plugins and themes updated is the most important security action, recommends choosing components that are actively maintained, and warns against obtaining plugins and themes from untrusted sources. Its plugin documentation also recommends taking a current backup before updating because updates can cause problems.

That is sensible advice. It is also a description of an ongoing operational job.

Why I do not choose WordPress for the platforms I build

I do not avoid WordPress because it is impossible to secure. I avoid it because I do not want a client’s critical sales channel to depend on a loose collection of extensions from unrelated suppliers.

I have seen the pattern too often:

• a plugin is installed for one small feature and becomes permanent infrastructure;
• an extension stops receiving updates, but removing it would break part of the site;
• an urgent security update clashes with a theme or another plugin;
• automatic updates reduce the exposure window but introduce a new need for regression testing;
• nobody is quite sure whether the host, developer or business owner is responsible for the layer that needs attention; and
• the cheapest build becomes an expensive platform to keep stable.

WordPress is flexible partly because almost anything can be added to it. That same flexibility can turn a business website into a dependency puzzle.

For a brochure site with disciplined maintenance, a carefully selected theme and very few trusted plugins, WordPress can be a reasonable choice. For a business where the website carries live stock, sales, fulfilment and customer operations, I prefer a platform with a smaller, controlled surface and clear ownership.

Why I built Jamtable differently

Jamtable is not WordPress with a commerce plugin attached. It is a commerce platform designed as one system: catalogue, stock, pricing, storefront, orders, fulfilment and customer records working from the same data model.

That does not make any platform magically immune to vulnerabilities. No responsible developer should make that promise. It does change the ownership model.

Instead of relying on a chain of unrelated plugin authors, the platform and its integrations are selected, built and maintained as one controlled product. Features are modules within the platform rather than a marketplace of extensions installed because somebody needed a quick fix on Friday afternoon. The storefront is built on Astro and runs at the edge, while the operational services sit behind a single managed API.

The goal is not merely to remove WordPress. It is to reduce the number of moving parts a retailer must trust, keep sales and stock connected, and make responsibility clear when something needs attention.

Security is a business decision

CVE-2026-109618 and CVE-2026-109619 need urgent technical action, but their lesson is broader than PHP.

Every platform depends on software. Every software platform will eventually need a security update. The business question is whether you know what you depend on, who owns each layer, how quickly it can be fixed and what happens to sales while the work is being done.

If your website has become a stack of plugins that nobody wants to touch, this is a good moment to review it. Confirm the PHP patch first. Then look at the wider platform: its extensions, ownership, recovery plan and real cost of maintenance. Our cyber security services can help you review those risks, while our ecommerce and retail work focuses on keeping sales, stock and operations connected.

If you want to replace that stack with a commerce platform built around connected operations, email info@digitaldiscovery.group and ask about switching to Jamtable. You can also contact Digital Discovery Group to discuss your current website.

---

Sources and further reading

• PHP security advisory: Critical remote code execution vulnerabilities, update now
• PHP advisory for CVE-2026-109618: RCE via OOM corruption
• PHP advisory for CVE-2026-109619: RCE via stale global state
• ENISA joint statement on critical PHP vulnerabilities
• Australian Signals Directorate ACSC alert: Critical vulnerabilities in PHP
• WordPress security guidance
• WordPress hardening guidance
• WordPress plugin management and update guidance
• WordPress supported versions
• Patchstack: State of WordPress Security in 2026

Security facts and links checked on 22 October 2026. Advice may change as vendors publish further analysis. Businesses should follow current guidance from PHP, their operating-system or hosting vendor, and relevant cyber security authorities.