Jessica Entwistle
July 21 2026
Today's brief focuses on three areas where trust in established security controls has been tested: widely deployed software, hardware encryption and vendor patching timelines. A critical WordPress vulnerability chain is being actively exploited across millions of sites, SonicWall firewalls were compromised for weeks before patches became available, and independent research has exposed serious weaknesses in the self-encrypting drives used across enterprise laptops. These stories share a common thread: security assumptions that organisations rely on daily need regular validation, not just at deployment but throughout the operational lifecycle.
TechCrunch and Dark Reading report that two critical vulnerabilities in WordPress core software, tracked as CVE-2026-60137 and CVE-2026-63030, are being actively exploited in the wild just days after patches were released. The vulnerabilities allow attackers to chain together flaws to achieve remote code execution and full site takeover. Security researchers estimate that tens of millions of WordPress sites remain at risk, with public proof-of-concept exploit code now widely available. Attackers are using the vulnerability chain to install backdoors, create rogue administrator accounts, and deploy web shells for persistent access.
WordPress powers approximately 43% of all websites globally, including a significant proportion of UK business, public sector and e-commerce sites. The speed at which exploitation began following disclosure reflects how quickly attackers can weaponise publicly available vulnerability details and proof-of-concept code. For organisations running WordPress sites, this creates immediate operational risk: unpatched sites are now trivial to compromise, and attackers are actively scanning for vulnerable installations. The risk extends beyond the website itself to any backend systems, databases or customer data the site can access.
For UK businesses running WordPress, this is a prompt to verify that all WordPress core installations, plugins and themes are fully patched and that a formal process exists to apply security updates within days of release, not weeks. Many organisations rely on managed WordPress hosting or agency partners to handle updates, so confirming who is responsible for patching and how quickly they act is essential.
Source: TechCrunch
SecurityWeek reports that two zero-day vulnerabilities in SonicWall firewall appliances, CVE-2026-15409 and CVE-2026-15410, were exploited by a threat actor tracked as UTA0533 for several weeks before patches became available. Volexity, the security firm that discovered the activity, observed the attacker using the vulnerabilities to deliver custom malware and establish persistent access to compromised networks. The exploitation targeted SonicWall devices used for remote access and perimeter security, allowing attackers to bypass authentication and execute code on affected appliances. Patches have now been released, but organisations using affected SonicWall models face a window of exposure during which compromise may have occurred undetected.
SonicWall appliances are widely deployed across UK businesses, particularly in small to mid-sized organisations and branch office environments where they provide VPN, firewall and remote access services. The fact that exploitation occurred before patches were available means that even organisations with strong patch management disciplines could not have prevented compromise through patching alone. This creates a difficult operational reality: perimeter devices that are meant to protect the network became the entry point, and the compromise may have gone unnoticed for weeks. For many organisations, this will require forensic investigation to determine whether their devices were targeted and what level of access an attacker may have gained.
For organisations using SonicWall appliances, this is a prompt to apply the available patches immediately and to review logs, access records and network traffic from the period before patches were released. Where forensic capability exists, investigating whether devices show signs of compromise is a sensible precaution, particularly if the appliances provide access to sensitive systems or data.
Source: SecurityWeek
Help Net Security reports that independent research by Milan Brož and colleagues has identified serious security weaknesses in self-encrypting drives (SEDs) that comply with the TCG Opal2 standard. The researchers tested 38 commercially available solid-state drives marketed as providing hardware-based encryption and found multiple implementation flaws that could allow attackers to bypass encryption protections. The drives are widely used in enterprise laptops and workstations, where organisations rely on hardware encryption to protect data at rest without the performance overhead of software-based encryption. Brož, who maintains cryptsetup, the disk encryption tool used across most Linux systems, noted that many of the tested drives failed to implement the Opal2 standard correctly, leaving encrypted data vulnerable to attack.
Many UK organisations have adopted self-encrypting drives as a standard control for protecting data on laptops, particularly for remote workers, field-based staff and executives who travel frequently. The assumption has been that hardware encryption provides strong protection with minimal user or IT involvement. This research challenges that assumption and suggests that organisations may have less protection than they believed. For businesses that have relied on SED technology as their primary data-at-rest protection, this creates a governance and risk management question: how confident can they be that the drives they have deployed actually provide the protection they were purchased to deliver?
For UK businesses using self-encrypting drives, this is a prompt to review what models are deployed, whether they have been independently tested, and whether software-based encryption such as BitLocker or LUKS should be enabled as an additional layer. Where SEDs are the sole protection for sensitive data, understanding the specific implementation and any known weaknesses is a sensible governance step.
Source: Help Net Security
The Hacker News reports that cybersecurity researchers have identified nearly 7,600 malicious GitHub repositories created as part of a campaign named FakeGit. The repositories pose as legitimate artificial intelligence tools, skills or Model Context Protocol (MCP) servers, but deliver a malware family known as SmartLoader. The campaign uses convincing developer profiles, copied project documentation and realistic README files to appear legitimate. More than 800 of the repositories specifically target developers and data scientists looking for AI tooling. When users download and execute the code, SmartLoader is deployed, providing attackers with initial access to the victim's system.
GitHub is a trusted platform for software development, and many UK organisations encourage or require developers to use open-source libraries, frameworks and tools to accelerate development. The FakeGit campaign exploits that trust by creating repositories that look legitimate and appear to offer useful functionality. For organisations where developers routinely download and integrate code from GitHub, this creates supply chain risk: malicious code can enter the development environment or production systems through what appears to be a legitimate open-source project. The scale of the campaign, nearly 7,600 repositories, suggests that attackers are investing significant effort in making the malicious repositories appear credible and difficult to distinguish from genuine projects.
For UK businesses with software development teams, this is a prompt to review how developers evaluate and approve third-party code, whether controls exist to scan downloaded repositories for malicious content, and whether development environments are sufficiently isolated from production systems. Clear guidance on verifying repository authenticity, checking contributor history and using trusted sources is a practical step many organisations can take.
Source: The Hacker News
Today's stories illustrate that effective security depends on validating assumptions, not just setting controls and moving on. Patching needs to happen quickly and reliably, hardware security claims need independent verification, and trust in platforms like GitHub needs to be balanced with practical checks. Mature security practice comes from maintaining visibility, asking whether controls are working as intended, and ensuring that someone is clearly responsible for acting when they are not. Organisations that build these habits into their operational rhythm are far better positioned to manage risk than those that rely on static defences and hope for the best.