CSOonline

As CISOs know, an effective security program cannot be static. Rather, it must adapt to the evolving threat landscape and an ever-changing business environment. To adapt and improve, CISOs must continuously evaluate their existing program. That starts with asking tough questions about their performance, investments, and strategies. Here, security leaders share 15 questions every CISO should ask to ensure their programs can meet current demands and future needs. 1. What issue or incident has my security program addressed that would otherwise have hindered the business? Roland Palmer, CISO and vice president of security at tech company JumpCloud, says he regularly asks himself this question because it forces him to identify and communicate what security efforts avert a negative impact to the business. “This is about us trying to demonstrate ROI and articulating it,” he says. “It frames how I think about my role and where I should be targeting the media blitz [to inform] the business about what we do that demonstrates the value of security.” 2. How are we protecting our organization’s most important business processes? This question pushes CISOs to put business resilience front and center, a focus that helps ensure security programs are aligned with business needs. “Many organizations still take a broad, defensive approach rather than focusing their cyber strategy around critical processes. In an AI-enabled threat environment, the challenge is less about identifying every vulnerability and more about protecting critical processes and ensuring resilience when incidents occur. This is also increasingly reinforced by regulation,” says Richard Watson, global cybersecurity leader with professional services firm EY, noting the EU’s DORA, for example. 3. Do we know the actual business impact of critical service availability? In addition to knowing which processes are critical to the organization, CISOs need to understand the true impact of a successful attack on those processes. Such knowledge helps align their security strategy and articulate the value of their security investments to the C-suite colleagues. “Understanding which systems generate revenue, support customers, fulfill regulatory obligations, or enable critical operations helps organizations prioritize security investments where they matter most,” says Dale Hoak, CISO at software firm RegScale. “Business impact analyses should be reviewed regularly and updated whenever significant organizational changes occur.” Similarly, Sean Murphy, senior vice president and CISO at BECU, the nation’s fifth-largest credit union, asks, “What are the security things that will shut down the business?” He says this question helps security align and prioritize its work to business risk, which ensures business reliance not just IT resilience. 4. If we were breached tomorrow, how quickly would we know? Mean time to detect, as well as mean time to respond and mean time to contain, remain critical metrics for measuring the effectiveness of security programs, as a low MTTD generally correlates to a smaller blast radius and less impact to the business. That’s what makes asking this question critical, Hoak says. “The reality is that every organization should assume an attacker will eventually gain access somewhere within the environment. The more important question becomes how quickly security teams can detect malicious activity, understand the scope, and respond effectively,” he says. “This question should be evaluated continuously through monitoring, tabletop exercises, purple team exercises, and incident response testing.” 5. Are we operating at machine speed or human speed? According to Watson, CISOs should be wondering about their department’s overall speed and whether it’s as fast as needed. “Today’s cyber and IT operating models, governance processes, and controls were built for a slower threat landscape. As AI accelerates both attack and defense capabilities, organizations need to assess whether they are keeping pace or whether gaps are emerging as threat actors increasingly use advanced automation and AI,” he says. 6. What don’t we know? This is a question that Murphy regularly puts to his security team to help them prepare for whatever is out there. “We have to think about where we don’t have visibility, where are our blind spots, what we don’t know but need to know, whether it’s around people, process, or technology,” he says. “It’s an uncomfortable conversation, but we have to think about where the gaps might be. We have to think about where we may have new exposure.” Murphy and his team use threat intelligence and information from colleagues, peer groups, industry associations, and its own security systems “to understand what we’re seeing. It’s a lot of ingestion of information that’s available. And it’s about being curious and critical, and questioning and not assuming. I’m trying to see around corners.” 7. Which third parties could significantly impact our operations if compromised? “Recent attacks have demonstrated that compromising one trusted supplier can create downstream risk across thousands of organizations,” Hoak says. “Many companies have stronger visibility into their own environments than they do into the organizations they depend upon.” So CISOs must be continuously asking this, he adds, “because vendor relationships, software dependencies, and threat landscapes constantly evolve.” 8. How buttoned up is our IAM program for both human and nonhuman identities? Identity and access management (IAM) has become a central component of modern security programs. So it’s essential, Palmer says, for CISOs to know exactly how many human and nonhuman identities operate within their organizations and whether their access is restricted to just the appropriate use cases. “This has become an everyday question. I’d go farther and say it’s now an every-hour question,” Palmer says, noting that the proliferation of AI use, shadow AI, and AI agents means the number of identities and their access rights are constantly changing. 9. How are we securing our nonhuman identities? On another AI-related note, Watson says CISOs everywhere need to ask whether they have adequate security for their nonhuman assets. “Nonhuman identities are an emerging frontier of cyber risk, and many traditional identity governance tools have not yet evolved to address them. As organizations adopt more automated and agent-driven processes, managing access and privileges across these identities becomes increasingly important,” he says. 10. Do we know where AI is being used, what data is being shared, and who is accountable for those decisions? As Doug Kersten, CISO at software maker Appfire, observes, “Many employees are adopting AI tools on their own to solve real business problems before leadership even knows those tools exist, creating unidentified security risks. That creates the same kind of visibility and accountability issues we saw for years with shadow IT; [it’s] just happening much faster.” To ensure they can answer “yes” to those questions, CISOs need governance processes that keep pace with quickly evolving technology and that involve legal, procurement, HR, engineering, and business teams as well as security, he says. 11. Is my application security program built for a world where everyone is a coder? AI has made application development accessibility to everyone in the organization, so CISOs need to consider whether their security programs have the right controls for this new reality. “CISOs have to figure out the guardrails [for the organization] to do vibe coding in a secure way, and those guardrails have to match the speed of vibe coding,” says Nico Waisman, CISO at security tech company XBOW. 12. Are we ready for the expanding attack surface that vibe coding is creating? Similarly, Waisman says he and other CISOs have to ponder whether their security programs are capable of safeguarding the expanding attack surface and technical debt that vide coding is creating. “If anyone can generate their own product, we’re going to have applications popping up all over the network and the environment. That means [the organization likely] is generating technical debt, because people love to build software but no one loves to maintain software. And if no one is maintaining it, then it could have vulnerabilities that no one is monitoring or fixing. It may end up with only security caring for it,” Waisman says. To avoid such a scenario, CISOs must be diligent about inventorying assets and assigning ownership to every application, he says. 13. What are we doing to prepare for a world where hackers have Mythos? Claude Mythos is a frontier AI model from Anthropic that can autonomously find and exploit software vulnerabilities. In hackers’ hands, this would drastically shrink even further the speed at which attacks can be built and launched. “The speed and scale are different now,” Waisman says. “Anthropic and OpenAI models have opened the doors for a scale of attacks that we have never seen before. So CISOs have to think about how that will affect their security posture and how they’ll be defending against attacks as the scale and speed change even more.” 14. Am I confident enough to share our real-time security posture if a customer asked for it? JumpCloud’s Palmer puts himself and his security team to the test by regularly asking whether he’d be comfortable sharing a real-time snapshot of his security program. “Am I comfortable with our patch management, our vulnerability management, and with our customers seeing those stats? Am I comfortable with customers looking behind the curtain?” he asks. Palmer says such questions help him assess whether his security program is where it should be. He says he can answer “yes” to those questions most of the time, but he admits that sometimes he answers “no.” And while a “no” from time to time is expected, Palmer says if there are two or more a quarter, he knows he must focus on righting the security team’s efforts to get him back to more affirmative responses. 15. Are we securing the business we have today and the business we’ll have a year from now? Given the speed of technology advancements, changes in the threat landscape, and business strategy, RegScale’s Hoak knows he must have his eyes on the horizon and a plan to meet it head-on. “Security programs often lag behind business growth and transformation initiatives. Organizations are rapidly adopting AI, modernizing applications, expanding cloud environments, and integrating new third-party services. If security strategies are only focused on current-state risks, they quickly become outdated,” he explains. So he actively asks himself whether he’s prepared for the future, noting that “this question should be revisited whenever strategic business plans, acquisitions, major technology initiatives, or new market opportunities emerge.” View the full article

Have you ever watched a military cyber ops team go to work responding to a cyberattack simulation? It’s like that scene from Die Hard 4.0 when all the screens start flashing red and systems start shutting down; however, unlike the movies, where bumbling government IT workers are caught out and panicking, our military actually moves with practiced precision to understand, contain, and mitigate the threat. Everybody understands their roles and any gaps are quickly highlighted and handled. This is because the military treats cyber as a kinetic threat requiring constant mission rehearsal, while the corporate sector is still treating cyber defense as a compliance checkbox, rather than an operational capability. This is untenable in a world where attackers constantly innovate their tactics and techniques to probe and access systems. Over the past 12 months, we’ve seen just how unprepared different industry sectors have been in the face of major cyber incidents. Early in 2025, retailers and insurance brokers were brought down by the Scattered Spider group, and major manufacturers, including Jaguar Land Rover and Asahi Beer, saw months of downtime following ransomware attacks resulting from supply chain compromises. More recently, researchers at Cisco revealed that frontier models from OpenAI, Anthropic, Google, xAI, and Amazon have significantly worse risk profiles when pressured in multi-turn attacks, a discovery that revealed attack success rates are considerably higher than those benchmarked in simulated single-prompt attacks. This, combined with recent news that the Google Threat Intelligence Group identified what researchers believe to be the first zero-day exploit created using AI, represents an entirely new stage in the technological arms race. Those old-fashioned tabletop exercises where, once a year, you’d get everyone from IT to PR in a room for a couple of days and play out various scenarios and then tick that audit box for another 12 months aren’t going to cut it when attackers are probing on a daily basis. The military is using dynamic cyber ranges to test their real tools, people, and processes, in an exact simulation of their unique environment, against real-world threats like the tactics of Scattered Spider. Without real-world testing of your team’s capabilities, you’re not going to be able to go into an incident scenario confident that everyone’s prepared. So, what can we learn from how the military prepares for cyberattacks in terms of mindset, readiness, and execution? Military cyber doctrine starts with the assumption that you will be attacked and so prepare as though an attack is inevitable and not hypothetical. Businesses need to shift their mindset from “preventing breaches” to “detail, contain, and recover” and treat incidents as operational events rather than reputational crises. This reduces panic and leads to better decisions under pressure. It’s also critical for business leaders to understand their true vulnerabilities. Reputational and financial harm is typical collateral damage following a cyberattack, but was this the intended outcome? If sensitive data is compromised, are there persistent threats beyond the initial attack? Just as the military examines the secondary and tertiary impacts of risk scenarios in threat modeling, business leaders have to consider what else beyond their reputation and stock price may be compromised when they are attacked. The military runs constant exercises; simulations, red team and blue team drills, and scenario planning that reflects real adversary behavior. Businesses can exercise that muscle by running regular live cyber simulations and updating based on real-world attacks. Conventional training still has its place, and companies should continue to invest in professional development programs that provide a strong foundational understanding of the most urgent threats facing their business. But, as the military says, “train like you fight.” There is simply no substitute for practical, hands-on training, especially when it comes to high-pressure, time-sensitive scenarios such as large-scale cyberattacks. This readiness and preparedness training can, and should, extend to AI Agents too. Think about it like an “AI Proving Grounds”. Effectively, a realistic, intelligent environment where organizations can safely train human operators alongside AI agents, test autonomous workflows, and validate how both perform under real adversarial pressure before deployment. Continue to involve all the stakeholders, including executives and comms teams, who are going to be on the front line of customer, investor, and media inquiries should an attack occur. Without realism, readiness is an assumption, not a fact. In a military cyber incident, everyone knows who decides, who communicates, and who executes, reducing any mid-crisis debate and empowering teams to act without permission to faster contain the incident. This principle is just as relevant in a corporate environment. Individual training is crucial, and operators should be confident acting in isolation, but it’s just as important that everyone in a rapid response team can work effectively with others, under often-intense pressure. This simulated teamwork is another advantage offered by AI Proving Grounds. In the same way that everyone in a military chain of command understands their role and that of their unit, businesses can pre-assign decision makers and define escalation paths before an incident to ensure clarity and calm rather than blind panic. Finally, attackers are sharing knowledge all the time. Defenders must adopt the same approach. We know that militaries collaborate extensively across allies, agencies, and domains, recognizing that no unit has the full threat picture. Businesses can benefit from this information sharing by participating in ISACs, CERTs, and industry groups, treating threat intel as a collective defense rather than a competitive weakness. AI Proving Grounds themselves are only part of the solution. Security is cultural, not just procedural. Even the most realistic simulated attack scenario is only useful if structures are in place for stakeholders to learn from it. What didn’t work well? What didn’t go as expected? What are the weakest links in the response chain? These are all questions executives and technical leadership should be comfortable asking themselves, and businesses must adopt cultures of responsibility to identify potential weaknesses beyond technical limitations. Such retrospectives can and should inform rapid-response playbooks to ensure that training is relevant and that weaknesses cannot be exploited in a production environment. Many of the clients we work with are corporations and enterprises, but AI Proving Grounds have other applications. Recent years have seen coordinated attacks on critical infrastructure such as the nation’s power grid, including the prolonged intrusion by the Volt Typhoon persistent threat actor, which maintained unauthorized access to the operational technology networks of Littleton Electric Light and Water Departments in Massachusetts from February 2024 to November 2024. Such threats can also be simulated in AI Proving Grounds and provide crucial hands-on training opportunities for critical infrastructure providers that, until now, have been challenging to realistically model. With geopolitical tensions rising across the globe, operational readiness has never been more critical. “Cyber resilience” has become something of a buzzword in itself and I can almost hear the eye rolls just using the phrase, but it is something the military does actively practice. Cyber resilience isn’t about prevention; it means being able to recover from as well as protect against attacks. With AI-powered adversaries scaling their approach to infiltration, extortion, and espionage, attacks are only going to increase and businesses need to be prepared to deal with them as well as prevent them. Continuous training within highly realistic and dynamic environments against real threat examples is the best way to ensure your teams are prepared at a military grade to secure your organization. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security researchers are warning of an issue with the default HTTP/2 configuration used by major web servers which reportedly survived more than a decade of human review before showing up in Codex-assisted analysis. A flaw in the handling of the HTTP/2 protocol made a denial-of-service (DoS) attack possible on web servers including nginx, Apache HTTP server, Microsoft IIS, Envoy, and Cloudflare’s Pingora, according to security consultancy Calif. HTTP/2 was introduced in 2015 to increase the speed of HTTP by allowing multiple simultaneous connections, and is gradually being superceded by HTTP/3, which is built on the new QUIC encrypted transport protocol. The problem uncovered by Calif lies in how affected servers handle HTTP/2 header compression and request processing, allowing an attacker to trigger disproportionate memory consumption. “The attack chained two techniques known to humans for a decade: a compression bomb and a Slowloris-style hold,” Calif CEO Thai Duong said in a blog post, calling the technique HTTP/2 Bomb. A search of Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, although many of these websites use a Content Delivery Network (CDN), which may add some complexity to the attack, he said. Weaponizing a compression feature for DoS The issue, tracked as CVE-2026-49975, involves HPACK, the header compression mechanism built into HTTP/2. Calif found that attackers can abuse the protocol’s dynamic header table in a way that forces servers to repeatedly allocate memory far beyond what would normally be expected from the size of incoming requests. A relatively small amount of attacker-controlled traffic can trigger excessive memory allocations on the target server, Duong said. “The bomb targets HPACK, HTTP/2’s header compression scheme: One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request,” he said. “The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.” This isn’t the first time HTTP/2 was flagged for allowing DoS attacks. In 2019, multiple HTTP/2 denial-of-service vulnerabilities disclosed by Netflix affected numerous server implementations and prompted emergency patches across the ecosystem. In October 2023, the protocol was disclosed to be prone to massive DDoS attacks owing to its stream multiplexing capability. Duong recalled in the post how in 2012 he contributed to the discovery and patching of a flaw in HPACK, that back then was exploited by a different attack, CRIME. “I was too fixated on fighting CRIME and missed the Bomb,” he reflected. Calif reported the flaw to all affected projects. nginx and Apache HTTP Server moved quickly to block the attack path, while Envoy patched on June 3. Microsoft IIS and Cloudflare’s Pingora had yet to release patches at the time of publication. Cloudflare updated Pingora to version 0.8.1 later on June 4, mitigating the memory exhaustion problem. Admins will need to obtain the fixed versions of nginx (v1.29.8+) or Apache (mod_http2 v2.0.41), through the normal update channels used for these products. Envoy issued patches for versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. For organizations without a patch available to them, Calif recommended disabling HTTP/2 if possible, or “front the server with something that enforces a hard cap on header count per request.” Updated to note that Cloudflare has since patched Pingora. View the full article

