Threat Analysis: Critical PHP Vulnerabilities and the Wazza M365 Phishing Kit, What UK SMBs Need to Know Today
This is your Daily Threat Analysis for the 21st of October 2026.
Two stories today. One is urgent in the technical sense, patch it now, no exceptions. The other is the kind of threat that does not announce itself, which makes it considerably more dangerous for organisations that have not thought about it.
Story One: Critical PHP Vulnerabilities, CVE-2026-109618 and CVE-2026-109619
The NCSC published an urgent alert today encouraging UK organisations to take immediate action on two critical security vulnerabilities affecting PHP: CVE-2026-109618 and CVE-2026-109619. The SANS Internet Storm Center raised its InfoCon level to Yellow on the same basis, citing a CVSS score of 9.4 and the availability of proof-of-concept exploit code that was circulating before PHP.net’s patch had been formally released.
Let that second point sit for a moment. Proof-of-concept exploits were already public before the patch was out. That is not a situation where you have a comfortable patching window. That is a situation where you act today.
The NCSC advisory does not spell out what percentage of UK business websites run PHP, because it does not need to. The answer is: most of them. WordPress powers a significant proportion of UK small business websites. WooCommerce runs on WordPress. Magento, which handles a substantial share of UK e-commerce, is PHP-based. If your web developer built you a custom application in the last decade, there is a reasonable probability it runs PHP. Laravel, Symfony, Drupal, all PHP. The language is not glamorous, but it is everywhere.
What the advisory is not telling you explicitly: the risk here is not limited to your web server being defaced. Depending on how the vulnerabilities are exploited, successful attacks could lead to remote code execution on your server. That means access to your database. That means customer records, payment data, contact forms feeding into your CRM, and potentially credentials reused elsewhere in your business. The downstream consequences of a compromised web application extend well beyond the website itself.
What to do
First, find out what PHP version your website is running. If you do not know how to check this yourself, call your web hosting provider or the agency that built your site. Ask them directly: which PHP version is running, has it been patched for CVE-2026-109618 and CVE-2026-109619, and when will the update be applied if not already done. Get a written answer.
Second, if you are running PHP yourself on any internal system, and some SMBs run PHP-based tools internally for project management, invoicing or customer portals, apply the patched release as a priority. Do not wait for your normal patching cycle.
Third, if your web application firewall or hosting provider offers virtual patching or a WAF rule set, check whether rules covering these CVEs have been deployed. That is not a substitute for patching, but it is a meaningful layer of protection while the patch is being applied.
Fourth, check your hosting contract. A surprising number of SMBs are on shared hosting plans where the provider controls PHP versions. If your provider has not updated and cannot give you a timeline, that is a conversation worth having urgently.
The NCSC published guidance on web application security years ago. The fact that PHP vulnerabilities with publicly available exploits are still reaching CVSS 9.4 in 2026 tells you something about the state of the ecosystem, but it does not change what you need to do right now.
Story Two: The Wazza Phishing Kit and the Trust Problem in Microsoft 365
The second story today is less dramatic in its immediate presentation, which is precisely why it deserves attention.
A phishing kit named Wazza has been actively targeting Microsoft 365 accounts since early July 2026. The research from SpiderLabs at LevelBlue documents a multi-stage campaign that is considerably more sophisticated than the average credential-harvesting operation, and its relevance to UK SMBs is direct.
Here is how it works. The campaign starts with a phishing email sent from a previously compromised account, not from an obviously malicious domain, but from a real account belonging to a real business that has already been taken over. The email contains a PDF with business-themed content: invoices, contracts, the kind of document your finance team opens without a second thought.
The PDF does not contain a macro or a malicious attachment. It contains a link. That link routes the victim through a chain of legitimate infrastructure: Google Sites, Cloudflare Workers, and a series of intermediate domains. This routing is deliberate. Most email security tools and web filters maintain lists of known-malicious domains. Google Sites and Cloudflare Workers are not on those lists. The traffic looks legitimate because it is passing through legitimate platforms.
At the end of the chain, the victim is presented with a device code phishing page targeting their Microsoft 365 account. Device code authentication is a legitimate Microsoft flow designed for devices that cannot easily display a browser, think printers, certain meeting room hardware. The attacker generates a device code and presents it to the victim. When the victim authenticates using that code, the attacker’s session receives the token. No password is captured; no MFA prompt stops the process, because the victim has already completed MFA as part of the authentication flow they were tricked into completing.
This is the attack that bypasses MFA. Not because MFA has failed, but because the victim was socially engineered into completing an MFA flow that authenticated the attacker’s session.
Cisco Talos published research today on a related pattern: the abuse of legitimate platforms as delivery infrastructure. They documented abuse of more than 25 legitimate platforms over the past year, collaboration tools, file-sharing services, payment systems, exploited precisely because the built-in trust organisations place in those platforms makes malicious traffic harder to detect. Wazza is one manifestation of a broader trend.
The Wizza research adds further context from a different angle. Threat actors compromising Google Cloud Platform environments are using phishing via sponsored search ads to harvest privileged credentials, then creating service accounts with API access and inviting attacker-controlled external accounts. The mechanism, abuse of trusted platforms and legitimate authentication flows, is consistent across all three reports.
What this means for your Microsoft 365 tenancy
Device code authentication flows should not be available to most users in a typical SMB environment. Microsoft allows administrators to restrict this through Conditional Access policies. If your Microsoft 365 environment has not been configured to block device code flows for standard users, it should be.
If you manage your Microsoft 365 through an IT provider or MSP, ask them directly whether device code authentication is restricted in your tenant. Ask them to show you the Conditional Access policy. If they cannot, that is a problem.
Beyond the specific Wazza mechanism, the campaign illustrates something worth understanding at an organisational level: your email security tools are filtering on known-bad indicators. A phishing email sent from a compromised legitimate account, linking to Google Sites, routing through Cloudflare Workers, will very likely reach your inbox. The technical controls are not sufficient on their own. Your staff need to understand that PDFs from suppliers can be weaponised, that clicking links in unexpected documents carries risk regardless of who sent the email, and that any authentication prompt that appears after clicking a link in an email should be treated with suspicion.
This is not a pleasant message to deliver. Staff awareness training has a poor reputation in the industry, some of it deserved. But the NCSC published guidance on this years ago and the campaigns have not stopped. At minimum, your finance team and anyone with admin access to your Microsoft 365 tenancy should understand what device code phishing looks like and what to do if they encounter an unexpected authentication prompt.
One More Item: AOMEI Backupper Supply Chain Compromise
A brief note on something that deserves attention if you run AOMEI Backupper as part of your backup infrastructure. Between April and July 2026, attackers compromised AOMEI Technology’s update and notification infrastructure during three separate windows, the longest lasting ten minutes. During those windows, they modified download instructions to deliver a malicious archive containing malware to users who were updating the software.
AOMEI Backupper claims over 100 million users worldwide. The software is commonly used by smaller businesses precisely because it is affordable and straightforward. If you or your IT provider installed or updated AOMEI Backupper between April and July 2026, this warrants a conversation about whether your endpoints were affected.
Supply chain attacks of this kind are not new. The mechanism, compromising update infrastructure to deliver malicious payloads to a trusted software’s user base, has been documented repeatedly. The NCSC published guidance on software supply chain security. The fact that a backup tool used by millions was successfully compromised through its own update mechanism is a useful reminder that the software you trust to protect your data can itself be a vector.
Summary: Three Actions Before End of Day
-
PHP patch status: Contact your web host or IT provider. Ask which PHP version your site runs and confirm it has been patched for CVE-2026-109618 and CVE-2026-109619. Get a written confirmation.
-
Microsoft 365 Conditional Access: Ask your IT provider whether device code authentication flows are restricted in your M365 tenant. If they are not, request that they be blocked for standard users.
-
AOMEI Backupper: If you run this software and updated it between April and July 2026, flag it for review.
None of these require significant budget. All three require someone to make a phone call or send an email today rather than tomorrow.
If today’s Threat Analysis is useful to you, follow the show wherever you listen so tomorrow’s briefing lands automatically. And if you know someone who should be reading this, a fellow business owner, an office manager who handles the IT, a board member who keeps asking whether the company is covered, pass it on. The people who need this information most are often the ones who do not know to look for it.