UK Power Plant Taken Offline by Cyberattack; Car Systems Infected with Proxy Malware; N-able Passportal and Keycloak Fix Flaws

This incident is a small-scale demonstration of the distinction between asset risk and systemic risk. An individual asset failed, while the larger engineered system absorbed the failure without loss of service. That being said, the small size of the generator should not distract from the fact that a cyberattack apparently caused a physical operating asset to remain offline for four days. What happens when the same capability is applied to a larger facility, or simultaneously to a number of smaller ones?

"Legislation that would help improve the cybersecurity posture of public services and digital services providers" — please remind me when legislation measurably and immediately reduced cyber risk for, well, anything? Does anybody have an example?

A couple of points here: (1) No legislation leads to rapid improvement in cybersecurity failures, but there are many examples of how safety and security legislation *and enforcement* did set and raise the bar for everyone — which is necessary when everyone is connected to everyone else — leading to major advances. There are many examples of this, and my favorite in modern times is circa 2001 when the US government started requiring government agencies to only use browsers that had FIPS 140 certified crypto in use. The financial world and many others quickly added that to their compliance regimes. Today we take that transportation for granted even by the smallest companies. (2) Most legislation sets different bars for small businesses, but everyone gets a minimum expectation of safety and security to be in business.

This is yet another reminder that cyberattacks against critical infrastructure are not constrained by geography. Organisations responsible for energy, water, healthcare, and other essential services should assume they could become targets during geopolitical conflicts, regardless of where they are physically located. The UK's forthcoming Cyber Security and Resilience Bill, similar to the EU's NIS2 Directive, should make organisations strengthen their resilience. However, legislation and compliance alone will not keep the lights on, so operators need to regularly test whether they can maintain essential services when their technology is disrupted.

Every so often, we are lucky — this incident was not large enough to cause serious damage, but it was large enough to hopefully cause people to listen and learn from it.

Perhaps I'm wearing my tinfoil hat, but if the power outage was coordinated with water utilities and scaled up, I think the effect would be both dramatic and impactful. There are a lot of small supplemental power sources which offset shortfalls in mainstream power production, and these are likely less well secured. Meaning, take a lot of them out and you could overwhelm the mainstream, and if you also take out other utilities — ouch. If you're in the critical infrastructure sector, never assume you're too small to matter. Work with local resources to not only implement security controls but also verify their operation. With available and affordable resources (and guidance) partnered with supporting legislation, like the UK Cybersecurity and Resilience bill making its way through parliament, providers will have the resources and requirements to keep these systems secure.

One sentence in the Telegraph’s reporting of this incident stood out to me: "It is unlikely that the attack against the UK power plant was intended to inflict genuine harm on civilians, and is not thought to have been widely noticed by the public." That feels a bit disingenuous, because adversaries generally don't go after critical infrastructure because they want to make life better for their victims. Any attack on critical infrastructure should be seen as intent to harm civilians, because these are civilian targets, not military targets. While this event and this facility — and the power grid in general — had some resilience in their architecture, I don't think that changes the narrative that the adversaries didn’t intend harm.

While the impact of this attack was minimal, it highlights a stark reality: Critical infrastructure remains a prime target, making robust cybersecurity essential. Currently, much of this infrastructure is privately owned and operates without mandatory baseline security standards. The UK Cybersecurity and Resilience Bill aims to address this gap by requiring a set of standardized security controls across operators.

Anton raises a fair question about the limits of legislation here. I'd add that regulation can set expectations and incentives, but it does not operate the plant, configure the firewalls, segment the OT network, or rehearse the recovery plan. Those are ultimately engineering and operational responsibilities. This incident is another reminder that resilience in critical infrastructure comes from layers: good architecture, good operations, realistic exercises, and the ability to keep serving people even when one component fails.

The length of a power outage is in part a function of how widespread it is. Therefore, we all have a common interest in resilience. While law alone will not achieve it, legislatures may be a place to identify the risk and start the cooperation necessary to achieve it.

I have seen many articles about possible attacks on car systems. This is an actual attack. It does appear that pre-installed software is to blame, and I am not sure whether the call for malware defenses on the head unit is appropriate or more of a result of the products Kaspersky has to offer to solve this problem. These systems should be prime candidates for some form of allow listing or software control.