Cybersecurity professionals were offered lessons of resilience in the most extreme circumstances from Ukraine’s former minister of foreign affairs. Dmytro Kuleba, who served as Ukraine’s Minister of Foreign Affairs between 2020 and 2024, told Infosecurity Europe delegates that the key to Ukraine’s survival after the full-scale Russian invasion of 2022 was pre-planning, a lesson learned in the early weeks of the war. Ukraine’s largest mobile operator KyivStar was subjected to an outage in December 2023 because of a Russian cyberattack. “They got to the very core of their system of their network,” Kuleba said. “They put it down, or they knocked it out, and the way they did it, they penetrated through an account of one single employee of KyivStar.” Kuleba added: “Miraculously, KyivStar did [the] unimaginable, and within days they restored the system and fenced it off.” Few successful cyberattacks have happened since this incident, according to Kuleba, who credited this success on a pre-planning for resilience methodology that has been adopted by the Ukrainian government and businesses. “We don’t know what and how it is going to happen,” Kuleba said. “But you can presume, you can brainstorm, you can calculate, and you can prepare. You can prepare so that it becomes your muscle memory.” Even if the unexpected happens you will be more prepared if you’ve gone through preparations, Kuleba argued. “Make no mistake when the crisis situation occurs, everything will be different,” said Kuleba. “You will be punched in the face. You plan not to follow the plan but to know your environment perfectly and to develop instincts of survival in this environment.” Exodus Kuleba began preparing Ukraine’s foreign ministry for the war in November 2021, starting with learning precisely how its systems worked and planning for contingencies such as how diplomats and staff could communicate if online messaging apps became unavailable. When war broke out foreign ministry services was evacuated abroad. “We did not waste a single second on figuring out what is possible and what is impossible, because we knew all of that in advance,” Kuleba said. Preparation for potential disasters might seem like a distraction from more immediate projects or even boring but making contingency plans is vital not just for Ukraine but for technologists around the world. “There are more important projects than preparing for something that might not even happen,” Kuleba advised. “But if you care for your company, if you care for your country, you have to prepare for the worst.” Kuleba concluded: “Resilience is not being prepared to repair a destruction. Resilience is your ability to keep repairing the wrecks as destruction becomes new normal.” The war has affected the operations of even smaller Ukrainian businesses as Russian cyberattacks have become stealthier. For example, Russian operatives have recently sought to gain “pattern of life” intelligence that might be used to assassinate Ukrainian officials or target members of their family for kidnap after hacking into the customer relationship management (CRM) systems used by businesses such as barbers, gyms, and nail bars. “What Russian security services are doing is they break into CRM systems of barbers, fitness clubs … the loyalty programmes of supermarkets, to track your movements, to understand whether you usually show up, [and] how much time do you usually spend, to build a picture, and then do what they believe is necessary,” Kuleba said. In one case Kuleba linked to this tactic, the son of an unspecified Ukrainian official was kidnapped before his father was blackmailed by the Russians into leaking intel. CRM systems in the Ukraine were particularly vulnerable because for years before the invasion, “Russian companies had been offering very lucrative offers to Ukrainian businesses so that they would install [their] CRM platforms,” Kuleba said. Kuleba added: “Did these Russian companies do that on their own initiative? Perhaps. Did the Russian security service ask them to do that and help them to do it? Perhaps. But the thing is, even such innocent programme as a check-in system at a restaurant, or a barber shop, or a gym, can help your enemy to kill someone … to kidnap.” “Do not trust the products made by your potential enemy,” Kuleba concluded, adding that the incident shows the importance of technological sovereignty and data security even for the smallest companies. View the full article

Microsoft has identified seven new failure modes in agentic AI systems, in addition to those it identified last year in its first Taxonomy of Failure Modes in Agentic AI Systems. Four things contributed to the growing list of ways agentic AI can go wrong: the speed at which the technology went mainstream, the growing maturity of the Model Context Protocol (MCP) ecosystem, the rise of computer-use agents, and finally the gathering of more empirical evidence as researchers obtained more real-life findings. The seven new failure modes it has identified are: Agentic Supply Chain Compromise —agent behavior can be affected by natural language rather than malicious code; Goal Hijacking — adversarial instructions appear aligned with legitimate task completion, while silently redirecting the agent’s terminal goal; Inter-Agent Trust Escalation —a compromised agent asserts false identity or inflates claimed permissions to an orchestrator; Computer Use Agent (CUA) Visual Attack — agents operating through graphical interfaces can be manipulated through content that carries adversarial instructions for the agent; Session Context Contamination —an adversary introduces data that biases the agent’s reasoning in subsequent steps, without triggering safety controls at any individual step; MCP / Plugin Abuse — an update on the original taxonomy’s coverage of function compromise around MCP and plugin protocols, specifically attack surfaces specific to those protocols; Capability / Architecture Disclosure —an agent reveals internal implementation details such as tool names and schemas, system-prompt structure, memory interfaces, or consent/human-in-the-loop trigger logic. Microsoft advises security teams using these definitions to influence their planning to inventory their your supply chain, generating a software bill of materials (SBOM) for every deployed agent, to verify agent identity cryptographically, not positionally, by issuing attestable credentials at provisioning, to add the seven new failure modes to their red-team coverage matrix, and to audit the human-in-the-loop user experience as a security control. This article first appeared on InfoWorld. View the full article

The team behind RubyGems, a package hosting site for Ruby developers, has added a new feature to bundler, a tool for managing Ruby packages (or ‘gems’) to protect developers against the recent wave of software supply chain attacks: A cooling-off period before recently updated packages are installed on their systems. Recent attacks on software repositories have focused on stealing developer credentials in order to introduce malicious code into the packages they create, which then steals more developers’ credentials when they install the malicious updates, and so on. Users of the repositories are vulnerable if they download an affected package during the short interval between it being interfered with and the malicious additions being discovered and removed. To counteract this, RubyGems team has added a new cooldown argument to Bundler that takes ignores gems until they have been published for a specified number of days. This provides an additional layer of defense against malicious package releases as it gives others an opportunity to identify any malicious code they contain before installation. The cooldown system works by checking the timestamp of any new versions of gems. Any new additions to the source will have to come from older versions, any new additions will be delayed until they are validated. In situations where waiting is unhelpful — for instance when a known-good package is released to patch a dangerous security flaw — the delay can be overridden. This article first appeared on InfoWorld. View the full article

Ongoing cyber-attacks on automated tank gauges (ATGs) could result in fuel tanks being drained without businesses noticing, the US Cybersecurity & Infrastructure Security Agency has warned. Connected ATGs are widely deployed in gas stations, as well as on military bases, in hospitals, and in manufacturing plants. And it’s not just fuel stores at risk: ATGs are also used in the chemical, food, and agriculture industries. CISA and other agencies warned that such attacks could lead to the gauges being dangerously compromised, leaving tank owners unaware of leaks or theft of their contents. The attacks take three forms: authentication bypass and hardcoded credentials, which allow attackers to gain access to device management; OS command execution and SQL injection to manipulate underlying databases; and privilege escalation, in which attackers obtain full administrator access. System administrators working for organizations using ATGs are advised to protect their systems by removing connections to serial ports to eliminate public internet exposure by, changing default passwords immediately, applying the latest patches, reporting any suspicious activity to the CISA, and urging companies in their supply chain to also adopt best practises against such attacks. CISOs in these companies should already be doing this as they can’t say that they were unaware of the risks: Last year, a Canadian fuel company was attacked and its systems compromised and in 2024, security company BitSight warned that ATGs were a sitting target for cyber criminals. View the full article

