The 9.1-CVSS vulnerability enables attackers to circumvent RCE protections in the de facto template engine for the Java Spring ecosystem.

Maintainers of Thymeleaf, a widely used template engine for Java web applications, fixed a rare critical vulnerability that allows unauthenticated attackers to execute malicious code on servers.

The vulnerability, tracked as CVE-2026-40478, is rated 9.1 on the CVSS severity scale and is described as a Server-Side Template Injection (SSTI) issue. Thymeleaf has a sandbox-like protection that prevents user input from executing dangerous expressions, but this flaw allows attackers to bypass those protections.

“Although the library provides mechanisms to prevent expression injection, it fails to properly neutralize specific syntax patterns that allow for the execution of unauthorized expressions,” the developers said in their advisory. “If an application developer passes unvalidated user input directly to the template engine, an unauthenticated remote attacker can bypass the library’s protections to achieve Server-Side Template Injection (SSTI).”

Thymeleaf is the de facto template engine in the Java Spring ecosystem and Spring is the most popular framework for developing web applications in Java. Since Java is still widely used for development in enterprise environments, this vulnerability has the potential to impact numerous business applications.

Straightforward exploitation

According to researchers from application security testing firm Endor Labs, exploitation is straightforward with no special privileges or conditions required. Attackers just need to control input that reaches Thymeleaf’s expression engine, which is a common pattern in web applications.

Endor Labs notes in their report that Thymeleaf has defense-in-depth layers to block dangerous expressions and in this case two of them failed. For example, a string check scanned the expression text for dangerous patterns, such as the new keyword followed by an ASCII space, T (Spring Expression Language type references) and @ (SpEL bean references in some code paths). However, the check only looked for ASCII space 0x20 characters, but the SpEL’s parser also accepts tab (0x09), newline (0x0A), and other control characters between new and the class name.

Another policy blocked classes that start with java.* from being used inside T() type references, but did not block types from org.springframework.*, ognl.*, or javax.*.

“Since typical Spring applications have spring-core on the classpath, classes like org.springframework.core.io.FileSystemResource were freely constructable, and that class can create arbitrary files on disk,” the researchers said.

As such, Endor Labs was able to easily build a proof-of-concept exploit by combining the two: use a tab character after new and calling the org.springframework.core.io.FileSystemResource class to create a file on disk.

“With the right class, an attacker can escalate from file creation to full remote code execution, for example, instantiating a ProcessBuilder wrapper from a third-party library, or leveraging Spring’s own GenericApplicationContext to register and invoke arbitrary beans,” the researchers explained.

Vulnerabilities in the Java Spring Framework itself have been exploited in the past to compromise web servers, so it’s likely that an easy-to-exploit flaw such as this one will be quickly adopted by attackers.

Logs in wireless access point flash memory grow by 5MB a day in certain IOS XE devices until space runs out.

Cisco admins are scrambling to patch a critical flash memory overflow vulnerability in over 200 Cisco Systems IOS XE-based models of wireless access points (APs), caused by a recent flawed software update.

If the issue is not corrected quickly, the AP’s memory will become so flooded that new software updates will be blocked and the AP rendered insecure, or possibly even bricked.

The problematic library update causes a specific log file in the flash memory of affected access points to grow by about 5MB a day. Over time, Cisco said in an advisory this week, this could consume “a big portion” of the available memory space.

“The longer an AP runs the affected software, the higher the probability that a software download will fail due to insufficient space,” the advisory says.

Analyst Rob Enderle of the Enderle Group said that ‘buggy logs’ are a common trope in networking. But, he added, “this particular case is dangerous because it targets the physical limitations of flash memory on hardware that is notoriously difficult to access once it becomes bricked or enters a boot loop. In the world of networking, this is a high-impact, medium-rarity event.”

He explained, “what makes this unique is the Catch-22 it creates. To fix the bug, you must upgrade the software. However, the bug itself prevents the device from having enough space to download the fix. If an admin waits too long, the device may require manual, physical intervention or become permanently stuck in a boot loop.”

Johannes Ullrich, dean of research at the SANS Institute, called this particular problem uncommon, although he acknowledged flash memory space in IoT devices like access points is limited and may fill up from time to time.

“But,” he added, “there is a bigger issue: A competent [vendor] vulnerability management program must always include verification that the patch was indeed applied as expected. There are many reasons why a patch may not be applied correctly, and this is just one way a patch may fail to apply.”

Kellman Meghu, CTO of incident response firm DeepCove Cybersecurity, said overflowing a fixed device’s memory due to a bug “would have me rather annoyed with this vendor. This is very rare in my experience, and something that was an issue way back when storage costs were a factor. I would expect my vendor to be able to clean and manage storage for fixed devices. If this device is supported, this would be an RMA [return merchandise authorization] or fix issue, and expectation [for vendor action] would be right away/proactive.”

[Related content: Cisco Webex SSO flaw]

Affected are access points running IOS XE versions 17.12.4, 17.12.5, 17.12.6, and 17.12.6a. These include Cisco Catalyst 9130AX series APs, as well as 9130AX models with a Stadium Antenna, Catalyst 91361, 91621, 9163E, 91641, 9166D1, and IW9167 series APs, and Wi-Fi 6 Outdoor APs,

There are two ways for admins to solve the problem: Download a Cisco tool called WLANPoller, which automates execution of a fix across multiple APs, or manually use the show boot command on each device to look into the boot partition and see if it has enough space for an upgrade. Greater detail on the necessary action is in the Cisco advisory.

Cisco says a mandatory precheck of an AP’s status should be run as close to the scheduled maintenance window as possible. But because the affected log file grows daily, Enderle said, “you sure don’t want to wait until [AP] failure.” 

Manual fixing will probably take 5-10 minutes of active work per AP, he cautioned, plus another 15-20 minutes soak time to make sure the fix takes if the AP does have room for the upgrade. But if the AP has space problems, the time per device could jump to around 20-45 minutes.

And if the AP has failed, then it would take one to two hours to fix, he added, and would need physical access to the device.

Using WLANPoller will make the process faster, he added.

Enderle said that if an admin finds an AP whose flash memory is already too full to upgrade, a reboot sometimes clears temporary buffers or allows a small window for a manual transfer. However, with this specific log bug, a reboot may not be enough if the file is persistent. Admins should contact Cisco for the emergency cleanup script before attempting a mass push, he said.

Ultimately, Enderle said, the pushing of a flawed update is a supply chain integrity issue. CSOs should ask their teams, ‘Do we have monitoring in place for hardware health metrics (CPU, RAM, Flash), or only for ‘Up/Down’ status?’ An AP that is Up but has 0MB of free flash memory is a liability, he said.

