PHP Under Active Attack and 953 Online Shops Compromised: What UK Small Businesses Need to Know Now
Two stories landed in the last 24 hours that deserve your attention above everything else in this week’s threat feed. The first: two PHP vulnerabilities confirmed as actively exploited, added to the CISA Known Exploited Vulnerabilities catalogue on the 26th of October 2026. The second: 953 online stores, most running Magento, have been quietly harvesting customer card data since July 2025 using JavaScript specifically engineered to evade security scanners.
Neither story is theoretical. Both have direct, practical implications for UK small businesses. Let’s go through them properly.
The PHP Exploits: What Is Actually Happening
PHP is the server-side scripting language that underpins a significant proportion of the web. WordPress runs on PHP. Magento runs on PHP. Most small business websites and e-commerce platforms run on PHP, often without the business owner knowing or caring about the version number.
On the 26th of October 2026, CISA added two PHP vulnerabilities to its Known Exploited Vulnerabilities catalogue. That catalogue is not a list of theoretical risks or vendor speculation. It is a list of vulnerabilities that CISA has confirmed are being actively exploited in the wild.
CVE-2026-109618 describes an out-of-memory corruption vulnerability in PHP that allows unauthenticated remote code execution. Unauthenticated means an attacker does not need a username, a password, or any prior access to your system. They send a crafted request to your server. If your PHP version is vulnerable, they can execute arbitrary code on that server.
CVE-2026-109619 describes a stale internal request-state vulnerability in PHP, also allowing unauthenticated remote code execution via the same mechanism. Two separate flaws, both confirmed exploited, both in the same software stack.
The CISA required action is unambiguous: apply vendor mitigations in accordance with their instructions, or discontinue use of the product if mitigations are unavailable.
Translated into plain English: update PHP now, or take your site offline until you can.
Why This Matters More for Small Businesses Than Large Ones
Large organisations typically have dedicated patch management processes. They know what software version is running on which server. They have someone whose job it is to respond when CISA publishes a KEV entry.
Small businesses typically do not have any of that. They have a website built by a developer three years ago, hosted somewhere, running a PHP version that nobody has checked since the site went live. The hosting company may or may not be applying security updates automatically. The MSP, if there is one, may or may not be monitoring this.
This is not a hypothetical failure mode. It is the standard operating condition for a large proportion of UK small business web infrastructure.
If you do not know what PHP version your site runs, you cannot know whether you are vulnerable. And if you cannot know whether you are vulnerable, you cannot take informed action. That information gap is the actual risk.
The Magento Skimming Campaign: 953 Stores, 15 Months, Designed to Hide
The second story comes from Dutch e-commerce security company Sansec, reported by The Hacker News on the 26th of October 2026. An unknown threat actor has infected 953 online stores, the majority running Magento, as part of a campaign that has been active since July 2025.
The attack methodology is worth understanding in detail, because it illustrates precisely why standard security scanning provides false assurance.
The malicious code is embedded as JavaScript loaders hidden inside Magento CMS content blocks. CMS blocks are the editable content sections that site administrators use to manage page content. They are trusted. They render without question. They are not typically subject to the same scrutiny as core application files.
The JavaScript loader then pulls in a card skimmer: code that captures payment details entered by customers and transmits them to an attacker-controlled server. The customer sees a normal checkout process. The store owner sees normal transactions. Everyone is unaware.
The evasion technique is the part that should concern anyone who relies on security scanning as a comfort measure. The malicious JavaScript includes bot-filtering logic. When a security scanner visits the page, the code detects it and does not load the skimmer. The scanner reports the page as clean. The skimmer is not there when the scanner looks. It is only there when a real customer visits.
This is not a novel technique, but it is a well-executed one. The campaign has been running for fifteen months. 953 stores. The number of customers whose card data has been exfiltrated during that period is not stated in the available reporting, but the arithmetic is not encouraging.
The connection to the PHP KEV entries is direct: CVE-2026-109618 and CVE-2026-109619 are both referenced in the Sansec reporting as part of the attack chain. A vulnerable PHP installation is the entry point. The Magento CMS block modification is the persistence mechanism.
What Your MSP or Web Host Should Be Doing Right Now
If you use a managed service provider or a managed hosting company for your website or e-commerce platform, this is a reasonable set of questions to put to them today:
First, what PHP version is currently running on my site? The answer should be immediate and specific. PHP 8.2, 8.3, 8.4, or 8.5 are the current maintained branches. Earlier versions are end-of-life and should not be running production systems.
Second, have you applied the PHP security updates released in response to CVE-2026-109618 and CVE-2026-109619? The answer should be yes, or should include a specific timeline for when the update will be applied.
Third, if I run Magento, have you audited my CMS content blocks for unauthorised JavaScript? This is a more involved question. If they have not done this, ask them to.
If the answer to any of these questions is evasive, vague, or reveals that nobody has thought about this, that is useful information. It tells you that your current provider does not have an adequate security posture for the infrastructure they are managing on your behalf.
How to Turn This Into a Competitive Advantage
If you run an e-commerce business, the Magento skimming campaign creates an opportunity that most of your competitors will not act on.
You can commission a formal audit of your Magento installation, document it, and communicate it to your customers. Not in marketing language. In specific, verifiable terms: the date the audit was conducted, what was checked, and the outcome.
Customers increasingly understand that their payment data can be stolen without any visible sign of a breach. A business that can demonstrate it has actively checked its systems, and found them clean, is a business that has earned a form of trust that a competitor running an unchecked installation cannot claim.
For businesses in sectors with procurement requirements, this kind of documented assurance also feeds directly into supplier security assessments. A customer asking about your security posture now has something concrete to point to.
Making the Business Case
If you need to justify the cost of a PHP update or a Magento security audit to a director or board, here are three arguments that stand up to scrutiny.
The liability argument. If customer payment data is exfiltrated via your checkout because you were running a known-vulnerable PHP version with a publicly confirmed exploit, the ICO’s assessment of your GDPR obligations will not be sympathetic. A vulnerability on the CISA KEV catalogue is, by definition, a known risk. Choosing not to mitigate a known risk is a materially different position from being unaware of a risk.
The operational argument. Unauthenticated remote code execution means an attacker can take complete control of your web server. That is not a data breach scenario. That is a business continuity scenario: your website goes down, your e-commerce revenue stops, and the recovery process takes days to weeks, not hours.
The cost argument. A PHP update applied proactively takes a competent developer or hosting administrator less than an hour. A Magento CMS audit takes a few hours. The cost of incident response after a compromise: significantly higher, and that is before you factor in ICO notification obligations, customer communication, and reputational impact.
What to Do Next
1. Establish your PHP version today. If you have a hosting control panel (cPanel, Plesk, or similar), this is usually visible under PHP settings. If you do not have access, email your web host or MSP and ask directly. You need a specific version number, not a reassurance.
2. Update PHP to a current patched release. PHP 8.2, 8.3, and 8.4 are the currently maintained branches. If your site runs PHP 7.x or earlier, you have a more significant problem: those versions are end-of-life and no longer receiving security updates. A migration to a supported version is not optional; it is overdue.
3. Audit your Magento CMS blocks if you run Magento. Ask your developer or Magento administrator to review every CMS block for unexpected JavaScript, particularly any code that makes external HTTP requests. If you do not have an internal developer, a specialist Magento security review is the appropriate route.
4. Do not rely on scanner results as reassurance. The Sansec research confirms that the skimming JavaScript in this campaign is designed to hide from automated scanners. A clean scan report does not mean your site is clean. Manual review of CMS content is required.
5. Check your hosting provider’s auto-update policy. Some managed hosting providers apply PHP security updates automatically. Others require you to opt in or initiate updates manually. Knowing which applies to your environment is essential information, not an optional detail.
Before you go: if you found this useful, follow the show wherever you listen and leave a rating or review. It genuinely helps more small business owners find content that is actually trying to help them rather than sell them something. Drop a comment with your thoughts, or share it with someone who runs an online shop and probably has not checked their PHP version since the site went live.