Claude Code is Anthropic’s AI coding assistant — a command-line tool that developers are adopting fast. It connects to external services through Model Context Protocol, the standard that lets AI tools interact with Jira, Confluence, GitHub, databases and internal APIs. When a developer connects one of those services, Claude Code runs an OAuth flow, the user approves the scopes and the tool receives a bearer token it uses for every subsequent request. That token is stored in plaintext in a configuration file on the developer’s machine. And researchers have now shown exactly how attackers are getting to it. What researchers found Last week, researchers atMitiga Labs published an attack chain that should concern every security team whose developers use Claude Code. The attack starts with a malicious npm package — something that looks like a legitimate utility or wrapper. Hidden inside is a post-install hook that runs silently during installation. That hook rewrites a single file: ~/.claude.json. That file is the control point for how Claude Code routes MCP traffic. Change it, and you can point Claude Code’s authenticated requests to attacker-controlled infrastructure instead of the legitimate service. The OAuth tokens stored in that same file get intercepted in transit. The attacker now holds valid, long-lived bearer tokens for every SaaS platform the developer had connected — Jira, Confluence, GitHub, whatever was integrated. What makes this particularly difficult to detect is what the audit logs look like on the other end. The IP address in the provider’s logs resolves to Anthropic’s egress range. The user is real. The session is valid.As Mitiga put it, nothing in that log row is wrong — but nothing in it is right either. The user did not run the query. An attacker did, using a token that was silently redirected before it ever reached its intended destination. Mitiga reported this to Anthropic on April 10.Anthropic responded on April 12 that the issue was out of scope, reasoning that the attack requires prior code execution through a package installation that the user consented to. As of this writing, no patch exists. The attack chain is live. This is not the first time The Mitiga disclosure is the most recent, but it is not the first time Claude Code’s configuration model has created a security problem. In February 2026,Check Point Research published findings on two separate vulnerabilities. The first, CVE-2025-59536, allowed remote code execution through malicious hooks planted in a repository’s settings file — code that ran before the user could even read the trust dialog. The second, CVE-2026-21852, allowed API key exfiltration by overriding a single environment variable, redirecting authenticated traffic to attacker-controlled infrastructure before any consent prompt appeared.Simply cloning and opening an untrusted repository was enough to trigger both. Anthropic patched those vulnerabilities after Check Point’s disclosure. But the pattern they reveal — configuration files that security teams treat as passive metadata actually functioning as active execution paths — is the same pattern the Mitiga attack exploits. The mechanism keeps working because the underlying architecture creates it. Why security teams need to pay attention If you have read about adversary-in-the-middle phishing, this should feel familiar. AiTM attacks do not steal credentials directly — they sit between the user and the legitimate service, wait for authentication to succeed and walk away with the session token that proves it happened. The Mitiga attack on Claude Code works the same way. The OAuth flow completes legitimately. The user approved the scopes. The token is valid. The attacker just inserted themselves into the routing layer before the token reached its intended destination. The difference is that AiTM attacks target browser sessions. This targets developer tooling — and developer tooling sits closer to your source code, your internal APIs, your cloud infrastructure and your production systems than most browser sessions ever do. Claude Code adoption is accelerating. Developers install it because it genuinely improves their workflow. They connect it to the tools they use every day. Most of them are not thinking about what the post-install scripts in their npm dependencies are doing to their local configuration files. That is not a failure of awareness — it is an unreasonable expectation. The security team needs to be thinking about it instead. Three controls that help right now Monitor ~/.claude.json for unexpected changes. This file is the pivot point in the Mitiga attack. Changes to MCP server endpoints in that file — particularly additions of new localhost proxy addresses or unfamiliar external endpoints — should trigger an alert. Most organizations have no monitoring on user-level configuration files in developer environments. That needs to change.Mitiga specifically recommends tracking changes to Claude Code configuration, MCP server URLs and OAuth refresh behavior as the primary detection layer. Treat npm post-install hooks as a first-class security concern. The Mitiga attack begins with a malicious npm package. Post-install hooks that execute arbitrary code at install time are a known supply chain risk class — but enforcement in developer environments is inconsistent. Audit what runs during package installation in your development pipelines. Consider requiring review of packages that include post-install scripts before they reach developer machines. This is not a Claude Code-specific recommendation; it applies to every tool in your development stack. Claude Code just made the consequences of getting it wrong much more tangible. Audit OAuth tokens connected to Claude Code integrations and rotate them. Developers who connect Claude Code to Jira, Confluence, GitHub or any other SaaS platform create OAuth tokens that persist across sessions. If those tokens were active during a period when a malicious package was installed, they should be treated as potentially compromised. Rotate them. Review the audit logs on the provider side for the activity patterns Mitiga describes — valid-looking requests from Anthropic’s egress IPs that the developer did not initiate. Note thattoken rotation alone does not break the chain if the malicious hook is still present — the hook will reseed the configuration and capture new tokens on the next refresh. Remediation requires removing the hook and cleaning the configuration first. An honest assessment Anthropic’s response to the Mitiga disclosure — that the attack is out of scope because the user consented to installing the package — follows a logic that security practitioners will recognize and most will reject. Consent to install a package is not consent to have that package rewrite your AI tool’s routing configuration and intercept your SaaS credentials. The two things are not the same and treating them as equivalent places the entire burden of supply chain security on the developer, making a split-second judgment about a dependency name. That is not a reasonable security model. The patched Check Point vulnerabilities show that Anthropic is responsive when the issue is framed correctly. The Mitiga research is a week old. Whether a patch follows is an open question, but the attack chain works today regardless of how that question resolves. Your developers are using Claude Code. The question for security teams is not whether to engage with this risk but how quickly you can implement detection and response that accounts for it. The configuration file is small, the monitoring requirement is specific, and the attack chain is documented. Starting there is better than waiting for a vendor patch that may not come. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Sales of AI-based tools is accelerating within underground ransomware marketplaces, lowering the barrier to entry for new actors in the process. An analysis of Telegram channels, 20 dark web forums, and five underground markets by anti-ransomware platform vendor Halcyon found that AI utility posts grew to 1,486 in February 2026, up from just 38 in December 2025. The AI tools for sale divided into four categories: Weaponized LLMs: Sometimes called dark LLMs, these tools omit the safety guardrails and rules present in legitimate large language models (LLMs). “WormGPT” is the market leader in this category of cybercrime-focused AI tooling but only as a brand used by multiple operators, some of which are straightforward scams that collect payments without offering any service. AI-enabled identity fraud: Tools in this category include voice and video-enabled deepfakes, created using AI, that are used to fool selfie-based recognition systems and other know your customer (KYC) security controls, among other fraudulent applications. The same tools can also be used as part of business email compromise scams. AI-augmented malware and attack infrastructure: AI-driven infrastructure is being used to aggregate, process, and exfiltrate stolen data more efficiently. Jailbroken and stolen AI services: Hacked AI accounts are the largest category of services offered and the cheapest. Halcyon estimates that ransomware attacks have grown in volume by 20% since 2023 with an increased focus on targeting smaller enterprises, which now comprise 80% of attacks. During a keynote presentation at Infosecurity Europe, Cynthia Kaiser, SVP of Halcyon’s Ransomware Research Center, told delegates that the largest ransomware operators — such as Akira — are increasingly operating the same business models as legitimate vendors by selling services and infrastructure to their clients and affiliates. The main difference is that the goods on offer are exploits and stolen credentials rather than the legitimate goods sold through legitimate marketplaces. Ransomware groups sell routinely through multiple channels, thereby creating redundancy in the event that any channel is taken down. Their services are often offered with tiered pricing, and are commonly available with a freemium model popularised by legitimate web services. Telegram bot-driven channels are automating the process of sales and marketing, while AI-based utilities are being applied by cybercriminals to offer customer service. “Modern ransomware operators don’t need to build their operations from scratch,” said Kaiser, the former deputy assistant director of the FBI’s Cyber Division, who added that the skill level required from would-be cybercriminals has dropped. Dishonour among thieves All this may seem impressive, but Kaiser noted that criminal operational security (OpSec) is weaker than it looks. “Criminal AI markets have a theft problem [because] black hats are attacking each other,” Kaiser said. For example, credentials from one WormGPT instance were stolen by rival cybercriminals and dumped back onto the same forum that originally sold access to the malign AI-based utility. Such disruption aside, the greater use of AI tooling is part of a sign that the underground ransomware scene has professionalised not least by making it easier in run multiple attacks at scale. Raking it in According to separate research from Rapid7, ransomware is becoming more profitable, up 39% between Q1 2025 and Q1 2026. The Qilin ransomware group made an estimated $193 million between July 2025 and March 2026. And The Gentleman, which is just behind Qilin as the biggest ransomware group, made an estimated $52 million between July 2025 and March 2026, according to Rapid7. Rapid7’s analysis is based on average ransom payments and payment rates from CoveWare, a ransomware and cyber extortion incident response firm. Thom Langford, CTO EMEA at Rapid7, said that the ransomware ecosystem has evolved into a mature underground marketplace where access, tooling, and full attack services are now commercially available to almost anyone. Langford added that AI-based social engineering, primarily to craft more convincing phishing lures, is widely used. Marketplaces offer an a la carte menu where cybercriminals can contract services for initial access, exfiltration, or negotiation with victims, according to Langford, who added that many if not all of the principal players in the ransomware scene “speak Russian.” Countermeasures Law enforcement takedowns are curtailing the growth of ransomware operations, but businesses also need to play their part in defence, Halcyon advises. Enterprises should concentrate on measures such as stopping initial access, detecting lateral movement, and disrupting exfiltration and encryption. Companies can also build resilience through tabletop exercises, Kaiser concluded. View the full article

