CSOonline

A massive credential-compromise campaign dubbed “Fortibleed” has been found to expose tens of thousands of Fortinet devices worldwide, with researchers warning of persistent attacker access to affected enterprise environments. The campaign was first flagged by security researcher Volodymyr Diachenko, who posted on LinkedIn about finding an attacker-controlled list of potentially working FortiGate passwords collected “through various means.” Further details came from SOCRadar after its team independently discovered an operational server, which belonged to an unnamed threat actor and contained a list of stolen FortiGate passwords, tools, automation infrastructure, victim list, and some telling information about who could be behind the attack. “Attribution is ongoing, but the operational fingerprints are clear,” SOCRadar researchers said in a blog post, adding that the tooling and targeting choices are consistent with Russian-speaking threat actors. According to independent analyses, including by SOCRadar, Hudson Rock, and security researcher Kevin Beaumont, the threat actors systematically collected configuration files from internet-facing Fortinet FortiGate firewalls and used them to recover working administrator credentials. The initial access vector is presently unknown. CEO of watchTowr Benjamin Harris said the campaign is consistent with what he has been seeing lately. “The uncomfortable reality is that modern exploitation isn’t always about immediate impact,” he said. “It’s about harvesting data that retains value long after the underlying vulnerability has been patched.” These credentials were likely accumulated over time by exploiting many vulnerabilities affecting sensitive, externally facing Fortinet applications, he added. Fortinet did not immediately respond to CSO’s request for comments. Cracked passwords, global reach While SOCRadar initially reported that the dataset contained working login credentials for over 30,791 devices, further analysis by Beaumont, along with Hudson Rock, placed the affected devices at 75000, about 50% of the total internet-facing Fortinet firewalls found on Shodan. Researchers found affected devices across 194 countries, spanning more than 21000 domains. The dataset reportedly contains a mix of administrative and SSL VPN credentials recovered from compromised configuration files. Researchers said the operation is highly automated, allowing threat actors to collect, process, and crack credential material at a very large scale. SOCRadar found the top affected countries to be India, the US, and Mexico, with a little under 12000 compromised credentials between them. A credential-type breakdown revealed Organization-specific credentials to be most probed, indicating enterprise targeting. Explaining the potential impact, Beaumont said the threat actors “can log in remotely and gain remote access to the firewall — and so the network.” They can also change settings, including security controls, and make backdoor users, he added. Old Hashes, new problems Additional investigation into the campaign highlighted why some Fortinet deployments proved easier to crack than others. Researchers noted that many affected systems stored administrator credentials using older hashing approaches that were significantly less resistant to offline password-cracking attacks than more recent implementations. “Fortinet introduced PBKDF2-based password hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing the legacy SHA-256-based storage mechanism,“ Arctic Wolf researchers explained in a blog post. “However, when upgrading from earlier versions, existing administrator passwords remain stored as SHA-256 hashes until the corresponding administrator successfully logs in following the upgrade.” This could be leading to many organizations continuing to store admin credentials using older SHA-256 with Salt hashing mechanisms, they noted. Defenders told to assume credential exposure Researchers urged organizations to assume that credentials contained in exposed FortiGate configuration files have been compromised and to immediately rotate affected administrative and VPN passwords. Additional recommendations include enforcing multi-factor authentication (MFA), restricting internet access to management interfaces, and reviewing devices for signs of unauthorized access. Upgrading to supported FortiOS versions and replacing weaker or reused passwords was also advised. “After upgrading FortiOS, require all administrators to log in to the firewall at least once: this will automatically set the encryption to PBKDF2,” the researchers said. Admin passwords can also be manually updated by using a super_admin account, they noted. View the full article

The upper ranks of corporate security are seeing a high rate of change as companies try to adapt to the evolving threat landscape. Many companies are hiring a chief security officer (CSO) or chief information security officer (CISO) for the first time to support a deeper commitment to information security. Follow this column to keep up with new appointments to senior-level security roles and perhaps gain a little insight into hiring trends. If you have an announcement of your own that you would like us to include here, contact Peter Sayer, executive editor of news, at [email protected]. New CISO appointments in June 2026 SolarWinds appoints Justin Henkel as CISO IT management software vendor SolarWinds has named Justin Henkel its new CISO. Henkel was previously deputy CISO at OneTrust, and before that spent 25 years as an intelligence officer in the US Air Force. New CISO appointments in March 2026 Kathy Wang joins micro1 as CISO Frontier AI model training company micro1 has hired Kathy Wang as CISO. She was most recently CISO at hospitality software developer Otelier, and has previously held top cybersecurity roles at Discord and GitLab. Green Impact Exchange names John Visneski CISO John Visneski has joined stock exchange operator Green Impact Exchange as CISO. He was previously CISO at MGM Studios, and following that company’s acquisition by Amazon became head fo security for mergers and acquisitions. His cybersecurity career began with the US Air Force, where he served as cyber advisor to the Secretary and Chief of Staff of teh Air Force. New CISO appointments in January 2026 Julien Mousqueton joins Cohesity as field CISO for Europe Data security firm Cohesity has hired Julien Mousqueton as field CISO for Europe. His previous role was as CTO at IT service provider Computacenter. He is a reservist advisor for OFAC, the French national police force’s anti-cybercrime division, and created the real-time ransomware activity-tracking platform ransomware.live. View the full article

The upper ranks of corporate security are seeing a high rate of change as companies try to adapt to the evolving threat landscape. Many companies are hiring a chief security officer (CSO) or chief information security officer (CISO) for the first time to support a deeper commitment to information security. Follow this column to keep up with new appointments to senior-level security roles and perhaps gain a little insight into hiring trends. If you have an announcement of your own that you would like us to include here, contact Peter Sayer, executive editor of news, at [email protected]. New CISO appointments in June 2026 SolarWinds appoints Justin Henkel as CISO IT management software vendor SolarWinds has named Justin Henkel its new CISO. Henkel was previously deputy CISO at OneTrust, and before that spent 25 years as an intelligence officer in the US Air Force. New CISO appointments in March 2026 Kathy Wang joints micro1 as CISO Frontier AI model training company micro1 has hired Kathy Wang as CISO. She was most recently CISO at hospitality software developer Otelier, and has previously held top cybersecurity roles at Discord and GitLab. Green Impact Exchange names John Visneski CISO John Visneski has joined stock exchange operator Green Impact Exchange as CISO. He was previously CISO at MGM Studios, and following that company’s acquisition by Amazon became head fo security for mergers and acquisitions. His cybersecurity career began with the US Air Force, where he served as cyber advisor to the Secretary and Chief of Staff of teh Air Force. New CISO appointments in January 2026 Julien Mousqueton joins Cohesity as field CISO for Europe Data security firm Cohesity has hired Julien Mousqueton as field CISO for Europe. His previous role was as CTO at IT service provider Computacenter. He is a reservist advisor for OFAC, the French national police force’s anti-cybercrime division, and created the real-time ransomware activity-tracking platform ransomware.live. View the full article

For years we’ve heard the frightening prediction that AI will take jobs away from people. It will and it already is, but that doesn’t mean it won’t also create new jobs and skills demands — like every other labor trend driven by technology advances. Take security operations for example. Historically, security operations centers (SOCs) were built on a three-tier analyst model. Tier 1 analysts were junior personnel, paid to monitor activity and triage alerts. Their job was often described as “eyes-on-glass” as they tried to uncover signals among the noise. Tier 2 analysts specialized in investigating alerts (lots of them) that seemed fishy to the Tier 1 crew. When something was truly suspicious or malicious, they took remediation actions or worked with IT teams and others on incident response. Finally, Tier 3 analysts were the most senior and generally focused on threat hunting and engineering. Beyond hunting, these gurus performed deep forensic investigations, controls tuning, and detection engineering. Fast forward to 2026 and the AI-SOC (or the agentic SOC, autonomous SOC, human-augmented AI-SOC, etc.) is not only here but also maturing quickly. At last count, there are over 120 vendors claiming to participate in this market. As of today, AI-SOC capabilities center on autonomous alert triage and basic investigations. When something looks awry — a suspicious login, an EDR alert, etc. — agents call disparate tools to enrich the alert, create a timeline of activities, produce a confidence score, and even suggest steps for remediation. Sounds like an efficient Tier 1 analyst to me. In the near future, AI-SOCs will delve into Tier 2 analyst tasks with automated remediation. Additionally, agent swarms will have specialized roles for detection, investigations, remediation, and even system tuning. Some vendors also propose agents for threat hunting and continuous posture management. There’s still a lot of innovation, development, and real-world testing needed, but it’s clear that agents will increasingly perform more of the heavy lifting. So where does that leave humans? Here are a few roles where cybersecurity professional skills will be needed and in high demand. Security data engineer AI agents can deliver value only if they have continuous access to the right data. This requires moving beyond basic SIEM parsers and API connectors. Security data engineers must know the ins-and-outs of all the data: threat intelligence, identity and access management (IAM), cloud logs, endpoint/network/application telemetry, business context, third-party access patterns, and so on. All this data must fit into unified data layers that support multi-modal ingestion. This requires managing massive data pipelines to ensure context-rich, normalized, and high-fidelity logging from a potpourri of assets, cloud infrastructures, SaaS applications, and identity providers. Ideally, security data engineers will transform today’s data format and API mess into cohesive data layers using standards such as the Open Cybersecurity Schema Framework (OCSF). AI security agent orchestrators As agent-based solutions proliferate into swarms, someone has to act as the conductor of the orchestra. This involves an understanding of how to piece together multi-agent systems while defining boundaries and guardrails, establishing memory persistence, and determining which agents can take autonomous actions and which activities still demand a human-in-the-loop. Aside from technical agentic chops, AI security agent orchestrators will need a keen understanding of business-centric AI applications and workflows, as well as how all this relates to the latest threat intelligence. AI model trainers Rather than “set it and forget it,” AI models for security operations demand continuous updating and specific context for each individual organization based on threats, industry, and business processes. AI model trainers must become adroit with retrieval-augmented generation (RAG) to update models with local threat intelligence, asset criticality maps, new identities, and internal network architectural changes. Trainers must also be experts at fine-tuning datasets to ensure accurate and optimized results. AI-augmented threat hunters With AI agents in tow, threat hunting evolves from a sporadic to continuous activity. This means moving beyond cyber threat intelligence (CTI) update triggers such as new indicators of compromise (IoCs) to focus on adversary behavioral knowledge across entire campaigns and TTPs (throughout the MITRE ATT&CK framework). In the near future, agents do the basic work while AI-augmented threat hunters use their experience to come up with highly sophisticated, creative, and complex attack scenarios that standard detection logic likely misses. Hunters then utilize AI to instantly write complex queries across massive datasets. The goal? Hunt for adversary intentions — sensitive data exfiltration, data encryption, etc. — rather than easy adversary tradecraft such as file hashes or IoCs. AI-savvy red teaming/penetration tester As AI cascades across the enterprise, SaaS applications, and third-parties, organizations will need a new breed of red teamers to discover weaknesses and gaps in enterprise AI infrastructure and applications across the software supply chain. To accomplish this, AI-savvy red teams and penetration testers must possess the skill set and knowledge to circumvent new types of AI-enabled security defenses. Once beyond security controls, red teaming and penetration testing roles move on to attack an enterprise’s internal AI deployments — testing for things such as data poisoning, prompt injection vulnerabilities, and unauthorized access to underlying data stores used for building and fine-tuning various AI-models. As the saying goes, “AI won’t take your job, but someone who knows how to use AI to their advantage will.” Cybersecurity professionals who follow this logic, invest in their skill sets, and pursue jobs like those described above will flourish professionally, prosper economically, and be extremely valuable to their organizations. View the full article

