100+ US Water Systems Attacked, CISA Urges Exposure Management; OWASP GenAI LLM Top 10 2026; Ten CVEs Added to CISA KEV

We should stop expecting every small water utility to discover and remediate its own Internet exposure independently. CISA's guidance is sound, yet the recurrence of essentially the same weaknesses across more than 100 systems suggests an opportunity for a shared capability that continuously identifies exposed water-sector assets and helps the affected utilities remediate them. This capability could be something like a water sector attack surface management service operated through a trusted organization such as WaterISAC, MS-ISAC, a state program, or a consortium of utilities.

CISA’s four steps here are wonderfully unglamorous: know what is exposed, remove what does not need to be there, secure what must remain, and keep checking. I especially like the explicit recommendation to look at your own environment through services such as Shodan and Censys. If defenders can find an exposed PLC from the public Internet, assume the bad guys can too.

Time and time again we see guidance like this issued by CISA and other government agencies around the world. What is particularly frustrating is that many of CISA's recommendations in this report are not new or sophisticated, such as knowing what you have exposed, removing unnecessary exposure, changing default passwords, using MFA, and securely managing remote access. Cyber resilience often starts with getting the basics right and ensuring they remain right.

CISA has been issuing advisories for these facilities for at least five years. The question is whether the industry can actually act on it. I worry most about rural utilities where IT is one technician wearing many hats. You can argue vendors should do more secure-by-design, but a lot of these aren't enterprise environments: SOHO routers, big-box store computers, no central management, no granular firewall rules, no IDPS. Guidance you can't implement doesn’t protect anyone. And while we can go without a lot of things for a while, water isn't one of them. I usually look for the silver lining in these stories, the opportunity, but I don't have one here. What I do have is a proposal: something like a Civil Air Patrol, but for cyber, that can help these organizations with implementation, monitoring, and hardening. The good news is the model already works. Louisiana, Maryland, Michigan, Ohio, Texas, and Wisconsin run volunteer civilian cyber corps, and Ohio's is explicitly scoped to serve small utilities. The bad news is that it is state by state, thinly staffed, and adversaries against these systems won't care about state lines. The only way out of this category of problem is to march through it together.

We've seen a lot of stories of late about vulnerable infrastructure (e.g., PLCs) being compromised because it's exposed to the Internet. We've also had cases where something is made available so it can be worked on remotely even just once, but then it never gets undone. We need to stem the tide. The guidance from CISA is a great way to get your arms around doing just that. Mind you, this is not a five-minute thing, it's a self-assessment with opportunities to improve, and it's well worth going through their process. Notice it includes third-party risks, and even worse, you'll find you need to regularly repeat these activities, including, as Ed mentioned, going to Shodan or Censys to see what in your environment is exposed. Here's an idea for you: Have those who want to access components remotely — and who are not keen on having to use a VPN, secure gateway, or centralized remote access solution — research and present alternatives. There are some newer solutions for remote access which are worth consideration, and they could be your partners in assessing them.

Media scrutiny finally forced CISA's hand. But CISA's four-step guidance has been around for nearly a decade, and advice doesn't fix systems — execution does. The real barrier is resources. Many local critical infrastructure operators lack dedicated IT staff, let alone cybersecurity specialists. If we expect state and local entities to secure their networks, the federal government must back its guidance with real funding.

Many OT connections to the public networks are created for operator convenience and may not be known to management. They hardly ever employ strong authentication.

If you're not yet tracking the OWASP LLM Top 10, you need to. They are not only enumerating the top risks but also providing examples. As we ask staff to do more and more with AI, many controls will be pushed to the breaking point, and likely integrated into everything we're doing, raising the importance of Excessive Agency. That pertains to the degree of autonomy, permission, and functionality granted to your agents. Too often the agent is granted full access/permissions, so things "just work" — thing is, we don't give that level of access to users without caution, so shouldn't we be equally cautious with these non-human users, which I've characterized as a precocious six-year-old with a tendency to prevaricate? Make sure that your access-granting, revocation, and review includes Agent accounts.