A report from the US Commerce department’s inspector general blames the National Institute of Standards and Technology (NIST) for the ever-growing backlog of vulnerabilities for inclusion in the National Vulnerability Database (NVD). But cybersecurity practitioners say that the backlog, although very real, has been building for years, and that the government is doing little to help. NIST defenders point to budget cuts that have made its mission far more difficult. And a potentially bigger issue is that the nature of vulnerability identification and patching has changed sharply over the last two years, via genAI developments that have dramatically increased the number of vulnerabilities discovered and accelerated of those discoveries. That raises questions about whether NVD processes need to be completely re-envisioned. Inter-agency squabbles The Inspector General’s report blamed NIST for a variety of management and strategy shortcomings. “NIST’s lack of strategic planning and decisive action have allowed the backlog of unprocessed vulnerabilities to continue growing,” the report said, pointing out that NIST and the Cybersecurity and Infrastructure Security Agency (CISA) are operating two vulnerability enrichment programs with significant overlap, leading to duplicated efforts and waste of approximately $200,000 since May 2024. Additionally, it said, NIST’s insufficient communication has frustrated stakeholders and decreased confidence in the NVD. The report also said, “NIST must improve the efficiency of enrichment processes to ensure sustainability. We estimate that NIST could put approximately $800,000 to better use over the next two years.” It also attributed some of the issues with the vulnerability identification programs to bureaucratic infighting over the years, pointing out that for two years, CISA has been independently providing nearly all of the same enrichment data as NIST. “Therefore,” it said, “an opportunity existed for NIST to leverage CISA’s data to expedite backlog reduction. However, NIST officials stated that the NVD system required technical updates to incorporate CISA’s enrichment data because the system lacked the capability to attribute data to specific sources.” Because of this, before system updates and subsequent process changes were completed in March 2025, NIST refused to use CISA’s data because it would have appeared that an NVD analyst had performed the enrichment. “While it is understandable that NIST wanted to be clear about the source of data in the NVD,” the report said, “it ultimately delayed vulnerability processing to distinguish whether enrichment was completed by NIST or CISA, both federal agencies with access to the same public information.” Another example of inefficiency also involved enrichment: “In May 2024 … CISA launched its own vulnerability enrichment program, called Vulnrichment. At the time, CISA invited NIST to collaborate and issue a joint statement about the new program. However, NIST did not take part in a joint statement or issue any announcement about CISA’s program. Ultimately, the two programs have operated without coordination and have duplicated enrichment activities.” NIST severity score calculations ‘may no longer be necessary’ Another concern cited was the reliability of NIST’s calculation of severity scores. “To generate a severity score for vulnerabilities, NIST uses the industry standard Common Vulnerability Scoring System (CVSS). … Our review found that implementation is highly dependent on available information and professional judgment,” the report said, noting that in internal testing, severity scores among independent OIG evaluators matched just 12% of the time. “We concluded that severity scores vary depending on who performs the work and the information available to them.” It added: “Traditionally, NIST calculated its own independent severity score for each vulnerability. NIST stated that it did so as part of its mandate to determine the nature and extent of information security vulnerabilities and independently assign severity metrics to identified vulnerabilities. However, NIST is not required to calculate a severity score for every vulnerability. Today, this approach may no longer be necessary and, considering the increasing volume of vulnerability submissions, is no longer sustainable.” The IG report also included an official NIST response; CSO Online asked NIST for clarifications, but it did not respond before publication. In that response, NIST said that it agreed with all of the report’s technical recommendations, mostly involving creating a better strategic plan for the NVD and a better backlog management plan, but that it disagreed with the tone and phrasing used. “Rather than assess the impact of NIST’s actions in a fair, factual, and objective manner, this statement unnecessarily casts doubt on NIST’s intentions and priorities,” the NIST response, attributed to Acting Director Craig Burkhardt, said. “The Draft Report is replete with language that goes beyond objective, factual evaluation.” Industry response However, said some observers, while the AG report was accurate, it missed the bigger picture. “The backlog is getting all the attention, but underneath it, this is a money story. CISA was covering close to half the NVD’s funding and then walked away from it, and NIST’s lab budget got cut on top of that. You can’t pull that kind of money out of something this important and then act surprised when it breaks,” said Jeff Williams, CTO at Contrast Security. He noted the revelation that OIG analysts’ vulnerability severity calculations only matched NIST’s 12% of the time, suggests that the measure, used by IT to prioritizes fixes, “is barely better than guessing.” That should worry people more than the backlog does, he said. Williams also argued that the manual parts of threat analysis no longer make much sense, pointing out that the “easy parts” of security such as scanning and ticketing are already automated. “We got very good at producing findings and never got good at dealing with them. The real prevention work — threat modeling and looking hard at architecture — is still done by hand by a small number of senior people,” he pointed out. “We automated the wrong half. Where AI can be truly groundbreaking is helping with the expert work we could never hire enough people for, to prevent vulnerabilities in the first place.” Braden Perry, a litigation, regulatory, and government investigations attorney at Kennyhertz Perry, also took issue with NIST’s defense that legal obligations forced it to make some of those decisions. “It’s a lawyer’s argument and a partial one,” he said. “The law sets the mission. It doesn’t dictate the choices that created the backlog. Here’s the distinction: NIST cites [a federal rule] which directs the agency to assign severity metrics to open source software vulnerabilities. That’s a mandate. But it only covers open source software, not all vulnerabilities. It says ‘severity metrics,’ not CVSS.” And, he said, the rule doesn’t tell NIST to recalculate a score that a vendor or CISA already produced; that was NIST’s decision. “So the mandate is narrow and the practice is broad,” he said, pointing out that the inspector general’s report made that clear. “The statutes NIST cites don’t say how to run the database or what to produce,” he noted. “They leave the operational calls to NIST. On the central question, whether NIST was legally compelled into this backlog, the answer is no. The duty to keep the database running is real. The mess was a choice.” NIST’s complaints, he said, “are management failures, not statutory commands. [NIST] spends most of its energy arguing that the report was unfair and lacked context. That is a process complaint. It is not a defense of the record.” Erik Avakian, technical counselor at Info-Tech Research Group, said the NVD issues identified in the report are less of a concern than the fact that too many enterprises have grown addicted to NVD as their sole source of vulnerability truth. “I would ask the question: why are we waiting for NIST to tell us something that’s important?” Avakian said. “Organizations that are relying so much on the NVD have deeper maturity problems because NVD should be treated as a support function to a vulnerability management program, not the entirety of it.” Ishraq Khan, CEO of coding productivity tool vendor Kodezi, added that the changing scale of vulnerability discovery is the bigger issue. “Cybersecurity infrastructure must scale at the same pace as vulnerability discovery. If discovery becomes exponentially faster through automation and AI, while enrichment and analysis remain heavily manual, the gap will continue widening,” Khan said. “I suspect many CISOs will read this report less as an audit finding and more as a warning sign. The question is no longer whether vulnerabilities can be found. The question is whether the institutions responsible for organizing and prioritizing them can keep pace.” View the full article

Security researchers are warning of an issue with the default HTTP/2 configuration used by major web servers which reportedly survived more than a decade of human review before showing up in Codex-assisted analysis. A flaw in the handling of the HTTP/2 protocol made a denial-of-service (DoS) attack possible on web servers including nginx, Apache HTTP server, Microsoft IIS, Envoy, and Cloudflare’s Pingora, according to security consultancy Calif. HTTP/2 was introduced in 2015 to increase the speed of HTTP by allowing multiple simultaneous connections, and is gradually being superceded by HTTP/3, which is built on the new QUIC encrypted transport protocol. The problem uncovered by Calif lies in how affected servers handle HTTP/2 header compression and request processing, allowing an attacker to trigger disproportionate memory consumption. “The attack chained two techniques known to humans for a decade: a compression bomb and a Slowloris-style hold,” Calif CEO Thai Duong said in a blog post, calling the technique HTTP/2 Bomb. A search of Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, although many of these websites use a Content Delivery Network (CDN), which may add some complexity to the attack, he said. Weaponizing a compression feature for DoS The issue, tracked as CVE-2026-49975, involves HPACK, the header compression mechanism built into HTTP/2. Calif found that attackers can abuse the protocol’s dynamic header table in a way that forces servers to repeatedly allocate memory far beyond what would normally be expected from the size of incoming requests. A relatively small amount of attacker-controlled traffic can trigger excessive memory allocations on the target server, Duong said. “The bomb targets HPACK, HTTP/2’s header compression scheme: One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request,” he said. “The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.” This isn’t the first time HTTP/2 was flagged for allowing DoS attacks. In 2019, multiple HTTP/2 denial-of-service vulnerabilities disclosed by Netflix affected numerous server implementations and prompted emergency patches across the ecosystem. In October 2023, the protocol was disclosed to be prone to massive DDoS attacks owing to its stream multiplexing capability. Duong recalled in the post how in 2012 he contributed to the discovery and patching of a flaw in HPACK, that back then was exploited by a different attack, CRIME. “I was too fixated on fighting CRIME and missed the Bomb,” he reflected. Calif reported the flaw to all affected projects. nginx and Apache HTTP Server moved quickly to block the attack path, while Envoy patched on June 3. Microsoft IIS and Cloudflare’s Pingora had yet to release patches at the time of publication. Admins will need to obtain the fixed versions of nginx (v1.29.8+) or Apache (mod_http2 v2.0.41), through the normal update channels used for these products. Envoy issued patches for versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. For organizations without a patch available to them, Calif recommended disabling HTTP/2 if possible, or “front the server with something that enforces a hard cap on header count per request.” View the full article

OpenAI has proposed mandatory federal evaluations of the most capable AI models before public release while arguing that regulators should stop short of deciding whether those systems can be deployed, staking out a middle ground in the debate over how frontier AI should be governed. The company’s proposal came a day after the White House issued an executive order on advanced AI innovation and security, amid ongoing discussions in Washington of whether oversight of frontier AI systems should rely on voluntary commitments, mandatory evaluations, licensing requirements, or some combination of the three. At the center of OpenAI’s proposal is a distinction between government evaluation and government approval. The company proposed that the most capable AI models undergo pre-release assessments by the Center for AI Standards and Innovation (CAISI), the federal government’s AI evaluation and standards body, while stopping short of giving regulators authority to approve or block deployments. “Policymakers should require the most capable frontier models to undergo a CAISI evaluation before public release,” OpenAI wrote in its proposal, “Democratic Governance of Frontier AI: A blueprint for a federal framework.” But it added that “CAISI’s role should be to conduct evaluations and recommend mitigations—not to approve or block deployments.” It also proposed a broader federal framework that would require evaluations, audits, transparency reports, incident reporting, whistleblower protections, and stronger security controls around frontier AI systems. Shaping the governance debate Sanchit Vir Gogia, chief analyst at Greyhound Research, said OpenAI’s proposal appears designed to influence the direction of an emerging federal governance framework rather than respond to one that is already settled. “The contest is no longer whether frontier AI is governed, but who governs it, on whose terms, and where final authority rests,” he said. OpenAI argued governments need greater visibility into frontier AI development and that voluntary commitments alone will not be sufficient as AI systems become more capable. “Democratic governments — not private companies acting alone — must ultimately determine the rules, safeguards, and accountability mechanisms,” it wrote. “Decisions about the pace of AI innovation should not be left to any one lab, company, or special interest group.” The company also said, “If artificial general intelligence is going to benefit all of humanity, the world needs more than voluntary commitments, individual company policies, and isolated regulatory interventions.” Instead, it argued, “It needs harmonized legal frameworks and durable institutions capable of adapting as technology advances.” A procurement gate for enterprise AI The proposal also addresses government buyers. OpenAI said federal agencies should not run frontier AI systems that have not passed a recognized evaluation and should “prohibit procurement of products and services that rely on unevaluated frontier models” in sensitive settings. It would also sort the federal market into evaluated and unevaluated models: Any vendor building on a frontier model would have to show the system had cleared evaluation to keep selling to government. Gogia said compliance-heavy rules favor the largest developers, who help define the thresholds and audit templates that others inherit. “Governance of this shape can become a moat dressed as maturity,” he said. Beyond voluntary commitments OpenAI’s proposal goes beyond model evaluations, suggesting a broader governance framework for frontier AI developers. Among the measures it recommends are annual third-party audits, public transparency reports, critical safety incident reporting requirements, cybersecurity protections for unreleased model weights, and whistleblower safeguards. “Large frontier developers should annually retain an independent third party to audit compliance with frontier safety requirements,” OpenAI said in the document. The company is also calling for mandatory reporting of critical incidents involving deployed models, including dangerous model behavior and unauthorized access to sensitive model weights. Shreeya Deshpande, senior analyst at Everest Group, said the proposal attempts to balance stronger oversight with continued innovation. “This creates a credible middle path between voluntary commitments and licensing, while preserving developer control,” she said. “The model’s effectiveness will depend on CAISI’s technical capacity, independent assessment quality, and the strength of enforcement mechanisms.” Building institutions, not gatekeepers A central element of OpenAI’s proposal is to expand CAISI into what it describes as the federal government’s primary institution for frontier AI evaluation, standards development, independent assessment certification, and coordination with national security agencies and international partners. OpenAI argues policymakers need a permanent institution capable of monitoring frontier capabilities and evaluating emerging risks as AI systems evolve. At the same time, the company repeatedly cautions against turning CAISI into a deployment gatekeeper. Developers, it argues, should remain responsible for release decisions, and model deployment should not be delayed because of government capacity constraints or administrative bottlenecks. Gogia said the framework should be understood primarily as a mechanism for generating evidence about frontier AI systems rather than directly determining whether they can be deployed. “It is best understood as an evidence-producing regime rather than an accountability-producing one,” he said. “It will make developers more legible. Whether it makes them more answerable is a separate question.” View the full article