Every major technology shift changes cybersecurity. I’ve spent much of my career working through major technology transitions, from the rise of the commercial internet to mobile and cloud computing. Each shift created new opportunities for innovation, but it also created new security problems organizations weren’t fully prepared for. AI may resemble previous technology shifts in some ways, but it differs in one important respect: it challenges one of the foundational assumptions modern security programs were built around: predictability. For most of my career, security teams operated in environments where systems behaved deterministically. Applications generally executed the same way every time. Infrastructure changed slowly enough for humans to map dependencies, understand trust boundaries and implement controls around them. Even cloud transformation allowed us to apply familiar security models to new infrastructure. AI changes those assumptions. Agentic systems make decisions dynamically. Large language models generate different outputs based on context. AI systems increasingly interact with external tools, APIs and environments in ways their developers can’t always fully predict ahead of time. When systems stop behaving consistently, the traditional “keep bad things out” approach to cybersecurity starts to break down. Prevention still matters. But prevention alone is structurally insufficient for environments where risk evolves continuously at runtime. Security was built for deterministic systems When I was helping build security programs years ago, much of the focus centered on hardening systems before deployment. Security teams tried to identify vulnerabilities early, reduce exposure and prevent attackers from gaining access in the first place. Even during the early years of cloud adoption, most organizations still approached security primarily through configuration and policy management. We worried about permissions, exposed storage buckets and identity sprawl while cloud security tools focused heavily on identifying misconfigurations and locking down infrastructure. Those controls remain critically important today. But the cloud era also taught us that security failures rarely happen in static diagrams. They happen in live environments, where permissions change, APIs evolve and identities gain unexpected access paths while systems interact in ways architects never fully anticipated. By the time organizations map one state of the environment, it’s already changed. Risk increasingly emerges at runtime, when identities inherit unintended access, APIs change behavior or AI agents interact with systems in ways no architecture diagram captured. In conversations I’ve had with companies, I’ve seen them go from generating hundreds of thousands of lines of code per month to millions. AI-assisted development tools are fundamentally changing software engineering workflows. A Harvard Business School study found that after developers gained access to GitHub Copilot, coding activity increased by 12.4% while time spent on project management tasks dropped by nearly 25% – a shift that can leave less time for the reviews and coordination governance depends on. From a business perspective, acceleration creates leverage, but it also compresses the time security teams have to understand what’s entering production. Attackers are beginning to use AI to reduce the manual effort historically required for reconnaissance, exploit chaining and vulnerability validation at scale. Security by obscurity isn’t a winning strategy. For years, organizations often accepted certain vulnerabilities because exploitation required too much time, expertise or effort from attackers. Vulnerabilities once considered difficult to chain together are becoming easier to operationalize at scale as attackers use AI to automate portions of the process. Security leaders need to recognize that some of the prioritization models organizations built over the last decade may no longer reflect today’s reality. Why prevention alone no longer works As AI systems become more autonomous, runtime visibility becomes critical. Many organizations historically treated runtime monitoring as a secondary layer behind prevention, viewing it mainly as a safety net for edge cases. That model breaks down when systems can evolve and interact faster than security teams can realistically validate in real time. If an AI agent can interact with multiple systems, generate new actions independently or adapt its behavior based on changing context, organizations can’t rely exclusively on pre-deployment controls. Security teams need visibility into what these systems are doing while they operate. That includes: What data AI systems can access How identities interact with sensitive environments What actions agents are taking Whether systems are deviating from expected behavior How quickly organizations can contain unintended consequences In many ways, modern security is shifting from trying to prevent every compromise to limiting how quickly unintended behavior can spread once systems begin acting autonomously. Security leaders should be careful not to overreact to this shift with fear-driven narratives. AI will absolutely create new security challenges, but it also creates opportunities for defenders. Security teams can’t scale using human labor alone anymore. The sheer volume of infrastructure changes, software generation and vulnerability management exceeds what most organizations can handle manually. We’re already seeing organizations experiment with AI-assisted triage, automated investigation workflows and defensive agents that can help security teams move faster and manage growing operational complexity. Security products are beginning to evolve into operational extensions of security teams rather than passive alerting systems. That evolution makes sense. Attackers are using automation and AI to increase speed and scale. Defenders will need to do the same to maintain parity. 5 priorities for security leaders in the AI era The organizations that adapt best to AI-driven risk won’t necessarily be the ones with the largest security teams or the biggest budgets. More often, they’ll be the ones that adjust fastest as software, infrastructure and attacker behavior evolve more quickly than traditional security operations were built to handle. That shift requires you to think differently about how you manage risk, operations and resilience. 1. Rebuild vulnerability management for AI-scale software development Many vulnerability management programs were already overwhelmed before AI accelerated software generation and lowered portions of the attacker cost curve. That challenge is becoming exponentially harder. Stop assuming old exploitability models will hold up in an environment where attackers can use AI to accelerate reconnaissance, vulnerability chaining and exploit development. You need to reassess how vulnerabilities are prioritized, validated and remediated because some of the assumptions organizations made over the last decade about attacker limitations may no longer reflect reality. Some organizations are already investing in model harnesses to deploy new AI models more effectively and securely. 2. Treat runtime visibility as a primary control Runtime monitoring can no longer be treated as a secondary capability behind prevention. Every team needs to invest in new forms of tooling to gain this visibility. That said, runtime monitoring is not something security organizations can vibe code into existence. We need to expect our security vendors to build continuous visibility into workloads, identities, APIs and AI system behavior in production environments. Prioritize clearer context around which vulnerabilities are reachable, exposed or being actively leveraged. This becomes increasingly important as AI systems interact with infrastructure and data in less predictable ways. 3. Use AI to augment defensive operations Most organizations can’t hire enough people to keep pace with the operational demands AI introduces. Use automation and AI to reduce investigation time, automate repetitive workflows and improve response speed. Human judgment still matters, but security teams are operating in environments where the volume of alerts, infrastructure changes and software generation exceeds what people can manage manually. AI can help teams focus on higher-order decisions instead of operational noise. 4. Focus on resilience and containment Perfect prevention has never existed, but it becomes even less realistic in highly dynamic AI environments. Think more carefully about blast radius reduction, rapid containment and operational resilience. Your ability to detect unintended behavior quickly and limit downstream impact will matter far more as organizations deploy more autonomous systems. I think many security leaders are still too focused on whether AI systems can fail instead of preparing for how to operate safely when they inevitably do. 5. Position security as an enabler of transformation One of the biggest mistakes security organizations can make right now is to approach AI primarily as something to stop. Boards and CEOs are pushing aggressively toward AI adoption because they view it as strategically necessary. If you position security purely as a blocking function, you risk losing influence during one of the most important technology transitions in decades. Executive teams understand AI transformation can’t succeed without strong security leadership guiding risk decisions in real time. That creates an opportunity to help your business move faster safely while building security programs better equipped for dynamic environments. AI is forcing a new security operating model The core challenge AI creates for security teams isn’t simply scale. It’s the erosion of predictability. The pace of change will accelerate as AI systems become more deeply integrated into business operations. To operate effectively in this environment, focus on building security programs that can adapt quickly, contain risk in real time and support innovation without losing visibility or control. Drive this evolution through both hiring and vendor investments, with a stronger focus on AI fluency and operational expertise. Only with prioritized investment in staff and tooling can you achieve stronger runtime awareness, faster response capabilities and operating models that keep pace with continuously changing infrastructure and software environments. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

There’s no shortage of agentic AI tools out there that offer to perform online tasks on your behalf, if only you’ll give them all your passwords and credit card details. The trouble starts when those agents don’t know when to stop — or when others don’t know to stop them. In Estonia, the country’s AI Council has plans to change that, proposing to issue government-backed digital identities for AI agents that spell out what powers a person or company is willing to delegate to them. “In the future, AI will increasingly perform digital operations on behalf of a person, company, or institution,” said Estonian Prime Minister Kristen Michal in a news release. “To do this, it must be clear who is acting, on whose behalf, with what rights, and who is responsible.” He supported the AI Council’s proposal to create a digital identity for AI agents that will define agents’ rights and enable them to act in a verifiable and auditable manner. The ID could, the council suggests, show whether an agent is only allowed to view data, create or edit documents, or make payments, and if so, up to what limit. First mover advantage There’s no telling when the plan will come to fruition — although Michal is keen for his country to take the lead. “If we act quickly and wisely, Estonia will become the first country in the world to create an official digital identity for AI agents,” he said. Estonia is already a leader in the use of digital identities for humans. Estonians can use their national digital ID cards for voting, signing documents, accessing medical and tax records. The country also offers foreigners the option of applying for “e-residency,” a digital identity enabling them to create a company in Estonia and digitally sign all related documents online as they interact with the country’s widely digitized administrative processes. Michal created the AI Council in January, calling on Estonian startups, investment funds, industry and research institutions to systematically implement AI across the country’s industry, education, healthcare, and energy sectors. AI vendors have already proposed creating digital identities for agents, but so far these are intended only to manage the activities of agents within the enterprise, or for interconnecting enterprise IT platforms, and none of them have the backing of governments. Estonia’s proposal could put the tiny Baltic country at the cutting edge of agentic AI usage and set an example for others. This article first appeared on Computerworld. View the full article

A design flaw in the Vertex AI software development kit (SDK) for Python, Google Cloud’s managed platform for building, training, and deploying AI agents, could allow hijacking and poisoning of models outside of a developer’s own Google Cloud project. According to Unit 42 researchers, a combination of bad bucket naming logic and missing authentication made it possible for an attacker to hijack the victim’s project by just knowing their project ID and region. “Since no two buckets across all of Google Cloud can share the same name, an attacker who is able to predict a bucket name can preemptively create it in their own project,” the researchers said in a blog post. “Any subsequent attempt to use a bucket with that name, even from a different project, silently falls back to the attacker’s bucket.“ Researchers said this is a known class of vulnerability that “takes advantage of the global uniqueness” of cloud storage bucket names. They called it “Bucket Squatting”. Successful exploitation could inject a malicious model that gets loaded by the Vertex AI infrastructure, resulting in code execution across tenants. The flaw was reported to Google, which reportedly fixed the underlying issue. Google did not immediately respond to CSO’s request for comments. pickle deserialization for cross-tenant RCE According to Unit 42, the vulnerable model workflow in Vertex AI SDK for Python versions 1.139.0 and 1.140.0 relied on a staging bucket name derived exclusively from a customer’s project ID and region. When a bucket with that name already existed, the SDK only verified its existence and did not confirm ownership. This created a bucket-squatting scenario in which an attacker could pre-create a bucket matching a victim’s expected staging bucket and wait for model uploads to be directed there. Once a model artifact was uploaded to the attacker-controlled bucket, the attacker could replace it with a malicious version during a narrow race-condition window before Vertex AI’s service agent retrieved it. The attack could turn into an RCE as machine learning models in Python are commonly stored using pickle or Joblib serialization formats. Since pickle deserialization can execute arbitrary code through specially crafted objects, a poisoned model could run remote code when loaded by Vertec AI’s serving infrastructure. This cross-tenant exploitation process was dubbed “Pickle in the Middle” by the researchers as it depended, in parts, on the deserialization of Python’s built-in pickle module. Google fixed the AI-hunted bug As part of the research, Unit 42 incorporated a large language model (LLM) into its code analysis workflow to accelerate vulnerability discovery. “Analysis that once took days can now be executed significantly faster,” the researchers said. “By iteratively narrowing the model’s focus and instructing it to look for specific patterns, we found paths that led to resources provisioned on the cloud, affected by user-controlled or project-derived inputs.” Google reportedly modified the affected workflow so that staging buckets are now validated before use, preventing attackers from registering bucket names that could be mistaken for resources belonging to other projects. The fixes were deployed in SDK versions 1.144.0 and 1.148.0, and users must upgrade to either of the patched versions. View the full article

Organizations racing to embed AI into business operations are realizing that the risk management frameworks they’ve relied on for decades aren’t built for the behaviors, failure modes, and ethical complexities AI systems introduce. Fortunately, a new generation of AI-specific frameworks has emerged to give organizations a structured way to identify where AI can go wrong, what controls to put in place, and how to demonstrate responsible AI use to regulators, customers, and investors. Not all of these emerging frameworks address the same problem. Some focus on governance and organizational accountability, others on technical security controls, threat modeling, or regulatory compliance. Choosing the right one for your organization depends on where your most pressing gaps reside. The frameworks are complementary, not competing, because they have different intents, priorities, and objectives, says Nicole Carignan, CISO at Darktrace. “There is overlap across these frameworks, but that overlap is helpful,” Carignan points out. “It reinforces the core practices organizations need to get right: governance, data integrity, security, accountability, oversight, testing, and continuous improvement.” Here are five frameworks worth considering for your AI risk management needs. ISO/IEC 42001 Artificial Intelligence Management System ISO/IEC 42001:2023 is the first internationally recognized formal standard for AI management. Published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in December 2023, ISO/IEC 42001 follows a similar structure to management system standards such as ISO 27001. The framework gives organizations a structured methodology for establishing policies, processes, operational controls, and accountability mechanisms to ensure responsible development and use of AI. ISO/IEC 42001 requires companies to document how they design, monitor, validate, and control AI systems, while also requiring them to conduct AI impact assessments to evaluate potential legal, ethical, and societal impacts. The standard covers governance structures, third-party supplier oversight, data management, transparency obligations, and lifecycle management. ISO/IEC 42001 is a voluntary but certifiable standard that applies across sectors and organization sizes. A growing number of organizations have begun using it to demonstrate adherence to responsible AI practice and alignment with regulations such as the EU AI Act. The ISO/IEC have described the framework as helping organizations align their AI practices with legal and regulatory requirements; demonstrate responsible AI governance; manage risks tied to bias, safety, and security; and enhance stakeholder trust. ISO 42001 is a great option for organizations just getting started with AI risk management, says Nicole Carignan, senior vice president for security and AI strategy and field CISO at Darktrace. “It provides the strongest foundation for building an AI risk management program, rather than addressing individual AI risks in isolation,” she explains. “From a program-building standpoint, ISO 42001 is the right place to start because it forces organizations to think holistically about ownership, governance, oversight, data integrity, security risk mitigation, accountability, and continuous improvement.” One downside Carignan is that the framework is resource-intensive to implement, and the full standard is not publicly available. Both challenges can be formidable for organizations that are very early in their AI governance journey, she says. NIST AI Risk Management Framework (AI RMF) Released by the US National Institute of Standards and Technology (NIST) in January 2023, the AI Risk Management Framework (AI RMF) is a voluntary framework designed to help organizations of all sizes and across all sectors identify, assess, and manage risks associated with AI systems across their entire lifecycle. The framework consists of two parts. The first offers guidance on how organizations should think about AI risks and the characteristics of trustworthy AI systems, such as validity, safety, security, transparency, explainability, privacy, and fairness. The second part is structured around four interconnected functions: Govern focuses on what organizations need to do to build internal culture, policies, and accountability structures for AI use. Map involves understanding the broader context and potential risks of specific AI systems. Measure focuses on how organizations must evaluate and track those risks using both qualitative and quantitative methods. Manage provides guidance on risk prioritization and appropriate responses such as mitigation, transfer, or acceptance. NIST AI RMF includes a separate Playbook that provides practical implementation steps to help organizations implement each of these functions effectively. For organizations that are not ready to pursue ISO 42001 formally, the NIST AI RMF can serve as a more flexible and accessible starting point, Carignan says. “It is public and gives organizations a common language for understanding and mitigating AI risk,” she adds. “But if the goal is to build a durable AI risk program, ISO 42001 is the strongest foundation.” Ram Varadarajan, CEO at Acalvio recommends NIST AI RMF as a good place for organization to get started on AI risk governance, “because it’s built around maturity rather than pass/fail audits.” Its gives organizations starting from zero an opportunity to discover where they stand rather than immediately handing out a failing grade. “More importantly, it forces the three conversations that have to happen first: who owns AI risk, what AI is actually running, and who gets hurt if something goes wrong,” Vardarajan says. While researchers at Forrester described NIST AI RMF as a step in the right direction soon after its launch, they also expressed concern over conflicts of interest among the multiple stakeholders that helped draft the framework, the absence of an explicit role for data governance, and the fact that the framework was “still descriptive and not prescriptive.” As a result, “Chief data officers and heads of data science need to navigate this framework wisely to interpret and apply it to their AI governance efforts,” the analyst firm advised. ENISA Framework for AI Cybersecurity Practices ENISA, the European Union Agency for Cybersecurity, developed its Framework for AI Cybersecurity Practices (FAICP) in anticipation of the EU AI Act. Published in June 2023, the framework gives EU organizations structured, AI-specific cybersecurity guidance for enhancing the trustworthiness of their AI activities. FAICP is organized around three progressive layers. The first covers foundational information and communications technology cybersecurity practices that AI systems inherit by running on standard software infrastructure. The second addresses AI-specific risks, including adversarial attacks, model tampering, data pipeline integrity, and supply chain security. The third provides sector-specific guidance for regulated industries such as energy, healthcare, and telecommunications. According to the European Parliament, FAICP’s layered nature provides organizations with “a gradual approach” to enhancing the trustworthiness of their AI activities. FAICP is voluntary, but its close alignment with the EU AI Act and the NIS2 Directive, which is the EU’s primary cybersecurity law, means that EU regulators consider the framework as a baseline for AI governance practices at all organizations doing business within the EU. FAICP is important because “Europe’s AI Act will likely become the global reference point, the same way Europe’s data privacy law became the de facto standard for companies worldwide regardless of where they’re headquartered,” Vardarajan predicts. “Within two to three years, expect two frameworks to dominate: the EU AI Act setting the legal floor, and NIST AI RMF providing the operational playbook for meeting it,” Vardarajan says. ISO/IEC 23894:2023 Information Technology — Artificial Intelligence — Guidance on Risk Management The ISO/IEC 23894:2923 framework provides organizations with specific guidance on managing risks associated with artificial intelligence. Released jointly by ISO and IEC in February 2023, the framework builds on and adapts the ISO 31000 general risk management standard to address AI-specific risks such as those tied to algorithmic bias, model drift, unpredictable behavior, and lack of transparency in decision-making. It provides organizations a way to evaluate the likelihood and potential consequences of these risks throughout the full AI system lifecycle. The ISO has described the standard as a “companion to ISO 31000 (Risk Management) and ISO/IEC 42001 (AI Management Systems).” The main difference between ISO/IEC 42001 and ISO/IEC 23894 is that the former is a certifiable management system. It provides organizations with the full requirements for establishing, implementing, and maintaining an AI management system. ISO/IEC 23894:2023 on the other hand is a guidance-only standard focused on how to identify, assess, and manage AI-specific risks. “Notably, ISO/IEC 23894 offers concrete examples of effective risk management implementation and integration throughout the AI development lifecycle and provides detailed information on AI-specific risk sources,” according to UK-backed AI Standards Hub. “A key benefit of this standard is that application of the guidance can be customized to any organization and its business context.” Google Secure AI Framework (SAIF) Google Secure AI Framework (SAIF) is Google’s practical guide for helping organizations develop and run AI systems with strong built-in protections against digital threats. Launched in 2023, it focuses on weaving security and privacy considerations directly into every stage of an AI project’s life cycle, from design through deployment and ongoing operation. Its main goal is to tackle the unique vulnerabilities that come with AI technologies such as attacks that tamper with training data, trick models through engineered prompts, or steal sensitive information. SAIF draws on Google’s own experiences developing and deploying large scale AI systems and therefore is more engineering-heavy than other frameworks. SAIF is largely focused on helping organizations make their AI systems more resistant to cyberattacks and cyber adversaries and covers areas like data handling, underlying infrastructure, the AI models themselves, user-facing applications and verification processes. It offers organizations practical guidance on implementation controls, shared responsibility, and defending against technical attacks. Technology consultancy Thoughtworks has assessed SAIF as a framework that helps organizations systematically address “common threats such as data poisoning and prompt injection through a clear risk map, component analysis, and practical mitigation strategies.” According to the firm, SAIF’s “focus on the evolving risks of building agentic systems especially timely and valuable. SAIF offers a concise, actionable playbook that teams can use to strengthen security practices for LLM usage and AI-driven applications.” David Brumley, chief AI and science officer at Bugcrowd, says that for organizations that want to adopt a framework, the question is not really “which AI risk framework is best?” but “which framework helps [the] organization safely build, deploy, and learn from AI in the real world?” While most of the currently available AI risk frameworks have their use, most are still focused on preventing bad outcomes rather than helping organizations pave safe roads for a technology that is already inevitable. “That distinction matters,” Brumley says. “AI adoption is not waiting for perfect governance, and those who focus on a [risk management framework] could inadvertently create a shadow AI problem in their organization.” View the full article

