Jessica Entwistle
October 28 2026
Today's stories reflect a consistent theme running through the UK threat landscape: the gap between assumed protection and actual protection. Whether it is a sanitiser that fails to catch malicious SVG content, a skimming campaign that evades standard detection tools, a widely used networking product patched under pressure, or a certification scheme that has quietly raised its requirements, the common thread is that controls which organisations believe are working may need a closer look. For UK businesses, this is a timely reminder that security assurance is not a one-time exercise.
Security researchers at PortSwigger have published new findings showing that six out of eight widely used SVG sanitiser libraries can be bypassed in ways that allow JavaScript execution, even when the response body appears to be entirely harmless XML. The research, published on 27 October 2026, demonstrates how a response header alone can be used to trigger script execution in Firefox, effectively circumventing the sanitisation step that many web applications rely on to safely handle user-uploaded SVG files. The researchers tested eight popular sanitiser tools and found meaningful bypass routes in the majority of them.
SVG file uploads are common across a wide range of web applications, from content management systems and document platforms to e-commerce sites and collaboration tools. Many development teams implement SVG sanitisation as a trusted control against cross-site scripting (XSS), and the assumption that a sanitiser is doing its job reliably can create a false sense of security. If the sanitiser can be bypassed, an attacker may be able to inject and execute malicious scripts in the context of a user's browser session, potentially leading to session hijacking, credential theft or further exploitation of authenticated users.
For UK businesses running web applications that accept SVG uploads, this research is a prompt to verify which sanitiser library is in use and whether it is among those found to be vulnerable. Development and security teams should review the PortSwigger findings directly, check for available patches or updated versions of affected libraries, and consider whether additional server-side controls or content security policies are in place to provide defence in depth beyond the sanitiser layer alone.
Source: PortSwigger Research
Infosecurity Magazine reports that attackers have infected 953 online stores with a JavaScript loader designed to evade standard security scanners, in a campaign that has been running since July 2025. The malicious code acts as a skimmer, capturing payment card data and other sensitive customer information entered at checkout. The loader's design specifically targets detection avoidance, meaning that routine automated scanning tools used by many e-commerce operators may not flag the presence of the code. The scale of the campaign and its longevity suggest a well-organised operation targeting merchants across multiple platforms.
For UK retailers and any organisation operating an e-commerce presence, this campaign highlights a persistent and evolving risk in the online payments environment. Magecart-style skimming attacks have been a known threat for several years, but the use of scanner-evading loaders raises the bar for detection. Many smaller and mid-sized retailers rely heavily on automated scanning as their primary means of detecting web-based threats, and a loader specifically engineered to bypass those tools can remain undetected for extended periods. The reputational and regulatory consequences of a payment data breach, including obligations under UK GDPR and PCI DSS, make this a risk that warrants active attention rather than passive monitoring.
For UK organisations running online stores, this is a prompt to review whether your current scanning tools are capable of detecting obfuscated or loader-based skimming code, and to consider whether manual code review or specialist web application testing forms part of your security programme. Reviewing third-party scripts loaded at checkout, implementing subresource integrity checks, and ensuring your payment pages are regularly assessed by a qualified security tester are all practical steps worth prioritising.
Source: Infosecurity Magazine
SecurityWeek reported on 27 October 2026 that Tailscale is preparing patches for a set of vulnerabilities in Tailscale SSH, disclosed publicly under the name 'Tailworm' before any fixes had been released. The details of the flaws were made available over the weekend ahead of coordinated disclosure, leaving a window during which organisations using Tailscale SSH were exposed without an available remedy. Tailscale is a widely used zero-trust networking tool that allows organisations to create secure private networks across distributed infrastructure, and its SSH functionality is used by many teams to manage remote access to servers and cloud environments.
Tailscale has grown significantly in adoption among UK businesses, particularly those operating hybrid or cloud-first infrastructure, remote development teams, and managed service environments. The Tailworm disclosure is a reminder that even tools positioned as security-enhancing infrastructure can carry vulnerabilities, and that the timing of public disclosure relative to patch availability matters enormously. Organisations that rely on Tailscale SSH for privileged access to production systems should treat this as a prompt to verify their current version, monitor Tailscale's security advisories closely, and assess whether compensating controls are in place while patches are finalised and deployed.
For UK organisations using Tailscale, particularly those using the SSH feature for administrative access, the immediate action is to check Tailscale's official security advisory pages for patch availability and apply updates as soon as they are released. More broadly, this is a useful moment to review whether privileged access paths through networking tools like Tailscale are included in your vulnerability management and patching processes, and whether those access routes are subject to regular security review.
Source: SecurityWeek
GRC Solutions has published a detailed overview of the latest updates to the UK's Cyber Essentials scheme, covering the changes that have been introduced and their practical implications for organisations seeking or renewing certification. The Cyber Essentials scheme, backed by the NCSC and the UK government, sets a baseline of technical controls that organisations are expected to have in place to protect against common cyber threats. The updated requirements reflect the evolving technology landscape, including changes relating to cloud services, home working environments, multi-factor authentication, and the scope of devices that must be included in an assessment.
Cyber Essentials certification is increasingly a commercial and contractual requirement for UK organisations, particularly those working with central government, the Ministry of Defence supply chain, and a growing number of private sector clients who use it as a baseline assurance measure. The scheme updates mean that organisations approaching renewal or first-time certification need to understand what has changed, as controls that previously met the standard may no longer be sufficient. Areas such as MFA requirements, the treatment of cloud-hosted services, and the scope of bring-your-own-device policies have all seen meaningful changes that could affect how organisations prepare for assessment.
For UK organisations holding or planning to obtain Cyber Essentials certification, this is a prompt to review the updated requirements before your next assessment window. IT and security teams should compare current controls against the revised standard, paying particular attention to MFA coverage, cloud service scoping, and device management policies. Organisations that are part of government or defence supply chains should also check whether their contracts specify a particular version of the standard or an updated compliance deadline.
Source: GRC Solutions
What today's stories share is a reminder that security controls need to be verified, not just assumed. A sanitiser that is deployed but bypassable, a scanner that misses obfuscated code, a networking tool that carries unpatched vulnerabilities, and a certification standard that has moved on while an organisation's controls have not — each of these represents a gap between what an organisation believes is in place and what is actually working. Mature security programmes build in regular verification: through penetration testing, code review, configuration audits, and keeping pace with changes to the standards and frameworks they rely on. The organisations that fare best are those that treat their security controls as something to be tested and maintained, not simply installed and forgotten.