A high severity vulnerability in Hugging Face Transformers enables attackers to compromise systems that use the popular Python library to test and run AI models. The flaw impacts library versions that continue to be actively downloaded and comes at a time when attackers are increasingly targeting the AI supply chain, including through malicious models hosted on the Hugging Face platform. The exploit for this vulnerability involves adding an innocuous-looking parameter called _attn_implementation_internal to remote model configuration files on Hugging Face and bypasses the trust_remote_code=false flag that normally prevents the execution of remote code accompanying models. “The malicious field uses an underscore-prefixed name that looks like an internal implementation detail — the kind of field that config files are full of,” researchers from Pluto Security who found the vulnerability said in their report. “There are no runtime warnings, no consent prompts, no unusual log entries.” The Hugging Face Transformers library allows Python developers to deploy over 1 million machine learning model variants hosted on Hugging Face on their local hardware or cloud instances. It is used in many enterprise environments and CI/CD pipelines to test models pre-trained for various tasks and to fine-tune them with proprietary data. The Hugging Face Transformers PyPI package is downloaded over 146 million times per month and has a total of 2.2 billion installs to date. The project is also one of the highest-rated repositories on GitHub with 161K+ stars, so the blast radius of a remote code execution (RCE) vulnerability is huge. This previously undisclosed flaw, now tracked as CVE-2026-4372, was silently patched in Transformers 5.3.0, which was released on March 3, but it impacts all versions released since August starting with 4.56.0. Vulnerable versions continue to be downloaded 7 to 8 million times per week and account for around a fourth of weekly installations. Custom ‘attention’ kernels bypass RCE defenses AI models hosted on Hugging Face can contain custom Python code, which can present a serious security risk if downloaded and executed alongside the model automatically. In the past this capability has been abused by attackers, which is why a parameter called trust_remote_code: was added to configurations. When set to false, it is meant to give developers an assurance that additional code will not be automatically executed. However, in March last year, Hugging Face added a feature called Hub Kernels that allows users to host custom compiled attention kernels. These kernels improve the performance of models when loaded on GPUs and require an additional package called kernels. The presence of this package on the machine is required to exploit this vulnerability, which is a limiting factor at first glance. However, even though it’s an optional dependency, having the kernels package installed is not uncommon, especially because most users who run local AI models want to benefit from GPU acceleration and will install Transformers with all “extras” packages. “Users who work with GPU-accelerated inference — arguably the most valuable targets — are the most likely to have it installed,” the researchers said. “Enterprise ML platforms and GPU clusters commonly install all optional dependencies to maximize hardware utilization.” The vulnerability is the result of three separate design decisions made in the code that combine to introduce the silent RCE risk. First, when the model loading is invoked with AutoModelForCausalLM.from_pretrained(“model-name”) the library proceeds to download the model’s configuration, weights, and tokenizer from the Hub, assemble the correct architecture, and return a ready-to-use model to the application. The code that parses the model’s config.json file uses a function called setattr that parses every key-value pair in the file and loads it into the config object, but does not differentiate between user-configurable parameters and internal parameters that start with the _ character. Such internal parameters should never be present in a user-supplied config because they are not meant to be touched by developers. One of those internal parameters is _attn_implementation_internal, which is used to control which attention mechanism implementation the model uses: Flash Attention, SDPA, or the default eager implementation. Furthermore, the hub_kernels.py component checks for the value of this parameter and if it’s set to a pattern that matches two strings separated by / it assumes this is an owner/repository definition from the Kernels Hub. The code then proceeds to download the kernel from the defined repository and execute it. “No sandboxing. No code signing. No integrity verification. No user prompt,” the researchers said. “Just a raw import of whatever Python code lives in the attacker’s repository — including anything in __init__.py, which executes automatically on import.” As a result of these three independent issues — the unfiltered setattr, the unprotected internal attribute, and the unsandboxed kernel loader — exploitation becomes trivial: Publish an attractive model with a configuration that includes _attn_implementation_internal set to attacker-repo/malicious-kernel. Supply chain attacks via malicious AI models are increasing This is not an unusual attack. Malicious models get uploaded to Hugging Face all the time and they can be quite successful in tricking users. Last month, a malicious Hugging Face repo posing as a new release of OpenAI’s Privacy Filter model reached the No. 1 trending spot on the platform within 18 hours and was downloaded 244,000 times. The model code contained infostealer malware for Windows. Last year, researchers showed how attackers can hide malicious code inside Python Pickle files, a format that is commonly used to distribute AI models. This Transformers vulnerability is not the first that enables remote code execution through maliciously crafted AI models. Last month researchers from security firm HiddenLayer disclosed a RCE vulnerability in ChromaDB that allowed unauthenticated remote attackers to trick Chroma servers into executing malicious code from model configurations hosted on Hugging Face. Earlier that same month, the same researchers showed how remote code execution can be achieved by making minor changes to a model’s tokenizer.json file, which is used to map token IDs to words and characters creating an alphabet the model uses to generate its outputs. Mitigation With the number of such supply chain attacks increasing, having checks in place for model provenance becomes very important for organizations experimenting with AI and machine learning. Cisco’s AI research team has recently released an open source-tool called the Model Provenance Kit that uses fingerprints from model weights, tokenizers, and architecture metadata to determine whether a machine learning model derives from one of the 45-plus known base model families from more than 20 trusted publishers, including the leading AI labs. That said, the Pluto Security researchers advise organizations to treat AI model loading and config deserialization APIs in ML frameworks and libraries as code execution surfaces, regardless of the safe flags they provide. This means model loading should be sandboxed and isolated inside monitored containers that don’t have access to host credentials, outbound network access, and extensive filesystem permissions. Configuration files should also be scanned before loading and checked for unexpected fields, including those prefixed with underscore. Transformers users should upgrade to version 5.3.0 immediately and should search for _attn_implementation_internal in any cached or downloaded config.json files to determine whether they’ve been targeted. View the full article

A high severity vulnerability in Hugging Face Transformers enables attackers to compromise systems that use the popular Python library to test and run AI models. The flaw impacts library versions that continue to be actively downloaded and comes at a time when attackers are increasingly targeting the AI supply chain, including through malicious models hosted on the Hugging Face platform. The exploit for this vulnerability involves adding an innocuous-looking parameter called _attn_implementation_internal to remote model configuration files on Hugging Face and bypasses the trust_remote_code=false flag that normally prevents the execution of remote code accompanying models. “The malicious field uses an underscore-prefixed name that looks like an internal implementation detail — the kind of field that config files are full of,” researchers from Pluto Security who found the vulnerability said in their report. “There are no runtime warnings, no consent prompts, no unusual log entries.” The Hugging Face Transformers library allows Python developers to deploy over 1 million machine learning model variants hosted on Hugging Face on their local hardware or cloud instances. It is used in many enterprise environments and CI/CD pipelines to test models pre-trained for various tasks and to fine-tune them with proprietary data. The Hugging Face Transformers PyPI package is downloaded over 146 million times per month and has a total of 2.2 billion installs to date. The project is also one of the highest-rated repositories on GitHub with 161K+ stars, so the blast radius of a remote code execution (RCE) vulnerability is huge. This previously undisclosed flaw, now tracked as CVE-2026-4372, was silently patched in Transformers 5.3.0, which was released on March 3, but it impacts all versions released since August starting with 4.56.0. Vulnerable versions continue to be downloaded 7 to 8 million times per week and account for around a fourth of weekly installations. Custom ‘attention’ kernels bypass RCE defenses AI models hosted on Hugging Face can contain custom Python code, which can present a serious security risk if downloaded and executed alongside the model automatically. In the past this capability has been abused by attackers, which is why a parameter called trust_remote_code: was added to configurations. When set to false, it is meant to give developers an assurance that additional code will not be automatically executed. However, in March last year, Hugging Face added a feature called Hub Kernels that allows users to host custom compiled attention kernels. These kernels improve the performance of models when loaded on GPUs and require an additional package called kernels. The presence of this package on the machine is required to exploit this vulnerability, which is a limiting factor at first glance. However, even though it’s an optional dependency, having the kernels package installed is not uncommon, especially because most users who run local AI models want to benefit from GPU acceleration and will install Transformers with all “extras” packages. “Users who work with GPU-accelerated inference — arguably the most valuable targets — are the most likely to have it installed,” the researchers said. “Enterprise ML platforms and GPU clusters commonly install all optional dependencies to maximize hardware utilization.” The vulnerability is the result of three separate design decisions made in the code that combine to introduce the silent RCE risk. First, when the model loading is invoked with AutoModelForCausalLM.from_pretrained(“model-name”) the library proceeds to download the model’s configuration, weights, and tokenizer from the Hub, assemble the correct architecture, and return a ready-to-use model to the application. The code that parses the model’s config.json file uses a function called setattr that parses every key-value pair in the file and loads it into the config object, but does not differentiate between user-configurable parameters and internal parameters that start with the _ character. Such internal parameters should never be present in a user-supplied config because they are not meant to be touched by developers. One of those internal parameters is _attn_implementation_internal, which is used to control which attention mechanism implementation the model uses: Flash Attention, SDPA, or the default eager implementation. Furthermore, the hub_kernels.py component checks for the value of this parameter and if it’s set to a pattern that matches two strings separated by / it assumes this is an owner/repository definition from the Kernels Hub. The code then proceeds to download the kernel from the defined repository and execute it. “No sandboxing. No code signing. No integrity verification. No user prompt,” the researchers said. “Just a raw import of whatever Python code lives in the attacker’s repository — including anything in __init__.py, which executes automatically on import.” As a result of these three independent issues — the unfiltered setattr, the unprotected internal attribute, and the unsandboxed kernel loader — exploitation becomes trivial: Publish an attractive model with a configuration that includes _attn_implementation_internal set to attacker-repo/malicious-kernel. Supply chain attacks via malicious AI models are increasing This is not an unusual attack. Malicious models get uploaded to Hugging Face all the time and they can be quite successful in tricking users. Last month, a malicious Hugging Face repo posing as a new release of OpenAI’s Privacy Filter model reached the No. 1 trending spot on the platform within 18 hours and was downloaded 244,000 times. The model code contained infostealer malware for Windows. Last year, researchers showed how attackers can hide malicious code inside Python Pickle files, a format that is commonly used to distribute AI models. This Transformers vulnerability is not the first that enables remote code execution through maliciously crafted AI models. Last month researchers from security firm HiddenLayer disclosed a RCE vulnerability in ChromaDB that allowed unauthenticated remote attackers to trick Chroma servers into executing malicious code from model configurations hosted on Hugging Face. Earlier that same month, the same researchers showed how remote code execution can be achieved by making minor changes to a model’s tokenizer.json file, which is used to map token IDs to words and characters creating an alphabet the model uses to generate its outputs. Mitigation With the number of such supply chain attacks increasing, having checks in place for model provenance becomes very important for organizations experimenting with AI and machine learning. Cisco’s AI research team has recently released an open source-tool called the Model Provenance Kit that uses fingerprints from model weights, tokenizers, and architecture metadata to determine whether a machine learning model derives from one of the 45-plus known base model families from more than 20 trusted publishers, including the leading AI labs. That said, the Pluto Security researchers advise organizations to treat AI model loading and config deserialization APIs in ML frameworks and libraries as code execution surfaces, regardless of the safe flags they provide. This means model loading should be sandboxed and isolated inside monitored containers that don’t have access to host credentials, outbound network access, and extensive filesystem permissions. Configuration files should also be scanned before loading and checked for unexpected fields, including those prefixed with underscore. Transformers users should upgrade to version 5.3.0 immediately and should search for _attn_implementation_internal in any cached or downloaded config.json files to determine whether they’ve been targeted. View the full article

Enterprise security teams were urged by security experts at Infosecurity Europe to brace for impact as both Anthrophic and OpenAI expand access to their frontier AI models for vulnerability discovery. Anthropic, in particular, is significantly expanding Project Glasswing, its scheme to provide select organizations with access to Claude Mythos, an AI-powered vulnerability discovery tool that many industry observers and practitioners believe signals a structural shift for cybersecurity. After initially granting access to around 50 organizations in April, Anthropic is now adding roughly 150 more vetted partners to its program. In a parallel development, OpenAI reportedly has offered nine major UK banks access to its cybersecurity AI tool, GPT-5.5 Cyber. Prepare for the son of Mythos Speaking at Infosecurity Europe, Gunter Ollmann, CTO at penetration testing and security services firm Cobalt, said frontier AI models from Google and two from China are not far behind in their capabilities. “Security teams should prepare for the son of Mythos,” said Ollmann. “These frontier AI tools are still restricted in their access, but they are only going to get cheaper as we go along.” Paul Chichester, director of operations at the UK’s National Cyber Security Centre (NCSC), backed up this assessment by citing estimates that China was eight months behind. Misuse of frontier AI models represents a threat while also offering defenders the opportunity to push additional costs onto adversaries, Chichester told Infosec Europe delegates. “Organisations can use AI to write better code and look for vulnerabilities,” said Chichester, who added that frontier AI tools have the potential to democratise security assessments and penetration testing. Organisations should improve cybersecurity by hardening access controls and running incident response exercises, Chichester advised. Daniel Wilcock, threat intelligence analyst at managed security services firm Talion, warned that organisations that fail to explore advanced AI risk falling behind those that are using the technology to accelerate vulnerability discovery and security operations. “Advanced AI platforms are already being used by malicious threat actors, and all organisations must be prepared for this,” Wilcock warned. Exploit chains Ollmann told CSO that AI is far from replacing security experts such as penetration testers. “The combination of AI-driven analysis and human expertise is proving far more effective than either operating alone,” Ollmann said. “The organizations that benefit most from these advances will be the ones that can rapidly validate, prioritize, and remediate the issues being discovered before attackers find them first.” Ollmann added: “Mythos appears to be operating with a level of software access and analysis flexibility that most commercial security researchers and testing platforms don’t typically have, including the ability to examine code and behaviours that may otherwise be restricted by licensing or terms of service. That creates a unique opportunity to identify classes of vulnerabilities that conventional testing approaches often miss.” For example, Mythos makes it easier to chain together several medium severity vulnerabilities to create a high impact risk. The topic of AI flaw-chaining was also central to a panel on Mythos at the recent CSO Cybersecurity Awards and Conference in the US. “When we’re doing threat modeling, we have some sense that these are the known vulnerabilities that we are modeling against and here’s where we think we are weak, and that kind of goes away with chaining multiple vulnerabilities,” Jim Reavis, CEO and co-founder of Cloud Security Alliance (CSA) told attendees. “CVSS scoring, it seems like that’s not super relevant anymore.” Jon Yeoh, chief scientific officer at CSA, agreed, touching on the “son of Mythos” threat as well. “It’s not just about Anthropic. It’s about what these next-generation AI will be doing,” he said. “This is a major step change in what AI can do.” View the full article