The 2026 Verizon Data Breach Investigations Report analyzed more than 22,000 confirmed data breaches across 145 countries. Its findings point to a single uncomfortable truth: organizations cannot patch fast enough to prevent every incident. Exploitation of vulnerabilities surged to become the leading initial access vector, the median time to remediate a critical flaw climbed to 43 days, and the volume of critical vulnerabilities grew 50% year over year. Even top-performing organizations only managed to fix 30% to 40% of known exploited vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalog within the first week of detection. That rate barely budged despite years of investment in tooling, process maturity and regulatory pressure. Most organizations will eventually face a serious incident. The quality of your response determines the outcome. Ransomware hits 48% of breaches. The payment decision is just the beginning Ransomware appeared in 48% of all confirmed breaches, up from 44% the prior year. Among cases where organization size was known, 96% of victims were small and medium-sized businesses. The “climax” of every ransomware tabletop I witness has always been the question: pay or refuse? The DBIR reveals that 69% of victims chose not to pay, up from 65% the year before. That number held even when attackers encrypted systems. Refusing is becoming standard practice. The median payout dropped to $139,875. Facing shrinking revenues, ransomware operators now deliberately maximize operational disruption to force faster decisions. The 2025 attack on Marks & Spencer knocked out online sales, inventory tracking and refrigeration monitoring for weeks, costing an estimated £300 million. The Jaguar Land Rover breach halted manufacturing for five weeks, inflicted £1.9 billion in damages and dragged UK GDP below its quarterly forecast. Consider using these cases to inspire your next ransomware drill. The ransom question is one agenda item. Sustaining operations without primary systems, coordinating with legal counsel and law enforcement, managing customer and investor communications under regulatory deadlines, deciding what to disclose and when: these are the decisions that determine whether a company survives a ransomware event or becomes a cautionary headline. Organizations that rehearse only the payment question are practicing the opening scene and skipping the rest of the play. Third-party breaches jumped 60%. Your exercises should reflect that Breaches involving a vendor, supplier or service provider reached 48% of all confirmed incidents, a 60% increase from the previous year. This metric doubled the year before that. The trajectory is unmistakable. The DBIR identifies three archetypes: a vulnerability in a vendor’s product opens the door to your environment; a vendor holding your data gets compromised directly; or an attacker breaches the vendor and pivots laterally into your network. Several of the year’s most prominent campaigns triggered two or all three archetypes simultaneously. Most tabletop programs ignore this scenario entirely. I have seen organizations rehearse their internal playbooks dozens of times without once simulating a call to a compromised vendor. When the real call comes, they freeze. A third-party breach tests a fundamentally different set of skills than an internal compromise. When a vendor is breached, the information your team needs most is the information the vendor is least prepared to share quickly. Tabletop exercises should simulate that friction. Participants should practice asking precise questions: What data of ours did you hold? What is the confirmed scope? What logs exist? How are you notifying other affected customers? The other half of the exercise is equally critical. Your customers will demand answers while the investigation is still unfolding. Transparency builds trust. Premature attribution destroys partnerships. The discipline lies in communicating what you know and what you are doing about it without publicly blaming a vendor whose cooperation you still require. A press statement that throws a third party under the bus may generate a satisfying headline. It will also guarantee that the vendor’s legal team stops sharing information with yours. Vulnerability exploitation is the top attack vector. AI will accelerate it Exploitation of vulnerabilities reached 31% of all confirmed breaches, a 55% increase over the prior year’s 20%. It displaced credential abuse as the leading initial access method for the first time in the DBIR’s history. The structural problem is straightforward. Organizations faced a median of 16 CISA Known Exploited Vulnerabilities in 2025, up from 11 the year before. Only 26% were fully remediated, down from 38%. Defenders are caught in Alice’s Red Queen Race. AI is compressing the timeline further. The DBIR’s collaboration with Anthropic examined 793 threat actors who misused AI platforms for malicious purposes between March 2025 and February 2026. The median actor sought assistance across 15 distinct ATT&CK techniques. Thirty-two percent of AI-assisted initial access activity targeted vulnerability exploitation specifically. The report notes that creating exploit tools, adapting them across languages and discovering new vulnerabilities “is within reach with current AI coding assistance.” Anthropic’s own threat research documented the first known AI-orchestrated cyber espionage campaign, in which attackers used agentic AI to execute intrusions autonomously. By December 2025, researchers documented VoidLink, a complete malware framework built by an AI agent in six days. Twenty-nine percent of KEV vulnerabilities were attacked before public disclosure that year. This acceleration demands a shift in how organizations exercise their incident response capabilities. NIST SP 800-84 has long recommended formal test, training and exercise programs for evaluating incident response preparedness. The growing speed and volume of exploitation makes that guidance urgent. Technical tabletop exercises, where participants work through actual triage rather than discuss hypothetical responses, should become routine. Teams need to practice identifying affected systems, determining blast radius, executing containment playbooks and coordinating remediation across departments under realistic time pressure. The window between initial compromise and full-blown breach is shrinking. How fast your technical teams can triage and contain directly determines the severity of the outcome. Organizations that encounter these decisions for the first time during a live incident will not move fast enough. The breach you practice for is the one you survive The 2026 DBIR and Google’s M-Trends 2026 report paint the same picture from different angles: the speed of attacks is accelerating, the surface area is expanding through third-party dependencies, and the sophistication gap between attackers and defenders is narrowing thanks to widely available AI tooling. These are not projections. They describe the threat landscape as it exists today. Organizations that wait for a breach to test their response capabilities will discover their gaps at the worst possible moment. Playbooks that have never been exercised under pressure tend to collapse on first contact with a real incident. Communication plans that look reasonable on paper fall apart when the general counsel, the CISO and the CEO are in the same room arguing about disclosure timing while customers flood the support lines. The remedy is deliberate, repeated practice. Tabletop exercises that simulate ransomware scenarios should go beyond the payment question and into the operational chaos that follows. Exercises involving third-party breaches should force participants to navigate the tension between transparency and partnership preservation. Technical exercises should compress timelines and demand the same speed of triage that a real exploitation campaign would require. None of this is new advice. But the 2026 data makes the stakes clearer than ever. The organizations that build crisis response as a practiced skill will weather these incidents. Those that treat their incident response plan as a static document will learn its shortcomings the hard way. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Despite best efforts by defenders, malicious emails continue to slip through the cybersecurity cracks, leading some enterprises to implement a layered “defense in depth” strategy that incorporates multiple tools. Microsoft seems to be challenging this idea, revealing that there are only nominal returns from adding integrated pre- and post-send partners to Defender for Office 365’s protections. According to its new quarterly benchmarking data, the tech giant catches the vast majority of malicious and spam emails before delivery, misses the fewest compared to competitors by a wide margin, and removes nearly 100% of dangerous emails that do reach the inbox. Collectively, its integrated partners improve that catch rate by less than .05%. While these numbers seem to tip the scales towards a one-vendor email security stack, experts urge enterprises to be skeptical and cautious of such vendor claims. Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, pointed out, “percentages obscure the true quantity and severity of what’s getting through, and, considering it only takes one message to result in an incident, it’s simple enough to argue that there is real value in the defense in depth that having multiple tools provides.” Malicious and spam email catch by the numbers Microsoft introduced its quarterly benchmarking report in July 2025 alongside a Defender integrated cloud email security (ICES) ecosystem designed to support multi-vendor security strategies. The SEG players it ranked itself against this year includes Mimecast, Proofpoint, Hornetsecurity, Trend Micro, Iron Port (Cisco), Barracuda, and FireEye (Trellix); ICES companies include Abnormal, Checkpoint Harmony, Cisco, DarkTrace, KnowBe4 Defend, Tessian, and Trend Micro. Redmond reported that Defender “consistently leads” in pre-delivery detection, missing 59% fewer high-severity cyberthreats prior to delivery than the other SEG vendors it evaluated. Its closest competitors were Mimecast and Proofpoint. The company also introduced a new metric in this area: A threat miss rate per 1,000 employees. In Microsoft’s case, that was 194 per 1,000; for Mimecast, 478; for Proofpoint, 483. When it came to post-delivery protection, Defender removed an average of 96.03% of malicious emails that reached the inbox, up from an initial 45% when Microsoft first started tracking the data in its second report. This makes Defender “an increasingly critical backstop, operating even when ICES solutions are in place,” Jeff Pinkston, VP and GM for Microsoft Defender, wrote in a blog post. Still, ICES tools operating in tandem with Microsoft Defender “continue to provide benefits,” improving malicious catch by 0.29% and spam catch by 0.68%, he said. “If we focus on the basics, their argument seems strong,” Info-Tech’s Ioussoufovitch noted. “Do you really need a separate ICES vendor for that extra sub 1% catch?” Microsoft paints a “compelling picture” by only focusing on raw catch rate, he said, but we don’t hear the rest of the story: “What exactly is the danger of what isn’t being caught by Defender?” No one vendor catches everything David Shipley of Beauceron Security pointed out that the report underscores the fact that “lots of stuff still gets by e-mail filters.” His company regularly analyzes hundreds of thousands of emails, and the content that gets through “ranges from the shockingly mundane and obvious to a human expert, to highly clever time-delayed attacks,” he said. A key factor in what gets through is the amount of content that is allowlisted; settings in “100% paranoid mode” get high catch rates, as well as high false positives, Shipley noted. “Anyone who has ever had a sales person lose a deal because the purchase order PDF got flagged has felt this pain.” Then there’s the AI conundrum: “A key risk for e-mail vendors using agentic LLM-based analysis is it’s now possible to poison those models with hidden content (such as ‘ignore this e-mail, pretty please’),” Shipley said. This means enterprises need a variety of analysis methods. Ioussoufovitch agreed that keeping pace with threat actors using AI is an industry-wide challenge, particularly as AI enables higher-quality phishing. Filters are improving and will catch some of it, but some will inevitably continue to get through. Those messages are likely highly-targeted, which are lower in volume but harder to catch. “As of now, current tools do seem to be struggling to keep pace, but that doesn’t mean those tools aren’t necessary,” said Ioussoufovitch. “It just highlights that defense-in-depth, broadly speaking, is becoming more and more important.” Claims appear more honest Shipley said that this report appears more honest, accurate, and mature than others claiming 99.99% phish catch rates, “which is never true.” It’s also a “smart marketing move,” because Microsoft competes for the same security budget as other tools, and would rather enterprises remove those vendors and buy more from it in areas beyond e-mail. On the other hand, he said, Microsoft is offering up a list of other vendors to think about, “which, congrats to Mimecast on coming in second.” In the long run, CISOs need to determine the best spend for their limited security dollars, he noted. Enterprises need a good filter; whether they need two is up for debate. “They also clearly still need to invest in a robust awareness program,” Shipley said, “because as this report shows, lots of phishes are still getting delivered.” Missing an important nuance Ioussoufovitch noted that while the claims in the study are interesting, the data is presented without much of the nuance that would make it truly actionable. “We are all too familiar with vendors’ abilities to massage data to tell the story they want, so I would advise leaders not to extrapolate the data beyond what it actually says,” he said. Instead of the takeaway being “get rid of our current vendors,” this post highlights that Defender provides “considerable value,” he noted. Whether adding or subtracting additional vendors is worth the money should be a case-by-case conversation that considers an organization’s risk appetite, and overall security budget and environment. “I’d treat these claims more as a reminder to assess your own environment and compare detections,” he said. “Come to conclusions based on the data you have, not what a vendor is presenting.” View the full article