CSOs should look at this vulnerability as a Critical Availability Risk, he added. “While it isn’t a data breach, the potential for a site-wide Wi-Fi outage (due to failed automated updates or boot loops) can halt business operations,” he noted, adding that CSOs should also enforce a policy where even “minor library updates” are still tested in a lab environment for seven to 14 days. “This 5MB/day log growth would likely have been caught in a lab before hitting a production fleet of 5,000 APs,” Enderle said.

This article originally appeared on NetworkWorld.

The move would allow civilian agencies to access a modified version of Anthropic’s powerful vulnerability‑hunting AI, under safeguards designed to limit misuse.

The US government is preparing to authorize a version of Anthropic’s Claude Mythos model for use by major US federal agencies, amid concerns that the AI model could rapidly spot cybersecurity vulnerabilities and offer the ability to exploit them.

Federal Chief Information Officer Gregory Barbaccia at the White House Office of Management and Budget (OMB) told officials at Cabinet departments on Tuesday that the OMB was setting up protections to allow federal agencies to begin using the model, reported Bloomberg, citing an internal memo.

The memo did not commit specific agencies to deployment or provide a timeline, the report said.

“We’re working closely with model providers, other industry partners, and the intelligence community to ensure the appropriate guardrails and safeguards are in place before potentially releasing a modified version of the model to agencies,” Barbaccia wrote in the email, according to the report.

The OMB move comes while the Department of Defense’s supply-chain risk designation against Anthropic, issued on March 3, remains in force. The D.C. Circuit refused to stay the designation on April 8, keeping Anthropic barred from defense contracts while civilian agencies are now being positioned for access.

The White House and Anthropic did not immediately respond to requests for comment.

Defining the guardrails

The memo’s reference to a modified version of the model points to open questions about what agency deployment would actually look like. Anthropic announced Claude Mythos Preview on April 7 under Project Glasswing, a controlled-access program for select technology and financial organizations.

The company then said the model identified thousands of zero-day vulnerabilities across every major operating system and browser in internal testing and stated it did not plan to make the model generally available.

“For a federal deployment to be defensible, the modifications must cover specific assurance dimensions,” said Neil Shah, VP for research and partner at Counterpoint Research. “The software code base being scanned should remain sovereign within an isolated and air-gapped environment, and the data should not be used to retrain the base model.” Additional steps could include transparency requirements and human-in-the-loop review before any bug fix is applied, he said, to make the deployment more controlled.

Enterprise implications

Those same assurance questions translate directly to enterprise procurement. The OMB move signals that federal cyber defense is pivoting toward frontier models that can find vulnerabilities faster than human teams can patch them, and the rift between the Pentagon and the White House carries a lesson for private-sector buyers, Shah said.

“The rift between the two government entities is a lesson on how important it is to control the deployment of potent AI capabilities which could be misused,” he said, calling for a multi-layered control framework spanning discovery, classification, security, assurance, and action.

The asymmetry extends beyond US borders. European agencies have largely been blocked out of early access, with only the UK AI Security Institute granted the ability to test the model. If the OMB authorization proceeds on the terms Barbaccia described, defensive AI capability inside the US federal government would advance ahead of European counterparts, while the Pentagon designation against the same vendor continues to move through the courts.

A civilian workaround to the Pentagon ban

The modified version approach is how Anthropic is navigating around the Pentagon position without losing control of the model, Shah said.

“The Anthropic modified version thereby circumvents the Pentagon’s black and white approach and helps other entities adopt the model as a security enclave for civilian and enterprise sovereignty with agreed-upon guardrails,” Shah said. He added that the arrangement sets a precedent for Anthropic’s future adoption across other government entities and enterprises.

Federal access to Anthropic has been in flux for weeks. A US District Court in California granted Anthropic a preliminary injunction on March 26 against a parallel civilian designation, a ruling that gave contractors breathing room to reassess AI supply chains.

New PoC shows how Microsoft Defender can be tricked into rewriting malicious files into protected locations, enabling SYSTEM-level privilege escalation on fully patched Windows systems.

Days after Microsoft patched a high-severity issue affecting its Windows Defender antivirus tool through April’s Patch Tuesday, researchers warn of another vulnerability that could enable SYSTEM privileges through local escalation.

In a newly disclosed proof-of-concept (PoC) exploit, dubbed “RedSun,” GitHub user going by the name “Nightmare Eclipse” demonstrated how Microsoft Defender’s handling of certain cloud-tagged files can be abused to overwrite protected system files and escalate privileges.

“When Windows Defender realizes that a malicious file has a cloud tag, for whatever stupid and hilarious reason, the antivirus that’s supposed to protect decides that it is a good idea to just rewrite the file it found again to its original location,” Eclipse wrote in the PoC repository description.

The PoC exploit impacts Windows 10 and Windows 11 systems running Microsoft Defender, specifically builds with cloud files features enabled.

Antivirus rewrites the threat

The RedSun PoC highlights a counterintuitive behavior. Defender’s remediation process may restore a flagged file under certain conditions. Specifically, files tagged with cloud metadata (such as those used by OneDrive and similar services) trigger a different handling path inside the antivirus engine.

Rather than permanently removing the malicious file, Defender attempts to restore it to its original source, rewriting the file back to disk. The PoC exploits this mechanism to, during the rewrite process, manipulate the file contents or destination.

If an attacker can control the timing and location of the rewrite, they can replace legitimate system binaries or configuration files with malicious payloads. RedSun demonstrated this exploit to gain SYSTEM-level privileges.

Will Dormann from Infosec Exchange verified the PoC using the Cloud Files API. “This works ~100% reliably to go from unprivileged user to SYSTEM against Windows 11 and Windows Server 2019+ with April 2026 updates, as well as Windows 10, as long as you have Windows Defender enabled,” he said. “Any system that has cldapi.dll should be affected.”

Dormann used the Cloud Files API to introduce a specially crafted file, followed by “oplock“ to control file access timing. From there, the exploit leverages Volume Shadow Copy race conditions and directory junctions/reparse points to redirect where Defender writes the file.

Second Defender-based LPE in days

The Defender flaw addressed earlier this week as part of Patch Tuesday was one of the two zero-day bugs Microsoft fixed, and it also allowed local privilege escalation stemming from “insufficient granularity of access control.”

While Microsoft attributed the discovery of the flaw, tracked as CVE-2026-33825, to security researcher Zen Dodd, the flaw already had a PoC exploit, “BlueHammer,” available before it was even fixed. It came from “Chaotic Eclipse,” an alias used by Nightmare Eclipse on other publishing platforms. The flaw received a high-severity rating of 7.8 out of 10.

Helmut Reisinger, Palo Alto’s CEO for EMEA, reflects on the importance of Project Glasswing, the company’s recent slate of acquisitions, and the evolution of cybersecurity in the AI era.

In two decades, Palo Alto Networks has evolved from a next-generation niche player to one of the largest global cybersecurity giants today. Under its mantra of “platformization,” the company has catapulted its revenues over its closest competitors and boosted its stock valuation to over $130 billion.