LONDON — Enterprise security teams were urged by security experts at Infosecurity Europe to brace for impact as both Anthrophic and OpenAI expand access to their frontier AI models for vulnerability discovery. Anthropic, in particular, is significantly expanding Project Glasswing, its scheme to provide select organizations with access to Claude Mythos, an AI-powered vulnerability discovery tool that many industry observers and practitioners believe signals a structural shift for cybersecurity. After initially granting access to around 50 organizations in April, Anthropic is now adding roughly 150 more vetted partners to its program. In a parallel development, OpenAI reportedly has offered nine major UK banks access to its cybersecurity AI tool, GPT-5.5 Cyber. Prepare for the son of Mythos Speaking at Infosecurity Europe, Gunter Ollmann, CTO at penetration testing and security services firm Cobalt, said frontier AI models from Google and two from China are not far behind in their capabilities. “Security teams should prepare for the son of Mythos,” said Ollmann. “These frontier AI tools are still restricted in their access, but they are only going to get cheaper as we go along.” Paul Chichester, director of operations at the UK’s National Cyber Security Centre (NCSC), backed up this assessment by citing estimates that China was eight months behind. Misuse of frontier AI models represents a threat while also offering defenders the opportunity to push additional costs onto adversaries, Chichester told Infosec Europe delegates. “Organisations can use AI to write better code and look for vulnerabilities,” said Chichester, who added that frontier AI tools have the potential to democratise security assessments and penetration testing. Organisations should improve cybersecurity by hardening access controls and running incident response exercises, Chichester advised. Daniel Wilcock, threat intelligence analyst at managed security services firm Talion, warned that organisations that fail to explore advanced AI risk falling behind those that are using the technology to accelerate vulnerability discovery and security operations. “Advanced AI platforms are already being used by malicious threat actors, and all organisations must be prepared for this,” Wilcock warned. Exploit chains Ollmann told CSO that AI is far from replacing security experts such as penetration testers. “The combination of AI-driven analysis and human expertise is proving far more effective than either operating alone,” Ollmann said. “The organizations that benefit most from these advances will be the ones that can rapidly validate, prioritize, and remediate the issues being discovered before attackers find them first.” Ollmann added: “Mythos appears to be operating with a level of software access and analysis flexibility that most commercial security researchers and testing platforms don’t typically have, including the ability to examine code and behaviours that may otherwise be restricted by licensing or terms of service. That creates a unique opportunity to identify classes of vulnerabilities that conventional testing approaches often miss.” For example, Mythos makes it easier to chain together several medium severity vulnerabilities to create a high impact risk. The topic of AI flaw-chaining was also central to a panel on Mythos at the recent CSO Cybersecurity Awards and Conference in the US. “When we’re doing threat modeling, we have some sense that these are the known vulnerabilities that we are modeling against and here’s where we think we are weak, and that kind of goes away with chaining multiple vulnerabilities,” Jim Reavis, CEO and co-founder of Cloud Security Alliance (CSA) told attendees. “CVSS scoring, it seems like that’s not super relevant anymore.” Jon Yeoh, chief scientific officer at CSA, agreed, touching on the “son of Mythos” threat as well. “It’s not just about Anthropic. It’s about what these next-generation AI will be doing,” he said. “This is a major step change in what AI can do.” View the full article

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher. The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds. First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL. Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.” Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.” For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces. The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog. “The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote. The exploit Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token. This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.” In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.” This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.” This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian. Short notice Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands. [Related content: When responsible disclosure becomes unpaid labor] An ethical question Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it? These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch. For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident. An imbalance of power Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.” The spokesperson added that the issue Askar reported “has been mitigated for our services and no customer action is required.” [Related content: Is the vulnerability disclosure process glitched?] There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.” However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.” This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.” This article originally appeared on InfoWorld. View the full article

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher. The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds. First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL. Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.” Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.” For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces. The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog. “The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote. The exploit Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token. This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.” In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.” This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.” This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian. Short notice Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands. [Related content: When responsible disclosure becomes unpaid labor] An ethical question Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it? These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch. For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident. An imbalance of power Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.” [Related content: Is the vulnerability disclosure process glitched?] There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.” However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.” This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.” This article originally appeared on InfoWorld. View the full article

Cloud computing has reached a crossroads. The high cost and data sensitivity of AI workloads are raising the appeal of private clouds, even as neoclouds and sovereign clouds shake up the cloud provider landscape. New cyberthreats, shifting compute requirements, and management complexity are adding to cloud complications. Download the June 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World, and learn how to navigate the latest cloud strategy developments. View the full article

As enterprises race to adopt AI agents across software development workflows, Microsoft is rolling out new controls aimed at keeping the transformation from becoming a security headache. At its annual developer conference, Microsoft Build, the company unveiled a set of initiatives, including a brand new runtime containment offering, Microsoft Execution Container (MXC), for agentic AI workloads, and improvements to its recently launched multi-agent vulnerability research system MDASH, among others. “AI is accelerating development and introducing new issues around insecure code, opaque models, data exposure, and compliance,” Aleš Holeček, chief architect at Microsoft Security, said in a blog post. The new tools and capabilities will “give developers clear guidance in real time, scale with the complexity of tasks, and provide security teams with a consistent view across the full lifecycle,” he added. The idea of sandboxing untrusted code is obviously not new. Containers, VMs, browser sandboxes, and GitHub Codespaces all exist. What’s new is that Microsoft is positioning MXC as a dedicated runtime containment environment for agentic AI workloads, where autonomous agents can take actions, invoke tools, modify code, and access resources. A lot is said and seen about what could happen when these agents have a little too much autonomy. Coding agents today can access files they shouldn’t, leak secrets, make unauthorized network calls, and execute other unexpected actions. Microsoft puts AI agents in a security sandbox Microsoft Execution Containers are a new containment technology intended to place guardrails around autonomous AI agents. It is a policy-driven execution workflow that lets developers specify what an AI agent can access, such as files, networks, resources, credentials, and then enforces those boundaries at runtime. “MXC is a sandboxed code execution system for running untrusted code (model output, plugins, tools) on Windows, Linux, and macOS,” Microsoft’s official description of the offering reads. “It provides multiple containment backends — from OS-native process sandboxes to full VMs — behind a unified JSON configuration schema and TypeScript SDK.” Build announcements also included Microsoft’s two new offerings made public in May 2026. These included the Agent 365 SDK, which provides developers with tools to build, deploy, and manage AI agents, and Windows 365 for Agents, a managed environment intended to give autonomous agents dedicated cloud-based workspaces. Microsoft also revealed its plans for MXC, serving as a security foundation for several agent platforms. Agent 365 will integrate with the framework to bring controls from Defender, Entra, Intune, and Purview to agent environments, while OpenClaw and NVIDIA’s OpenShell are already adopting MXC to run AI agents within isolated execution containers designed to limit risk and improve runtime security. MDASH moves beyond a research project While MXC fell under Microsoft’s “secure your agents” initiative at Build, the “secure your code” drive had the company announce updates to its Security Multi-model Agentic Scanning Harness (MDASH). The system claims to use more than 100 specialized AI agents operating across multiple models to identify vulnerabilities, assess exploitability, and reduce false positives before findings reach security teams. At Build, Microsoft positioned MDASH as part of a broader enterprise security workflow, announcing expanded preview availability and integration with Microsoft Defender. MDASH was first introduced in May, when it was revealed to have helped uncover multiple Windows vulnerabilities, including critical remote code execution flaws. Open-source controls aim to govern agent behavior Microsoft also used Build to introduce two open-source initiatives designed to address the governance challenges around AI agents. The first, Adaptive Spec-driven Scoring for Evaluation and Regression Testing (ASSERT), is intended to help organizations evaluate agent behavior against defined security and operational requirements. The second, the Agent Control Specifications (ACS), provides an open standard framework for defining and enforcing governance policies in a portable manner, capable of moving with the agent across different frameworks, platforms, and runtimes instead of being tied to a specific vendor’s technology stack. Together, MXC, MDASH, ASSERT, and ACS sum up Microsoft’s attempt at securing AI models’ entire lifecycle, from the code they generate to the actions they take later. View the full article

For nearly two decades, cybersecurity leaders have faced the same reality: No matter how catastrophic the latest breach, ransomware attack, or nation-state intrusion, security spending often struggled against competition with every other business priority. AI may finally be changing that equation. The rapid emergence of frontier AI systems capable of autonomous cyber operations — combined with the spread of agentic AI inside enterprises — has created something security leaders rarely enjoy: urgency at the board level. That urgency was unmistakable at the recent SANS AI Cyber Summit in Washington, DC, where former deputy national security adviser Anne Neuberger urged security leaders to capitalize on the moment. “We have a moment in time now where the knowledge of how LLMs are enabling attacks … [means] let’s change the culture, let’s operate with speed,” Neuberger said during a keynote address. Her comments came just days after Bain & Co. warned that many organizations may need to double or even triple cybersecurity investments to prepare for the operational challenges created by advanced AI systems such as Anthropic’s Mythos. “What I’m seeing is very refreshing,” Nate Rollings, CISO at threat exposure management vendor Zafran Security, told attendees at the recent CSO Cybersecurity Awards and Conference in Nashville. “Over the last couple years, we’ve seen these budgets for the business and IT to adopt AI … to drive revenue-generating activity,” he noted. “Because of Mythos and Glasswing, there’s been this realization that we haven’t enabled AI as much as we need to in security.” As a result, “we’re seeing this buy-in from the top down to say, ‘Listen, we need to increase some of the budget so we can use AI within security in response to AI threats.” For many CISOs, the convergence feels less like another hype cycle than a structural shift — especially as organizations rapidly deploy autonomous systems that security teams barely understand how to govern. How AI is expanding enterprise risk With the rapid adoption of AI agents, organizations are creating a new operational layer across their enterprises. These systems are increasingly capable of making decisions, initiating actions, accessing sensitive systems, and interacting with other software at machine speed with minimal human oversight. “Agentic AI is operating in ways we have not seen before in business,” Diana Kelley, CISO at Noma Security, tells CSO. “We’re now protecting a decision and automation layer with AI because agentic AI is making decisions.” Bernard Brantley, CISO at Corelight, tells CSO that AI is exposing years of accumulated technical debt by collapsing operational boundaries that security teams once relied on to isolate systems, data, and identity domains. “I’ve got a single potential agent that can go interact with all 50 interfaces available in the company in a sub-second,” he says. “Now we have to think about how much and how widely it proliferates.” “If we said every person in the company now has three agents, we’re now three orders of magnitude bigger in the landscape that we need to go secure,” Brantley adds. Existing security architectures were built for human-driven systems, not autonomous agents operating continuously at machine speed, forcing organizations to rethink identity management, monitoring, behavioral controls, and boundaries around AI systems. “You have to monitor it,” Kyle Lai, president and CISO of KLC Consulting, tells CSO. “If it starts misbehaving, capture it just like a human account.” Security leaders say one of the biggest emerging challenges is visibility. Many organizations still lack reliable ways to monitor what AI agents are accessing, what decisions they are making, which systems they are interacting with, and whether those actions remain aligned with corporate policy over time. Unlike traditional software, autonomous agents can dynamically chain together actions across multiple enterprise systems, making it significantly harder for security teams to predict behavior or constrain access using conventional privilege models. Lai says organizations increasingly recognize that AI agents require the same identity, logging, auditing, and behavioral controls historically applied to employees and privileged users. At the same time, AI is accelerating operational risk elsewhere inside enterprises. AI-assisted coding systems, for example, are enabling developers to generate enormous amounts of software quickly — but often without fully understanding the resulting security implications. Risk is accelerating faster than security teams can adapt Security leaders say generative coding systems are compressing development cycles faster than many organizations’ existing security review processes can realistically keep pace. Developers are increasingly deploying AI-generated code they may not fully understand, potentially introducing vulnerabilities, insecure dependencies, authentication flaws, and configuration errors into production environments at scale. “AI is generating a lot of code,” Lai says. “If you don’t manage the vulnerabilities generated by the AI, then it’s going to create more issues because now you’re creating all these vulnerabilities.” The operational implications are forcing many organizations to rethink cybersecurity less as a defensive IT function and more as a governance layer for autonomous enterprise systems. That shift is helping elevate cybersecurity discussions into broader conversations surrounding AI adoption, operational resilience, workforce automation, and business risk. Enterprise leaders are listening in ways they rarely have before AI is also changing C-suite and boardroom behavior. For years, many security leaders struggled to persuade boards that cyber risk represented a strategic business issue rather than simply an IT expense. “We often talk about culture as a defense mechanism to change,” Neuberger said at the SANS summit. “What we’re also seeing is suddenly CEOs talking about LLMs, talking about projects, and concerned about cybersecurity. That’s a massive change.” That attention matters because security spending has historically surged only when cyber risk becomes tied to broader business transformation. AI now sits at the center of boardroom conversations about competitiveness, automation, workforce productivity, and digital strategy, giving CISOs a rare opportunity to frame cybersecurity as an operational prerequisite for safe AI adoption. However, Brantley believes security leaders should resist fear-based messaging and instead position cybersecurity as a business enabler. “The increase in cyber budget should actually be oriented toward delivering business value with respect to the current or strategic AI goal,” he says. “There’s no way to address things at the speed of AI without using AI.” And what that often means is spending more on AI to tackle AI challenges. “I think [the increased spend] is going to be a blend of, say, 10 new people who are well-versed in this AI problem and potentially a contractor or a vendor who’s got a solution there, and then I will spend the money on the AI tokens to get to that answer.” The most effective leader-level pitch may be that cybersecurity is becoming the operational foundation that allows organizations to scale AI safely without losing visibility, governance, or control. “Data poisoning, indirect prompt injection, agents taking rogue actions — that’s all part of the risk conversation at an organization,” Kelley says. “This is a risk conversation about how the business is making decisions.” Budget requests need a business case Not everyone believes AI will trigger a cyber spending boom. Ian Thornton-Trump, CISO at Inversion6, warns that some organizations risk treating AI as a catch-all justification for spending without clearly articulating underlying business risks. “I think waving the flag of AI is the wrong answer,” Thornton-Trump says. “I would be laughing as an executive at a company if somebody came to me and said, ‘I want to spend a ton of money on AI for cyber.’” Thornton-Trump argues that boards continue to balance cybersecurity against a long list of competing strategic concerns, including geopolitical instability, climate risk, fraud, supply chain disruption, and rising operational costs. “Ask for more money, but have a plan,” he says. “Especially a plan that incorporates the fact that you’re not going to get everything you ask for.” The debate, in other words, isn’t really about whether to spend — it’s about whether security leaders can articulate why clearly enough to be heard. Whether the advent of AI is enough to boost budgets, it’s clear that frontier AI, autonomous enterprise systems, and executive fear of falling behind competitors have suddenly aligned cybersecurity with core business strategy. The result would be the most significant shift in enterprise security spending since the rise of cloud computing — not because leaders suddenly fear cyberattacks more, but because they increasingly view cybersecurity as the operational foundation that makes large-scale AI adoption possible. View the full article