Google is warning of a cyber espionage campaign linked to a China-nexus threat actor, UNC6508, that kept close tabs on valuable US and Canadian research environments for over a year. The campaign abused REDCap, a widely adopted platform for collecting and managing research data. Attackers, now disrupted, intercepted REDCap’s upgrade process to inject persistence malware. According to Google’s Threat Intelligence Group (GTIG), the campaign was particularly interested in academic institutions, medical research centers, healthcare providers, military health networks, and defense-focused research programs. Google said UNC6508 historically infected the legacy REDCap versions, and the observed campaign was just building on that initial compromise to push code for persistence. “GTIG was not able to confirm how UNC6508 initially gained access to the REDCap server,” GTIG researchers said in a blog post. “By design, REDCap allows administrators to continue running legacy software side-by-side with the current version. UNC6508 was observed probing for these vulnerable legacy versions on several target organizations’ REDCap systems.” The state-sponsored group was after a wide range of sensitive research and defense-related information, spanning national security, AI, cyber operations, and medical research. Research platform became the front door Other than persistence, the campaign supported credential discovery, internal reconnaissance, and post-compromise operations. UNC6508 used a payload tracked as INFINITERED, which is a modular malware designed to trojanize legitimate REDCap system files. The malware has three dedicated components: a dropper and upgrade Interception, a credential harvester, and a backdoor with command and control (c2). The upgrade interception module reads the legacy REDCap versions still accessible on some current REDCap deployments, already infected with malicious logic through an unknown initial access, and extracts the malicious logic from that version. It then injects this code into the upgrade system file. Parallelly, the other two modules inject credential harvester code into the authentication system file, and backdoor code into the custom hooks configuration file, respectively. “Upon establishing a foothold on the REDCap server, UNC6508 performed internal reconnaissance and credential discovery to obtain database and service account credentials,” GTIG researchers said in a blog post. “The threat actor also deployed a web shell named “help.php”, which maintained persistence and functioned as an uploader in the REDCap application.” The backdoor supports a range of remote commands that allow operators to manage files, execute shell commands, gather system information, and maintain control over compromised REDCap servers, providing UNC6508 with a rich post-compromise toolkit. REDCap’s maintainers did not respond to CSO’s request for comments. Hunting for and removing INFINITERED Because INFINITERED embeds itself into REDCap’s upgrade workflow and modifies legitimate application files, organizations are encouraged to inspect REDCap environments for unauthorized file modifications, unexpected web shells, and signs of credential harvesting activity using the GTIG provided YARA rule. Google also recommends upgrading vulnerable REDCap deployments, reviewing legacy versions that remain accessible alongside current installations, and validating the integrity of application files before and after upgrades. Enforcing phishing-resistant 2-step verification, device-bound session credentials, and relevant DLP rules were also recommended for tighter controls. Google said it notified several organizations across the US and Canada that it believes were compromised with INFINITERED, and offered remediation assistance. View the full article

Cisco has released fixes for a vulnerability in its Catalyst SD-WAN Manager software after becoming aware of limited exploitation of the flaw, which could allow an authenticated attacker to create or overwrite files that may later be used to gain root privileges. The vulnerability, tracked as CVE-2026–20262, affects the web interface of Cisco Catalyst SD-WAN Manager, formerly known as SD-WAN vManage, which enterprises use to manage SD-WAN deployments across distributed network environments. Cisco said the flaw stems from insufficient validation of user-supplied input during a file upload process. An authenticated remote attacker with valid credentials and at least write access could exploit the flaw by sending a crafted HTTP request to an affected API endpoint. A successful exploit could allow the attacker to create or overwrite any file on the underlying operating system. That file could later be used to elevate privileges to root, Cisco said. The company said the vulnerability affects all deployment types, regardless of device configuration, including on-premises deployments, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud managed by Cisco, and Cisco SD-WAN for Government. Cisco said there are no workarounds and advised customers to upgrade to fixed software releases. Cisco rated the flaw as a medium-severity risk. While the company did not provide details on the exploitation activity, it advised administrators to review SD-WAN Manager logs for attempts to upload files such as index.jsp and .war files. Root access raises network-wide risk The risk is not limited to a single device or endpoint. Cisco Catalyst SD-WAN Manager acts as a centralized control point for SD-WAN environments, making compromise of the management layer a broader operational concern for enterprises. A successful root compromise could have consequences across multiple branches and business applications, analysts said. “Root access to Cisco Catalyst SD-WAN Manager can become a network-wide control-plane compromise, and that can affect branch uptime, traffic segmentation, cloud connectivity, and the availability and integrity of critical business applications,” said Keith Prabhu, founder and CEO at Confidis. “This could lead to revenue loss, operational disruption if locations lose WAN connectivity, security exposure, incident response costs, and overall loss of reputation.” Devashri Datta, a cybersecurity researcher who previously worked in network security governance at Cisco, said root access to the SD-WAN Manager could allow an attacker to push destructive configuration templates or wipe local policies across large numbers of branch routers. Because enterprise segmentation is often enforced through centralized SD-WAN policies, a compromised controller could also be used to alter traffic separation rules, including policies tied to Virtual Routing and Forwarding instances, potentially enabling lateral movement across environments that were previously isolated, she said. Attackers could also manipulate cloud traffic-steering policies or degrade application-aware routing settings for critical systems, affecting services such as ERP platforms or real-time databases, Datta added. The impact of a compromise could go beyond a conventional security incident because changes made through the SD-WAN console may initially appear to be routine network or configuration problems, said Akshat Tyagi, associate practice leader at HFS Research. That could make attacks harder to detect, particularly if disruptions affect branch connectivity, SaaS access or traffic routing before security teams identify them as malicious, he said. A broader management-plane concern Security teams should view vulnerabilities in SD-WAN orchestration systems as a broader management-plane risk rather than only a patching issue, analysts said. “CISA and NSA have issued guidance about architecture, exposure, and management-plane hygiene, which goes beyond typical CVE-by-CVE patching,” Prabhu said. “Attackers are targeting the SD-WAN controller to gain fabric-wide control over routing, segmentation, and security policy, which can impact many sites at once. This warrants treating SD-WAN managers as Tier-0 assets: isolate and harden them, tightly control and monitor access, and assume potential controller compromise in your architecture.” Datta said CISOs should not treat flaws in network orchestration platforms as routine patching events because the management plane is a central trust layer in software-defined infrastructure. “When a platform repeatedly suffers from structural weaknesses such as insufficient input validation or authentication bypasses, it signals that the vendor’s internal secure software development lifecycle (SDLC) is struggling to defend its core trust boundaries,” Datta said. Emergency WAN updates can also create operational friction for global enterprises because they require testing, change windows, and rollback planning across infrastructure that supports branch and cloud connectivity, she said. Tyagi said CISOs should use the incident to review who can access SD-WAN management consoles, who has administrative access, and whether any unusual activity has already occurred. Patching remains essential, but analysts said organizations should also restrict access to SD-WAN management interfaces, require phishing-resistant multifactor authentication, isolate orchestration systems from general corporate networks, and continuously stream telemetry from managers and edge routers to an independent SIEM. Datta said enterprises should also press networking vendors for software supply chain transparency, including SBOM and VEX data, so they can assess exposure before rolling out emergency upgrades. View the full article

Cisco has released fixes for a vulnerability in its Catalyst SD-WAN Manager software after becoming aware of limited exploitation of the flaw, which could allow an authenticated attacker to create or overwrite files that may later be used to gain root privileges. The vulnerability, tracked as CVE-2026–20262, affects the web interface of Cisco Catalyst SD-WAN Manager, formerly known as SD-WAN vManage, which enterprises use to manage SD-WAN deployments across distributed network environments. Cisco said the flaw stems from insufficient validation of user-supplied input during a file upload process. An authenticated remote attacker with valid credentials and at least write access could exploit the flaw by sending a crafted HTTP request to an affected API endpoint. A successful exploit could allow the attacker to create or overwrite any file on the underlying operating system. That file could later be used to elevate privileges to root, Cisco said. The company said the vulnerability affects all deployment types, regardless of device configuration, including on-premises deployments, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud managed by Cisco, and Cisco SD-WAN for Government. Cisco said there are no workarounds and advised customers to upgrade to fixed software releases. Cisco rated the flaw as a medium-severity risk. While the company did not provide details on the exploitation activity, it advised administrators to review SD-WAN Manager logs for attempts to upload files such as index.jsp and .war files. Root access raises network-wide risk The risk is not limited to a single device or endpoint. Cisco Catalyst SD-WAN Manager acts as a centralized control point for SD-WAN environments, making compromise of the management layer a broader operational concern for enterprises. A successful root compromise could have consequences across multiple branches and business applications, analysts said. “Root access to Cisco Catalyst SD-WAN Manager can become a network-wide control-plane compromise, and that can affect branch uptime, traffic segmentation, cloud connectivity, and the availability and integrity of critical business applications,” said Keith Prabhu, founder and CEO at Confidis. “This could lead to revenue loss, operational disruption if locations lose WAN connectivity, security exposure, incident response costs, and overall loss of reputation.” Devashri Datta, a cybersecurity researcher who previously worked in network security governance at Cisco, said root access to the SD-WAN Manager could allow an attacker to push destructive configuration templates or wipe local policies across large numbers of branch routers. Because enterprise segmentation is often enforced through centralized SD-WAN policies, a compromised controller could also be used to alter traffic separation rules, including policies tied to Virtual Routing and Forwarding instances, potentially enabling lateral movement across environments that were previously isolated, she said. Attackers could also manipulate cloud traffic-steering policies or degrade application-aware routing settings for critical systems, affecting services such as ERP platforms or real-time databases, Datta added. The impact of a compromise could go beyond a conventional security incident because changes made through the SD-WAN console may initially appear to be routine network or configuration problems, said Akshat Tyagi, associate practice leader at HFS Research. That could make attacks harder to detect, particularly if disruptions affect branch connectivity, SaaS access or traffic routing before security teams identify them as malicious, he said. A broader management-plane concern Security teams should view vulnerabilities in SD-WAN orchestration systems as a broader management-plane risk rather than only a patching issue, analysts said. “CISA and NSA have issued guidance about architecture, exposure, and management-plane hygiene, which goes beyond typical CVE-by-CVE patching,” Prabhu said. “Attackers are targeting the SD-WAN controller to gain fabric-wide control over routing, segmentation, and security policy, which can impact many sites at once. This warrants treating SD-WAN managers as Tier-0 assets: isolate and harden them, tightly control and monitor access, and assume potential controller compromise in your architecture.” Datta said CISOs should not treat flaws in network orchestration platforms as routine patching events because the management plane is a central trust layer in software-defined infrastructure. “When a platform repeatedly suffers from structural weaknesses such as insufficient input validation or authentication bypasses, it signals that the vendor’s internal secure software development lifecycle (SDLC) is struggling to defend its core trust boundaries,” Datta said. Emergency WAN updates can also create operational friction for global enterprises because they require testing, change windows, and rollback planning across infrastructure that supports branch and cloud connectivity, she said. Tyagi said CISOs should use the incident to review who can access SD-WAN management consoles, who has administrative access, and whether any unusual activity has already occurred. Patching remains essential, but analysts said organizations should also restrict access to SD-WAN management interfaces, require phishing-resistant multifactor authentication, isolate orchestration systems from general corporate networks, and continuously stream telemetry from managers and edge routers to an independent SIEM. Datta said enterprises should also press networking vendors for software supply chain transparency, including SBOM and VEX data, so they can assess exposure before rolling out emergency upgrades. View the full article

