Flawed Patches Generated by Frontier LLMs; Water Watch Center Launched by NRWA & DEF CON Franklin; NC Ports Recovering from Cyberattack

AI is rapidly becoming astonishingly good at finding vulnerabilities, but this research shows that fixing them is a very different problem. Our team has actually had excellent results using AI to generate patches, but there's an important catch: You need the skills to evaluate whether the proposed fix really works, recognize when it doesn't, and then push the AI to analyze the shortcomings and make it better. In that iterative loop, our results have been remarkably good. That’s where I think we're headed with VulnOps against internally developed software: AI-assisted discovery, AI remediation fix development, human review of the fix, testing, and verification, with skilled humans providing the judgment and repeatedly steering the AI toward a robust fix. Don't expect one-shot AI patching to work reliably. Instead, iterate, test, challenge, improve, and verify. AI can be an extraordinary patching partner, but today it still needs a skilled human at the keyboard.

We are just not there yet when it comes to these LLMs and code. I will however say that if you consider that this time last year agentic AI was just something people discussed a bit, the speed at which this is moving is fairly impressive. I suspect that there will be a point in the near future where the ability to write better software improves dramatically. If you consider that GitHub copilot was 'amazing' in 2018/2019, consider what it looks like today.

I think the bumper sticker version is “AI-generated *.* requires skilled human review.” Tools that allow those skilled humans to more quickly and accurately remediate vulnerabilities are needed and achievable. FIX ALL buttons are neither.

With so much of flaw discovery and remediation being driven through the use of AI, it's really tempting to follow suit with your chosen LLM, because if they can do it, so can you, right? The trick is, just like that new intern, you need to review the work to make sure it's right. It is super tempting, particularly with complex solutions, to forgo that. You know the cliché — work smarter, not harder. Start by having it create an implementation plan with checkpoints, and then consciously decide what you're going to do and where you're checking its work. Have it cite sources for its work. Make sure the fix doesn't modify application behavior or introduce a new flaw.

One hope is that LLMs can patch the vulnerabilities they find. The problem with developing a patch is that verification is more difficult. For a vulnerability, there tend to be better-defined indicators that a vulnerability was found. Some vulnerabilities may be missed, but that is “ok” when looking for vulnerabilities. For a patch, verifying that it fixes the vulnerability completely and does not introduce new problems is more difficult.

Interesting analysis from 1Password. Much like junior engineers learning from past patching mistakes, AI models will refine their capabilities as they are exposed to these flaws. We've seen this evolutionary curve in other AI applications, which is precisely why maintaining a human in the loop remains essential for oversight and validation.

There are several ways to look at this. I don’t mean this in a humorous way, though it may sound it! Since our LLMs are generating probabilistic results, it makes you wonder if flawed code is more likely than not. More seriously, while LLMs are incredible, and while it is amazing how many tasks can be solved at some measure of success by applying a sophisticated attention mechanism to predicting the next most likely token based on context, these systems are not yet close to approximating critical thinking and problem solving. Will bigger be better? Will some of the recent advances in attention and newer models improve this? Probably. In the end, this all remains a math exercise.

Like natural intelligence, we can expect, and have seen, that artificial intelligence gets better over time. It struggles with similar, though different, limitations. It benefits from education and experience. It is best applied to hard problems with easily tested solutions. Said another way, "Trust but verify."

The Water Watch Center is a welcome addition to the resources already available through the WaterISAC, MS-ISAC, and federal programs. Better threat intelligence and managed detection can help small utilities understand when they are at risk, yet information alone does not mitigate that risk. Many small water systems simply do not have the trained technical staff or resources to act on what they are being told. The larger challenge is building shared, scalable capabilities that can turn that information into action across thousands of small utilities and begin addressing the systemic risk facing the sector.

I really like this initiative, and am thankful for the great work by NRWA and DEF CON Franklin behind it. Telling a small water utility serving a few thousand people that it needs a world-class SOC, a threat intelligence program, a vulnerability management team, and 24x7 incident response capability isn't particularly helpful when it has neither the people nor the budget to build them. Shared expertise and services can change that equation dramatically. Cybersecurity has spent decades developing sophisticated capabilities for large enterprises; figuring out how to deliver those capabilities economically to thousands of smaller critical infrastructure operators may be every bit as important.

Water utilities are being targeted and compromised, notably via PLCs exposed to the Internet. If you're a small water system, typically serving fewer than 10,000 people, you need to leverage resources such as the WWC from NRWA. NRWA has multiple initiatives and partnerships, including the WaterISAC, SANS, Microsoft, and DEFCON Franklin, along with a bunch of resources you can leverage to help raise the bar on your utility.

This incident has something in common with several of the recent attacks against water utilities. The systems and circumstances are different, yet the operational response is familiar. Digital systems become unavailable and operators fall back to manual processes to keep essential services running. That is exactly why manual operations need to be exercised and engineered as part of the resilience plan, not simply documented as an emergency procedure. It's good to know you can operate manually for a few hours, but how long you can sustain it safely and effectively before people, processes, and supply chains begin to break down?

