Threat Analysis: PHP2Shell RCE Exploited in the Wild, North Korea Linked, What UK SMBs Need to Know
This is your Daily Threat Analysis for the 26th of October 2026.
Today’s briefing covers three items that genuinely matter to UK small businesses: a pair of critical PHP vulnerabilities that are now being actively exploited in the wild by a campaign linked to North Korea’s Lazarus Group; a persistent Magento skimming campaign that has now compromised 953 online stores; and a UK-specific data breach postscript from UK Biobank that illustrates, once again, how long the gap between incident and disclosure can stretch.
Lead item first.
PHP2Shell: CVE-2026-109618 and CVE-2026-109619, Actively Exploited, Nation-State Linked
On the 26th of October 2026, BleepingComputer confirmed that two critical unauthenticated remote code execution vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, collectively tracked as PHP2Shell, are now being successfully exploited in the wild.
That confirmation matters. The CYFIRMA advisory tracking a suspected North Korean campaign had already flagged these vulnerabilities as the target of active planning by a threat actor linked with moderate confidence to Lazarus Group, the June 2026 Minjun campaign, in their tracking. The shift from planning to confirmed exploitation is significant. This is no longer a vulnerability management question. It is an incident response question for anyone still running unpatched PHP.
The Register’s coverage frames this with some useful context: roughly three quarters of the web runs PHP. That figure is not precise to the decimal, but it is directionally accurate and it is the number you need to hold in your head when thinking about blast radius. WordPress, WooCommerce, Magento, most budget CMSes, most shared hosting environments, all PHP. If your business has a website that was not built this year on a modern stack, the probability that it is running PHP somewhere in the chain is high.
What the Advisory Does Not Say
The CYFIRMA advisory attributes this to a Korean-speaking threat actor and links it with moderate confidence to Lazarus Group. What the advisory does not spell out in terms that will land with a small business owner is this: Lazarus Group is North Korea’s primary financially-motivated threat actor. They steal money. They have targeted financial institutions, professional services firms, manufacturing, logistics, and government agencies. The targeting list is not confined to large enterprises, it follows money and accessible infrastructure.
The TTPs described in the campaign involve web shell deployment following unauthenticated RCE. Once a web shell is in place, the attacker has persistent access to that server. On a shared hosting environment, that access may extend across multiple tenants. If your website sits on shared hosting and your provider has not patched, you are exposed. More to the point, you have no visibility into whether they have acted, because most budget hosting providers do not send security patch notifications to customers.
What UK SMBs Should Do
Three actions, in order of priority:
1. Contact your hosting provider today. Ask them directly which version of PHP your environment is running and whether CVE-2026-109618 and CVE-2026-109619 have been patched. Get a written response. If they cannot confirm patching within 24 hours, treat the environment as potentially compromised and escalate accordingly.
2. Check your own PHP version if you have access. PHP 8.1 reached end of life in December 2024. PHP 8.2 reaches end of life in December 2025. If your environment is running either of those versions, you are likely outside the patch window for these vulnerabilities regardless of what your host says. PHP 8.3 is the current supported release. If you cannot upgrade immediately, speak to your developer or IT provider about a migration path.
3. Review recent access logs for anomalies. Look for unusual POST requests, unexpected file creation in public directories, and access from unfamiliar IP ranges, particularly in the period since the 1st of June 2026 when the Minjun campaign is assessed to have been active. If you do not have access to your server logs, ask your host. If they cannot provide them, that is a problem in its own right.
The NCSC has published guidance on vulnerability management that covers exactly this kind of scenario. The fact that thousands of UK websites are still running end-of-life PHP in 2026 tells you everything about how seriously that guidance has been absorbed.
Magento Skimming Campaign: 953 Stores, Still Running
While PHP2Shell is the headline today, the Magento CMS block loader campaign tracked by Sansec deserves attention from anyone running an e-commerce operation.
Since July 2025, a criminal group has compromised 953 online stores, predominantly Magento installations, by injecting malicious JavaScript loaders into CMS blocks. The latest infrastructure domain, deepveindrilling.com, was registered in October 2026. The campaign employs browser fingerprinting to detect and evade security scanners, and stores malicious code in visitors’ localStorage for persistence across sessions.
The CVEs associated with this campaign, CVE-2025-54236, CVE-2026-48356, and CVE-2026-75650, span the period from 2025 to 2026, which tells you this campaign has been iterating and persisting for well over a year.
The SMB Angle
Magento is disproportionately used by small and mid-size retailers. It is not a platform that tends to receive the same administrative attention as, say, a Shopify storefront, because it sits on infrastructure that the business nominally controls. That is both its strength and its risk surface.
A CMS block injection attack is particularly insidious because it targets the store’s own content management interface rather than exploiting a vulnerability in the platform code directly. The malicious loader is placed inside a legitimate-looking content block. Standard automated scanning tools will not detect it if the attacker is using browser fingerprinting to show clean content to scanner IP ranges.
If you run a Magento store, or if you use an agency that runs one on your behalf:
- Audit your CMS blocks. Look for any blocks containing script tags or external resource loads that you did not authorise.
- Check for the deepveindrilling.com domain in any content, and review any recently modified CMS blocks regardless of domain.
- Review the three associated CVEs with your developer or platform administrator and confirm patching status.
- Consider a manual review by someone who knows what legitimate Magento CMS content looks like in your specific installation, automated tools are not sufficient here.
Nine hundred and fifty-three stores is not a large number by global standards. It is, however, a large enough number that the probability of one of them being a supplier, a customer, or a business you have transacted with recently is non-trivial.
UK Biobank: A Reminder That Disclosure Timelines Are Not Incident Timelines
The UK Biobank story today is quieter but instructive. The Register reports that the organisation, a health research charity holding data on approximately 500,000 people, is preparing to come back online months after an incident in which someone attempted to sell that data on Alibaba. The charity has confirmed a range of security improvements and is awaiting government clearance to resume operations.
There is no direct action for UK SMBs from this specific incident. What it illustrates, however, is worth naming: the gap between when a breach occurs, when it is detected, when it is disclosed, and when the affected organisation returns to normal operations can be measured in months. UK Biobank is a well-resourced research organisation with government oversight. The timeline for a small business without a dedicated security function would not be shorter, it would be longer.
The ICO’s 72-hour notification requirement for reportable breaches under UK GDPR applies to the detection of a breach, not its occurrence. If you do not have monitoring in place to detect a breach promptly, the clock does not start until you find out. In practice, that means smaller organisations often discover breaches through third parties, a customer complaint, a dark web alert, a supplier notification, rather than through their own detection capability.
If your business holds personal data and you do not have any mechanism for detecting unauthorised access to it, that is the gap to address. It does not require enterprise tooling. It requires access logging, anomaly alerting, and someone who looks at the output.
Sources
If this briefing is useful to you, follow Threat Analysis wherever you listen so tomorrow’s edition lands automatically. And if you know someone who manages a website, runs a Magento store, or has been putting off that PHP upgrade conversation with their developer, pass this on. Today is a reasonable day to have that conversation.