Zero trust is 15 years old, and like many teenagers, it can feel misunderstood and underappreciated. The concept of zero trust was first defined by John Kindervag, a Forrester analyst at the time, as a strategy to replace the outmoded perimeter security model with a “never trust, always verify” approach. But going from principle to practice isn’t easy. Accenture reports that 88% of organizations have encountered significant challenges implementing zero trust. In a recent Gartner survey, 35% of respondents who indicated that they either attempted or partially attempted a zero-trust initiative suffered failures that adversely affected their organization. “Gartner has observed numerous instances of failed zero-trust initiatives among end users who lacked a strategic and measurable plan,” the report says. At last year’s DefCon 33 conference, U.K. security researchers from AmberWolf poked holes in zero trust by identifying potential vulnerabilities in zero-trust network access (ZTNA) offerings from three vendors. “It turns out there are no magic ZTNA beans; we’ve got the same old bug classes reimagined for a new technology stack,” said AmberWolf researcher Richard Warren. “Rather than zero trust, we’re actually putting a lot of trust into these vendors to process our data securely.” Morey Haber, author and chief security advisor at BeyondTrust, sums up the state of zero trust in 2026 this way: “We all agree: zero trust is necessary. But it’s been hard to implement.” Haber describes the gap between intention and execution as “massive” during a Today in Tech episode focused on whether zero trust is failing or just misunderstood. “It doesn’t matter what you read or which framework you follow,” Haber said during the podcast. “The core issue is that we have a concept with principles and tenets, but not enough guidance on how to implement it.” Here are some myths and misconceptions associated with zero trust, as well as tips on how to avoid the pitfalls and successfully implement zero trust. Myth: Zero trust is a product Even after 15 years, there is still considerable confusion about what zero trust is. It answers to many definitions—strategy, philosophy, concept, mindset, and architecture. Chase Cunningham, who bills himself as DrZeroTrust, says,”Security is not a product, but a combination of strategy, process, and execution. Zero trust is not just an architecture—it’s a mindset. There is no zero-trust product, period.” Haber agrees. “You have vendors claiming to sell “zero-trust” products, which is misleading. There’s no such thing as a zero-trust product. Products implement security controls, but they don’t embody zero-trust principles.” He cautions, “If a vendor says, ‘This remote access solution achieves zero-trust principles,’ that’s great, but I have yet to see one that delivers more than 10%-15% of the required controls.” Gartner adds, “The concept of zero trust is a security approach that organizations adopt to mitigate access risks associated with networks, applications, and associated data. This is frequently overshadowed by vendor marketing, which tends to promise high expectations but often delivers suboptimal results.” Myth: Zero trust is a technology George Finney, CISO at the University of Texas and author of two books on zero trust, tells Network World that zero trust is not a technology; in other words, it’s not micro-segmentation to block lateral movement by attackers; it’s not policy-based identity to control who gets access to enterprise resources. Those are tools and tactics that help implement zero trust. Zero trust at its core is a way of thinking about risk that requires breaking down silos among security teams, networking groups, business units, compliance, and risk management functions, according to Finney. The first pillar of zero trust, as defined by Kindervag, is identifying the highest-priority protect surfaces in the organization. Kindervag says that unless the organization has a clear understanding of what the crown jewels are, there’s no way a zero-trust project can be successful. Kindevag adds that IT doesn’t necessarily know what those high-value protect surfaces are, but business leaders do, and that’s where a zero-trust initiative should start. The second pillar of zero trust is to map transaction flows associated with those mission-critical protect surfaces. Again, this requires coordination and collaboration with teams running key enterprise applications. This is particularly important in today’s multi-cloud environments, where a specific business process can span on-prem, edge, cloud, containers, microservices, etc. “It’s not a technology issue at the end of the day that makes it hard,” Finney says. It’s people issues, cultural issues, and politics. He recommends that organizations think holistically about securing sensitive data across all attack surfaces, including endpoints, remote users, IoT devices, LLMs, AI agents, etc. Gartner adds, “It is not a product or technology-focused exercise but rather a methodology driven by the organization’s overall objective and priorities.” Myth: Zero trust is expensive Finney says zero trust does not have to break the bank. “A lot of folks think it’s going to be too expensive, but it doesn’t have to be,” he adds. Here are key steps on the road to zero trust that don’t involve buying anything. Identifying high-value protect surfaces. This requires thinking like an attacker and pinpointing the assets that an attacker is most likely to consider valuable. Finney adds, “In a given protect surface, you might have multiple controls that all have to be working together to remove those trust relationships.” Creating a zero-trust team. Finney says most organizations already have governance, risk management, and compliance teams that can be brought into a comprehensive zero-trust task force that includes security and networking groups. Gartner adds, “A zero-trust strategy must be initiated at the executive level and integrated across all departments and teams.” Education. Education is critical, says Finney. “It’s helping folks see the big picture. It gets people out of their silos.”Finney adds that a major challenge is political, having to deal with a fragmented organization in which many stakeholders are dismissive of security because it’s not what they’re measured on. For example, application developers who are under the gun to get software out the door aren’t necessarily incentivized to bake security into their processes. Creating a strategy. “When I talk to boards of directors, they understand that to be successful in any part of the business, you need to have a strategy. That resonates from the top,” says Finney. In its analysis of why zero-trust initiatives fail, Gartner says, “The lack of a business-aligned strategic plan has led to ineffective governance, miscommunication, poor risk management, minimal budget allocation, poor execution of the organizational security objectives, and inefficient use of limited resources.” Defining an architecture: Every organization is different, so there is no boilerplate architecture that can be applied everywhere. Organizations need to write a specific architecture that fits their business needs, their level of risk tolerance, their specific vertical industry, and their unique technology infrastructure. Setting and applying policies. Again, there is no line item associated with writing access control and identity management policies. Leveraging existing tools. It’s important to realize that nobody is starting from zero. Most organizations already have multi-factor authentication or single sign-on in place, they already have identity management, network management, web application firewalls, etc. The key is to integrate and align existing technology and identify gaps where new tools might be needed. Speaking to AmberWolf’s point that attackers can always find bugs in vendor software, zero-trust advocates counter that zero trust implies defense in depth. So, even if there’s a flaw that allows an attacker to gain end-user credentials and access the network, there will be multiple security controls in place, such as incident detection, micro-segmentation, monitoring of end-user sessions, and controls that prevent access to and exfiltration of sensitive data. Myth: Zero trust is difficult to implement Zero trust doesn’t have to be hard to implement if organizations follow widely disseminated guidance provided by NIST, numerous books, webinars, podcasts, experts, consultants, and more. Finney recommends starting small and showing quick wins. Zero trust can’t be implemented all at once across a large organization; it requires a targeted, methodical strategy. The preferred approach is to start with those high-value protect surfaces and apply tools that support the overall architecture in a coordinated, consistent, managed, and monitored fashion. “An overall strategy can deploy different tactics,” Finney says. “You want to think about what will have the biggest impact on your organization today.” He says organizations need to make informed data-driven decisions based on logs, metrics, and other data, while factoring in an analysis of what attackers are doing vs. the specific vulnerabilities and weak points in the organization’s defenses. Gartner states: “Narrowing the scope of initiatives or projects within the zero-trust program is essential for attaining a zero-trust posture within practical and reasonable timeframes. Organizations define overly expansive future target states by incorporating an excessive number of systems, applications, use cases, or datasets in the initial phase—or by proposing overly intricate and granular policy sets. They will encounter scalability and cost challenges, along with extended project timelines.” Myth: AI breaks ZTNA Enterprises are racing to deploy generative AI and unleash semi-autonomous AI agents. This new world of black box large language models (LLM) and non-human identities (NHI) raises concerns that zero trust is an outdated strategy that’s not up to the challenge. Leading zero-trust proponents are pushing back, however, arguing that the core principles still apply. “With AI, zero trust is more important than ever,” says Finney. “Zero trust is a strategy; we don’t change the strategy because AI came out. AI proves how important that strategy is.” “AI is not magic,” he adds. “We secure it the same way we secure everything else. We integrate it into the tech stack and monitor it.” Kindervag, currently chief evangelist at Illumio, concurs. “AI doesn’t change the fundamentals of zero trust. It reinforces them. Zero trust is the strategy that allows you to safely embrace AI. Without strict segmentation, policy enforcement, and control over data flows, AI becomes another soft and chewy center waiting to be exploited.” He adds, “You don’t need a new security strategy for AI. You just need to apply the right one. That’s zero trust.” Myth: There’s no way to measure success Any project that seeks support from the board and C-suite, needs to be able to justify itself through some sort of metrics. Zero trust is no exception, but how do you measure “not getting hacked?” Gartner says teams should use outcome-driven metrics that link zero-trust initiatives directly to business objectives.“It’s crucial to focus on schedule adherence, cost discipline, and control effectiveness,” says Gartner. “Focus on outcomes like reduced breach incidents, improved compliance rates, and enhanced operational efficiency. Additionally, identify specific risks, such as lateral movement, data breaches, account takeovers, and insider threats, which are essential to drive value, and organizations can better justify investments and drive continuous improvement.” Myth: Zero-trust projects have a completion date Zero trust is more about the journey than the destination,” Finney says. He points out that organizations are constantly growing and changing. At the same time, attackers are evolving. “Zero trust is a strategy. You’re never done with a strategy,” he adds. Kindervag’s final pillar of zero trust is to monitor and maintain. In other words, organizations need to be actively monitoring to make sure that access control policies are not being violated. And the zero-trust implementation needs to keep pace with changing business needs. And since zero trust calls for organizations to focus on the highest value protect surfaces first, there are always additional protect surfaces that can be added under the zero-trust umbrella. When Finney looks back on how things have evolved over the past 15 years, he is encouraged by the fact that tools have improved dramatically. Teams can now apply AI and machine learning to functions like anomaly detection or incident detection and response. And there are now ways to automate tasks like networking monitoring or policy enforcement. “Overall, I’m feeling guardedly optimistic,” Finney says, “but the work is not done. We need to continue to make strides.” View the full article

Enterprises using the open-source AI orchestration platform Langflow are being urged to patch a high-severity path traversal flaw amid active exploitation, despite a fix having been available for more than two months. The bug, which stems from improper handling of filenames in Langflow’s file upload functionality, can allow attackers to write files to arbitrary locations within the affected system and, under certain conditions, can be used to achieve remote code execution (RCE) on affected servers. An added complexity is that Langflow is shipping with an auto-login behavior, allowing unauthenticated users with a valid session to reach the vulnerable endpoint without credentials. “Langflow is a popular open-source tool for building AI applications,” said Jim Sherlock, VP of cybersecurity R&D at ProCircular. “Because the platform ships with login disabled by default, exploitation takes a single request with no credentials, resulting in full takeover of the machine.” Cloud security non-profit, Cloud Security Alliance (CSA), said approximately 7,000 Langflow instances are exposed to the internet. Path traversal issue allowing full system takeover Langflow is a popular low-code platform for building AI agents, RAG pipelines, and MCP-based workflows through a drag-and-drop interface. That popularity is adding to the concerns over CVE-2026-5027, a path traversal vulnerability assigned an 8.8 CVSS rating. According to the CVE record, the vulnerability affects the POST /api/v2/files endpoint. The endpoint fails to properly validate the “filename” parameter supplied through the “multipart form data,” allowing attackers to include path traversal sequences such as “../” and write files outside the intended upload directory, onto an attacker-controlled location. >Using a GitHub POC exploit, EQST Lab demonstrated how the flaw can be exploited to place attacker-controlled files in arbitrary filesystem locations. They said that in environments where auto-login is enabled, the arbitrary file write can be escalated into remote code execution. “Arbitrary file write vulnerabilities are often more severe than standard unrestricted upload issues because the attacker controls not only the file contents, but also the destination path,” EQST researchers said in the POC note. “Depending on the runtime privileges of the Langflow process, this may enable overwrite of application files, modification of startup or scheduled task files, persistence through shell initialization or key files, and escalation from arbitrary file write to remote code execution.” The vulnerability affects Langflow versions up to 1.8.4, while researchers have indicated that the issue was addressed in version 1.9.0, released April 15, coming 73 days after the flaw was first disclosed to the vendor. The patch logic has been applied to all subsequent releases, including the current version 1.10.0. Langflow did not immediately respond to CSO’s request for comments. AI orchestration platforms continue to attract attackers The disclosure arrives amid growing attacker interest in AI infrastructure. VulnCheck confirmed that CVE-2026-5027 is already being exploited, with observed activity including attempts to drop files onto vulnerable systems. Public exploit code has further lowered the barrier for opportunistic attackers. Exploitation of CVE-2026-5027 has been linked to the Iranian state-sponsored group known as MuddyWater. Sherlock said many organizations have unknowingly expanded their attack surface through rapidly deployed AI tooling. “Through 2025, teams everywhere stood up Langflow, Flowise, n8n, Dify, and similar low-code tools to prototype agents and LLM workflows,” he added. “These deployments rarely got the hardening a production web app would. They run with default authentication settings and sit on public IPs because someone needed to demo a flow to a stakeholder, and nobody owns patching them.” Earlier this year, threat actors exploited another critical Langflow RCE shortly after its disclosure. More recently, researchers uncovered a severe bug affecting Flowise’s Model Context Protocol (MCP) implementation that allowed RCE through crafted configurations. View the full article

Attackers can turn AI agent guardrails into denial-of-service weapons, according to new research that found a single poisoned document can dramatically slow shared AI agent workflows by trapping reasoning-based safety systems in extended thinking loops. “Reasoning-based guardrails introduce a new attack surface where security mechanisms themselves become the target,” the researchers from Hong Kong University of Science and Technology and collaborators wrote in the paper. They added that “a single poisoned document can saturate shared guardrail infrastructures, effectively starving co-located agents and paralyzing the entire system,” describing a reasoning-extension denial-of-service (DoS) attack that targets the security layer rather than the underlying AI model. The researchers tested the technique against four AI agent frameworks — LangGraph, BrowserGym, OpenHands, and OSWorld — and found processing times increased across deployments. LangGraph recorded the biggest slowdown at 148x, followed by BrowserGym at 131x, OpenHands at 36.3x, and OSWorld at 18x, according to the paper. Attack exploits reasoning rather than bypassing security Unlike prompt injection and jailbreak attacks that seek to manipulate model outputs or circumvent safety controls, the new technique targets the reasoning process used by AI agent guardrails, the researchers wrote in the paper. “Unlike traditional LLM attacks that primarily compromise integrity, reasoning-extension DoS targets availability,” the researchers wrote, arguing that AI security discussions have focused largely on preventing unsafe outputs while overlooking resource exhaustion. The researchers also found that stronger AI safety checks may come at the cost of slower performance. “The stronger the guardrail reasons, the longer it reasons,” the researchers wrote, explaining that more sophisticated reasoning can inadvertently increase the time and resources required to process malicious inputs. The attack also worked across eight different LLM families. According to the paper, prompts designed for one open-source model were also effective against other models, suggesting attackers would not need detailed knowledge of a specific proprietary system OpenAI and Anthropic, whose reasoning-based guardrails are referenced in the paper as examples of LLM-powered security mechanisms, did not immediately respond to requests for comment. Shared AI governance creates concentration risk “The more important takeaway is not necessarily whether a specific ‘guardrail DoS’ technique proves practical at scale, but that AI governance infrastructure is increasingly becoming critical infrastructure,” said Sakshi Grover, senior research manager for cybersecurity services at IDC Asia/Pacific. “As agentic AI deployments mature, organizations will need to think about resilience, scalability, and fault tolerance for AI control planes in the same way they already do for identity services, API gateways, and other business-critical platforms,” she said. Grover said centralized AI governance also introduces concentration risk. “The consolidation dynamic is real — organizations are rationalizing AI governance by routing multiple agents through shared safety infrastructure, which creates concentration risk,” she said. “A successful guardrail DoS doesn’t need to breach anything; it just needs to make the system unusable at a critical moment.” For business-critical workflows such as automated claims processing, AI-assisted incident response and real-time fraud detection, even temporary latency or resource exhaustion could have material consequences, she added. Existing mitigations offer only partial protection The researchers found conventional prompt injection filters remained susceptible to the proposed attack, while strict token limits simply shifted deployments between fail-open and fail-closed behavior. Smaller reasoning budgets reduced latency but also weakened security decisions, creating a tradeoff between availability and protection. The study also found that larger reasoning models often spent more time following the injected reasoning structure, amplifying rather than mitigating the attack. The findings also reinforce the need for enterprises to move beyond model-level security and focus on governance of autonomous AI systems, analysts said. Through 2029, more than 50% of successful cybersecurity attacks against AI agents will exploit access control issues using direct or indirect prompt injection as an attack vector, while through 2028 at least 80% of unauthorized AI agent transactions will result from internal policy violations or misguided AI behavior rather than malicious attacks, said Apeksha Kaushik, senior principal analyst at Gartner. “The transition to autonomous multiagent systems introduces new risks, such as behavioral drift and destructive actions,” Kaushik said, adding that organizations should implement AI agent security lifecycle management that continuously validates agent integrity from deployment through retirement. Current fragmented tools cannot effectively govern complex multi-agent systems, she said, requiring unified discovery, identity, and guardian capabilities to monitor and block rogue behaviors at scale. AI governance moves to the forefront Grover said that organizations should begin preparing now by decoupling guardrail infrastructure from agent compute, implementing tiered or asynchronous guardrail checks where possible, monitoring for anomalous reasoning depth, and explicitly red-teaming AI safety stacks for availability failures rather than focusing exclusively on harmful outputs. “Architecture choices are becoming as consequential as model safety choices,” Grover said. “The organizations that treat agentic AI infrastructure with the same rigor they apply to critical application infrastructure will be better positioned. The ones that don’t will find out the hard way.” View the full article

