OpenAI Sued Over Accountability For Agents; Cisco SD-WAN Critical Flaw Exploited; Zammad Flaws Exploited to Breach DIVD

This feels like the first salvo testing California's Computer Data Access and Fraud Act (CDAFA) which attempts to make humans accountable for the actions of their AI. The interesting part is that LASST is operating on behalf of the public, rather than the injured party (Hugging Face), basing that on California's Unfair Competition Law. Given that they are seeking an injunction and legal fees, and that OpenAI has already taken steps to prevent recurrence, it's not clear that anything substantive will result here. Accountability is needed for the actions of one's software, but the fines here, if any, are trivial compared to the overall financial status of OpenAI.

At this point, any ruling/fines or settlement in this lawsuit is going be in the noise compared to money being invested in AI companies like OpenAI, but they will be important in setting precedent. This one is aiming at negating any "we didn't do it, it was AI" defense, among other things.

John Pescatore and Lee Neely both point out that the precedent here may matter far more than any financial penalty. Whatever the court ultimately decides, there's an important security principle underneath this case: Autonomy is not an accountability boundary. If an organization gives an AI agent credentials, network access, and tools, it needs to define what that agent is authorized to do, monitor what it actually does, provide ways to stop it, and establish who owns the consequences when it crosses a line. "The agent did it" is not an incident-response plan.

This is an interesting case and one that I recommend many CISOs, DPOs, and legal teams should follow closely. As organisations give AI agents greater autonomy and access to systems, the question of who is liable when those agents cause harm becomes increasingly important. “The AI did it” should not become the technological equivalent of “the dog ate my homework.” Organisations deploying agentic AI need appropriate controls, monitoring, and human oversight, but should also engage with their legal teams to understand their potential exposure should an AI under their control cause harm to another organisation. Also, if your organisation is based in or operating in the EU, you should understand whether and how the EU AI Act applies to the AI systems you develop or deploy.

AI (not just OpenAI) has reached the “too big to fail stage”, and as a result, has been above the law when it comes to copyright or breaching innocent bystanders’ systems. We will see if anything changes, but I doubt this will result in anything more than a slap on the wrist.

Unsurprising, given our litigious society, though the lawsuit is a stretch since Hugging Face, not the plaintiff, was the actual victim. While drafting emergency briefs may have served as an opportunity to draw attention to the non-profit, one fact remains undeniable: The legal status of autonomous systems is entirely unsettled. Furthermore, it's clear OpenAI failed to implement sufficient security controls and human oversight to monitor and halt the test environment.

I'm interested to see what happens in this lawsuit. Harm was done, but the extent and severity are in question. It also raises questions about whether it could have been prevented. My concern is a large imbalance between frontier labs and how they provision blue and red capabilities, and open-weight labs. If strict regulations follow this and provide individuals outside the US with superior cyber capabilities, we will be unable to respond effectively. In other words, someone with very little money in another country can just point a GLM-5.3 swarm at you, and neither can the Red Team model it nor the Blue Team defend against it. Or worse, they can, but at an extremely high cost through the vendor directly or a vetted third party. Sometimes the cure is worse than the disease.

If we are to avoid unintended consequences, we must hold people and enterprises responsible for the reckless use of AI. OpenAI needs to be held accountable for the good of us all. That said, where is Hugging Face, the victim in this? While I commend LASST both for its mission and this action, their standing is not nearly as clear as that of Hugging Face. It needs to join the suit.

We've had a brief respite in SD-WAN vulnerabilities, but we're back, and number five for 2026 is a pretty good one. Three things you need to do. First, upgrade to the fixed software. Second, hunt for the IoCs in the serviceproxy-access log and vmanage-server log files. Third, restrict access to the management interface to known trusted devices; don't expose them to the Internet directly.

The Cisco SD-WAN software has been under scrutiny for some time. If you are running SD-WAN on IOS (Viptela acquisition, I believe), update it and look for "unknown" third-party tunnels in your application stack. Most people do not know which VPN tunnels are valid, so documentation is critical here. I would suggest using a DCIM or another system like NetBox to track this.

CWE-84, "Improper Neutralization of Encoded URI Schemes,” is one of those early 2000s style vulnerabilities (remember Code Red?). But “Cisco SD-WAN Manager” is a typical Cisco product. It was originally released by a company called Viptela around 2012. In 2017, Viptela merged with Cisco. Cisco in 2023 renamed the product from “vManage” to “Cisco SD-WAN Manager.” Cisco may not call itself private equity, but it behaves like it. I doubt a lot of actual application security concerns went into the acquisition, and the renaming for sure didn’t fix any vulnerabilities.