Canvas cyberattack: Who, what, when, how? What and when? Over May 6 and 7, 2026, Canvas learning management system (LMS) users were served up a defaced web page in place of the expected login page. The altered web page displayed a warning by the ShinyHunters criminal hacker and extortion group advising of the Instructure compromise. Instructure, a leading educational technology company based in Salt Lake City, Utah, was founded in 2008 and its Canvas LMS was launched in 2011. The ShinyHunters warning gave Instructure a deadline of May 12, 2026, by which to contact them and negotiate a ransom deal in order to prevent the disclosure of Canvas data. As early as May 1, 2026, ShinyHunters claimed responsibility for the Instructure/Canvas attack that reportedly affected nearly 9,000 educational institutions globally and exposed sensitive information tied to 275 million students, faculty members and staff. Names, email addresses, student identifiers and private communications comprising a staggering 3.65 terabytes were stolen. The timing of the attack was especially damaging since it caused widespread operational disruption during final examinations and temporarily blocked access to coursework, assignments and collaboration systems at colleges and universities worldwide. Who? The ShinyHunters criminal hacker group’s name is believed to be derived from the rare Shiny Pokémon video game character. The character is an aspect of the Pokémon video game franchise where Pokémon appear in an alternate color scheme and produce a special sparkle animation when entering battle. Players who try to collect the scarce Shiny Pokémon through in-game strategies are often referred to as “shiny hunters.” Ransomware.live, a free and independent website, continuously updates its threat intelligence platform and tracks ransomware groups and their victims. Their statistics on ShinyHunter’s nefarious activities identify staggering statistics. Starting in 2020, ShinyHunters successfully compromised 104 victims across 14 countries and stole trillions of records. Of the 104 victims on the list, 73 are located in the United States and include some big names: Microsoft, Ticketmaster, Google, Cisco Systems, 7-Eleven, CarMax, Amtrak, McDonald’s, Disney/Hulu, Princeton, Harvard and the University of Pennsylvania. AT&T Wireless was compromised more than once as was Instructure. The Instructure/Canvas attack represents far more than an isolated technology outage – it is a high-profile demonstration of how centralized digital ecosystems, third-party dependencies and modern extortion operations are reshaping enterprise cyber risk. While the attack primarily disrupted the education sector, the lessons emerging from the incident are directly applicable to CISOs, boards of directors, risk management leaders and executive teams across every industry. How? Specific technical details about how Canvas was compromised are thin. But on Instructure’s Security Incident & Update page, the company identified a vulnerability with support tickets in their Free for Teacher environment was exploited. In the wake of the attack, Canvas temporarily disabled the Free for Teacher service while they complete a full security review. Free for Teacher is a standalone, no-cost version of the Canvas LMS, allowing teachers to build interactive classes and manage students independently, even if their school does not use Canvas. Attackers target lower-security environments, legacy systems, support portals, testing infrastructure, API integrations and less-monitored external services because they often possess weaker controls than primary production environments. Organizations often invest heavily in protecting their primary customer-facing infrastructure while underestimating risks associated with support ecosystems, development platforms and auxiliary services. Lessons learned Reliance on third-party cloud platforms that aggregate enormous quantities of sensitive data Educational institutions increasingly rely upon digital ecosystems not only for learning management but also for communication, grading, identity management, scheduling and operational continuity. Similar dependencies exist throughout the private sector. Modern enterprises increasingly centralize operational workflows within cloud-based Software as a Service (SaaS) providers, creating concentrated risk exposure. When these platforms fail, the consequences cascade rapidly. I recently asked one professor whose university was affected by the incident as to how she was impacted. She replied that the impact was somewhat insignificant since she stores all her class and student information locally in spreadsheets and similar offline formats. CISOs must reconsider how vendor risk is evaluated. Historically, many third-party risk programs focused heavily on compliance artifacts such as SOC reports, ISO certifications, penetration testing summaries and questionnaire-based responses. While these remain useful, the Canvas incident demonstrates that such controls alone do not guarantee operational security and resilience. Organizations must begin evaluating vendors not only on preventive security controls, but also on their incident response maturity, crisis communications capabilities, architectural resilience, data segmentation strategies, recovery timelines and executive transparency. As I researched Instructure for this article, I found an impressive website, the Instructure Trust Center. The site displays eleven compliance “badges” – SOC 2 Type 2, SOC 3, PCI, ISO 27001, GDPR, etc. The site also provides access to 74 compliance-supporting documents and 57 FAQ items. To illustrate an earlier point about organizations focusing on primary product offerings rather than risks associated with secondary products and services, I accessed and reviewed Instructure’s ISO 27001 certificate, which is current and expires October 15, 2027. The certificate states that “The scope of this ISO/IEC 27001:2022 certificate includes Instructure’s products, teams and ISMS managed at its HQ location in Salt Lake City, UT, USA. The in-scope people, processes, technology and locations are defined within the Instructure Scope of the Information Security Management System (ISMS), dated August 1, 2025, and the Statement of Applicability, dated April 16, 2025. The scope of the ISMS implemented by Instructure includes the following elements: Products: Canvas, Studio, Mastery Connect, Impact, Parchment Award, Parchment Pathways, Parchment. Services: Parchment Digitary Services (MyEquals and MyCreds), Intelligent Insights, Elevate Standards Note that the Instructure in-scope product list reviewed as part of the ISO 27001 assessment does not include Free for Teachers. Communications management Subsequent to the compromise, Instructure took the defaced web page offline and served up a status page referring to the outage as a “scheduled maintenance event.” Then, the following day, Instructure officials declared that the incident had been contained, even though it was at least the third time in the past eight months that Instructure had been breached by ShinyHunters. Public reporting suggested confusion surrounding the timeline, scope and nature of the compromise. Some institutions reportedly struggled to determine whether their local environments had been breached directly or whether the exposure was isolated to the vendor platform. For executive leadership teams, this reinforces a critical lesson: cyber incidents are communications crises as much as technical events. Organizations that navigate major cyber incidents most successfully are often those capable of delivering clear, transparent and credible communications early in the response lifecycle. Delayed or incomplete communication during a crisis often magnifies reputational damage because stakeholders begin filling information vacuums with speculation and distrust. Economics of attacks Boards of directors should also take note of the strategic implications surrounding ransomware and extortion economics. Although public details remain incomplete, multiple reports suggested that ransom negotiations or agreements may have occurred between the vendor and the attackers. This reflects a broader trend facing enterprises globally. Ransomware has evolved from operational disruption into multidimensional extortion campaigns involving data theft, reputational pressure, public exposure threats and business interruption leverage. Business continuity and recovery Executives must recognize that resilience planning cannot focus solely on technical recovery metrics. Business continuity strategies must incorporate operational timing risk, reputational escalation scenarios, communications management, regulatory exposure and executive decision-making frameworks surrounding extortion events. Organizations frequently underestimate how rapidly cyber incidents evolve into enterprise-wide crisis management situations requiring legal, public relations, compliance, insurance and board-level coordination. Data minimization Many organizations continue accumulating vast quantities of historical data without sufficiently evaluating whether long-term retention remains operationally necessary. The larger the centralized data repository, the more attractive the environment becomes for extortion-oriented threat actors. Healthcare and educational institutions are particularly vulnerable since supporting data management systems often contain years of communications, coursework, behavioral data, grading information and identity records. Data retention governance must therefore become a board-level strategic discussion rather than a purely operational records management issue. Long-term impacts and secondary breach concerns An often-overlooked concern with ransom/data exfiltration incidents is the potential long-term impact associated with exposed communications data. Even when passwords or financial information are reportedly unaffected, large-scale exposure of communications metadata, institutional relationships and personal identifiers creates significant downstream risk. Threat actors can leverage such information for future phishing campaigns, social engineering operations, credential harvesting and identity fraud. Cybersecurity leaders must think beyond immediate containment and evaluate how stolen information may fuel future attacks months or even years later. What’s next? In a letter dated May 11, 2026, from United States Congressman Andrew R. Garbarino, Chairman of the Committee on Homeland Security, requested Steve Daly, Chief Executive Officer Instructure Holdings, Inc., to participate in a briefing with the Committee, to be scheduled at a mutually convenient time no later than Thursday, May 21, 2026. Stay tuned! This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Anthropic on Tuesday announced that it was adding 150 more companies to its Project Glasswing AI-based vulnerability hunting initiative, with a particular focus on critical infrastructure companies including those involved in “power, water, healthcare, communications and hardware.” Analysts and security vendors agreed that the move is a positive step, noting that the more companies involved in bug identification, the better. But the bigger background issue is a practical one: the bottleneck problem. If Project Glasswing, and similar projects from other major AI vendors, increase the stream of vulnerability identifications by 10 or more times, will vendors be able to triage and patch them in a timely manner? Vendors have historically been notoriously slow to patch known security issues. Microsoft, for example, recently argued with a security researcher who went public with holes because he felt that Microsoft was too slow in addressing them. And even if those vendors can keep up, are enterprise SOCs going to be able to keep up with the avalanche of patches? And if extensive automation is deployed to generate those patches, will CISOs trust them enough to let them be deployed without manual verification? Trust is not a common CISO trait. “What each partner has in common is that a successful attack on their codebase could be catastrophic. For most partners, we estimate that a major attack could affect more than 100 million people, with important ramifications for both global and national security,” Anthropic said in its blog post announcing the new participants. “This expansion is the next step toward our long-term goals: for AI to make all software more secure, and for us to help the industry adjust to how AI could change many of the core assumptions of cybersecurity.” Glasswing was announced on April 7 and was initially supported by AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. Okta later confirmed that it was also involved. The patch bottleneck The bottleneck problem is a difficult one to solve, given that even the largest vendors can only cost-justify so many resources for patching security holes and distributing those patches. “The biggest issue is adaptability: once a vulnerability or weakness is found, defenders have to validate it, prioritize it, and fix it before attackers can operationalize the same insight. And that validation step matters,” said Tom Findling, CEO of Conifers.ai. “While testing the tool ourselves, we saw a lot of false positives, which means organizations cannot simply treat every finding as immediately actionable. They need the ability to separate signal from noise quickly, then adapt their processes, engineering workflows, and patching pipelines around the real issues.” “The most important metric for organizations to track may not just be how many vulnerabilities are found, but how long it takes them to adapt once a credible issue is identified. For some organizations, that adaptation cycle can still take months,” he added. “Reducing that time-to-adapt is what will determine whether AI-assisted vulnerability discovery actually improves defense or just increases the speed and volume of security noise.” A remediation problem Justin Greis, CEO of consulting firm Acceligence, agreed that the Glasswing expansion may simply demonstrate to CISOs how much the security hole problem is shifting, not shrinking. “It’s no secret that cybersecurity has been treated as a vulnerability discovery problem. AI is proving that it was really a remediation problem all along. The industry already struggles to validate, prioritize, patch, test, and deploy fixes fast enough. It may even be worse if security teams own the vulnerability identification and the IT teams, or the business teams, own the patching itself,” Greis said. “If AI can identify vulnerabilities 10x or 100x faster than humans, the bottleneck simply moves downstream. Organizations may soon find themselves in the uncomfortable position of knowing about far more vulnerabilities than they can realistically address. AI is turning cybersecurity from a visibility problem into an execution problem.” Greis added a frightening prediction: “AI could make organizations simultaneously more secure and more overwhelmed, if that’s possible. They’ll have unprecedented visibility into their risk, but they’ll also discover just how large that risk really is.” Trust required Grace Trinidad, research director for AI security at IDC, said the bottleneck problem at the enterprise needs to be addressed via extensive automation. But given the lack of trust by cybersecurity staff, vendors must have a rigorous method for producing a numerical confidence score for every patch. “Having a confidence score accompanying these patches is a new concept. There must be an ability of the enterprise to identify, triage and address the vulnerabilities that are specific to their environment,” Trinidad said. “We are learning a skillset that we are not ready for: How do we trust automated technologies? Given that we are having to move at this speed, that trust is going to get broken. Confidence scoring is a discipline that needs transparency. Don’t make the confidence [explanation] so complicated that you can’t explain it to a human being.” Trinidad also noted that the Anthropic announcement pointed out that each of the 150 new participants, in Anthropic’s phrasing, “will need to meet our security requirements before they gain access.” Trinidad said the security requirement claim doesn’t build confidence, because “nobody knows what those security requirements are.” One possible solution is for security vendors to use high-trust third parties so that they are not seen as ‘grading their own homework’. Enterprise software vendor Workday is using a similar third-party approach, relying on trusted services that use public standards such as Mitre ATLAS to validate the security and compliance of AI agents using its platform. Workday’s approach deals with security checks and not reliability scores, but the idea could potentially be tweaked. Expansion creates security concerns Carmi Levy, an independent technology analyst, was more skeptical about what Glasswing will ultimately be able to accomplish by adding 150 more participants. “The entire point of Project Glasswing was to allow Anthropic to work closely with a small, fully vetted group of vendors to develop stronger defenses against the cybersecurity risks posed by what was, and is, an entirely new LLM class that would otherwise pose unacceptable risks to existing protective technologies and protocols,” Levy said. “Expanding access into the hundreds may very well bring in more minds to build better defensive measures, but it simultaneously introduces significant concerns around potential leaks. And this from a company that has already reported two leaks involving this same model.” Levy added, “in an ideal world, Anthropic would announce alongside this major expansion a parallel effort to tighten internal security protocols to ensure the code doesn’t fall into the wrong hands. Bringing in a much larger cohort of researchers signals to potential attackers that they will soon have a larger pool of potential targets, and fails to allay fears of future breaches.” View the full article