Every enterprise security team is fighting a workforce problem they cannot see on any org chart. Bots, service accounts, API keys, OAuth tokens, machine certificates — non-human identities now outnumber human ones in most large organisations, often by a factor of ten to one. They authenticate constantly, operate across every environment, and when forgotten, they do not retire gracefully. They linger, accumulate privilege, and wait. Security practitioners have taken to calling them ghost identities — and the name fits. The security industry has had plenty of warnings. It just has not acted on it. Cast your mind back to SolarWinds story. The attackers did not smash through anything. They slipped in, found machine identities with significant access, and used them the way they were designed to be used — quietly, legitimately, invisibly. Eighteen thousand organisations. Months undetected. The credentials were not stolen in the traditional sense. They were just there, unmonitored, doing what attackers needed them to do. Uber, 2022. Simpler anatomy. A service account nobody owned. Credentials that had not been rotated in who knows how long. Found in a network share by an attacker who was already looking. That one ghost identity opened a direct path to the PAM system — and from there, everything else followed. Cloud environments. Source code. Internal tools. One forgotten credential. That was the price of admission. Okta, 2023. Different problem, harder to solve. The credentials that mattered were not even on Okta’s own infrastructure. They lived with a third-party support vendor. Technically, someone else’s environment. But they carried access rights into Okta’s systems, and when that vendor was compromised, the pathway was compromised too. Three incidents. Three different entry points. One thing in common — an identity that nobody was watching, carrying access nobody had recently justified, sitting exactly where an attacker needed it to be. Calling this a security problem is not wrong. It just does not cover what is coming next. The scheduled crisis In 2026, the consequences of unmanaged non-human identities take a new form. Not a breach. A calendar event. Machine identity certificates have finite lifespans. For much of the past decade, organisations issued them with validity windows of three to five years. Between 2020 and 2022, enterprises expanded their digital infrastructure at extraordinary speed — cloud migrations compressed into months, automation pipelines stood up under pressure, and new services connecting to other services with governance as an afterthought. Those certificates are expiring now. Not in ones and twos. In volume. The cascading failure scenario is not complicated. A certificate expires unnoticed. The service it supports drops. Dependent applications that are authenticated through that service start failing. Monitoring tools running on the same infrastructure miss the alert. The incident response team works on the problem without a complete picture of what connects to what. Hours pass. Sometimes a full day. What started as an overlooked credential with an expiry date becomes an outage with a revenue figure attached and a regulator taking notes. This has happened before on a smaller scale — a single expired certificate took Microsoft Teams offline for millions of users in 2020. What 2026 presents is the same failure mode, replicated across organisations that grew fast and governed poorly, hitting simultaneously. Certificate expiration is habitually treated as an IT operations issue. That framing does not survive contact with an outage that takes customer-facing services down for eighteen hours. Ashish Mishra The structural gap The root cause is not negligence. It is architecture. The tools organisations rely on to manage identity — role-based access controls, privileged access management platforms, access certification campaigns — were built for people. They assume an identity has an owner, a manager, and a review cycle. Non-human identities do not fit that model. They get created to solve an immediate problem, granted broad access to make the thing work, and left running long after the project moves on. Over-provisioning compounds the risk. Every unreviewed service account is a potential pivot point. Every dormant API key with write access is an open door. For ghost identities carrying legacy admin rights — and there are more of them than most organisations want to admit — the blast radius of a compromise is often organisation-wide. What good looks like The answer is not a tool. Every vendor in this space will tell you otherwise. They are wrong about the order of operations. Governance comes first. Tooling supports it. And governance starts with a question most organisations cannot currently answer: what non-human identities are we running? That question sounds simple. It is not. NHIs do not get created centrally. They get created by developers solving problems, by platform teams standing up services, by vendors connecting their products to yours. Each decision made sense at the time. None of them got logged somewhere useful. The result, in most large enterprises, is an estate that nobody has a complete map of — and that no tool can govern until someone builds one. So, start there. Not with a platform evaluation. Not with a policy document. With a discovery sprint. Four to six weeks, focused on your highest-risk environments. Cloud first. CI/CD pipelines. Third-party integrations. An imperfect inventory is still infinitely more useful than operating blind. While that work is running, pull your certificate expiration data. Today, not next quarter. Sort by expiry date. Filter for anything lapsing in the next eighteen months. Put a named owner against every entry — and where no owner can be identified, treat the certificate as a ghost identity. Escalate it accordingly. This one action directly addresses the 2026 expiration risk before it becomes an outage. Last, run a privilege audit on your highest-sensitivity service accounts. Any NHI with admin rights that has not been reviewed in the past twelve months should be treated as over-privileged until the evidence says otherwise. Assume excess. Prove necessity. None of this needs a new budget line. It needs someone to decide it is worth doing before the alternative decides for them. The broader problem One organisation fixing its NHI estate does not fix the problem. It just means one organisation is less exposed than the rest. The market around machine identity is still finding its feet. Ask three vendors to define the scope of NHI governance, and you will get three different answers. Lifecycle standards that should exist do not. The frameworks security teams rely on — NIST, ISO 27001 — address least privilege as a concept but stop well short of telling anyone what to do with fifty thousand unmanaged service accounts spread across a hybrid cloud environment. What is missing is not ambition. It is specificity. Agreed taxonomy. Shared lifecycle standards. Regulatory guidance that puts NHI governance on the same level as every other identity obligation — not buried in a footnote, not implied by a principle, but stated plainly and enforced accordingly. That conversation is happening. Standards bodies are moving. Regulators are paying closer attention. But the pace is measured in years, and the certificate expiration wave is measured in months. The expiry dates do not wait for the industry to catch up. The deadline is built in The ghost workforce does not announce itself. It does not resign or ask for a performance review. It runs until something stops it — a breach, an expiration, or a security team that finally decided to take inventory. In 2026, for organisations that have not mapped and governed their NHI estate, something is going to stop it. The only variable is whether that something is a deliberate programme or an unplanned outage. The runway is very thin. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

In June 2025, Simon Willison, the engineer who coined the term “prompt injection,” published a warning that circulated widely through the security community. He called it the lethal trifecta — three capabilities that, when combined in a single AI agent, create a near-guaranteed path to exploitation through indirect prompt injection: access to private data; exposure to untrusted content; the ability to communicate externally. The framing was sharp and useful. If your agent reads your email, ingests arbitrary web content, and can make outbound requests, an attacker who embeds malicious instructions anywhere in that content pipeline can direct the agent to exfiltrate your data without you ever knowing. Willison illustrated the point with a long list of real production exploits: Microsoft 365 Copilot, GitHub’s MCP server, GitLab Duo, Slack AI, Google Bard, Amazon Q. The same class of attack, over and over. The trifecta worked as a signal because, at the time, agents were mostly narrowly scoped. An agent capable of performing only one or two of the lethal trifecta activities could be assessed as lower risk. Avoiding the combination felt like a viable design strategy. That window has closed given what practitioners deploy today: A customer-facing support agent reads ticket histories and customer records, ingests user messages and attached files, and calls CRMs, refund APIs, or ticketing systems. An email AI reads your inbox and calendar, processes inbound messages from strangers, and sends replies on your behalf. Rather than being edge cases or poorly designed deployments, these are the agents enterprises and individuals actually want, and they’re the ones vendors are building toward. Lethal trifecta as default configuration Ross McKerchar, CISO at Sophos, put it plainly in a piece published this May: “the capabilities practitioners actually want (read my data, understand external context, take action) push firmly into dangerous territory. This isn’t a misconfiguration; it’s the architectural cost of usefulness.” He’s right. An agent without private data access is useless, one that can’t process external content is isolated, and the one that can’t communicate externally is inert. Strip any leg of the trifecta and you have something closer to a search box than an agent. If every legitimate agent architecture exhibits all three trifecta properties, the trifecta is no longer a meaningful indicator of elevated risk. It’s the default configuration. Treating it as a red flag is like treating DNS resolution as a signal of network compromise. Technically true in some threat models, but universally present in every real deployment. McKerchar’s piece frames the response as “blast radius reduction”: a reasonable operational philosophy, but one that accepts the trifecta as a given condition rather than a preventable one. That’s a reasonable call. The question is what comes after the acceptance. Meta’s security team arrived at the same conclusion from the other direction. In October 2025, they published the “Rule of Two,” a framework that recommends agents satisfy no more than two of the three trifecta properties in a single session, with human-in-the-loop approval required if all three are necessary. Willison himself endorsed the framework as “the best practical advice for building secure LLM-powered agent systems today.” Meta’s limitations section, however, concedes that many sought-after use cases won’t fit the framework cleanly, and that “designs that satisfy the Agents Rule of Two can still be prone to failure.” That’s not a criticism of the framework but confirmation that the problem has outgrown the architecture-level solution. The scale of exposure is no longer theoretical. Google’s April 2026 sweep of the Common Crawl repository found prompt injection attempts across public web pages, ranging from pranks to data exfiltration payloads, with malicious attempts up 32% between November 2025 and February 2026. Google noted sophistication remains low for now but flagged the trend as a signal of maturing attacker interest. The environment the trifecta warned about has arrived. How to sleuth out a compromised agent If the trifecta describes nearly every deployed agent, practitioners need signals that distinguish compromised behavior from normal operation within a trifecta-exhibiting system. That means shifting from architecture-level assessments to runtime behavioral detection. The production evidence arrived in a cluster. From Jan. 7 to Jan. 15, 2026, researchers disclosed exploits against four separate AI productivity tools in eight days: IBM Bob, Superhuman AI, Notion AI, and Anthropic’s Claude Cowork. Each used indirect prompt injection to exfiltrate data via a channel the agent had legitimate access to. In the Cowork case, a hidden prompt embedded in an uploaded document directed the agent to exfiltrate files via Anthropic’s own allowlisted API domain, invisible to any perimeter control and indistinguishable from normal agent behavior until the data was already gone. In all of these cases, the trifecta wasn’t a risk factor but the operating condition. Here’s what’s worth watching to detect an agent has been compromised. Instruction-following anomalies. A compromised agent doesn’t usually do something structurally different from a healthy one. Following instructions is its normal function. The difference is whose instructions it’s following. Look for agent actions that have no plausible correspondence to a user-initiated task. An agent that was asked to summarize a quarterly report but then attempts an outbound DNS request to an unfamiliar domain didn’t spontaneously decide to do that. Something in the content it ingested told it to. Tool call sequences that break expected topology. In a well-designed agent system, the graph of tool calls for any given task should be relatively predictable. A coding agent invoked to fix a bug should touch files, run tests, perhaps check documentation. It shouldn’t be reaching for email or calendar APIs. Tool call sequences that cross expected workflow boundaries are worth flagging even when each individual call looks legitimate on its own. Exfiltration via low-bandwidth channels. The classic prompt injection exfiltration attack routes stolen data through a mechanism the agent has legitimate access to: a rendered image URL with encoded query parameters, an API call with data embedded in a parameter, a link in a generated document. These don’t look like data theft in isolation; they look like normal agent output. Detection requires correlating what data the agent had access to against what it embedded in its output. That requires end-to-end visibility into the agent’s actions, not just the final response. Credential and secret access outside task scope. If an agent with legitimate access to a secrets store or key vault touches credentials that have no relationship to the current task, that’s a signal. An agent fixing a React rendering bug should likely not be reading AWS credentials. Least-privilege scoping is the architectural defense here, but monitoring for out-of-scope credential access is the detection layer that catches failures in that scoping. Memory-write anomalies. Agents with persistent memory are a growing attack surface. A poisoned memory entry that looks like legitimate user context but contains dormant trigger instructions can persist across sessions and fire long after the initial injection. Monitoring for memory-writes containing instruction-like content, or writes made during sessions that ingested untrusted content, is worth adding to any agent observability pipeline. Runtime alone can address the agent redirection threat For practitioners operating production agent infrastructure, the lethal trifecta tells you what you know: Your agents are exposed. The question is what to do about it. The answers are at the runtime layer, not the architecture layer. That’s where EDR and SIEM live for traditional infrastructure — agents need the same instrumentation, and most deployments don’t have it yet. Full execution traces on every agent invocation. Tool call anomaly detection. Input screening at ingest. Credential access monitoring scoped to task context. Memory-write auditing. Not a human attacker logging in. An agent that’s been quietly redirected. Willison’s trifecta was the right alarm for its moment, which was last year. Almost every production agent now fits the profile. Because of that, only runtime anomaly detection can potentially provide adequate defense. The above signals are a good place to start. View the full article