North Carolina serves as a trade hub along the southeastern US. Agricultural exports, retail goods, and raw materials predominantly flow through the port of Wilmington, and when you consider the volume of the three ports, this could have been a fairly disruptive supply chain attack. While the details are getting sorted, it's important to note that their incident response and contingency plan both appear to be working as planned, to include minimal schedule disruptions. Make sure you're set to do this well when it's your turn in the barrel.

One of the most interesting words in this story is "manually." We spend enormous amounts of effort trying to prevent cyberattacks, as we should, but organizations operating critical infrastructure also need to ask a powerful old-fashioned question: "What happens when the computers don't work?" The ability to fall back to well-practiced manual processes can turn a potentially catastrophic cyberattack into a painful but manageable operational disruption. Resilience isn't just automation, backups, and redundant systems. Sometimes it's people who know how to keep the real-world process running without the computers. Humans are a VITAL aspect of resilient operations. Let's never lose sight of that.

While details on the intrusion remain limited, the takeaway is clear that any organization utilizing Operational Technology (OT) must regularly train for manual operations. Cyber risks to OT systems should be formally documented and routinely reviewed in the corporate risk register.

It's easy to look at the security update and note only one flaw is fixed. Rather than second guessing where screen sharing is and isn't used, push the update to your macOS 26 (Tahoe), 15 (Sequoia) & 14 (Sonoma) systems. Then get moving on updating those macOS 14 systems — Apple is getting ready to release macOS 27 (Golden Gate), ending support for Sonoma. Plan on a three-year lifecycle for any given macOS version, ideally updating yearly to stay on the latest release.

This is the second time in a few weeks that Apple patched screen sharing flaws. macOS 26.6 was released at the end of July, addressing several screen-sharing flaws, but missed this one. These vulnerabilities are logic errors; all an attacker needs is a valid user's username on the system. Exploits exist for these vulnerabilities, but have not been made public so far.

CEVA is a fully owned subsidiary of the CMA CGM group, the world's third-largest shipping company, which operates 1,000 warehouses and handled 15 million shipments last year. CEVA has been notifying retailers of the breach, who are in turn notifying affected customers. Nobody is taking credit for the attack yet. The data includes the information relating to shipments from May through July: name, address, phone, email, and item purchased. Note that CEVA does have an information retention policy and is only collecting the information needed to deliver the shipment, which is a best practice for third-party integration. That said, this data is a boon for a targeted social engineering attack or other scams, so be on the alert for such activity if you're affected.

Computers really do improve our efficiency, and today most enterprises use them. However, they are also fragile and vulnerable. They should always be used in a manner that does not sacrifice enterprise resilience.

Beyond the update to Metabase, the added steps are critical to invalidate all existing sessions and connections which could then return regardless of the fix. Don't cut corners, as you don't want to repeat this exercise because you missed something. Framework computers are popular as they are modular and repairable/upgradable. While the attack path to Framework was via the Metabase flaw, the attackers only accessed customers’ personal data, not payment information. Hopefully their customers already have credit/ID monitoring in place.

Ouch! SQLi remains a major problem today, sadly. Pay close attention to Metabase's instructions here. They aren't simply saying "patch." Because this vulnerability has been actively exploited, they're telling exposed customers to invalidate sessions, inspect API keys and administrator accounts, rotate database credentials, and hunt through logs for evidence of compromise. That's an important distinction: Once exploitation is occurring in the wild, patching closes the door but doesn't evict attackers who may already have walked through that door. For exploited vulnerabilities, remediation should increasingly mean patch + hunt + credential rotation + clean-up + verification = eradication.

Yes, it is 2026, and we are still worrying about SQL injection. Software like Metabase takes the nitty-gritty details of writing SQL commands away from you and hides them behind a slick UI. But in the end, you are creating SQL, and the systems allow essentially arbitrary SQL queries, making it more difficult to prevent SQL injection with standard techniques like prepared statements. You should always use database permissions to restrict access by frontend tools like Metabase. This will at least reduce the impact of any SQL injection vulnerability.

Reusable credentials need to go the way of the Dodo bird. And you need to move not just to MFA, but to phishing-resistant MFA. Coincidentally, I saw an announcement from Microsoft that they are moving to phishing-resistant authentication. Specifically they are making passkeys the default authenticator on September 1 for users currently enabled for SMS or phone, prior to retiring SMS and phone validation next February 1.

The IEH breach was enabled by use of reusable passwords; the Levi Strauss incident may have involved some level of MFA bypass, but that is not clear. Both are good reminders to continue to prioritize migration to phishing resistant strong authentication, and to make sure awareness campaigns are reminding everyone not to trust voice messages.

A clear reminder from these filings: cybercriminals love using social media activity to make their phishing and smishing attacks look authentic. Before responding to an urgent or convincing message — whether it's an email, text, or call — always stop and verify the source first.

This really is 2026, and any use of reusable credentials really is reckless.