US federal government departments have been given until Thursday to patch a two-year old high severity vulnerability in Oracle WebLogic Server that could allow an unauthenticated attacker to access critical data. The vulnerability, CVE-2024-21182, was added Monday to the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, giving federal Oracle admins a mere four days to plug the hole. Supported versions that are affected are 12.2.1.4.0 and 14.1.1.0.0. While the KEV is aimed at US federal departments, inclusion of a vulnerability on the list should be taken as a warning to the private sector as well. At the time it was discovered, this vulnerability was rated 7.3 on the CVSS scale, nowhere near the 9+ rating that many infosec pros would see as signaling a need for immediate attention. However, Robert Enderle, a consultant who heads the Enderle Group, said the inclusion of this vulnerability in the KEV now means that CISA has recently confirmed that threat actors are actively weaponizing it. “To make the CISA KEV means that we’re seeing active exploitations,” agreed Tyler Reguly, Fortra’s associate director of security R&D. “Given that this CVE was patched by Oracle in the July 2024 Critical Patch Update (CPU), I would expect most admins to have patched this by now, particularly since it is a WebLogic vulnerability and, prior to the addition of this CVE, there were already a dozen WebLogic vulnerabilities listed in the KEV catalog.” Older vulns under exploit Reguly also had an observation about how fast vulnerabilities are added to the KEV. Based on a cursory review, he figured only about 41% of CVEs in the list were added during the same year they were released. Looking at release year + 1, that goes up to about 58%. That still means that, surprisingly, more than 40% of the CVEs added to the CISA KEV catalog are added two or more years after they are released. “I suppose it makes sense that it [the two-year-old Oracle hole] is just popping up now, if you consider that an organization that hasn’t patched their systems in multiple years is likely an easier target than an organization that patches regularly. After all, regular patching probably implies a more security-conscious environment.” Asked for comment on why this vulnerability is being added two years after its discovery, a CISA spokesperson referred to the department’s webpage explaining criteria for including bugs in the catalog, which says the list is of vulnerabilities that have been exploited in the wild. The spokesperson didn’t answer a question about how many federal servers were still unpatched after so long. Oracle WebLogic Server is a unified and extensible platform for developing, deploying, and running enterprise applications in Java, on-premises and in the cloud. It’s fully supported on Kubernetes, and enables users to migrate and efficiently build modern container apps with comprehensive Java services. It short, it’s a vital piece of middleware that can host sensitive corporate data. Not surprisingly, threat actors are eager to exploit any vulnerabilities of this type. In 2019 it was reported that threat actors were scanning for WebLogic servers vulnerable to a new method of bypassing protections that Oracle had fixed the year before. Earlier this year, security firm CloudSek set up a honeypot to study threat actor response to a newly discovered and extremely serious WebLogic Server remote code execution vulnerability, CVE-2026-21962, with a CVSS score of 10, as well examining their interest in older holes. Over a 12 day period, attack attempts targeting the new zero day-like flaw were observed immediately following the public release of its exploit code, “demonstrating the rapid weaponization of critical Oracle WebLogic vulnerabilities.” Attackers also tried to exploit a flaw reported in 2017 and two 2020 vulnerabilities in the unpatched honeypot server that CloudSek created. Slow patching a ‘clear risk’ Given the importance of Oracle products to large enterprises, the company recently switched to a monthly security patch release cycle from quarterly. The first of these patches was released Monday. The recent addition of the WebLogic vulnerability to the KEV illustrates a common problem in how many organizations handle security, said Gene Moody, field CTO at Action1. “The issue is not just the vulnerability itself. The bigger problem is the delay between when a fix is released and when it is actually applied to real systems. That delay gives attackers a chance to act, while also signaling that the security practices of the target org may be under-enforced.” It takes on average around 60 days for organizations to apply patches, he pointed out. Meanwhile, attackers are building and using exploits in just hours or days. This gap creates a convenient window where unpatched systems become simple targets, he pointed out. In addition, systems suffering from vulnerabilities greater than a year in age are likely not silos in an otherwise well-managed vulnerability management plan. “Attackers pay close attention to how quickly patches are applied,” he said. “When a well-known fix is not widely used, it demonstrates more than just exposure. It can point to poor system tracking, weak patch processes, or other priorities taking focus away from security. These issues often mean there are more weaknesses beyond the one vulnerability.” Organizations should treat slow patching as a clear risk, Moody warned, not just a yet another task waiting to be done. To improve the situation, there needs to be better tracking of systems, clear patch timelines, and making sure that fixes are actually applied, not just planned. View the full article

HP has released patches for a critical buffer overflow vulnerability in multiple IP-enabled conference phones from its Poly Voice line. The flaw allows unauthenticated attackers to obtain root privileges on the underlying operating system, potentially enabling them to execute other attacks such as eavesdropping on conversations and recording voice data for AI-enabled impersonation attacks. The vulnerability, tracked as CVE-2026-0826, was discovered by researchers from security firm Rapid7 and resides in the code that parses Session Description Protocol (SDP) attributes when the Interactive Connectivity Establishment (ICE) feature is enabled. ICE enables VoIP devices to establish peer-to-peer connections using the shortest available network path. The feature is not enabled by default on HP Poly devices, and the company advises administrators to disable it if it’s not needed. The flaw, rated 9.2 on the CVSS severity scale, affects all phones from the HP Poly VVX series, as well as the Trio 8300, 8500, and 8800 IP conference devices. HP has fixed the flaw in its Poly Unified Communications Software (UCS) versions 6.4.8 for the VVX devices, 8.1.7 for the Trio 8300, and 7.2.8 for Trio 8500 and 8800. VoIP exploit is public for pen testing An exploit module targeting this vulnerability has already been developed and released for the widely used Metasploit penetration testing framework that’s maintained by Rapid7. The exploit executes code as root on an affected device with ICE enabled by sending a SIP INVITE request with a specially crafted candidate attribute. This attribute normally contains a transport address that can be used for connectivity checks and is part of the ICE RFC8839 standard. The buffer overflow bug is located in a helper function called ParseICECandidate in the polyapp binary that processes such requests on the device. “The start of the function contains a call to memcpy, which will copy the incoming string line being processed into a 256 byte stack buffer,” Stephen Fewer, senior principal security researcher at Rapid7, said in a blog post. “No length check is performed to ensure the incoming string length is less than 256 bytes. Therefore by providing a candidate attribute whose length is greater than 256 bytes, a stack-based buffer overflow will occur.” Address Space Layout Randomization (ASLR), a kernel feature that randomizes memory addresses to defeat buffer overflow exploits, is enabled on the device. However, the protection is not operating correctly on the HP Poly devices because it does not randomize the load addresses of .so (Shared Object) libraries. These libraries, such as libc, are loaded by other processes, including the polyapp process, and because their memory addresses never change, they can be leveraged to bypass ASLR and execute the attacker’s payload. “We create a ROP chain that will execute an arbitrary OS command via the system standard C library function,” Fewer said. “The accompanying Metasploit exploit modules source code details the entire ROP chain.” VoIP phones are attractive targets Attackers have increasingly targeted embedded devices inside enterprise networks in recent years because unlike laptops, workstations, and servers, these devices are not monitored by endpoint detection and response (EDR) products. As such, they provide perfect footholds inside corporate environments that allow attackers to remain undetected for long periods of time and attack other systems. In the age of AI these devices become even more relevant for attackers, going beyond corporate espionage by recording conversations or internal network pivoting. “Attackers no longer need massive datasets to make use of synthetic speech tooling,” Douglas McKee, Rapid7’s director of vulnerability intelligence, said in a blog post. “In many cases, they just need clean source audio of the right person saying enough words in enough contexts. That has made executive voice data, call recordings, and live conversation capture far more valuable than many organizations seem prepared to admit.” Attackers could collect audio and then use AI deepfakes to impersonate executives in calls to employees and business partners to authorize fraudulent transactions, gain access to sensitive systems, and more. “The concern is not just ‘someone might hear something confidential,’” McKee said. “That would be bad enough. The broader concern is that voice infrastructure can now support both traditional espionage objectives and modern AI-enabled fraud operations at the same time.” View the full article