It does not surprise me at all that we saw more shuffling around the top 10 this year, because undeniably adoption and implementation into critical workflows increased significantly this year. I also think it's important to call out OWASP's specificity that these top 10 apply to "models as components," not agentic behavior, which has its own lists. As you're evaluating your architecture, you need to understand what type of AI implementation you’re dealing with. The easiest way to eat an elephant is one bite at a time. I'd suggest organizations start by looking at the included example attack scenarios in the most common techniques, and set up your next tabletop exercises aligned to them. The guidance in the PDF is just paper until you translate it to your organization’s implementations and capabilities. This is your roadmap.

The movement that jumps out at me is Excessive Agency rising from number six to number three. Prompt Injection is still number one, but prompt injection becomes vastly more consequential when the model can do things, not merely say things. As we (probably unwisely) wire agents into email, cloud consoles, source-code repositories, ticketing systems, financial workflows, and more, authorization architecture becomes every bit as important as model behavior: least privilege, narrow tool scopes, explicit transaction boundaries, and human approval for consequential actions. I suspect we're going to be talking about these kinds of attacks and security issues A LOT. Many thanks to OWASP for giving us this list and helping to ensure we have a consistent vocabulary for referring to these topics.

While we cringe at the increased occurrence of the three-day remediation window, the thing to keep in mind is that this is an indicator of the exploitation level being seen. Don't panic — you may already have mitigations, or deployed updates, if the affected products are in your environment. Do some validating; the flaws in SQL Server, RHEL, and Citrix devices are in published updates, and you should already have those deployed. That leaves the matter of finding out if you've got the other products in your shop and how quickly they can be updated.

Six of these ten newly added KEVs date from 2023 or earlier; attackers do not care whether a vulnerability is old, only whether it still works.

The three-day mitigation deadline is mandatory only for federal agencies. However, the rest of us should take it as an indicator of urgency.

Since the initial reporting, a pro-Russian group calling itself Server Killers has claimed this on Telegram, tying it to the Norway-Ukraine defense agreement signed August 23. The attack began at 03:38 the next morning. It's important to note that this attribution claim has not been confirmed by authorities as of the time of my comments. Hacktivist DDoS is motivated by visibility and attention, so targeting public-facing services aligned to calendar-specific events is a tried-and-true playbook. Fortunately, that also means you can anticipate it and harden against it. Watch your own organization's news calendar, geopolitical landscape, and headlines.