It is really cool to consider the devices that have been implemented using the Android platform. It's also concerning when you see how they are being extended for other uses, not all benign. In this case, add aftermarket car infotainment systems — where malware is being delivered via the standard update mechanisms — to your list of devices, like IPTV, where you have to choose wisely when purchasing. Often the malicious units are considerably cheaper than their OEM or mainstream alternatives. Don't go bargain basement with your car's electronics; car-hacking remains a thing, and you don't want to be an example. Authorities are working keep the BADBOX botnet used by these devices neutralized, but for now, don't rely on that.

A car getting malware just to be part of a botnet was not on my bingo card for 2026. Oddly, I thought it would have happened back in the 2010s, but this is frightening now. I'm not exactly sure what to advise on this one because "buying a new car" isn't a simple or cheap fix, and "Don't get a car with an infotainment" isn't easy either. The good news here (if there is any) is that it is an aftermarket unit, not one that ships with a vehicle, from a major manufacturer. Still kind of frightening.

Somewhere along the way, our cars became just another collection of networked computers, software supply chains, update mechanisms, third-party components… and now, apparently, botnet nodes. Yep. I remember Charlie Miller and Chris Valasek presenting their incredible work on car hacking over a decade ago. Now, car vulnerabilities and associated hacks seem to be with us to stay. Security assumptions that would be unacceptable for a laptop or server should not suddenly become acceptable because the computer happens to be bolted into a dashboard.

While auto vulnerabilities tend to be sensational, I never worried about them much. I did not think that they would scale or that they could be exploited to make money. Of course, I never expected "read/write" to be the default access control rule or that cryptography would be weaponized. (Perhaps I am too naive to be in this field). In any case, we must now add cars to the large population of overpowered and under-managed appliances that contribute to botnets.

The suggestion to re-engineer a platform's architecture is quite the red flag. Thing is, replacing your credential management system is non-trivial. Right now, if you're using Keycloak or Passportal, get those updated PDQ, and don't forget browser extensions. Forget the mitigation — apply the update. Interesting to see password books getting a little love here. While they are not the technical solution of a password manager, and while they are a potential single point of failure, they have the advantage of not being an online document that could become compromised. These often include sections for tracking software licenses, email settings, and other tidbits you want to track/organize.

The N-able Passportal attempts to solve a very difficult problem: Giving MSPs access to customer credentials. The implementation selected for this solution is risky, as it leverages the browser. Web browsers are shared environments, and while many features are sandboxed using same-origin policies, the messaging feature is not sandboxed, as it is intended to exchange data between different sites.

There is a lot packed into this story, but I want to applaud the N-able response in particular. A researcher found a potentially catastrophic flaw in a credential-management product, the vendor engaged constructively, and a fix was produced super quickly. That is exactly how the researcher/vendor relationship is supposed to work. We spend a lot of time studying vulnerability failures… It's worth celebrating when disclosure and remediation work well. Kudos to James Arnott and N-able for showing such an example.

Kudos to N-able for delivering a patch in just three days, and to the researcher who discovered the flaw — a flawless execution of responsible disclosure. That said, this incident highlights a major reality: Credential management systems remain the ultimate Achilles' heel if breached.

Password managers of any variety will always be attractive targets because they're essentially a skeleton key for access. In this story, we're lucky that the researchers and the N-able response both worked as shining examples of the researcher-vendor partnership. It also sounds like there was some use of automated pipeline scanning, which is yet another win for using advanced tooling and tech for good (I won't say AI because they don't specify AI based scanning). A few high points in this story for me: A human pulled on a thread that seemed off, which is the enduring value of human-in-the-loop on automated security scanning, the vendor response was timely and cooperative, and it was patched almost immediately. It's not all great news, though. N-able is still doing vault decryption server-side rather than end-to-end, which is why a leaked token is a skeleton key instead of a nuisance. In 2026, the E2EE recommendation isn't optional architecture advice. While most browser extensions auto-update, those updates don't always take effect until you've done a browser restart (and come on, how many of you have long-running browser sessions with 1,000 tabs?). If you're an admin, an inventory of browser extensions and versions has been a necessary asset management category for several years now. A quick note on the password book debate, while I'm here: I get it, we all used to dunk on them, but smart security professionals recognize that these are an offline, 'unhackable' source of password storage for the average consumer, and they are often the right option for your less tech-savvy friends and family. If it gets someone away from using 'Autumn2026!' as their password, let them use the password book, but encourage phishing-resistant MFA on top. Human beings want simple, easy systems, and this combination works for the vast majority of regular personal accounts and end users.

