Jessica Entwistle
August 11 2026
Today's brief highlights the operational reality of supply chain risk across multiple layers. UK manufacturers are reporting significant attack rates while many lack response plans, a WordPress supply chain compromise shows how attackers are bypassing traditional code review processes, widening attacks on water utilities demonstrate the vulnerability of internet-exposed industrial systems, and a patched flaw in Atlassian's AI assistant shows how new technology introduces new data exfiltration risks. These stories share a common thread: security depends on understanding where risk sits in the systems, suppliers and tools organisations rely on every day.
The Guardian reports that nearly a third of British manufacturers have been hit by a cyber attack on them or a company in their supply chain over the past year, according to a new survey. The findings come almost a year after JLR, Britain's largest automotive employer, was forced to halt production for weeks following an attack. The survey highlights that large companies describe being under constant threat, yet only half have a response plan in place. The research underscores the scale of cyber risk facing UK manufacturing, a sector that remains a significant target for ransomware groups and supply chain attackers.
For UK manufacturers, this is not just about direct attacks on their own networks. Supply chain compromises can disrupt production, delay deliveries, and create contractual and reputational risk even when the breach happens elsewhere. Manufacturing environments often involve a mix of IT and operational technology systems, third-party logistics providers, component suppliers, and managed service providers, all of which create potential entry points for attackers. The fact that only half of organisations have a response plan in place suggests many are still treating cyber incidents as an IT problem rather than an operational and business continuity risk that requires board-level ownership and cross-functional planning.
For UK manufacturers, this is a prompt to review whether incident response, supply chain risk management, and business continuity plans are in place, tested, and owned at the right level. Consider whether third-party suppliers are assessed for cyber resilience, whether operational technology environments are segmented and monitored, and whether the organisation has clarity on who makes decisions during a cyber incident.
Source: The Guardian
Infosecurity Magazine reports that a supply chain attack targeting WordPress plugin vendor BdThemes allowed attackers to create rogue administrator accounts on sites using affected plugins, without modifying any source code files in the official WordPress.org repository. Wordfence researchers explained that the attack worked by poisoning a JSON feed used by the plugins to retrieve updates and configuration data. This allowed attackers to inject malicious instructions that created backdoor admin accounts, bypassing traditional file integrity checks that would normally detect tampered plugin code. WordPress temporarily disabled downloads of BdThemes plugins while the issue was addressed.
This attack demonstrates how supply chain compromises are evolving beyond direct code tampering. Many organisations rely on file integrity monitoring, code signing, and repository audits to detect malicious changes to software they use. However, if an attacker can compromise the update mechanism, configuration feeds, or API endpoints that software relies on, they can achieve the same outcome without touching the code itself. For organisations running WordPress sites, particularly those used for customer-facing services, e-commerce, or internal portals, this type of attack can create a significant and difficult-to-detect risk. It also highlights the importance of monitoring not just what software is installed, but how that software communicates with external services and what permissions it requests.
For organisations using WordPress or other content management systems, this is a reminder to review whether plugins and themes are kept up to date, whether admin account creation is monitored and alerted on, and whether there is a process for reviewing and limiting the plugins in use. Consider whether web application firewalls, admin access logging, and anomaly detection are in place to catch unexpected changes to user permissions or site configuration.
Source: Infosecurity Magazine
Dark Reading reports that cyber attacks targeting water systems have widened across a dozen US states, with attackers exploiting internet-exposed programmable logic controllers (PLCs) used in water treatment and distribution infrastructure. The attacks are suspected to be linked to Iranian threat actors, though attribution remains under investigation. The incidents follow a pattern of targeting poorly secured industrial control systems that are directly accessible from the internet, often with default credentials or outdated firmware. The attacks have raised concerns about the vulnerability of critical infrastructure systems that were not designed with modern cybersecurity threats in mind.
While these attacks are occurring in the United States, the operational lessons are directly relevant to UK organisations managing critical infrastructure, utilities, and industrial environments. Many water companies, energy providers, manufacturing facilities, and building management systems in the UK use similar industrial control systems and SCADA environments, often with legacy equipment that was installed before cybersecurity became a design priority. Internet-exposed PLCs, weak authentication, and a lack of network segmentation between operational technology and corporate IT networks are common vulnerabilities. The widening pattern of attacks suggests that threat actors are systematically scanning for and exploiting these weaknesses, and UK critical infrastructure operators should assume they are being targeted in the same way.
For UK organisations managing operational technology, industrial control systems, or critical infrastructure, this is a prompt to review whether OT environments are segmented from corporate networks, whether internet-facing industrial systems are identified and secured, and whether remote access to these systems is properly controlled and monitored. Consider whether default credentials have been changed, whether firmware is up to date, and whether there is visibility into who is accessing these systems and from where.
Source: Dark Reading
Infosecurity Magazine reports that Atlassian has fixed a vulnerability in its Rovo AI assistant, dubbed RovoBlast, that allowed an attacker to craft a malicious URL that could cause the AI assistant to exfiltrate company data. The flaw was discovered by security researchers who demonstrated that a single crafted link could trick Rovo into accessing and sending sensitive information from Atlassian environments to an attacker-controlled server. Atlassian has released a patch and advised customers to update their Rovo deployments. The vulnerability highlights the emerging security risks associated with AI assistants that have broad access to corporate data and systems.
AI assistants and large language model integrations are increasingly being deployed across enterprise environments to help with productivity, knowledge management, and workflow automation. However, these tools often require extensive permissions to access documents, databases, communication platforms, and internal systems in order to function effectively. This creates a new class of risk: if an AI assistant can be manipulated or tricked into performing unintended actions, it can become a powerful data exfiltration tool. For UK organisations evaluating or deploying AI assistants, this incident is a reminder that these tools need to be treated as high-privilege applications with carefully scoped access, monitoring, and controls. The fact that a single crafted URL could trigger data exfiltration suggests that input validation, output filtering, and access controls around AI assistants need to be designed with the same rigour as any other privileged application.
For organisations using AI assistants or planning to deploy them, this is a prompt to review what data and systems these tools can access, whether their permissions are scoped to the minimum necessary, and whether there is monitoring in place to detect unusual data access or exfiltration patterns. Consider whether AI assistant deployments are treated as high-risk integrations requiring security review, access controls, and ongoing monitoring.
Source: Infosecurity Magazine
The stories today reflect a consistent theme: security risk increasingly sits not just in your own systems, but in the suppliers, tools, update mechanisms, and integrations that your organisation depends on. Whether it is a manufacturing supply chain, a WordPress plugin feed, an internet-exposed PLC, or an AI assistant with broad data access, the common thread is that mature security practice means understanding where trust is placed, what access is granted, and how those dependencies are monitored and controlled. Good security is not about reacting to every new threat with urgency, it is about building the habits, ownership, and visibility that allow you to manage risk confidently across the full scope of how your organisation operates. The organisations that handle these challenges well are the ones that treat security as a shared responsibility, with clear ownership, proportionate controls, and the discipline to review and improve over time.