Your board is asking. Your legal team is asking. Your auditors will be asking: Should AI workloads move to sovereign cloud, or stay on AWS, Azure or GCP? European enterprises have already run this experiment — under real regulatory pressure, with real money and real consequences. Many discovered that sovereign cloud alone didn’t deliver the control they expected. The real control point turned out to be somewhere else entirely. Europe ran this experiment first, under regulatory pressure US enterprises are only starting to feel. With DORA fully in force since January 2025, NIS2 enforcement underway across EU member states and the EU AI Act’s high-risk system provisions taking effect in August 2026, European enterprises — particularly in financial services, critical infrastructure and manufacturing — have spent two years migrating workloads, renegotiating contracts and writing sovereign cloud into board-level risk frameworks. The hyperscalers responded. AWS launched its European Sovereign Cloud in January 2026. Microsoft and Google followed with their own sovereignty offerings. The market arrived. US enterprises are not far behind. The SEC’s cybersecurity disclosure rules, CISA’s AI security guidance, proposed state-level AI regulations and growing board-level scrutiny of AI governance are creating comparable pressures on this side of the Atlantic. If your organization runs AI workloads on behalf of EU clients, operates EU subsidiaries or simply faces the question of where sensitive AI training data and model outputs should live — you are already in this conversation. The European experience is your preview. What has not arrived is clarity on what you actually get — and what you do not. At the European Identity and Cloud Conference in Berlin this May, the mood among practitioners had shifted measurably from previous years. The cheering for the sovereign cloud concept was over. What was happening on stage and in the corridors was a careful, sometimes uncomfortable, dissection of the gap between marketing slides and operational reality. (EIC returns to Berlin in May 2027.) The conference agenda made the shift visible. Where previous years centered on sovereign cloud architecture and vendor selection, the 2026 program’s trending themes — as mapped in the closing session — were AI security, identity fabric, workload identity management, and crypto agility. Sovereign cloud had become assumed infrastructure. The practitioner conversation had moved to what you build on top of it, and who controls that layer. Martin Kuppinger, distinguished analyst and co-founder of KuppingerCole, observed the same shift: “Cloud sovereignty had a much larger role at this year’s EIC, with a differentiated discussion about whether and where it is needed. There is common sense that sovereignty is not a value in its own right — the required level depends on the use case and a proper risk assessment. There is no binary model for sovereignty.” Sovereign cloud, on the slides, looks like control. In the contracts, service matrices and AI agent deployments, it often looks more like a very expensive illusion. The control question nobody answers clearly When enterprises talk about sovereign cloud, they are usually thinking about data residency — where the data lives. European data center, European jurisdiction. But data residency is the beginning of the conversation, not the end. The harder questions are about control. Who holds the encryption keys, and who can compel access to them under what legal circumstances? Who sees the metadata, the access logs, the telemetry from your workloads? When you run AI inference or model training on a sovereign cloud platform, who controls the model registry, the training data pipeline, the output logs? And when an AI agent acts autonomously on your behalf — scheduling workloads, provisioning resources, making access decisions — whose infrastructure is that agent running on, and who can observe what it does? These are not hypothetical concerns. The CLOUD Act of 2018 gives US authorities the ability to compel US companies to produce data stored abroad, regardless of where the servers sit. European sovereign cloud offerings from US hyperscalers are structured to address this — through operational separation, European legal entities and customer-managed keys — but the structures are new, partially tested and vary significantly between providers. Germany’s BSI has raised the stakes further. In April 2026, the agency published its Criteria Enabling Cloud Computing Autonomy (C3A): The first framework to operationalize what cloud sovereignty actually means in technical terms, including disconnect scenarios, staff residency requirements and an extraordinary provision for federal takeover of cloud operations in defense scenarios. Formally non-binding, the criteria are widely expected to become the de facto benchmark for German federal procurement — and a likely template for EU-level frameworks now in the legislative pipeline. For US CISOs, the direction of travel is clear: Regulatory definitions of cloud sovereignty are tightening, and the gap between “data in Europe” and “operationally sovereign” is only going to widen. Identity is where sovereignty actually lives The clearest theme at EIC 2026 was that identity — not network perimeter, not data residency — is where cloud sovereignty either holds or breaks down. The argument is becoming hard to avoid. Jason Keenaghan, who leads identity management strategy at Thales, framed it directly: “Identity is shifting from an IT function to a regulated infrastructure. The most important question for the next decade will be: Who is in control?” For a US CISO, this shift is very real: Identity governance is moving from pure IT plumbing to a regulated control surface that auditors, regulators and even enterprise customers in RfPs will increasingly scrutinize. The question of “who is in control” is no longer philosophical. It is contractual. Here’s the problem. You can put your data in a Frankfurt data center with customer-managed keys. But if your identity governance is weak — if you do not know which human users, service accounts and AI agents have access to what, and under what conditions — your sovereignty posture is only as strong as your weakest identity. A compromised privileged account does not care about data residency. This is particularly acute for AI workloads. Agentic AI systems — models that act autonomously, make API calls, provision resources, access data — are creating a new category of non-human identities that most enterprises’ IAM systems were never designed to manage. Consider a concrete example I have seen in client environments: An LLM-based deployment agent with standing access to production Kubernetes clusters. It schedules workloads, provisions resources and makes access decisions autonomously. If that agent runs on sovereign cloud infrastructure but its identity — its credentials, its permissions, its audit trail — is not properly governed, your sovereignty posture is exactly as strong as the weakest link in that agent’s access chain. If you are running similar agents in US-based cloud regions today, the same identity blind spots exist — even if you never touch a sovereign cloud region. Sebastian Rohr, an IAM consultant and IDPro member who has spent two decades on enterprise identity architectures, distilled the requirements for governing AI agents in practice: “Every agent needs an assigned non-human identity. A solid on-behalf-of delegation model must be established. An audit trail via SIEM integration is required. No long-lived credentials, no API keys — only ephemeral credentials. Context-based authentication and fine-grained access control. Agents must be managed as real identities. And once that foundation exists: Risk-based, continuous re-authentication combined with the ability for real-time revocation. Do we have all these capabilities everywhere today? Not necessarily — but designing the architecture for it? That is entirely possible.” For AI agents in particular, the practical question is this: Can you list every agent running in your environment, govern its entitlements and revoke access in real time? If not, you do not truly control the workload — regardless of which cloud region it runs in. What practitioners at EIC kept coming back to is not a sovereign cloud answer. It is an identity governance answer. Sovereign cloud buys you legal protection and data residency. Identity governance gives you operational control — and increasingly, it is the layer where AI workload sovereignty actually has to be enforced. When sovereign cloud is worth it — and when it is not For US CISOs managing EU operations, EU subsidiaries or EU customers, the practical question is not whether sovereign cloud is philosophically correct. It is whether the additional cost and complexity deliver sufficient risk reduction for specific workloads. Most organizations I have worked with are over-applying sovereign cloud to workloads that do not need it, while under-applying it to the ones that do. A working framework, refined across two years of European deployments. Use this as a quick triage for which workloads truly justify a sovereign cloud premium. As Kuppinger puts it: “Within an organization, varying levels of sovereignty demand for different use cases are the norm, not the exception.” Workload typeSovereign cloud?WhyNIS2-regulated processesYesLegal obligation, board-level personal liabilityHigh-risk AI under EU AI ActYesCompliance from August 2026Personal data with Schrems II exposureYesTransfer risk without adequate protectionSensitive metadata (access logs, AI telemetry)YesResidency alone does not protect metadataDev/test environmentsNoSignificant cost premium (15–30%) with minimal risk reduction for most US-based operationsNon-sensitive SaaS workloadsNoStandard DPAs and encryption are usually sufficient; no strong US or EU regulatory driverInternal productivity toolsNoNo material regulatory exposure; high cost not justified by risk profile Five things European enterprises learned the hard way Sovereign cloud does not mean the hyperscaler cannot see your metadata. Customer-managed keys protect data at rest. They do not prevent the platform from logging access patterns, API calls and resource consumption. Know what your provider logs and where those logs go. For US CISOs: This matters for any hyperscaler operating under foreign data localization requirements you may face as the regulatory landscape evolves. Early sovereign cloud offerings had real service gaps — and exit is harder than expected. Many advanced AI/ML services were unavailable at launch; enterprises that committed early ended up running hybrid architectures more complex than anticipated. And lock-in in sovereign cloud contexts is harder to escape than standard cloud. Build exit strategy into procurement decisions before you sign. Identity governance cannot be deferred. The enterprises that got the most value from sovereign cloud investments had already done the identity governance work — asset inventory, access classification, non-human identity management. For US CISOs facing similar AI governance and resilience requirements: This is the lesson that will hurt most if you have not done the work. Sovereign from a hyperscaler is not the same as sovereign from a European provider. AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty and Google Sovereign Cloud are structurally different from offerings built by IONOS, Hetzner, OVHcloud or Deutsche Telekom. The former offers broader service catalogs with sovereignty controls layered on. The latter offer cleaner legal structures with narrower feature sets. Neither is universally better — and the choice should follow workload characteristics, not procurement preference. What US CISOs should do now If your organization has EU operations, subsidiaries or customers — or AI workloads sensitive enough that the regulatory direction in the US matters — these are decisions you will face. Three concrete steps. 1. Classify your workloads by sensitivity and regulatory exposure before you classify them by cloud type. Not everything needs sovereign cloud. But know which workloads do before a regulator, auditor or customer’s procurement team asks. 2. Audit your identity governance posture before your cloud strategy. Sovereign cloud without IAM maturity is expensive and insufficient. Governance has to happen at the identity layer, not the data center boundary. 3. Read the contracts carefully. Key management, metadata logging, law enforcement access and service continuity provisions vary significantly between providers. Legal and security need to review them together — and AI workload provisions deserve their own column. Europe’s sovereign cloud experiment is still running. The early results suggest the regulatory pressure is real, the market response is genuine and the operational complexity is higher than the marketing suggested. AI workloads make it more complex, not less. That is not a reason to avoid sovereign cloud — it is a reason to approach it with clearer eyes than the first wave of European adopters had. Buy the jurisdiction. Then govern the identity. In that order. Sovereign cloud buys you a jurisdiction. Identity governance buys you control. AI workloads need both, and most enterprises are buying only one. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

A disgruntled researcher who has been publishing zero-day Microsoft Windows vulnerabilities for the past several months released a new exploit Thursday that promises to bypass BitLocker encryption on locked devices. A well respected security expert reported that the exploit doesn’t work as initially described, but the researcher is looking for ways to fix it. Dubbed GreatXML, the exploit is supposed to work from the Windows Recovery Environment (WinRE), a special boot mode in Windows from which startup issues can be troubleshooted. It also seems to be related to the Windows Defender offline scan feature. “If Defender offline scan was initiated in the victim machine at any point then there is no need to login, the machine is automatically vulnerable,” the researcher, who goes online by the name Nightmare Eclipse or Chaotic Eclipse, said in the exploit notes. “If Defender offline scan was never initiated then you have to either login and initiate it yourself or figure out a way to boot into WinRE in offline scan state (I believe it should be very possible to do so without logging in).” The requirement to log in is relevant here, because a system drive encrypted with BitLocker will be unlocked and decrypted when the user logs in. However, the whole point of a BitLocker bypass is to gain access to the unencrypted drive without having the credentials to log in, for example on a stolen laptop. On machines where an offline Windows Defender scan was performed in the past, the exploitation is supposed to work by copying two files (unattend.xml and Recovery/WindowsRE/ReAgent.xml) provided by Nightmare Eclipse to the WinRE partition — this can be done from outside the OS because the WinRE partition is not encrypted — and then restart the system in WinRE mode. “If everything was done correctly, a shell with unrestricted access to the BitLocker volume will spawn,” Nightmare Eclipse said. However, Will Dormann, an experienced vulnerability analyst who investigated previous exploits released by Nightmare Eclipse, was not able to replicate the bypass using the provided instructions after trying on three versions of Windows 11. “I think the writeup is flawed in that the spawned CMD.EXE happens on the NEXT time that a Microsoft Defender Offline scan is triggered,” Dormann said on his Mastodon account. “And in order to trigger a Microsoft Defender Offline scan, you both need to be logged in to Windows, and also have admin credentials. And if you’ve already got that level of access, you can just turn off BitLocker.” Dormann’s observation would be consistent with Microsoft’s documentation, which states that triggering a Windows Defender offline scan requires administrative privileges and will trigger a reboot into WinRE mode for the scan to initiate. The point of the offline scan is to be executed from outside the OS to clean up kernel-level threats such as rootkits that might otherwise interfere with the regular Windows Defender process. Nightmare Eclipse did not respond to Dormann’s report, but asked on X if anyone is aware of a way to trigger a Defender offline scan just by editing ReAgent.xml. This suggests the researcher is looking for an alternative way to trigger the exploit, but could be related to the scenario where a Defender offline scan was never executed in the past. Eclipse’s own blog post about GreatXML disappeared from his blogspot.com site, but he claims this was Google’s doing (Google owns the Blogger service). The GitHub repository where he posted his previous zero-day exploits was also removed recently, supposedly by Microsoft, which owns GitHub, a move that drew criticism from many in the security community, as GitHub has been a safe place to store security research, including zero-day proof-of-concept exploits. The researcher has a personal vendetta against Microsoft after claiming the company mistreated him and he has released eight zero-day exploits in Windows components so far. Some releases have been timed shortly after Microsoft’s Patch Tuesday to force the company to release out-of-band patches or wait until the following month. This was also the case earler this week, when the researcher released a zero-day privilege escalation exploit in Windows Defender dubbed RoguePlanet and followed that up two days later with the alleged GreatXML BitLocker bypass. Even if Dormann was not able to get the GreatXML to work, companies should still take the exploit seriously considering Eclipse’s track record of releasing functional zero-days. If there is a bug in the exploit, the researcher or someone else could fix it or find an alternative way to trigger it. View the full article

Lawmakers have failed to extend a surveillance law that allows US intelligence agencies to monitor targets abroad without a warrant. Congress rejected a vote to extend Section 702 of the Foreign Intelligence Surveillance Act to July 2, which means, for a few days at least, some surveillance will be put on hold, for the first time since the Act was passed in 2008. The next possible chance for a vote will be June 28. This has significance for CISOs because they need to be aware of how communication between the US and other countries is being monitored. The Act permits US intelligence agencies to collect texts and emails sent to and from foreigners living outside the US without a warrant — and when those communications are to or from an US citizen, it allows them to scoop them up too. “For too long, the FBI has been able to piggyback on a major national security tool as an unconstitutional backdoor way of reading Americans’ communications,” Electronic Frontier Foundation Senior Policy Analyst Matthew Guariglia wrote in article about the renewal vote this week. It is uncertain what will happen next. Some commentators expect things will proceed as if the Act had been extended, possibly through an executive order. However, the industry may well revolt against this and we could see some tech providers take legal action. View the full article

An intruder has breached the French government’s encrypted messaging service, Tchap, showing once again that human error is a weak spot in any security system. Tchap was developed in France as an example of national sovereignty and was designed to be a more secure option than WhatsApp for communication between government employees. In this case, it wasn’t the technology that was at fault, but a user: The intruder gained access to the system by taking over their account, according to DINUM, the French government’s interministerial digital directorate. DINUM said it has blocked the affected user’s access and is investigating how much information has been revealed. While the system’s encryption was not broken, the intruder would have been able to view unencrypted public chat rooms accessible to the account taken over, potentially affecting 73,467 of the system’s 825,000 users, DINUM said. That matches at least part of a post on X (formerly Twitter) reporting the intruder’s claim to have accessed the account of a Tchap user in the education sector through social engineering, exposing 73,467 user accounts, 643,459 messages, 876 chat rooms with message history, and 59,386 media files totalling 13.51 GB, including references to documents marked “Diffusion Restreinte” (restricted distribution). DINUM said that it had reminded all Tchap users that public chat rooms are accessible to any user and are not encrypted, so all participants should refrain from any sensitive or confidential information. View the full article