No stranger to AI use in cybersecurity, Palo Alto recently announced its participation in Project Glasswing, an AI-based vulnerability-discovery initiative led by Anthropic that many are viewing as a structural shift for the cyber industry. The initiative, which includes 10 other major technology companies as coalition partners, including AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, and Microsoft, aims to leverage Anthropic’s Claude Mythos to improve the security of the software that underpins much of the world’s technical infrastructure.

It is in this context that Computerworld Spain spoke with Helmut Reisinger, CEO of Palo Alto Networks for EMEA, in Madrid at the company’s Ignite event on April 14. The interview was conducted in Spanish, a language that the multilingual Austrian executive and PhD holder speaks fluently.

Following are excerpts from that interview, edited for length and clarity.

Computerworld Spain: Let’s start with the recent announcement of Palo Alto’s participation in the exclusive Mythos project, which few companies have access to due to the power of this technology and the risk of it falling into the wrong hands. Or is this just a marketing strategy?

Helmut Reisinger: Indeed, this is a restricted release that only a few companies can access for vulnerability testing. We’ve witnessed firsthand how this pioneering model represents a radical shift. With it, we’ve detected zero-day vulnerabilities in an unprecedented number of operating systems and browsers. And it’s capable of turning most of these vulnerabilities into working exploits, with all the risks that entails. For now, we can’t say much more. We’re currently working on providing more information through a blog. In any case, the important thing is the context in which this is happening.

On the democratization of AI.

Yes. At Palo Alto, we’ve been using AI to improve cybersecurity for a long time. Back in 2014, we integrated machine learning technology into our systems, initially just firewalls. But we also develop cybersecurity solutions specifically for AI. The major challenge today is that, according to a Stanford University report, only 6% of AI deployments are implemented with appropriate cybersecurity. And this is happening in the age of agents, where for every human identity there are approximately 80 machine identities, and even more if we include agents. That’s why, thanks to our acquisition of Protect AI, a company founded by Ian Swanson, formerly head of AI at Amazon, we’ve launched a security solution for AI deployments, language models, and agents.

This is just one of several purchases Palo Alto has made recently, correct?

Yes, we just closed the deal [in February] with CyberArk, a leader in identity security. At Palo Alto, we’re convinced that AI and identity are two worlds that must go hand in hand, especially now in the era of generative systems and agents.

Another acquisition we recently completed, in January, and which falls within this context of addressing the current AI landscape, is that of Chronosphere, a leader in observability. Chronosphere is capable of managing and protecting massive volumes of AI-generated data at a lower cost — half the price — of other market players. This is an important acquisition because observability is essential in cybersecurity.

And finally, we’ve acquired Koi, a deal I expect will close in a few days. Koi’s technology focuses on agentic endpoint security — protecting businesses from the risks of using AI agents and autonomous development tools operating on users’ devices. Koi’s technology will be integrated into our Cortex XDR platform to monitor what AI agents are doing on users’ computers and detect if they are being manipulated to execute malicious commands.

I imagine effectively integrate all these companies presents significant challenges.

That’s right, because many IT companies, when they make acquisitions, focus more on contractual than technological integrations, but that’s not our approach. Our strategy involves complete technological integrations, like Protect AI, which is now part of our network platform. This aligns with our commitment to platformization using a modular system.

It’s clear that ‘platformization’ is the company’s mantra and a way to simplify life for customers, but doesn’t it also create greater dependencies, including vendor lock-in?

Yes, we sometimes hear clients say they don’t want to put all their eggs in one basket. But that’s precisely why our strategy is modular, so the client can decide. It’s also true that all the clients who have experienced a massive data breach have opted for complete platformization. In fact, our founder [Nir Zuk] has always said that “everyone will switch to platforms as soon as they suffer a mega-breach.”

The speed of platform adoption, therefore, will be determined by the client themselves, their business, their use cases, their existing contracts, and so on. We are also making efforts to reduce costs to encourage clients to migrate and simplify their platformization process. Furthermore, we mustn’t lose sight of the fact that the approach to cybersecurity must be comprehensive; it’s a global chain.

Regarding cost, Palo Alto has a reputation for having powerful but expensive technology. What’s your opinion?

Compared to the level of protection we provide our customers, our technology isn’t that expensive. On the other hand, the cost also reflects all the innovation included in our solutions.

How do you see Palo Alto Networks’ major competitors, primarily Fortinet and CrowdStrike?

The cybersecurity market is fragmented, but we lead it. That said, we have to win every single day.

The current, highly turbulent geopolitical climate is having a significant impact on the cybersecurity field, as well as on customers’ IT purchasing decisions. Does being a US player in Europe affect Palo Alto? Are you seeing a shift among public sector clients toward more local options?

CISOs with high levels of responsibility know very well that a wealth of telemetry data is essential for effective protection, and that’s why we aren’t seeing a decrease in demand. That’s the primary reason. Furthermore, each region and country has its own legal frameworks and regulations, which we fully respect. In fact, we were among the first companies in the world to sign the European AI Act and ensured we also obtained the corresponding national certifications.

Our view on sovereignty is that we must find a balance between perfect sovereignty and zero sovereignty. When we talk about sovereignty, we can refer, for example, to hardware. Regarding this issue, we must accept the interdependence we have between different global markets; this happens, for example, in the field of chips. But if we talk about data sovereignty, this is something that can be easily achieved.

We implement the Bring Your Own Key (BYOK) policy for many clients to ensure that the telemetry data sent by their devices is encrypted and protected. We are not interested in accessing the personal data our clients handle; we only use telemetry, application identity, user, and device data. It was precisely thanks to this type of analysis that we were able to discover the attempted intrusion using SolarWinds, although, as it occurred years ago [2020], it was carried out using machine learning tools.

How is the current war in Iran affecting the threat landscape?

This has many implications. Our Unit42 team recently published a report outlining how the joint military offensive launched by the United States and Israel activated the Iranian-aligned cyber ecosystem, creating a scenario of digital confrontation that transcends the region and combines hacktivism, political messaging campaigns, and pressure on critical infrastructure.

In this regard, I want to bring up the issue of sovereignty again because what can a company do if its infrastructure is, for example, bombed? In other words, what does the concept of sovereignty mean in an emergency situation? We already have clients in the Middle East who are rethinking their sovereignty strategy because of this situation. Furthermore, as we saw earlier, we are talking about telemetry data, not other types of data. Ultimately, all of this shows that the concept of sovereignty is fluid.

Returning to Europe, in less than two months Palo Alto will be opening new offices in Spain and, in addition, a ‘hub’, correct?

Yes, we want to establish a center of excellence here. In Europe, in addition to Madrid, Palo Alto has large offices in London, Amsterdam, Paris, and Munich. From Madrid, Jordi Botifoll has been leading the business for 87 countries — not only in Southern Europe, but also in the Middle East, Africa, etc. — for the past three years.

