Threat Analysis: PHP2Shell KEV Confirmation and Microsoft Teams Social Engineering, What UK SMBs Need to Know
This is your Daily Threat Analysis for the 27th of October 2026.
Two threats are competing for your attention today. I am going to give you both, in the order of confirmed severity. The first is CISA-confirmed active exploitation of a PHP remote code execution campaign linked, with moderate confidence, to North Korea. The second is a detailed analysis of Microsoft Teams external chat abuse that has now been documented across more than 400 incidents. Neither of these is new in concept. Both are active right now.
Story One: PHP2Shell, CISA Adds CVE-2026-109618 and CVE-2026-109619 to KEV Catalogue
CISA has added two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalogue and ordered federal agencies to patch by Thursday. That deadline is for US federal bodies. There is no equivalent mandatory patch deadline for UK organisations. Draw your own conclusions about what that means in practice.
What CISA’s addition tells you is that exploitation is confirmed and active. What it does not tell you, and what matters for UK context, is that the campaign behind these vulnerabilities has been linked with moderate confidence to North Korea’s Lazarus Group, tracked here as the June 2026 Minjun campaign. The research from CYFIRMA identifies the targeting priorities as government agencies, financial institutions, manufacturing, logistics and transportation.
That list should get the attention of any UK SMB working in professional services, financial services, or manufacturing. Not because you are the primary target, you are almost certainly not, but because Lazarus Group campaigns that begin with government and financial sector targets have a documented history of pivoting through supply chains. If you are an accountancy practice with a client in financial services, a logistics subcontractor, or a manufacturer supplying into a government contract, you are a potential lateral move.
What the CVEs Actually Do
CVE-2026-109618 and CVE-2026-109619 enable unauthenticated remote code execution against PHP infrastructure. The campaign name, PHP2Shell, gives you a reasonably clear picture of the intended outcome: a web shell dropped onto a vulnerable server, giving the attacker persistent, remote command execution without needing credentials.
The attack does not require a user to click anything. It does not require a phishing email to land. It requires a vulnerable PHP installation to be reachable. If your website, e-commerce platform, CRM, or any customer-facing system runs PHP and has not been patched, the attack surface is open.
PHP powers an enormous proportion of the web. WordPress, Drupal, Magento, all PHP. The majority of small business websites in the UK run on one of those three platforms. If your web hosting provider manages updates on your behalf, the right question to ask today is: have CVE-2026-109618 and CVE-2026-109619 been patched on my hosting environment, and when?
If your hosting provider cannot answer that question clearly and quickly, that is useful information in itself.
What to Do
- Contact your hosting provider or managed IT supplier and ask specifically about CVE-2026-109618 and CVE-2026-109619. Get a written confirmation.
- If you manage your own PHP environment, apply vendor patches immediately. CISA’s deadline, even though it applies to US federal agencies, is Thursday. There is no sensible reason to be later than that.
- Review web server logs for unusual POST requests, unexpected file creation in web directories, or outbound connections from web servers to unknown IP addresses. These are indicators of a web shell being deployed or used.
- If you run Magento specifically, note that a separate active campaign, tracked via the domain deepveindrilling.com, has already compromised 953 online stores since July 2025 through CMS block injection. PHP exposure compounds that risk.
Story Two: Microsoft Teams External Chat, 400+ Incidents, One Default Setting
Arctic Wolf’s analysis of more than 400 incidents documents a consistent attack pattern that is worth understanding in some detail, because the mechanics of it are not obvious and the defence is straightforward once you understand what is being exploited.
The attack works like this.
An attacker creates a Microsoft 365 tenant. It costs very little and requires no meaningful verification. They name it something that sounds like an IT department: “IT Support”, “Help Desk”, “Systems Admin”. Because of how Microsoft Teams handles external chat federation, which is enabled by default, users in your organisation can receive messages from this external tenant.
Here is the part that the advisory summary does not emphasise sufficiently: Teams displays these external users with a label indicating they are from outside your organisation. However, the attacker names their tenant with an IT-sounding display name that includes “(Internal)” in the text. Users who are conditioned to look for that word as a trust signal see it and proceed accordingly.
Once initial contact is established, the attack typically escalates in one of two directions. The first is social engineering toward credential disclosure or the execution of a remote access tool, Quick Assist is mentioned explicitly in the research, as are connections to Qakbot and DarkGate malware delivery. The second is direct delivery of malicious files or links through the Teams chat interface itself.
The research also documents a common precursor: email bombing. Before the Teams contact, the target’s inbox is flooded with subscription confirmation emails and spam to overwhelm them and create a sense of urgency. The Teams message then arrives presenting itself as IT support reaching out to help with the email problem. From a social engineering perspective, it is well-constructed.
Why This Works
Most UK SMBs adopted Teams during the pandemic and have not substantially reviewed their configuration since. The default setting allows external organisations to initiate chat with your users. Most IT providers who set up Teams for SMB clients did not change this default, because at the time, cross-organisation collaboration was the point.
The NCSC has published guidance on Microsoft 365 security configuration. The fact that we are still seeing 400-plus incidents built on a default setting that could have been changed at any point tells you how much of that guidance has been acted on.
This is not a zero-day. There is no CVE. There is no emergency patch. The vulnerability is a configuration choice and an absence of staff awareness.
What to Do
Configuration change (takes under ten minutes): In the Microsoft Teams admin centre, navigate to External access settings. You can restrict external chat access to specific trusted domains only, or disable external chat initiation entirely if cross-organisation collaboration is not a business requirement. For most small businesses, the answer is to whitelist specific trusted partners and block everything else.
Staff awareness (the part most advisories skip over): Your staff need to know three things:
- Teams will tell you when someone is external to your organisation. Look for that indicator before responding.
- Your internal IT team or managed service provider will never cold-contact you via Teams from an account you do not recognise.
- If you receive a Teams message from someone claiming to be IT support asking you to run anything, install anything, or hand over credentials, pick up the phone and call the number you already have for your IT provider. Do not respond through Teams.
If your IT provider tells you that changing external federation settings will break your business processes, ask them to document specifically which business processes depend on unsolicited inbound Teams contact from unknown external tenants. In most SMB environments, the answer will be none.
One More Item Worth Noting: The LiteLLM Supply Chain Compromise
I am flagging this briefly because it has direct relevance to any business using AI development tools or LLM-based applications in their workflows.
On the 21st of October 2026, LiteLLM version 1.107.0 was compromised and distributed through PyPI and official container images. The malicious package used Python startup mechanisms to execute credential-stealing payloads automatically, without requiring applications to actively import LiteLLM. An attacker used stolen developer GitHub credentials to redirect the release workflow to a lookalike repository.
The practical implication: if your development team or any software supplier you use deployed LiteLLM between the 21st and the 23rd of October 2026, credentials from that environment should be treated as compromised and rotated immediately. This includes API keys, cloud credentials, and any tokens accessible from the affected environment.
This is supply chain compromise in its cleanest form. The attack did not require your developers to do anything wrong. They installed what appeared to be a legitimate update from a legitimate source. The advisory from Microsoft Security covers the technical detail.
The Thread Connecting Today’s Stories
All three of today’s items, PHP2Shell, Teams social engineering, and the LiteLLM compromise, share a common characteristic. None of them required a sophisticated, targeted attack against a specific victim. All three exploited legitimate infrastructure (PHP servers, Microsoft’s own federation features, PyPI’s distribution system) in ways that are difficult to detect without specific awareness of the technique.
The NCSC’s blog published today discusses information sharing between industry and regulators. The gap between what regulators and researchers know and what reaches the average UK SMB remains the core problem. Today’s briefing is one small attempt to close that gap.
If Threat Analysis is useful to you, follow the show wherever you listen, tomorrow’s briefing will land automatically. And if you know someone in your network who runs a business and should be hearing this, pass it to them directly. The people who most need this information are often the last to find it.