Well, that was fast. Apparently, when it comes to URL/URI encoding bugs, we're still partying like it’s 1999. In Tuesday's NewsBites, we were just talking about PeopleSoft attackers using URL encoding to make a security control and the application interpret the same request differently. Now we have an actively exploited Cisco SD-WAN authentication bypass caused by improper handling of URI encoding. Different product, same family of problem. Normalize first, then make the authorization decision on the canonical form. Security controls and downstream code need to agree on what request they are actually looking at — attackers love the gaps when they don't agree

If you're using the Zammad helpdesk system, update to 7.0.0 posthaste. Take it as a given that attackers will leverage all the available resources, including agentic AI to find weaknesses. We need to fall back to the basics: defense in depth, including WAF, phishing resistant MFA, monitoring, and alerting, as well as keeping packages and systems both updated and securely configured. Don't needlessly expose management interfaces or services. Yeah, some of these are a pain to get done, and you may have some things in limited production deployment or otherwise stalled, but it's time to roll up your sleeves and do these things comprehensively. Don't make the attackers' job any easier.

I very much like DIVD's stated approach to this incident of being “open, transparent and honest, even if it sucks.” No organisation wants to suffer a breach, especially an organisation whose mission is cybersecurity. However, as I regularly say, today you will not be judged simply for being the victim of a cyberattack, but you will be judged on how you respond to it. DIVD's willingness to openly share what happened, what it is doing about it, and what it has learned provides a useful example of how incident communications should work.

Rare transparency from a victim sharing every detail of a breach. While the headlines focus on agentic AI, defending against one zero-day is hard, let alone two of them. Huge credit to DIVD for sharing. It’s a tough break, but they've raised the bar for incident reporting.

Uh oh — excuse buzzword alert: "Agentic AI" as villain versus exposed vulnerabilities. "Not our fault, it was an Advanced Persistent Threat" sound familiar?

John’s skepticism about the "agentic AI" label is healthy, and Lee is right that none of this makes the fundamentals go away. Two exploitable vulnerabilities were there in the first place. But I'm also fascinated by DIVD's description of the attacker itself as loud, messy, and prone to overexplaining in its comments. If their assessment of agentic involvement holds up, machine-speed attacks do not necessarily have to be stealthy attacks. That makes high-quality logging, telemetry, and rapid containment even more valuable, because an offensive agent may generate a tremendous amount of observable behavior very quickly. And I have a lot of respect for DIVD's "open, transparent and honest, even if it sucks" approach to sharing what they're learning in the middle of a painful incident.

This story reinforces a point we regularly make in SANS NewsBites: Installing a patch does not necessarily mean you are secure. If attackers exploited a vulnerability before the patch became available, they may already have installed backdoors, created accounts, stolen credentials, or established other ways to maintain access. Where there is evidence that a vulnerability was actively exploited before it was patched, organisations should investigate for signs of compromise rather than simply install the update and consider the job done.

Have you verified how far back your logs go? Can/do you detect when devices stop sending logs to your SIEM? Yes, appliances like these do have on-device logs, but they (never) go far enough back, and for some reason, attackers like to zero out or change them to cover their tracks. What's up with that? Make sure that your device provisioning process has mandated steps for integrating with your SIEM/centralized logging. Have someone show you the security monitoring and alerting capabilities on your cloud services, and see if there are any new capabilities you need to leverage. Don't forget to have them show you how the information is used/stored/etc.

Looks like vendors are now disclosing that systems are being breached with zero-days, sometimes weeks before a patch is out. If you are running edge devices like this, I would consider reevaluating what is exposed on your network and how you can secure it. Perhaps it's time to reconsider the edge again, as VPNs, firewalls, and other portals are under such scrutiny.

Lee Neely’s advice in Tuesday's NewsBites to assume compromise and hunt now looks even more important, and his point here about retaining enough logs to do that hunt is critical. Mandiant says attackers had been exploiting this vulnerability since early September, deploying web shells, tunneling into internal networks, and stealing credentials. An upgrade fixes the vulnerable code, but it does not remove a web shell or invalidate credentials that have already been stolen. When an Internet-facing device has been exploited as a zero-day, patching and incident response need to happen together. Patch, yes. But hunt too.