And what are your expectations for the new center of excellence? Why have you chosen Spain?

Cybersecurity requires a lot of technological expertise, and Spain has very good engineers who can help our clients in case of emergency, both through our incident response unit, Unit 42, and through our partners, such as Telefónica Tech, Kyndryl, and Orange, because ours is a technology company, not a service company.

How many employees do they have in Spain, and what will the number of employees be at the new center?

I can’t break down local numbers, but overall, across the entire company, once the 4,000 CyberArk professionals are integrated, we’re already around 20,000 people worldwide. Our main development centers are in California and Israel, although we also have others in Poland and Lithuania.

Looking ahead, significant challenges in information security are coming with the arrival of the post-quantum era.

Yes, and we’re already preparing. We’ve launched Quantum Safe Security to help organizations get ready for the post-quantum era. Because the big question scientists and experts are asking now is when ‘Q Day’ will be, which might arrive sometime between 2029 and 2035. Furthermore, integrating CyberArk technology will help ensure that credentials used by machines cannot be compromised through quantum decryption.

The cybersecurity of the future must be real-time, highly automated, and simple for customers, or what we call modular ‘platformization.’

Finally, what would you say is the biggest challenge for CISOs today?

Shadow AI. We must prevent AI from suffering the same fate as other technologies in the past, creating what’s known as shadow IT. AI deployments must be accompanied by robust cybersecurity. And AI and identity management must go hand in hand. Another concern is the fragmentation of solutions. I was recently speaking with an executive at a large European bank who told me they have 60 different solutions; the gaps between these systems are a clear invitation to attack.

Unsafe defaults in MCP configs open servers to possible remote code execution, as evidenced by several commercial services and open-source projects.

AI agent building tools enable users to configure Model Context Protocol (MCP) servers may be exposing systems to remote code execution due to an architectural decision in Anthropic’s reference implementation.

At issue are unsafe defaults in how MCP configuration works over the STDIO interface, with broad implications for the agent ecosystem, according to a new report.

“The blast radius is massive,” researchers from application security firm OX Security wrote in their report on the design issue. “This exploit allowed us to directly execute commands on six official services of real companies with real paying customers, and to take over thousands of public servers spanning over 200 popular open-source GitHub projects with hundreds of millions of downloads.”

According to Anthropic and other MCP adapter developers, the STDIO command execution behavior is by design and the responsibility of sanitizing MCP configurations falls with developers of client applications. While this might be true, in practice OX Security found that few developers have attempted to filter commands in MCP configs and even those who did failed to catch all potential bypasses.

The root of the issue

MCP provides a standardized method for applications to expose data sources and tools to LLMs, improving their context and effectiveness in completing automated workflows. Originally developed by Anthropic, MCP has become a widely adopted technology in the agentic AI space.

Anthropic provides reference MCP implementations in the form of SDKs for a variety of programming languages, including TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Furthermore, other frameworks and functionality providers — such as FastMCP, LangChain’s mcp-adapters, Microsoft’s agent-framework, mcp-agent, browser-use, Amazon’s run-model-context-protocol-servers-with-aws-lambda, and NVIDIA’s NeMo-Agent-Toolkit — have Anthropic’s modelcontextprotocol reference implementation as a dependency.

MCP supports two transport interfaces between servers and clients: Streamable HTTP with Server-Sent Events (SSE), which is typically used for remote MCP servers and web services, and Standard Input/Output (STDIO), for MCP servers and applications that run locally on the same machine.

With STDIO, client applications can start MCP servers on demand as a subprocess and pass parameters to them. These parameters can include custom commands that get executed on the system with the permissions of the parent process. While in theory these commands are meant to tell the SDK’s StdioServerParameters function how to start the MCP server, they can technically be anything if no filtering is in place.

The OX Security researchers consider this a design flaw that should be mitigated, but Anthropic disagrees, as do the creators of other frameworks that enable MCP functionality, such as LangChain and FastMCP. The argument is that the responsibility for making sure malicious user input doesn’t reach the SDK’s command execution function resides with the developers of the client applications that integrate these MCP frameworks.

“The pattern of allowing user-supplied strings to flow directly into a shell execution environment is an anti-pattern that should be deprecated,” the OX Security researchers said. Anthropic’s SDKs should implement a command allowlist by default that blocks sh, bash, powershell, curl, rm, and other high-risk binaries, they added.

The core issue is that there’s currently no check in place to verify that a STDIO command is intended to initialize an MCP server rather than perform a malicious task. Furthermore, the researchers observed that even if the sent command fails to start the server, the SDK returns an error after the command has already been executed.

All modern IDEs such as VS Code, Cursor, and Windsurf, as well as agentic coding CLIs like Claude Code, OpenAI Codex, and Gemini CLI, have built-in support for local MCP servers over STDIO. But so do countless other agentic AI frameworks and open-source tools and few of them implement STDIO command allow lists.

RCE in real-world applications

The OX Security researchers have spent the past few months testing MCP support in numerous tools, including live production services. They found and reported more than 30 RCE issues stemming from this STDIO design decision to multiple projects and 10 have received CVE IDs so far.

Depending on how a tool implements MCP support and how it accepts user input, there are multiple attack vectors that exploit the lack of STDIO command filtering.

For example, some services and tools have not disabled STDIO internally even though their user interfaces only allow configuring MCP servers with Streamable HTTP. This was the case for Letta AI and DocsGPT, two platforms that enable companies to create AI agents via both cloud services and local deployments.

“An attacker crafting a network request for an MCP server configuration, and changing the transport type in the configured JSON to contain an STDIO type instead of SSE or HTTP, also adding an arbitrary command to the request’s payload, can achieve remote command execution,” the researchers said.

Another attack vector is prompt injection leading to malicious MCP configurations. While all IDEs are technically vulnerable to this — websites may contain hidden instructions for LLM agents to modify local files — most IDEs prompt users before making modifications to MCP configuration files. The exception was Windsurf, which directly modified the MCP config by default, resulting in a zero-interaction command injection attack.

Many other tools don’t apply filtering to MCP STDIO parameters, meaning any user with access to configure an MCP server gains code execution on the underlying server, including production servers in the case of SaaS deployments. Tools found vulnerable to this include LangFlow, GPT Researcher, LiteLLM, Agent Zero, LangBot, Fay Digital Human Framework, Bisheng, Jaaz, Langchain-Chatchat, and several others the researchers are not yet able to disclose.

Some developers were aware of the issue and did attempt to harden their implementations with command whitelisting. However, the hardening was insufficient, and the OX Security researchers found simple bypasses.

For example, Upsonic, an open-source framework for building AI agents, implements an allowlist that includes npx, which supports -c (—call), a flag that allows custom commands and shell scripts to be passed for npx to execute. The same bypass was observed in Flowise, another UI-based AI agent building framework that also restricts MCP configuration commands but allows npx.