Today’s AI web agents have no dependable defenses against prompt injection, according to new research showing that not a single attack scenario was consistently blocked across leading systems powered by GPT‑5 and Gemini. The findings come from StakeBench, a stakeholder-centric benchmark developed by researchers from Nanyang Technological University, ST Engineering, IBM Research, and the University of Illinois Urbana-Champaign to evaluate prompt injection attacks against AI agents operating in realistic web environments. The researchers executed 3,168 adversarial runs across NanoBrowser and BrowserUse using 264 benchmark cases. Indirect prompt injection attacks, where malicious instructions are hidden inside ordinary web content such as product reviews and metadata, achieved attack success rates ranging from 41.67% to 68.16%, while direct prompt injection exceeded 79% across all tested configurations. “Crucially, these failures exhibit distinct patterns when analysed through a stakeholder lens: some attacks succeed without disrupting the user’s delegated task while disproportionately harming third parties (stealthy parasitism), whereas others disrupt task completion without realizing the adversarial objective (misaligned disruption),” the researchers wrote in a paper. OpenAI and Google did not immediately respond to requests for comment. Every attack objective exposed at least one failure mode The benchmark evaluated web agents across four possible outcomes: Robust Behavior, Stealthy Parasitism, Misaligned Disruption, and Compounded Failure. Robust Behavior represents the ideal state in which an agent completes a user’s task without advancing an attacker’s objective or exhibiting execution instability. The researchers argue that the findings reveal a broader problem than high attack success rates. “The Robust Behavior region remains unpopulated across all evaluated configurations,” they wrote, meaning every tested attack objective resulted in at least one meaningful failure dimension, whether successful adversarial manipulation, disruption of the user’s intended task, or execution instability. The authors say this demonstrates that “prompt-injection vulnerability in deployable web agents cannot be characterized by any single metric in isolation,” because attack success and task disruption are “weakly coupled in practice.” Attacks can succeed while users see nothing wrong One of the failure modes identified by the benchmark is what the researchers call “stealthy parasitism,” in which an AI agent completes the user’s delegated task while simultaneously advancing an attacker’s objective. The paper illustrates the risk with an online shopping scenario: “A malicious prompt injected into product reviews may bias an agent toward a specific item: although the user may still receive an acceptable recommendation, the same behaviour can disadvantage competing sellers and undermine platform integrity.” The researchers argue that prompt injection has evolved into “a system-level security problem with multi-party harm,” rather than a model safety issue affecting only the end user. Different stakeholders face different risks Unlike existing benchmarks that primarily measure attack success, StakeBench evaluates harm across three stakeholder groups: end users, third-party sellers, and platforms. The results show that those groups experience materially different risks. Seller-targeted attacks recorded the highest attack success rates across both evaluated web agents. User-targeted attacks, however, produced the lowest task deviation rates, suggesting they may be harder to detect because workflows continue to appear normal even when adversarial objectives are achieved. According to the researchers, “the same agent can simultaneously appear stealthy on user-targeted attacks, susceptible on seller-targeted attacks, and unstable on platform-targeted attacks.” That, they argue, makes “aggregate ASR alone insufficient to characterize stakeholder-specific vulnerability.” Models and architectures influence outcomes The benchmark also found meaningful differences between AI models and agent architectures. Replacing GPT-5 with Gemini-2.5-Flash increased indirect prompt injection success rates by 26.49 percentage points on NanoBrowser and by 6.2 percentage points on BrowserUse, the paper said. BrowserUse also consistently exhibited higher task deviation and behavioral irregularity than NanoBrowser, it added. According to the researchers, the findings suggested prompt injection resilience depends not only on the language model but also on how it is implemented within an autonomous agent. “These results indicate that prompt-injection security in deployable web agents is not a scalar property of the backbone model but a distribution of harm whose realisation is jointly determined by the affected stakeholder, the semantic alignment between the injected objective and the user’s task, and the architectural context in which the backbone is deployed,” the paper added. Images may emerge as the next attack vector The researchers also explored whether prompt injection could extend beyond text. In a preliminary multimodal experiment, they modified only a product image while leaving accompanying text, ratings, and page structure unchanged. The manipulated product’s selection rate increased from 10% to 76.67% without rating signals, suggesting visual content alone may significantly influence AI agent decisions. While the experiment was limited in scope, the researchers said the results indicate “the IPI surface relevant to deployable web agents may extend beyond textual channels to visual ones,” pointing to another emerging attack vector as enterprises increasingly deploy autonomous AI systems. View the full article

A newly disclosed Oracle PeopleSoft zero-day became the weapon of choice in a recent ShinyHunters extortion campaign that primarily targeted universities and other educational institutes. Attackers exploited the critical remote code execution (RCE) flaw in PeopleSoft’s Environment Management component that Oracle started warning customers about on June 10, 2026. In an advisory, the company urged immediate patching with no indication that the flaw is being actively exploited. Google Cloud’s threat intelligence team (GTIG) said the attack unfolded between May 27 and June 9, before Oracle publicly acknowledged the issue. Google said it notified more than 100 organizations whose internet facing systems appeared potentially exposed, with 68% of identified targets belonging to the higher education sector. “While several organizations successfully blocked the activity or remediated the vulnerabilities, others experienced compromise, resulting in stolen data being published on the ShinyHunters DLS (Data Leak Site).” GTIG said in a blog post. Oracle did not immediately respond to CSO’s request for comments. ShinyHunters, or groups trying to use their name, reportedly posted downloadable evidence of the attack on their DLS on June 9. The post claimed compromised data included “over 40 GB of billing and payment records, credit card and payment details, student finance data, and campus portal exports.” In a follow up post on June 11, the attackers threatened data leak if the victims contacted by them did not respond within “the deadline.” James Davison, chief strategy officer at Pathlock, said the incident reflects an evolving threat landscape. “The Oracle PeopleSoft breach is an example of the new kind of attacks every ERP will face in today’s new agentic world,“ he said, pointing to the ease of attacks in the AI era. “Companies need to reassess their ERP security and controls and adapt, because they are exposed.” PeopleSoft flaw gave attackers a head start The campaign relied on CVE-2026-35273, a critical vulnerability in Oracle PeopleSoft’s Environment Management component, carrying a CVSS score of 9.8 out of 10, that allows unauthenticated RCE on vulnerable internet facing systems. According to Oracle’s advisory the vulnerability affects PeopleSoft Enterprise PeopleTools, versions 8.61 and 8.62, and mitigations are only available for supported versions. Earlier versions, which could be affected by the flaw, were advised to be upgraded to supported versions. After exploiting CVE-2026-35273 to gain initial access, the attacker moved to establish persistence and maintain remote control over compromised systems. Google researchers observed UNC6240, a cluster associated with ShinyHunters, deploying a customized version of the MeshCentral open-source remote monitoring and management (RMM) platform. They did so by disguising the platform as legitimate Microsoft Azure services. “(MeshCentral) agent is software that runs on remote devices to allow for remote management across various operating systems, including Windows, Linux, macOS, and FreeBSD,” the researchers said. “Static analysis indicates these agents were hardcoded to establish communication with the command and control (C2) server wss://azurenetfiles.net:443/agent.ashx.” Once installed, the tool allowed operators to execute commands remotely and continue interacting with infected environments. Attackers left the lights on Part of Google’s investigation was aided by operational mistakes made by the attackers themselves. The campaign first drew broader attention after a security researcher, known on X as @nahamike01, reported discovering internet-exposed infrastructure from the operation. “ShinyHunters exposed several directories revealing ongoing targeting of PeopleSoft environments,” the researcher said in an X post. “Also visible were staging materials, including MeshCentral agents, and a defacement and credential spray script.” Google said exposed attacker directories highlighted by @nahamike01 helped its team analyse the contents including staging materials, customized agents, and attacker command histories. The directories were exposed across five sequential IP addresses (142.11.200[.]186-190), making them the primary indicators of compromise (IOCs). Google urged organizations to apply fixes for CVE-2026-35273 and review PeopleSoft deployments for indicators associated with the campaign. The researchers further advised organizations to investigate privileged access, enable comprehensive logging, and strengthen monitoring around unauthorized MeshCentral installations. “This attack shows that traditional perimeter security and IdP-level authentication are necessary, but not sufficient,” Davison said. “Modern ERP security requires a layered approach that combines preventive controls, continuous monitoring, and visibility into user activity. The visibility into user activity is key here, behavioral monitoring to spot exceptions isn’t a ‘nice to have’ anymore.” View the full article

For 30 years, cybersecurity has operated like an emergency room. Reactive. Crisis-driven. Always triaging. We are extraordinarily good at it — our detection is faster, our response playbooks are sharper, our incident teams are more capable than they have ever been. When something goes wrong, the modern security organization runs toward the fire with real skill. But here is the uncomfortable truth that artificial intelligence is now forcing into the open: An emergency room does not produce a healthy population. Healthcare does that — through prevention, continuous monitoring, early diagnosis and a model of the whole patient. Cybersecurity never built that model. We built the trauma bay and called it a profession. For a long time, we got away with it. The threat environment moved at human speed. The gaps in our thinking were survivable. AI has ended that grace period. It has not created a new weakness so much as it has illuminated the oldest one — and it is now moving faster than our reactive posture can absorb. We do not have a tooling problem. We have a missing-model problem. And until we name it, no amount of investment will fix it. We’ve been asking — and answering — the wrong question Walk into almost any boardroom and you will hear the same exchange. A director asks the CISO: “Are we secure?” It is the wrong question, and most of us have known it for years. “Secure” is binary. It is a snapshot. It is a yes-or-no answer to something that is actually a living, continuously changing condition. No physician would accept that question from a patient. A doctor does not ask “Are you healthy?” and expect a useful answer. They ask a better set of questions: How are you functioning? What do the vital signs say? What is trending in the wrong direction? What needs attention now, before it becomes a crisis? Cybersecurity has never adopted that mindset because it never had the model that requires it. We have frameworks for controls. We have frameworks for adversary behavior. We have no widely adopted framework for organizational health — for whether the enterprise, as a whole living system, is well. That gap was tolerable when threats were slow. It is not tolerable now. Why AI breaks the reactive model AI changes three things at once, and each one punishes a reactive posture specifically. It compresses the timeline. Reconnaissance, exploitation, lateral movement and exfiltration that once unfolded over days now unfold in minutes. An emergency-room model assumes there is time between the symptom and the intervention. AI is closing that window. You cannot triage your way through an attack that completes before the triage begins. It industrializes the routine. AI makes competent attacks cheap and abundant — phishing that is grammatically perfect and contextually aware, deepfaked executives authorizing transfers, vulnerability discovery at machine scale. The reactive model assumes a manageable volume of meaningful events. AI removes that assumption. It introduces a new organ we do not know how to monitor. Every enterprise is now deploying AI systems into its own operations — including its security operations. These systems make decisions, take actions and carry risk. They are, in clinical terms, a new organ inside the body. And most organizations have deployed them with no intake assessment, no monitoring of their condition and no governance of their behavior. We have added an organ to the patient and never checked whether it is healthy. A reactive model has no answer to any of this. You cannot out-triage machine speed. The only viable response is to shift from reaction to health — to build the enterprise’s adaptive capacity before the crisis, not after. What a health model actually looks like This is the thinking behind the Clinical Cybersecurity Framework — a model I have developed over two decades in the CISO chair, and one that has resonated strongly enough with peers over the past months to convince me it is naming something the industry already feels. The premise is simple. An enterprise should be treated less like static infrastructure and more like a living organism — and once leaders see that anatomy clearly, the entire security conversation changes. Every enterprise has the same essential anatomy: ENTERPRISE SYSTEMCLINICAL EQUIVALENTCritical business servicesOrgansData flowsCirculatory systemIdentity and accessImmune systemInfrastructureNervous systemTelemetry and monitoringVital signsIncident responseEmergency medicineResilience and recoveryRehabilitationGovernanceClinical leadershipAI oversightAutonomous clinical supervision Patrick Doliny This is not a metaphor for its own sake. It is an operating model, and it does three things a controls checklist cannot. It makes diagnosis come before treatment. No competent clinician prescribes before examining. Yet cybersecurity routinely buys tools before it has assessed the patient. A health model requires a clinical intake first — an honest baseline of how the organization is actually functioning — and only then a treatment plan built for that specific patient. It makes health measurable and continuous. A patient’s vital signs are monitored continuously, against known healthy ranges, with the direction of movement mattering as much as the current value. A health model holds cybersecurity to the same standard: Not an annual audit snapshot, but continuous monitoring of the organization’s real condition. It gives every leader one shared question. A heart rhythm is universally legible — a clinician, an administrator and a frightened family member can all read the same monitor and grasp the same essential question: Is the rhythm steady, or is something wrong? Cybersecurity has never had that shared signal. Boards get threat counts and patch percentages; they do not get a pulse. A health model gives technologists, executives and directors one common language for the same reality. Where this fits with the frameworks we already have This does not replace what works. It completes it. NIST explains controls — the disciplined architecture of safeguards. MITRE explains adversaries — how attackers think and move. Both are essential. Neither was built to answer whether the organization, as a whole, is well. NIST tells you whether the safeguards exist. MITRE tells you who is coming for them. A clinical model tells you whether the patient can withstand the encounter — and recover from it. That third question is the one AI is now asking with an urgency the industry has never faced. It is the missing layer, and it sits above the others, not against them. Patrick Doliny Why this matters for the CISO and the board Adopting a health model changes the CISO’s role and changes it for the better. It moves the CISO out of the position of the technician who reports incidents and into the position of the clinician who reports condition. “Are we secure?” has no good answer. “Here is our organizational health, here are the vital signs trending the wrong way, here is the treatment plan and what it requires” — that is a conversation a board can actually govern with. It also reframes resilience itself. Resilience is not the redundant infrastructure that restores data. Resilience, properly understood, is the process and outcome of adapting successfully to difficult conditions — through mental, emotional and behavioral flexibility. Backups restore data. Only adaptive people and well-governed systems restore an organization. A health model treats that adaptive capacity as something to be built and measured, not assumed. And it gives the enterprise a way to think about AI that matches the stakes. If AI is a new organ, it requires what every organ requires: An intake assessment before deployment, continuous monitoring of its condition, defined operating boundaries and clinical-grade governance. AI deployed without that is not a capability. It is an unmonitored risk inside the body it was meant to protect. Patrick Doliny It’s time to stop running the emergency room The reactive era of cybersecurity is ending — not because it failed, but because it was never the whole job. We built a superb emergency room and mistook it for a healthcare system. AI is the force that has made the missing piece impossible to ignore. The organizations that will lead the next decade will not be the ones with the most tools or the loudest alerts. They will be the ones that can answer a better question than “Are we secure?” They will be the ones that can say, with evidence: We know how this organism is functioning. We are monitoring its vital signs. We are treating what the diagnosis revealed. And we are building the adaptive capacity to absorb what comes next. It is time to stop running the emergency room and start practicing medicine. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article