For years we have accepted that some industrial protocols cannot support strong security because authentication or encryption might interfere with deterministic performance. This research suggests we need to revisit that assumption. TSN's predictability is what makes it valuable for industrial control, yet that same predictability helped the researchers construct messages that appeared at the correct time and looked legitimate. In other words, a feature designed to support reliable, deterministic communications became part of the attack mechanism. Reliability, availability, and integrity are separate engineering properties; achieving the first two does not automatically provide the third.

A reminder that your OT systems are often real-time or time sensitive, which is easy to forget when they are "just working." While it's easy to focus on the TSN protocol, demanding security improvements (which are coming), don't expect rapid changes here. Instead, stick with the basics, segmentation/isolation and monitoring, watch for unexpected protocols, and deploy updates in a timely fashion.

Oracle's CPUs are cumulative, so make sure that you've got the latest deployed and you can move on. You likely already hit that Zimbra update, and can now take a look at TrueConf. TrueConf is secure corporate messaging, locally hosted, operating as an alternative to Zoom or Teams. If you have it, make sure it's updated and that you're not surprised to discover it. It's been targeted a couple of times, so you're going to need to make sure the clients are legitimate and the servers are updated and securely configured. Then have a chat about the need for it, to include keeping it secure.

The KEV catalog grew again, which is the least surprising sentence I'll write this year. Worth noting as usual that by the time it's in the KEV, it's already in the wild (and sometimes has been for weeks or months). If you're waiting on KEV status alone to prioritize patching, you're leaving an exposure door wide open during a hot phase of emerging attacks when detection capability is still limited. You'll hear me speak a lot on contextualized vulnerability relevance and prioritized remediation guidance. I don't mean them as buzzwords. I mean invest in tooling and workflows that allow you to know not just that you’re vulnerable, but to know which specific patches, libraries, functions, whatever you need to fix to actually reduce risk. Even presence on the KEV doesn't mean you are exploitable, so don't confuse chasing KEVs as progress towards maturity. Focus on outcomes — reduce real exposure and close the actual exploitable gaps in your specific environment.

Melissa’s point about KEV is important: It is evidence of exploitation, not a substitute for understanding your own exposure. Indeed, a vulnerability list tells you what is dangerous in the world; your own VulnOps process should tell you what is dangerous to YOU. That distinction becomes increasingly important as the number of vulnerabilities and the speed of exploitation continue to ramp up dramatically.

A three-day mitigation deadline is rapidly becoming the benchmark for FCEB agencies — a welcome shift. However, as frontier AI models start automating exploit development, even a three-day window will soon prove too slow. Organizations need to aggressively explore full automation for their patch management pipelines today to stay ahead.

Bravo — all service-side flaws addressed by Microsoft. And yes, you saw that, unsafe deserialization strikes again, but it's fixed. Not a lot to do here. Microsoft is keeping the details close; the CVE suggests a remote exploitable flaw of low complexity which may or may not have been actively exploited. For now, I think we have other fish to fry, so we move on, making sure we've got sufficient monitoring on our Entra ID (aka Azure Active Directory) environment.

The root cause of the Azure Entra directory vulnerability was "deserialization of untrusted data," which is part of the OWASP Top 10 Software vulnerability list under A08 – Software or Data Integrity failures. It would be good to hear from Microsoft why this made it to production software on a very critical cloud service.

We now live in an age when 22 vulns seems like a walk in the park. But these particular vulnerabilities are quite serious, and I'm glad these bugs have been squashed. Also, I appreciate Microsoft correcting the record here. CVE-2026-69836 was initially described as exploited and later changed to "not exploited." Vulnerability intelligence is inherently dynamic, and sometimes the responsible thing is to revise a conclusion as better evidence arrives. I would much rather see a vendor transparently correct an assessment than quietly leave an inaccurate one standing.

Cisco Secure Workload Software is a micro-segmentation tool, formerly known as Tetration. There are no workarounds, so apply the update. Note you need to update the Cluster, Agent, and Connector software components of Cisco Secure Workload. Similarly, Cisco Crosswalk products have no workarounds for these flaws, so you need to update. While there don't appear to be active exploits, those CVSS scores indicate you don't want to delay these updates, doubly so with updates available to reverse engineer.