Anthropic (modelcontextprotocol), LangChain (langchain-mcp-adapters), FastMCP, the browser-use project, AWS (run-model-context-protocol-servers-with-aws-lambda), NVIDIA (NeMo-Agent-Toolkit), OpenHands, PromptFoo, Firebase Studio, Gemini CLI, Claude Code, GitHub Copilot, and Cursor technically include the MCP STDIO code that allows for arbitrary command execution.

The cloud-based Webex service has already been patched, but admins must replace an identity provider certificate in Webex Control Hub to complete the fix.

Admins who use Cisco Webex Services configured to use trust anchors within the SSO integration with Control Hub must install a new identity provider certificate to close a critical vulnerability, or risk losing access control.

Cisco said in an advisory this week that admins must upload a new identity provider (IdP) SAML certificate to Webex Control Hub, the web-based management portal where IT administrators can control all Cisco Webex services, including certificate management, meetings, messaging and calling. Failure to close this hole will allow an unauthenticated, remote attacker to impersonate any user within the service.

The vulnerability, CVE-2026-20184, carries a CVSS score of 9.8.

Because Webex is a cloud service, Cisco can, and has, patched its side of the application. But admins using single-sign on (SSO) still need to install the new certificate. There are no workarounds.

A Webex support article on managing SSO integration says that information about certificates is found in the Webex Control Hub Alerts center, where customers can view which ones are installed, and their status. The Control Hub also contains an SSO wizard to aid in updating certificates. The article contains step-by-step details on the process.

Asked for comment, and for more details about the vulnerability, a Cisco spokesperson didn’t go beyond the advisory. “Cisco published a security advisory disclosing a vulnerability in the integration of single sign-on with Control Hub in Cisco Webex Services,” the spokesperson said. “At the time of publication (April 15) Cisco had addressed the vulnerability, and was not aware of any malicious use of this vulnerability. Affected customers must update their SAML certificate to ensure uninterrupted services.”

Gartner analyst Peter Firstbrook noted in an email that, since Cisco has applied the patch to the cloud service, this is more of a configuration change. But that doesn’t minimize the possible damage. “While we are not aware of exploits using this vulnerability, users can lose SSO access to Webex without this change,” he said. 

“This does illustrate a bigger trend that identity and access management is the corporate perimeter,” he added, “and the majority of attacks include an identity and access management component. CISOs must increase their focus on IAM hygiene, particularly as agentic computing is accelerating.” 

Identity and access management is, of course, the keystone of cybersecurity. As Crowdstrike observed in its 2026 Global Threat Report, abuse of valid accounts accounted for 35% of cloud incidents it investigated last year, “reinforcing that identity has become central to intrusion.” Single sign-on allows a user to authenticate to multiple applications through one set of credentials. It’s efficient, and, of more importance to a CSO, strengthens security.

Additional critical fixes

The Webex flaw is one of three critical vulnerabilities Cisco identified and issued patches for this week. In addition, multiple vulnerabilities have to be patched in Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC).

These holes (CVE-2026-20147 and CVE-2026-20148, which carry CVSS scores of 9.9), could allow an authenticated, remote attacker to perform remote code execution or conduct path traversal attacks on an affected device. To exploit these vulnerabilities, the attacker must have valid administrative credentials, and send a crafted HTTP request to an affected device. There are no workarounds.

Separately, two more vulnerabilities were found in ISE that could lead to remote code execution on the underlying operating system of an affected device. To exploit these vulnerabilities (CVE-2026-20180 and CVE-2026-20186), the attacker would only need Read Only Admin credentials.

The agency will only add enrichment details to CVEs in limited cases going forward, prioritizing known exploited flaws and vaguely defined ‘critical software.’

Overwhelmed by an escalating volume of security flaws, the National Institute of Standards and Technology (NIST) has announced significant changes to how it handles cybersecurity vulnerabilities and exposures (CVEs).

Rather than commit to providing enrichment for all entries in its National Vulnerability Database (NVD), the agency will focus on just the most critical CVEs, which will “allow us to stabilize the program while we develop the automated systems and workflow enhancements required for long-term sustainability.”

Starting immediately, NIST will focus on CVEs appearing in CISA’s Known Exploited Vulnerabilities (KEV) catalog. “Our goal is to enrich these within one business day of receipt,” the agency said.

Other high-priority CVEs will also include those for software used in the federal government and for other critical software.

All the other CVEs will still be added to the NVD, but will be categorized as “not scheduled,” meaning that NIST will no longer prioritize their enrichment.

Broken by backlog

According to NIST, a backlog of CVEs started to accumulate in early 2024, and the agency has been unable to clear it due to increasing submissions.

Submissions grew by 263% between 2020 and 2025, according to the agency, with nearly one-third more vulnerabilities reported in Q1 2026 than the same time last year.

The agency, which enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, now faces a total backlog of more than 30,000 CVEs, said Harold Booth, a technical and program lead at NIST, at this week’s VulnCon cybersecurity conference.

SOURCE: https://www.cve.org/about/Metrics

CSO

As a result, NIST will now forego enrichment for all but the most critical of vulnerabilities.

Backlogged CVEs received prior to March 1 will also be labeled “not scheduled.” None of those are critical vulnerabilities, NIST said, because those have always been handled first.

“They’ve just come out and publicly stated, ‘We are never going to get through this backlog,’“ Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CSO.

In addition, NIST will no longer calculate severity scores for CVEs submitted with scores provided by the reporting organization.

Security leaders reliant on NIST enrichment will need to take stock of their technology inventories to see whether they fall under NIST’s priority list, Childs said. That’s not easy.

“Discovery is one of the most difficult problems we’re dealing with,” he noted, adding that it’s also not clear what software actually falls into the priority category. “Software used by the federal government is a very vague statement.”

Mounting CVE counts — with AI flaw discovery on the rise

Childs is not surprised that CVEs numbers have been going up, citing AI as part of the reason why.

“We’re already seeing more garbage CVEs — and more real CVEs — related to AIs,” he says.

Dealing with these CVEs is going to be a massive problem for companies. “People still don’t patch,” he says. “And we’re going to quadruple the number of patches they’re going to have to deploy. How do we build our defenses across the entire enterprise? I don’t know if we’ll get there before the bad guys do.”

According to the Forum of Incident Response and Security Teams (FIRST), 59,427 CVEs are expected to be submitted this year, up from a little over 48,000 in 2025. That makes 2026 the first year that CVEs will pass the 50,000 milestone.

“The sheer velocity of vulnerability discovery and exploitation is unlike anything we’ve seen before,” FIRST CEO Chris Gibson told CSO.

FIRST has also modeled “realistic scenarios” in which the total number of CVEs cracks 100,000 for 2026 — but that was in February, before Anthropic announced Mythos, its vulnerability-finding AI model many foresee as a structural shift for the cybersecurity industry.

