Jessica Entwistle
October 23 2026
This week's threat landscape is a reminder that the most consequential security risks for UK organisations rarely arrive in isolation. Two critical vulnerabilities in widely deployed web infrastructure are already being actively exploited, a major supply chain breach has exposed thousands of businesses to espionage, and a newly documented attack technique is turning organisations' own AI investments against them. Taken together, today's stories reflect a consistent pattern: attackers are moving quickly, targeting commonly used platforms, and increasingly using automation and AI to accelerate their campaigns.
The NCSC has issued guidance urging UK organisations to take immediate action to address two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, collectively referred to as PHP2Shell. Reporting from Krebs on Security and Wired confirms that working exploits for both flaws exist and are already being used in the wild, with Amazon Web Services logging exploitation attempts several days before patches were made available. The vulnerabilities allow attackers to achieve remote code execution, effectively enabling full control over affected servers. Researchers at The Register note that adversaries have invested significant effort in refining these exploits, and broad exploitation is now under way across the internet. PHP underpins an estimated 70 per cent of websites, making the potential scale of impact substantial.
For UK businesses, the risk is direct and immediate. Any organisation running PHP-based web applications, content management systems such as WordPress, Drupal or Joomla, or custom-built platforms on PHP infrastructure should treat this as a priority review. The NCSC's involvement signals that this is not a theoretical risk — exploitation is confirmed and ongoing. Organisations that rely on managed hosting providers or third-party web development agencies should also verify that their providers have applied the relevant patches, as the responsibility for remediation may not sit entirely in-house.
For UK businesses running PHP-based websites or applications, this is a prompt to verify patch status immediately and confirm with any hosting or managed service providers that updates have been applied. Organisations should also review web server logs for signs of unusual activity over the past week, given that exploitation began before patches were publicly available.
Source: NCSC UK
A maximum-severity vulnerability in GitLab has been disclosed, allowing unauthenticated remote code execution across versions spanning more than twelve years of releases, according to reporting by The Register. GitLab has strongly recommended that all users upgrade to a fixed version as soon as possible. The flaw affects both self-hosted GitLab Community Edition and Enterprise Edition installations, meaning organisations that manage their own GitLab instances are directly at risk. GitLab is widely used by development and engineering teams to manage source code repositories, CI/CD pipelines, and software delivery workflows, making a successful exploit particularly consequential — an attacker gaining access to a GitLab instance could potentially access source code, credentials, pipeline secrets, and deployment configurations.
For UK organisations, the concern extends beyond the immediate technical risk. GitLab instances frequently sit at the heart of software development operations, and a compromise could expose intellectual property, customer data embedded in codebases, or credentials that provide onward access to cloud environments and production systems. Organisations that have adopted DevSecOps practices and store secrets or API keys within their GitLab pipelines face a compounded risk if an instance is left unpatched. The breadth of affected versions means that even organisations running relatively recent installations should verify whether they fall within the vulnerable range.
For any organisation running a self-hosted GitLab instance, this is a prompt to check the installed version against the vendor's advisory and apply the available patch without delay. Teams should also audit pipeline secrets, access tokens, and any credentials stored within GitLab repositories as a precautionary measure, regardless of whether a compromise is suspected.
Source: The Register
Microsoft has linked a China-aligned threat actor, tracked as Storm-0940, to a supply chain attack on IT management platform ConnectWise, according to reporting by Dark Reading and TechCrunch. The attackers used an AI-enabled penetration-testing tool to automate and accelerate their campaign, ultimately compromising more than 2,200 customer tenants. ConnectWise is widely used by managed service providers and IT teams to remotely manage client environments, meaning a single breach of the platform created a pathway into thousands of downstream organisations. Microsoft's threat intelligence indicates that the group used AI agents to rapidly identify and exploit vulnerable configurations across the affected tenants, significantly compressing the time between initial access and lateral movement.
This incident is significant for UK organisations in two respects. First, it is a direct illustration of supply chain risk in practice: organisations that had no direct vulnerability themselves were compromised because a shared tool they relied on was breached. Second, it demonstrates how AI is lowering the barrier for sophisticated, large-scale attacks — what might previously have required significant manual effort was automated at scale. Managed service providers operating in the UK, and the businesses that rely on them, should treat this as a prompt to review the security posture of the tools and platforms that sit within their supply chain.
For UK organisations using ConnectWise or similar remote management platforms, this is a prompt to review access logs, audit privileged accounts, and confirm with your managed service provider what steps have been taken in response to this incident. More broadly, it is worth reviewing what third-party tools have privileged access to your environment and whether those relationships are subject to regular security assurance.
Source: Dark Reading
Researchers at Symantec have documented a new attack technique, known as LLMjacking, in which attackers scan for publicly accessible AI models and then use them to plan and execute cyberattacks — with the computing costs billed to the model's owner, according to Help Net Security. Symantec captured the attacker's full instruction set via a honeypot posing as an unprotected AI service over the summer. The technique involves an automated agent that identifies exposed large language models, then uses them as a planning and reconnaissance tool for further intrusions. The financial impact on victims can be significant, as cloud-hosted AI inference carries substantial per-token costs that can accumulate rapidly when an attacker is running extended sessions.
As UK organisations increasingly deploy AI capabilities — whether through cloud APIs, self-hosted models, or third-party integrations — the attack surface associated with those deployments is growing. Many teams building AI-powered applications may not apply the same access controls and monitoring to their AI infrastructure as they would to more traditional systems. An exposed model endpoint is not simply a data risk; it is a launchpad that attackers can use while the legitimate owner absorbs the cost and the reputational consequences. This is an emerging area of risk that security and development teams should be factoring into their AI deployment practices now, before it becomes a more widespread problem.
For UK organisations running or integrating AI models, this is a prompt to review whether any model endpoints are publicly accessible without authentication, and to ensure that usage monitoring and spend alerts are in place. Development and security teams should work together to apply the same access control principles to AI infrastructure that they would apply to any other sensitive system.
Source: Help Net Security
Today's stories share a common thread: the organisations best placed to respond to these developments are those that already have clear ownership of their assets, established patching processes, and regular visibility into what third-party tools have access to their environments. None of these are complex capabilities — they are the fundamentals of good security practice, applied consistently. The emergence of AI as both a target and a tool for attackers is a genuine shift in the threat landscape, but the defensive response remains grounded in the same principles: know what you have, control who can access it, and monitor for the unexpected. Organisations that invest in those habits now will be far better positioned to absorb new threats as they emerge, without needing to respond from a standing start.