Clearly, if you're a Zimbra shop, make sure that you've applied the update to version 10.1.20 or higher; this is a flaw that can be exploited remotely without authentication. If you don't need the SNMP notifications, uninstall the zimbra-snmp package. Now here's the one that will get eyerolls from staff: Ask how your SNMP services are secured. SNMPv3 should come up, as well as how community strings, where used, are chosen/changed/unique. Consider that if one SNMP weakness is being exploited, it's not unlikely that others are being looked for.

This report implies attackers are reverse-engineering vendor patches and building exploits faster than standard organizational patch cycles can keep up. It's another data point that automated patching right out of the gate has to become routine.

I am known for not wanting to criticize victims of a cyberattack, but it does concern me that in 2026 an attacker was apparently able to access such sensitive information in plaintext. Also, ten months is a very long time for an attacker to have access to a system containing highly sensitive information on millions of military personnel. While preventing attackers from gaining access is important, organisations also need to assume that some attacks will succeed and need to ensure they have the monitoring and detection capabilities needed to identify them quickly. Your security controls should not be thought of as solely designed to stop attackers, but to be designed to delay attackers long enough for you to detect and respond to them in a timely manner.

I'm wondering why it took ten months to find and stop the access. This appears to be another attack leveraging weaknesses in file sharing services. I'm thinking three things: First, make sure you really have monitoring on all your systems, including third-party services; second, review all your file sharing solutions to make sure that they are needed, configured securely, up-to-date, and supported; and lastly, meet your business requirements, including data protection. I was involved in ETL/data migrations back in 1993, and maybe before that. I bring that up as you likely have solutions that have been around a long time; they need to be on your radar.

Better late than never. However, every one of these breaches enriches the data brokers at the expense of the general welfare.

South Africa’s ATNS RFQ describes suspicious activity in OT that supports weather services, and indications consistent with early ransomware activity. Weather systems may not directly control an aircraft or issue an air traffic control instruction, yet their data feeds operational decisions. That makes this another example of how an attacker can potentially affect a physical operation by compromising the information that operators rely upon, rather than the primary control system itself. Because Aviation is designed around layers of systems and procedures, compromise of one supporting system should not automatically create an unsafe condition. This leads to a question all system operators should be asking: How long can operations continue safely when the integrity or availability of a supporting data source is uncertain?

The words you don't want to read together in a story are "ransomware" and "Air Traffic Control." Hopefully, the investigators engaged in this incident will be able to identify the source and root cause of the attack so that South Africa and other nations can shore up their cyber defences around air traffic control systems and indeed other critical OT environments.

Don't wait for the incident to perform a security assessment — particularly for OT systems, which are a hot target right now. There are advantages to hiring a third party, as they are independent and up on the latest tools and techniques for making the assessment and working for you. You need to have a better services map and inventory than the attackers. I recall Ed telling me to rest assured they (the attackers) will create one, but they're not going to share it with you.

Take a look at the Fakturownia security incident web page (it's in Polish, but your browser translation will work fine). This is a good example of explaining everything people need to know about the incident and what they need to do. Notice they also notified customers directly. Have you reviewed how you would publish a similar notification? Did you consider what happens if your primary website is down? How about communicating directly to affected users? Have you tested these options recently? Food for thought.

While passwords may not be implicated in the breach, "set new password" sounds like strong authentication is not in use. Do not let that be you.

Operation KillSwitch, in addition to shutting down the leak site, made several arrests, including the 16-year-old believed to be the main administrator, a suspected developer, a possible negotiator, and a believed affiliate of KillSec. Law enforcement continues to identify and stop ransomware gangs, which I applaud, but as successful as ransomware/extortion remains, we need to remain diligent — celebrate the win, but don't let our guard down.

Each case demonstrates the modern reality of organized cybercrime functioning like a business. They rely on distinct roles, such as malware developers, leak-site administrators, and cash-out networks, rather than isolated lone-wolf hackers. Law enforcement must employ aggressive, multi-pronged disruption tactics to counter these types of cybercriminal groups.

"The worst, the most corrupting lies are problems poorly stated." —Georges Bernanos.

IT is full of such problems. Business e-mail compromise is an egregious example. Business e-mail is not broken. It is not "compromised." It is working exactly as it is intended to work. The problem is fraudulent content. When we mis-name a problem we may inadvertently obscure the solution. The ways to resist this kind or fraud include out-of-band confirmation of unusual messages and multi-party controls for large transactions. Neither of these is suggested by "BEC."