“And if it’s not Mythos, or whatever else is coming out now, something is going to come out next week,” said Empirical Security founder Jay Jacobs, who also leads the Exploit Prediction Scoring System special interest group at FIRST.

Still, Jacobs is optimistic that turning to technology will help NIST deal with rising CVE volumes.

“Harold Booth has a lot of experience and skill working with AI over the last few years,” Jacobs told CSO. “So I’m expecting him to bring some expertise and I hope we do see some AI news there.”

Both large language models and AI agents are on the agency’s to-do list, as is old-fashioned robotic process automation (RPA), Booth said in his presentation at VulnCon, which Jacobs chairs. NIST also plans to delegate some of the work to CVE Numbering Authorities (CNAs), which includes security vendors and researchers.

A cybersecurity researcher says Recall’s redesigned security model does not stop same-user malware from accessing plaintext screenshots and extracted text, without admin rights or exploits.

Microsoft’s Windows Recall feature remains vulnerable to complete data extraction despite a major security overhaul, according to a cybersecurity researcher who says malware running in a user’s context can quietly siphon off everything Recall has captured, without administrator privileges, kernel exploits, or breaking encryption.

Alexander Hagenah, executive director at Zürich-based financial infrastructure operator SIX Group, made the claim in a LinkedIn post, where he also published a proof-of-concept tool called TotalRecall Reloaded to demonstrate the issue.

Hagenah first exposed Recall’s security flaws in 2024, forcing Microsoft to pull the feature from preview and rebuild it. Microsoft relaunched Recall in April 2025, saying the new architecture would restrict “attempts by latent malware trying to ‘ride along’ with a user authentication to steal data.” Hagenah said it does not.

“When you use Recall normally, TotalRecall Reloaded silently holds the door open behind you and then extracts what Recall has ever captured. That is precisely the scenario Microsoft’s architecture is supposed to restrict,” he wrote in the post.

Hagenah wrote in the post that he disclosed the research to Microsoft’s Security Response Center on March 6, submitting full source code and reproduction steps. Microsoft reviewed the case for a month and closed it on April 3, telling him the behavior “does not represent a bypass of a security boundary or unauthorized access to data.”

“Microsoft says this is by design,” Hagenah wrote. “That worries me.”

Hagenah’s research does not challenge Microsoft’s encryption, which he said is sound. The gap, he told CSO, is in how decrypted data is handled once it leaves the enclave.

“Plaintext screenshots and extracted text end up in an unprotected process for display,” he told CSO. “As long as decrypted content crosses into a process that same-user code can access, someone will find a way in.”

What a fix would require

A fix is technically feasible, Hagenah said.

“The short-term fix is fairly straightforward. Microsoft could add stronger code integrity and process protections to AIXHost.exe, the process that renders the Recall timeline. Right now, it has none, which makes the injection path possible. That would block the specific technique I demonstrated and materially raise the bar,” he said.

The longer-term problem runs deeper, he said. “Microsoft should rethink how decrypted data is handled after it leaves the enclave. The cryptography and enclave design are genuinely well done, and I want to be clear about that. The problem is that plaintext screenshots and extracted text end up in an unprotected process for display. As long as decrypted content crosses into a process that same-user code can access, someone will find a way in,” he said.

“A durable fix would mean either rendering inside a protected process or adopting a compositing model where raw data never leaves the trust boundary. That is a bigger effort, but it is the only way to close this class of issue properly,” he said.

Exploitation risk

The barrier to weaponizing this technique is lower than Microsoft’s security messaging would suggest, Hagenah said.

“They only need code running in the user’s context and a way to reuse the authorized Recall session,” he said. “That is a much lower bar than many people would assume from Microsoft’s security messaging.”

While Recall’s limitation to Copilot+ PCs and its opt-in status reduce the scale of exposure, targeted abuse is a realistic near-term risk, he said. “For targeted abuse, surveillance, or high-value user collection, this is absolutely realistic,” he said.

Hagenah said he published the source code deliberately so defenders, EDR vendors, and security teams could build detections before threat actors operationalize the technique independently. “In my view, that gives the defensive side a valuable head start,” he said.

Independent security researcher Kevin Beaumont reached a similar conclusion after separately testing the current Recall implementation. “Yep, you can just read the database as a user process,” Beaumont wrote on Mastodon on March 11. “The database also contains all manner of fields that aren’t publicly disclosed for tracking the user’s activity. No AV or EDR alerts triggered,” he wrote.

Microsoft did not immediately respond to a request for comment.

As hype builds around Anthropic’s offensive AI model, VulnCheck’s analysis finds just one confirmed CVE tied directly to Project Glasswing, raising questions about how Mythos’ real-world impact should be measured.

Efforts to cut through the buzz surrounding Anthropic’s Mythos are emerging. As OpenAI moves to counter the hype around it with its own cybersecurity model, VulnCheck is reporting that the model’s publicly attributable output amounts to just one confirmed CVE.

While Project Glasswing, the controlled access program for Mythos, promises a powerful offensive capability, gated behind vetted organizations, VulnCheck’s recent findings reveal what those capabilities actually represent in practice.

“Anthropic’s Project Glasswing has generated significant attention—but very little concrete data,” said Patrick Garrity, researcher at VulnCheck, in a blog post. “While Anthropic researchers are actively contributing to vulnerability discovery and appear to be promising, the publicly attributable impact of Glasswing itself remains limited so far.”

Anthropic did not immediately respond to CSO’s request for comments.

Only one CVE is attributable to Glasswing

VulnCheck’s analysis of Project Glasswing drills into the numbers behind the claims by looking into public CVE attribution. “I started by re-reading the Glasswing report and the advisories published at red.anthropic.com,” Garrity said. “Neither source provides a comprehensive CVE list of vulnerabilities discovered by Anthropic. So I decided to search the full CVE record database, and searched every CVE record containing the term “anthropic” and reviewed each one.”

Garrity identified 75 CVE records that mention Anthropic. But only 40 of those were actually credited to Anthropic researchers, with the rest tied to affected products or unrelated references. Of those 40, 10 originated from external collaboration programs, such as Calif.io’s MADBugs initiatives.

The 40 CVEs attributed to Anthropic researchers span multiple products, including 28 affecting Firefox, nine tied to wolfSSL, and one each impacting NGINX Plus, FreeBSD, and OpenSSL.

When narrowed down further, the number that mattered the most showed up. Only one CVE is explicitly attributed to Project Glasswing itself, CVE-2026-4747. This is a FreeBSD NFS remote code execution (RCE) flaw described as autonomously identified and exploited.

Garrity did not include the three vulnerabilities without CVE numbers mentioned on the Glasswing page. These include a 27-year-old OpenBSD flaw, a 16-year-old FFmpeg bug, and Linux kernel privilege escalation chains, all under embargo pending patches.

Why is Glasswing still a big deal