(Source for my claim on Server Killers: https://abcnews.com/Technology/wireStory/pro-russian-hackers-claim-responsibility-major-cyberattack-norways-135965611)

It's been a minute since we talked about DDoS. You should be checking your DDoS protections regularly for two reasons. First, you may have new services, possibly third-party, that are not protected. The distributed nature of the attack impact on Norway illustrates what that can look like. Second, as the level of DDoS attacks increase, providers have increased their capabilities, but you need to make sure you've got the latest protections. Schedule a review around an ongoing date that you can remember and that has some meaning, like the beginning of your fiscal year. With luck, you'll find it's all good, and if not, you have a chance to be proactive.

This incident demonstrates how the loss of one piece of shared digital infrastructure can quickly cascade across multiple services. As governments and organisations increasingly centralise identity, authentication, messaging, and other digital services, they also create potential concentration risks. Cyber resilience therefore needs to consider not just whether individual systems can withstand an attack, but what happens when a common service upon which many other essential services depend becomes unavailable.

Cybercriminals hack for money; nation-states launch DDoS attacks for political revenge. Hostile nations already know which third-party providers keep government systems running. That's why every major international policy announcement needs to come with an immediate review of supply chain cybersecurity.

Kudos to DoJ and the FBI for shutting down malicious services that have been operating for eight years. Even so, assume these state-sponsored threat actors will be back, although with hard coded domains in their tools, they'll need to re-establish access or infect new targets. Seize this opportunity to scan for the IoCs and apply mitigations: patch, isolate critical systems from edge devices, and verify protections on sensitive information in internet-facing applications, if that information even needs to be there. The joint cybersecurity advisory has a lot of good background information, mitigations, and IoCs — something different to peruse with your second cup of coffee.

Some might read this story and think "Oh, good, a problem solved," but this is a hydra, and it goes back years. The proxy system isn't going away, and so the takeaway here is that IoT and infrastructure devices need monitoring, scanning, and alerting as much as or more than your traditional endpoints do. Just because you cannot install an EDR agent on the device doesn't mean you shouldn't be closely monitoring it and its associated traffic.

Melissa’s hydra analogy is apt: This disruption certainly does not make the underlying problem disappear. But I love the technical lesson here. QScan and QTRouter depended on hard-coded domains for critical functions, which gave defenders a centralized point we could take away. We often have to remediate compromises one victim at a time. Occasionally, good disruption lets us pull a piece of shared infrastructure out from under the attackers instead. Hard-coded domains can create a very useful choke point defenders can leverage. Of course, attackers will learn from this and adapt, but let’s celebrate a win when we can.

A quick tip of the hat to law enforcement for stopping these hackers for now. But let's be real: Manufacturers are still shipping wireless-enabled devices with zero concept of secure-by-design. If you aren't tracking IoT under CIS Control 1 (Inventory and Control of Enterprise Assets), you have a massive blind spot in your cybersecurity program. Get them cataloged and secured. https://www.cisecurity.org/controls/inventory-and-control-of-enterprise-assets

Software supply chain attacks are so powerful because attackers get to borrow our trust. Compromise one maintainer or package, and malicious code can ride a legitimate update path into hundreds or thousands of organizations. Josh Wright, SANS Fellow, spoke powerfully about these attacks from the RSA Conference keynote stage this year, referring to "Your Vendor's Vendor's Vendor," and highlighting how compromise can cascade through dependencies far beyond the vendor, software repository, or library you directly know. These arrests are very welcome, but the underlying lesson remains: We need stronger provenance, maintainer authentication, signing, dependency controls, and sometimes even a little intentional friction before automatically pulling a brand-new package update into production.

Steal credentials, compromise tools created for use by other developers (publish malicious versions), lather-rinse-repeat. TeamPCP even initiated a contest to see who could do the most supply chain compromise with the Shai-Hulud worm (scoring was based on the number of weekly/monthly downloads of the compromised packages). So, while the members of TeamTCP are cooling their heels in custody, you need to make sure that you're on genuine, good packages, that your GitHub repos are clean, that you've implemented the latest security settings, and that no remnants of Shai-Hulud are lurking in your systems.

I'm glad to see these arrests, but like other problems I've commented on today, this is a hydra. Factions spin off, new leaders emerge, groups regroup.

Takedowns and arrests for groups like this, especially the more informal and decentralized ones, often come from the incredibly hard work of dedicated researchers who engage closely with criminal communities. That is an important part of what we do. It is also a delicate balance between enabling safe research and taking on risk that the security organization never agreed to carry. The AFP credits information from cybersecurity firms with starting this investigation. Work like that is often the least-governed thing a security program does. If your team engages with these communities, it needs to be a sanctioned function: written authorization, identity separation and OPSEC support, counsel in the loop, law enforcement deconfliction, supervision, and an off-ramp for when it stops being safe. If you don't know whether anyone on your team is doing this, that is your answer. No one should be carrying this kind of risk (for themselves or their employer) on their own judgment.

If you are going to read one news article this week, then I strongly recommend the KrebsOnSecurity article at the top of the source links. It is an excellent article demonstrating how effective open-source intelligence can uncover treasure troves of information. It is also a good template for checking your own online profile and those of senior or critical members of your organisation to ensure they are not inadvertently revealing sensitive information about themselves or your organisation.

Credit is due to law enforcement for this successful operation. For enterprise leaders, this incident underscores the supply chain risks associated with open-source software. Organizations must implement strict source-verification protocols before integration; unvetted "free" software frequently introduces undisclosed security vulnerabilities and potential liability.

Email addresses were most commonly compromised during the process of signing up for the airport's public Wi-Fi, followed by car parking and Fast Track. The good news is that MAG already contacted affected users; the bad news is that the information is already being used in phishing campaigns. In addition to being diligent when signing up for services, as dodgy credential stealing portals are extra hard to detect from your mobile device, consider whether you need to be on that network, particularly if abroad. Can you survive disconnected or on cellular/hotspot? If you must enroll, evaluate using disposable email addresses where needed.

8.7 million addresses stolen is the number headlines will repeat, but it is the least interesting thing here. MAG told The Register that for most of those people, the compromised data was an email address, which makes this more like a stolen mailing list than sensitive PII being stolen. Still not great, but not catastrophic. As it’s the end of the summer travel season, breaches like this may lead to some travel-themed vishing/phishing/smishing against the accounts listed in the breach, so keep your awareness up. On the operational side, this does bring up the conversation of how many of those email addresses and customer records were still relevant and required to be kept. Were they years old? How long after a booking for car park and lounge access do you need to retain the data related to the booking? Data you don't keep can't be stolen.

Sending employees home because a cyber incident has made it impossible for them to work demonstrates why cybersecurity is a business resilience issue. Boards should understand which business processes depend on technology, how long those processes can tolerate disruption, and what alternatives exist when systems become unavailable. Your first business continuity exercise should not be the actual cyberattack.

The reflex on a story like this is to wait and find out what data was taken, but that's not the real story here. This is a story about what it means to know what your Crown Jewels are, and how to define them. The Crown Jewels in your environment are not just the systems that you'd get the biggest breach fine for, they're the systems that can prevent the business from operating and have the potential to be single points of failure for an entire business unit. A network outage stopped a company from shipping pacemakers, stents, and catheters, which makes this a supply problem for hospitals with procedures already scheduled. If staff really were sent home, that tells you there may have been no manual fallback. When that happens, you do not have degraded operations, you have a full stop. Most BIAs rank order management below critical because nobody gets hurt when an order ships late. In medtech, sometimes they do. Go check where order-to-ship sits in yours, and whether anyone has tested running it on paper. If you are on the provider side, your version of this question is different, but it’s the same concept: Which scheduled procedures depend on one vendor's shipping working, and what is the plan when it does not?

We don't have many specifics yet, but when an attack forces a company to shut down operations, you know it's bad. Here's hoping Boston Scientific releases a thorough after-action report so we can learn from it. Was it a missing patch, a misconfiguration, stolen credentials, or the classic lethal combination of all three?

To date, nobody is taking credit for the attack. Boston Scientific is doing the right things to contain, eradicate, and restore, while providing updates on their website. If you're a new user of a Boston Scientific cardiac rhythm management device or insertable cardiac monitor, you may be impacted — read and monitor the bulletin from Boston Scientific on service status.

At the risk of sounding like an alarmist, I really think we're going to see more and more cyberattacks disrupt human activities in the physical world. I know, I know. Many readers will reasonably point out that we're already seeing plenty of that. But it feels to me like we're still looking at the tip of the iceberg. There's no indication that AI played a role in this particular incident, but as attackers get access to increasingly capable autonomous agents and even coordinated agent swarms, I worry that the scale and persistence of real-world disruption could increase dramatically.

You know me, I'm not happy with Paylogix taking almost a year to disclose the event. They have published information and a helpdesk number, but are only offering guidance on ID theft protection, rather than providing a service. I expect this to be an increasing trend, so don't wait; get yourself protected. Use the incident at the ATF to check for standalone systems, probably outside your network, to make sure they are fully protected, to include asking why they are outside. As much fun as it is to create a system operating outside the corporate constraints, the threats are just too great to not include the protections your enterprise has for other applications, to include WAF, IdM, monitoring, and updates. Here is an opportunity to have a dialog and figure out how to achieve what's being done while remaining secure — don't be the bastion of "No."

Not all breached data carries the same risk. Information identifying targets of ATF investigations could potentially expose individuals, investigative activities, and law enforcement operations. Incident response therefore needs to assess not simply how many records were compromised, but what those records represent and what harm could result from their disclosure. Context matters when assessing the impact of a data breach.

Last fall is hardly recent. One hopes that they notified their customers before this.