Most enterprises are part of our economic and cyber infrastructures; any risk to one is a risk to all. Cisco products are part of many, not to say most, enterprise cyber infrastructures.

UNC6671, formerly the BlackFile extortion gang, specializes in vishing attacks, posing as IT helpdesk staff. They contact staff via their mobile devices, luring them to fake login portals, known as Adversary-in-the-Middle (AiTM) infrastructure, where they collect reusable passwords and MFA tokens. Once sessions are established, they then proceed to exfiltrate data via automated scripts. The AiTM environments use legitimate-sounding names incorporating the term ‘passkey’ or ‘sso’ in the URL. Mitigate the risks by enforcing phishing-resistant MFA, and leverage SSO to ensure the level of authentication rigor is consistent across platforms. Reduce session timeouts — while less popular, this will cause session keys captured during phishing campaigns to stop working. Require corporate-managed devices, with active EDR/MDM for access. Look at SASE and other mechanisms to restrict access to authorized devices and locations. You're taking a multi-pronged approach to raising the bar on authentication to make it harder for the attackers, and adding engineered controls for when we have a bad day.

Regarding Apollo, all I can say is, "another day, another social engineer bypassing your best-laid technical plans." This problem is only going to get worse, friends, because our adversaries know how effective it is. Basic security literacy (and now, basic AI literacy) is an essential skill we need to be teaching in practical ways as early as grade school because employees of all organizations are targeted pretty much as soon as they enter the workforce. Is your awareness training and cyber literacy education: a) being taken seriously by the org, and b) keeping pace with the threat actors? On SickKids: It is a vile, especially low kind of criminal who'd go after a hospital for sick children. The reporting points to a vulnerability in a third-party app used by plenty of other organizations, so this may be a case where nobody bothered to look at whose door they were opening. Somehow that's worse. While I generally don’t expect a high level of honor and integrity among criminals, I do think there's a bit of a "pirate’s code" among some of them — LockBit apologized to this very hospital in 2022 and handed over a free decryptor because an affiliate broke their rule about medical institutions (because victimizing or putting the health and lives of sick children at risk is generally the lowest depth of amorality). While this breach was "only" employee data, it still has an impact on facility trust and potential downstream impact on the mental wellbeing of victimized employees, which cascades into care. For this to be the second breach in fewer than 5 years for this organization is unusual to me — what lessons can their leadership learn from this combination of events and the opportunities to prevent?

OMB Memo M-26-14 replaced the previous M-21-31 logging directive, which required 12 months online plus 18 months of archive storage of logging, and set the details required, which were not always achievable. The LRA and updated guidance allows a modernized/updated risk-based approach, which hopefully is also more affordable and incorporates things like the use of AI and updated guidance of use of the SIEM vs log repository. Read the LRA. You may wish to skim M-26-14 for context first — it's 80 pages, so grab your coffee and give yourself a moment — but it has stuff you may not have considered you can leverage, including validation and readiness checklists, which are useful for validating your logging system, regardless of having to follow M-26-14.

Collecting logs is easy; however, collecting the right logs and being able to use them during an incident is much harder. Too often when dealing with incidents, I have found many organisations treat logging as a compliance exercise and then discover during an incident that the information they actually need was never collected, retained, or monitored. While CISA's guidance is aimed at US federal agencies, it applies to all organisations. In simple terms: start with what you need to detect and investigate, then design your logging around those outcomes.

There's a joke in here somewhere about a tree falling in the woods and collapsing into logs that no one is watching or using… On first glance, this is actually a solid primer for orgs who don't have a logging strategy, or for those who are looking to ensure they're making the right investment in logging (because unfortunately, logging cost is often a limiting factor of logging efficacy). While this isn't a concrete roadmap, it is a good framework for having risk-informed and outcome-focused conversations on log strategy and architecture, and it allows you to make incremental progress as you onboard new applications and log sources. Additionally, if you're a software vendor, this helps you with that whole ‘secure by design’ thing in practice, because your logging sources should make it effortless for organizations to achieve these outcomes and anticipate the architecture design questions your customers will be asking. If you're doing business with the federal government, your customers are looking at this already.

Logs alone do not an audit trail make. Audit trails, like identity management and access control, must be designed. The fundamental rule is that there should be mutually referential logs on each side of any interface where control passes from one person or process to another.