VulnCheck’s findings reframe Glasswing’s capabilities. The limited number of directly attributable CVEs is just one way of measuring its impact. Industry observers are interpreting Mythos much differently.

Melissa Bischoping, a SANS Technology Institute board member and senior Director of security and product research at Tanium, thinks Mythos potential lies elsewhere. According to a breakdown of the Claude Mythos Preview System Card, which Bischoping and her colleagues at Tanium reviewed, the model achieved an unseen exploit success rate. “Jumping from near-zero success to ~72% on the same class of targets suggests exploit development is no longer a high-skill, high-effort bottleneck,“ she said, adding that it’s only a matter of time before every other model catches up.

While Mythos is being regulated under Glasswing, it has already shown the world what is possible. “The gap between frontier models and open-weight models has compressed from more than a year to a matter of weeks, which means this level of capability is poised to spread rapidly, likely without the same safety guardrails,” Bischoping noted.

Bischoping is also concerned about whether organizations can act on what Mythos finds before Mythos is out in the wild. “Agentic patch workflows are possible and can match pace with adversarial AI in a lot of cases, but org politics and change control don’t run at the speed of AI today.”

The full picture about the model’s true capability won’t be known before July 2026, when Anthropic will make a full public accounting of what Glasswing found and fixed, Garrity said.

Many insurers have begun to exempt AI workloads from cybersecurity and errors and omissions coverage, saying their outputs are too unpredictable to write policies around.

Several major insurance carriers have begun to back away from providing cybersecurity and other insurance to companies using AI to run internal processes, insiders say.

While there’s no standard response to customer use of AI in the insurance market, many carriers are now quietly declining to write policies for claims related to AI-generated outputs in cybersecurity and errors and omissions (E&O) coverage, these observers say. Other insurance carriers are jacking up prices to cover AI-related claims, they say.

Dozens of insurance carriers appear to be rethinking coverage for mistakes related to AI, says Connor Deeks, CEO of Codestrap, an AI development and consulting firm that works with insurance firms.

Many insurance companies aren’t comfortable with covering AI outputs because they can’t track the reasoning path the AI took to come up with a result, he says.

“That’s playing out downstream with insurance companies basically carving out coverage, whether that’s across cybersecurity or E&O,” he says. “All of these vibe-coded solutions and these AI systems that people have constructed have inherent risk baked into the cake now, and you can’t actually see the full process.”

The insurance carrier concerns about AI workloads first surfaced in November 2025, when Financial Times reported that three major carriers, AIG, Great American, and W.R. Berkley, filed requests with US regulators to offer insurance policies that exclude liabilities tied to AI tools such as chatbots and agents. At the time, those requests appeared to be preemptive moves to be allowed to exclude AI mistakes sometime in the future.

But now, many carriers seem to be moving forward with plans to exclude AI mistakes from policies, Deeks says. Several carriers he’s been in contact with are moving to limit or end coverage for AI-related business disruptions and liabilities, he adds. The irony is that many insurance carriers are embracing AI for their own internal purposes.

Deeks’ company has a vested interest in AI insurance coverage — Codestrap markets its AI coding platform as traceable and therefore insurable — but other industry insiders have also seen similar carrier decisions.

Carriers find exclusions

It’s still unclear how many carriers will refuse to insure AI workloads, but several carriers are now writing insurance policies that exempt coverage for AI-related business chaos, says Jason Bishara, financial practice leader at global carrier NSI Insurance Group.

“The risk appetite is changing among the carriers, and it’s always constantly evolving,” he says. “With regard to AI, there are carriers that are just removing it from their risk appetite and declining to quote altogether.”

While some carriers have declined to cover AI outputs, others are building in rate hikes to cover the increased risk, Bishara says. While he doesn’t have numbers on the extent of the rate hikes, they are significant, he adds.

“Every business has insurance, and every business now is using AI to some extent,” he adds. “Are you seeing those liabilities and exclusions within these policies and an aversion to it from the carriers? The answer is yes.”

Carriers are also treating AI vendors differently than AI users, he says. In many cases, carriers are declining to cover AI vendors altogether, while they carve out exceptions in policies against covering AI at companies using the technology.

“If you’re an AI-related company or specifically an AI company, there’s a good chance that you’ll get a declination at this point,” he adds.

In recent months, many carriers have been asking detailed questions about how customers are using AI to better understand the risk of insuring potential mishaps, he says. Ultimately, this increased scrutiny will make it more difficult for companies to buy insurance for AI workloads.

“For everybody leveraging AI right now, you’re seeing questions like, ‘What are your AI policies? What are your procedures? How are you leveraging AI within your business?’” Bishara adds. “We’re getting a lot of questions from the underwriters on, ‘How do you leverage AI within your business?’”

Coverage in flux

Phil Karecki, CTO for the insurance sector at managed services provider Ensono, also sees some carriers backing away from covering AI outputs, although he’s not sure whether it’s a major trend. Insurance carriers continuously experiment with how to provide coverage, he notes.

Carriers have tried to separate tightly governed AI deployments from more experimental projects when determining whether to provide coverage, he says.

“You’ve got this bifurcation of AI, the governed generative and the autonomous pieces,” he says. “It’s no longer, ‘Are you using AI?’ It’s asking, ‘Are you using governed AI? How are you governing it? How are you keeping it safe and secure?’”

Carriers have been trying to determine whether covering AI workloads can be profitable for them, Karecki adds. Governed AI tools operating in a bounded decision-making process will be more insurable, while experimental AI systems with no monitoring and no easy rollback will be difficult to cover, he notes.

“There’s a repositioning versus a pullback, and that’s very common to the industry, and they will at times open up coverage just to see if it’s this type of insurance that will sell,” he says. “They will assess the results and what needs to change so they can decide whether to re-enter this marketplace or abandon it completely.”

In some cases, whether an AI system is insurable may come down to circumstances at individual insurance customers. Carriers in general don’t want to get out of the business of providing insurance, Karecki says.

“What they’re working for right now is, ‘How do I make this profitable, and is this sector insurable?’” he says. “They make those decisions on every application regardless, but now, depending upon what they’re being asked to insure, the questions will follow. ‘What are you using AI for? How are you governing it? What risks does that introduce?’”

It makes sense that some carriers have begun to question whether to cover AI outputs, given the current level of unreliability of most AI systems, says Dorian Smiley, CTO at Codestrap.

“The math says these models should be deterministic, like given the same input, you should get the same output,” he says. “But you can get very different output from the same input, and they can’t know if the answer that they’re giving you is actually correct.”

In most cases, AI models lack inductive reason and can’t review their own work, but many organizations are talking about deploying hundreds of autonomous agents and treating them like digital employees, he notes.

“The idea that these agents are going to become employees, autonomous people working in your organization, is insane,” he says. “You would never hire a person that can’t learn new information, can’t reliably retrieve information, or check their own work.”

NSI’s Bishara has advice for IT and business leaders looking for insurance coverage for their AI workloads: Be honest about how they’re using AI. If they try to hide their AI risks, they risk having their claims rejected when something goes wrong, he says.

“If you don’t fully disclose these things appropriately in the way in which you’re functioning and operating, it could be utilized as an excuse to deny a claim at a later date,” he says. “You don’t want a carrier to come back and say, ‘We didn’t underwrite to that risk. We asked these questions, and you didn’t disclose it.’”

It’s 2026 and we’re still arguing about who the CISO reports to. The truth? The chart matters less than whether the CISO has the actual authority to influence the entire business.

It is difficult to understand why, in 2026, we are still debating the reporting line of the chief information security officer (CISO).

It is one of the first topics I wrote about in 2015, and after more than two decades of high-profile cyber incidents, sustained regulatory pressure, massive technology investments and the steady elevation of cybersecurity to boardroom agendas, one might reasonably expect that this issue would have been settled long ago.

Yet the question persists. And articles like this It’s time to rethink CISO reporting lines show that the debate is still raw.

The fact that the debate continues tells us something important. It reveals that many organizations still struggle with a more fundamental question: What exactly is the role of the CISO within the enterprise?

The reporting line matters — but it was never the real question

Let me be clear. The reporting line matters. It matters because it defines the authority, visibility and influence of the security function across the organization. It signals internally how seriously cybersecurity is taken and determines how effectively the CISO can engage with the executive leadership team.

But the reporting line was never the real question.

The real question is whether the CISO has the organizational standing necessary to influence decisions across multiple silos: IT, operations, legal, compliance, HR, procurement, third-party suppliers and increasingly a complex ecosystem of partners and digital platforms.

Cybersecurity is one of the very few corporate functions that touch virtually every part of the enterprise. It is therefore inherently cross-functional. Without sufficient authority and visibility, the CISO cannot hope to influence behaviour across the organization, let alone drive meaningful change.

If we are still debating the reporting line in 2026, it is largely because many organizations still treat cybersecurity as a technical issue rather than a leadership issue.

The governance gap behind the debate

The persistence of this debate reflects a broader governance gap.

Historically, information security emerged as a technical discipline embedded within IT departments. Early security teams focused primarily on protecting infrastructure: Firewalls, access controls, network monitoring and vulnerability management. In that environment, it was natural for the security function to sit within the IT organization.

But the nature of cyber risk has evolved dramatically.

Cybersecurity today is not merely about protecting technology infrastructure. It is about protecting digital business models, customer trust, intellectual property, operational resilience and in some sectors even national security interests.

In other words, cybersecurity has become a strategic business issue.

And yet, in many organizations, the governance structures surrounding cybersecurity have not evolved at the same pace.

The continuing debate about the CISO reporting line is therefore less about organizational design and more about whether companies have fully internalised the strategic nature of cyber risk.

There is no universal reporting line

Another recurring misconception is the search for a universal answer.

Every year, surveys attempt to determine the “correct” reporting line for the CISO. Some conclude that the CISO should report to the CEO. Others recommend the CRO or the COO. Some insist that independence from IT is essential.

In reality, there is no universal model. The reporting line remains a means to an end.

Organizations differ widely in their structure, culture, maturity and regulatory environment. What works in one organization may not work in another.

In many organizations, the CIO remains the most natural reporting line for the CISO, particularly where technology transformation and digital innovation are core strategic priorities. In others, the COO or the CEO may be better placed to support the operational changes required to embed security across business processes.

What matters is not the job title of the executive above the CISO.

What matters is whether that individual has the authority, credibility, organizational reach and personal willingness to support the security agenda.

Authority matters — and quite a lot of that is forged in the first 100 days

When a new CISO joins an organization, their immediate priority is rarely technical. Instead, it is organizational: Understanding the business, mapping stakeholders, assessing governance structures and identifying the cultural barriers that may hinder security improvements.

During those first months, the CISO must build credibility quickly across multiple constituencies. They must engage with senior executives, operational leaders, technology teams and sometimes regulators or external partners.

None of this can be done effectively if the CISO lacks organizational authority.

A reporting line that leaves the CISO buried several layers below executive leadership severely limits their ability to build the relationships required to succeed. Conversely, a reporting line that provides direct access to senior decision-makers can dramatically accelerate the process.

The reporting line, therefore, matters not because it determines technical decisions, but because it determines access, influence and credibility.

The illusion of structural solutions

At the same time, we should be careful not to overstate the importance of organizational charts.

A common mistake is to assume that moving the CISO reporting line will automatically solve cybersecurity challenges.

It will not.

Cybersecurity failures rarely occur because the organizational chart was incorrect. They occur because of poor governance, weak leadership, unclear accountability or cultural resistance to change.

The most effective CISOs succeed not because of perfect reporting structures but because they build trust, credibility and influence across the organization.

Which brings us to perhaps the most important factor of all: The relationship between the CISO and their direct superior.

Trust matters more than structure

In practice, the success of the CISO depends heavily on the quality of the relationship with the executive to whom they report.

That relationship must be built on trust, alignment and shared understanding of the organization’s risk appetite and strategic priorities.

If the executive above the CISO understands the importance of cybersecurity and is willing to champion the security agenda at the board level and across the firm, the reporting structure can work extremely well.

If that support is absent because the business at large does not see the strategic importance of cybersecurity, no reporting line will magically solve the problem.

The myth of the CIO–CISO conflict

One final argument frequently raised in these discussions is the supposed “conflict of interest” between the CIO and the CISO.

According to this theory, the CISO should not report to the CIO because the CIO is responsible for delivering technology projects and operational performance, while the CISO is responsible for enforcing security controls that may slow things down.

This argument may have had some relevance 20 years ago, when security functions were primarily responsible for auditing IT operations.

But today, it increasingly reflects an outdated understanding of both roles.

Modern cybersecurity is deeply intertwined with technology architecture, cloud platforms, DevOps pipelines, digital transformation programs and operational resilience initiatives. Security cannot be treated as an external oversight function policing IT from a distance.

It must be embedded within technology strategy itself. Any modern CIO should see it that way.

In that environment, close collaboration between the CIO and the CISO is not only desirable — it is essential.

Framing the relationship as a structural budgetary conflict and a source of friction is counterproductive and outdated. The real objective should not be to avoid friction but to engineer alignment: Ensuring that technology leadership and security leadership work together to support the organization’s strategic goals.

Moving beyond the debate

Ultimately, the continuing debate about the CISO reporting line distracts the security industry from more important questions.

What matters far more is whether cybersecurity is integrated into corporate governance, supported by executive leadership and aligned with business strategy.

If organizations are still arguing about where the CISO should sit in 2026, it may simply indicate that they have not yet fully accepted the strategic nature of cyber risk.

And until that changes, the debate will likely continue.

Not because the answer is difficult — but because the underlying governance challenge remains unresolved.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?