CSOonline

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

Quantum technology may feel far off but certain risks are already with us in the form of “harvest now, decrypt later” — an attack vector in which malicious actors steal data now for a future in which they have access to quantum computational tools capable of breaking encryption deployed by most companies today to protect their data. Despite increasing discussion surrounding this issue, not all organizations are aware of the risk. According to a 2025 ISACA survey, only 5% of cyber professionals considered the threat a high priority, despite two-thirds being concerned about quantum’s future ability to break encryption. That 5% was the same percentage of organizations that had defined a strategy to prepare for the quantum threat, according to the survey’s findings. Contrary to the rhetoric of a “Q-Day” — a pivotal date on which classical cryptography will be broken by quantum computers — organizations such as the European think tank CEPS warn that this possibility will not arrive suddenly, but gradually. “We’ve been waiting for some time for something like a quantum computer, which will likely allow us to break traditional encryption systems in a seemingly simple way,” explains Félix Barrio, director general of Spanish national cybersecurity institute INCIBE, via video call. “Although this has been demonstrated theoretically and we haven’t yet seen computers with that capability, there are different estimates,” ranging from a few months to a decade. Barrio notes, however, that such computational power will probably only be available to a few entities, generally government agencies, given their high cost. The first three standards for post-quantum cryptography (PQC) encryption were published by the US National Institute of Standards and Technology (NIST) in 2024. “These are algorithms that could supposedly withstand a quantum attack using a quantum computer,” Barrio says. Currently, these algorithms are being tested and adapted to various technologies. Quantum key distribution (QKD) — a quantum-like system that could be applied to data transmission over cable, adapted fiber optic cable, or satellite — establishes an alternative key exchange system that, through properties of quantum physics, functions as an early warning mechanism in case of detected breaches or intrusions, enabling compromised keys to be discarded. The EU has already designed a roadmap for the transition to post-quantum cryptography, which sets the end of 2026 as the first phase for deploying these tools, with 2030 as the deadline for high-risk use cases and 2035 for the rest. Barrio explains that INCIBE has allocated part of the resources from its innovative public procurement program to advanced cryptography resistant to quantum attacks, funding five initiatives located in different cities in Spain. “In Spain, we have taken the lead in investing in this transition phase with the most promising projects we have identified in these public calls for proposals, and over these three years we have been working to ensure that test systems using Spanish technology can be offered and that these systems can also be commercialized,” he notes. “In Europe, in general, when you talk to other cybersecurity agencies, they are genuinely concerned.” Where the sector stands on quantum resilience “Today we take for granted that communications with our bank or healthcare systems are private, and that digital signatures — for example, those that support financial transactions or cryptocurrencies — are unforgeable. The impact of these guarantees becoming invalid is enormous, both economically and socially,” Alberto de Mercado, manager of systems engineering for service providers at Fortinet, tells Computerworld Spain via email. From a cybersecurity vendor’s perspective, De Mercado speaks of the need to “implement a phased transition strategy,” taking into account elements such as the type of information exchanged and its need for long-term confidentiality, available resources, compatibility with the existing architecture, and prioritization over other more immediate cybersecurity risks. “In this context, the concept of cryptoagility is key: deploying solutions that allow for the agile change or combination of cryptographic algorithms when necessary, guaranteeing service continuity without needing to completely redesign the architecture or change providers,” he says. De Mercado calls for “acting now” when dealing with sensitive information that must remain confidential long-term. “In these cases, waiting for absolute certainty means taking a risk that may be unacceptable,” he says, adding the regulatory factor: Although there is no explicit European regulation on the subject, it can be linked to regulations such as GDPR, NIS2, or DORA, which establish protection obligations, “without explicitly limiting the time frame.” “From this perspective, organizations that handle sensitive information long-term must begin to consider this risk as part of their security assessments,” he says, a trend that also applies to cybersecurity providers, “who are progressively incorporating quantum-safe algorithms and mechanisms into their products,” as is the case with Fortinet. Regarding current demand, De Mercado observes an initial trend toward PQC, “as it requires less investment and is easier to integrate into existing environments. QKD is reserved for very specific scenarios, such as highly sensitive interconnections between large headquarters or data centers.” Overall, he perceives an “uneven” level of concern, with the most regulated sectors or those with the highest confidentiality requirements at a more advanced stage of testing, transition planning, or even initial deployments of secure communications. “Generally, the more mature an organization is in cybersecurity, the better it is at mitigating immediate risks and the greater its capacity to anticipate emerging threats such as quantum computing,” he says. How to protect yourself From the banking sector, CaixaBank addresses the quantum threat “understanding that it is a real risk and, as such, must be managed proactively,” a company representative said via email. “The risk is already relevant, and it is necessary to have mitigation measures in place now,” the representative continued. “At the same time, the approach is not simply to replace one encryption algorithm with another, but to equip the bank with the necessary crypto agility to be able to rotate keys, change cryptographic models, or adopt new standards quickly and in a controlled manner when necessary. In this way, not only is this specific threat mitigated, but the bank’s resilience and preparedness for future technological changes are structurally strengthened.” The firm itself is already developing a comprehensive plan, currently under way, with 2029 as the target date for a robust crypto-agility model. This plan has two complementary dimensions. On the one hand, it includes the new PQC schemes, which the bank is currently analyzing to determine how they can be incorporated in an orderly fashion. “The goal is to ensure that the bank is technically prepared to protect both data in transit and data at rest, as these new standards reach the necessary maturity,” the bank’s representative said. But “the approach goes far beyond a one-off technological transition, taking the opportunity to build a structurally more robust, automated, and repeatable model that will allow for much greater agility in implementing any cryptographic changes in the future.” CaixaBank is also participating in European projects to validate practical post-quantum security solutions applicable to the financial sector, as well as in industry forums such as the Quantum Safe Financial Forum (QSFF), where they “share experiences, define best practices, and contribute to a transition that is realistic, interoperable, and aligned with the sector’s regulatory requirements,” according to the bank’s representative. With the quantum threat becoming increasingly prevalent, reviewing the cybersecurity model will soon be imperative for all companies. View the full article

ServiceNow is notifying customers after discovering and remediating a vulnerability that could have exposed data via an unauthenticated API endpoint on affected instances. The issue emerged publicly after customers began discussing security notifications from ServiceNow and reports of suspicious activity linked to their environments. According to the company’s advisory, the vulnerability was initially reported through ServiceNow’s bug bounty program in April, prompting an investigation and subsequent security updates. ServiceNow said hosted customers received a security update (KB3067321) on June 5, while guidance (KB3067372) was issued for self-hosted deployments. The flaw appears to have affected tenants running specific versions and configurations. Cory Michal, CISO at SaaS and AI security company AppOmni, said the issue involved “An unauthenticated, internet-facing ServiceNow API endpoint” that could be accessed without authentication when certain conditions were present. “In practical terms, anyone who knew the endpoint URL and how to structure the request could access data from the affected ServiceNow tenant without authenticating first,” Michal said. Because ServiceNow often stores IT service requests, employee information, and internal security data, unauthorized access to customer instances can pose significant risks to enterprises. The advisory said that suspicious activity highlighted in security notifications sent to customers can, so far, be linked to security researchers investigating the vulnerability. An API endpoint from a specific release was impacted While ServiceNow’s advisory offered few technical details about the vulnerability itself, customers discussing the issue on Reddit have mentioned the affected endpoint as “/api/now/related_list_edit/create,” an API that could allegedly be queried without authentication under certain circumstances. The API shipped with “requires_authentication = false”. The same discussions point to only ServiceNow’s Australia release being impacted, as ServiceNow reportedly told customers through private security notifications. This suggested that release-specific changes may have played a role in the exposure. However, customers were far from convinced that the issue was confined to a single release. Several participants speculated that older releases with particular configurations may also have been vulnerable. “Don’t assume you’re safe just because you’re on a different release,” one of them commented. Speaking of the impacted API, the user added, “That’s a config flag, not a release-specific code change. Worth pulling up your own instance’s Scripted REST API table and auditing any resources where that checkbox is unchecked, especially anything that hasn’t been touched since before 2022.” Researchers, attackers, or both? The important question surrounding the incident is whether the activity observed against affected ServiceNow environments was solely the work of security researchers or whether malicious actors may also have taken advantage of the flaw. ServiceNow confirmed that unauthorized access could all be attributed to research attempts. “We have reason to believe the observed activity can be attributed to security researchers or customers conducting their own research,” the company said, adding a “however”. “Our investigation is ongoing, however, and subject to additional validation.” Michal urged caution before assuming all observed activity was benign. “The attribution question is less clear,” he said. “At least one system publicly associated with exploitation of this vulnerability appears to have targeted tenants of other SaaS platforms with similar unauthenticated-access weaknesses. So while researcher activity clearly occurred, I would be cautious about saying all observed activity was benign research until the investigation is complete.” Customers urged to investigate, not just patch While ServiceNow says fixes and mitigations are available, Michal warns that applying updates should be only the first step. According to him, organizations should definitely verify that the June 5 security update has been applied or that recommended mitigations have been implemented for self-hosted deployments. Just as importantly, they should also examine historical logs for evidence of exploitation. “Review ServiceNow access and transaction logs for known IoC, unauthenticated requests to the affected API endpoint, and unusual table or field queries, ideally covering at least the last 90 days,” he said. “If suspicious activity is found, determine which data was accessed and treat it as an incident investigation, not just a patching exercise.” ServiceNow reassured customers that mitigations have been applied and that it continues to investigate the incident internally. “Based on our investigation to date, it appears that a subset of customer instances were queried successfully as part of this activity, and dedicated support cases have been created for impacted customers,” the company noted in its advisory. Associated activities from confirmed researcher IP addresses were investigated for possible sharing, using, or retention of data. Involved researchers reportedly told ServiceNow “they queried tables and fields only for purposes of validating their finding and submitting bug bounty reports.” View the full article

The future of reliability will not be defined by whether site reliability engineering (SRE) teams use AI agents, but by the conditions under which they choose to trust them. In high-stakes systems, trust is never granted because a demo looks impressive; it is earned through observability, constraints, accountability and repeated evidence that the system helps more than it harms. Right now, many teams are exploring AI for incident response, alert triage, root cause analysis and runbook automation because modern systems generate more context than humans can process quickly under pressure. That interest is justified. But the most mature SRE organizations understand something important: the real challenge is not building an agent that can act, it is building an operating model that people can trust in production. Trust is operational, not emotional SRE teams do not trust tools in the abstract. They trust behavior under stress. A platform earns credibility when it helps engineers make better decisions during noisy alerts, partial outages, failed deploys and ambiguous telemetry, not when it generates polished answers in ideal conditions . That is why generic AI often falls short in production. It may be fluent, but fluency is not reliability. Live systems demand awareness of ownership, dependency maps, escalation paths, blast radius and policy boundaries, and without that context an AI agent can sound helpful while being operationally dangerous . For SRE teams, trust starts when the agent proves it understands the system it is operating around. The trust ladder Neel Shah Teams do not move directly from experimentation to autonomy. They move up a ladder of trust, where each step is validated in production-like conditions before the next one is allowed. The 1st requirement: Grounded observability Before teams trust an AI agent, they need a telemetry foundation that the agent can actually reason over. If logs are incomplete, traces are missing, ownership is unclear and deployment metadata is scattered across tools, the agent will not become intelligent by magic. It will simply become confidently under-informed. This is why observability is the real prerequisite for agentic SRE. The strongest AI SRE approaches are grounded in correlated metrics, logs, traces, changes and incident history so that recommendations are evidence-backed rather than speculative. An AI agent cannot create operational truth; it can only synthesize the truth your systems already expose. In practice, that means teams need more than dashboards. They need clean service ownership, change tracking, incident timelines, runbooks and enough signal quality that an agent can distinguish a symptom from a cause. Without that groundwork, the AI layer becomes theatre What grounded observability looks like Neel Shah Monitoring tells you that something is wrong, while observability helps explain why. AI becomes useful only when it sits on top of both layers, not instead of them. The 2nd requirement: Clear guardrails The fastest way to lose trust in AI is to give it authority before defining its boundaries. In operations, the question is not “Can the agent do this?” but “Under what conditions should it be allowed to do this, and who is accountable if it is wrong?” This is where guardrails matter. Strong SRE teams want explicit permission models, approval gates, action allowlists, audit trails and rollback paths before an agent touches anything meaningful in production. That may sound restrictive, but it is exactly what makes adoption viable. Constraint is not the enemy of agentic systems; constraint is what makes them usable. The most practical path is progressive autonomy. Let the agent start by summarizing incidents, correlating changes and suggesting next steps. Then move to read-only diagnostics. Only after consistent success should it be allowed to trigger low-risk automation, and even then, within tightly defined policies. Trust grows when the blast radius stays small. Visual: Progressive autonomy model StageAgent roleRisk levelHuman involvementStage 1Summarize alerts and incidentsLowHuman reviews output [cite:8]Stage 2Pull telemetry and correlate changesLow to mediumHuman approves decisions [cite:41][cite:52]Stage 3Recommend remediation actionsMediumHuman confirms action [cite:42][cite:43]Stage 4Execute pre-approved low-risk actionsMediumHuman supervises and can override [cite:44][cite:52]Stage 5Broad autonomous actionHighRarely acceptable without strict policy controls [cite:43][cite:54] The 3rd requirement: Human-in-the-loop design SRE teams are not looking for an AI replacement. They are looking for leverage. The most credible operating model is not autonomous-by-default but supervised-by-design, where agents accelerate understanding and execution while humans retain judgment over risk, trade-offs and unusual conditions . That distinction matters because incidents are rarely just technical events. They involve business impact, customer communication, cross-team coordination and decisions shaped by context that may not exist in telemetry alone . An agent can help identify a likely bad deploy, but it cannot fully own the decision about whether to roll back during a major customer launch without broader situational awareness. Human-in-the-loop does not mean slowing everything down. It means designing different levels of oversight for different classes of action. Low-risk tasks such as drafting an incident summary or pulling related dashboards may be automatic. Restarting a background worker might require lightweight approval. Disabling a core production dependency should remain firmly human-controlled . Mature trust comes from matching autonomy to risk. The 4th requirement: Explainability over magic SRE teams will not trust an agent that gives answers without showing its work. In reliability engineering, a recommendation is only as useful as the evidence behind it. Engineers need to know which metrics changed, which deployment correlated with the issue, which logs support the hypothesis and how confident the system actually is. This is one of the biggest lessons emerging from operational AI systems. Precision matters but trust also depends on whether humans can inspect the reasoning path, challenge it and understand uncertainty in familiar terms . The best agent experiences feel less like oracles and more like disciplined collaborators: they surface context, rank hypotheses and make clear what they know versus what they infer . That is especially important because AI failure in SRE is rarely dramatic at first. It often starts as subtle overconfidence. The agent sounds convincing, the team moves faster and only later does it become clear that the recommendation was based on incomplete evidence. Explainability is what keeps speed from turning into hidden fragility. The 5th requirement: Evaluation in real incidents Trust cannot be built on benchmarks alone. SRE teams need evidence from scenarios that resemble their actual world: noisy alerts, incomplete data, conflicting symptoms, repeated incidents and multi-service failures . This is why post-incident evaluation is becoming one of the most important practices in AI-assisted operations. Some of the most interesting approaches focus on replaying past incidents and measuring how the AI would have performed once the real outcome is already known . That creates a concrete way to score whether the agent identified the right signals, prioritized the right hypotheses or recommended safe and useful next steps. It also shifts the conversation from hype to measurable reliability impact. For SRE leaders, this is a critical mindset change. Do not ask whether the agent is impressive. Ask whether it consistently shortens investigation time, reduces false escalation, improves documentation quality and avoids introducing new operational risk . Trust follows evidence, not enthusiasm. The 6th requirement: Fit with existing workflows One reason some AI initiatives fail inside engineering teams is that they force a new workflow instead of strengthening the one that already works. SRE teams already have paging tools, Slack channels, dashboards, escalation policies and runbooks. An AI agent earns trust faster when it respects those patterns rather than trying to replace them all at once. This is where incremental adoption becomes strategic. If the agent can appear in the incident channel, pull context from observability tools, draft timelines and recommend actions inside the systems engineers already trust, the barrier to adoption drops sharply. The agent becomes part of the response loop rather than another platform demanding attention during an outage. That compatibility matters culturally as much as technically. SRE is built on disciplined operational habits. Tools that complement those habits can gain traction. Tools that disrupt them without providing value usually get ignored after the first few frustrating incidents. If you need a more detailed guide to keep points while evaluating AI SRE tools, then check this buyer’s guide by one of the senior leaders. What trust looks like in practice When an SRE team truly trusts an AI agent, several things are visible. The team does not treat it as a novelty. They treat it as a bounded operational partner. They know where it adds value, where it must ask for approval and where it should stay out of the way. Trust also changes behavior. Engineers stop wasting the first 10 minutes of an incident assembling basic context because the agent already did that well. Incident channels become more structured because summaries, timelines and likely causes are surfaced early. Runbooks improve because teams start writing them in ways both humans and machines can execute or reference . In that environment, AI is not replacing rigor. It is reinforcing it. Most importantly, trusted AI agents reduce toil without eroding accountability. The on-call engineer is still responsible. The incident commander is still responsible. The organization still owns the reliability posture. The agent simply helps the system operate with more speed and clarity. The leadership shift behind all of this This is why the conversation about AI agents in SRE is ultimately a leadership question, not just a tooling question. Teams do not need another shiny automation layer. They need a clear philosophy for how autonomy, human judgment, safety and reliability will work together. The most forward-looking SRE leaders will not ask, “How quickly can we automate incident response?” They will ask, “What conditions must be true before our engineers feel safe delegating part of this workflow to a machine?” That is a much better question because it forces investment in the real foundations: observability, governance, evidence, workflow design and measurable trust. AI agents may become standard in reliability engineering over the next few years, but standard does not mean automatic. The teams that benefit most will be the ones that treat trust as infrastructure. They will build it deliberately, test it relentlessly and expand autonomy only where the evidence justifies it. Closing thought Before SRE teams trust AI agents, they need more than a capable model. They need grounded telemetry, explicit guardrails, human-centered workflow design, explainable reasoning, rigorous evaluation and operational fit with the systems they already rely on. Only then does the promise of agentic SRE become credible. That is the real frontier. Not autonomous operations for their own sake, but reliable collaboration between humans and intelligent systems. In the end, SRE teams will trust AI agents for the same reason they trust any production system: because it behaves predictably, shows its work, respects constraints and makes the organization more resilient when it matters most . This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

A botnet made up of compromised small office and Internet of Things devices has grown into a larger reconnaissance network capable of rapidly identifying vulnerable internet-facing systems after public vulnerability disclosures, researchers said. The botnet, tracked by Lumen’s Black LotusLabs as JDY, now comprises more than 1,500 compromised small office and home office, or SOHO, and IoT devices, and is being used to “discover, fingerprint and continuously map exposed services at scale.” Lumen said the activity is linked to Chinese nation-state-backed actors, including Volt Typhoon. The findings point to a growing challenge for enterprise security teams. Many enterprise edge systems remain outside traditional endpoint monitoring, giving adversaries room to move quickly from vulnerability disclosure to targeted reconnaissance. Lumen added that JDY’s distributed infrastructure can also help operators evade geofencing and other IP-based defenses because the activity may appear to come from legitimate residential or small-business internet traffic. JDY undermines several defensive assumptions that many enterprises still rely on, according to Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services. Geofencing and IP reputation controls have limited value when used in isolation, Grover said, while static blocklists are structurally weak against botnets that continuously rotate compromised infrastructure. JDY also exposes a broader visibility gap around edge devices, which are often difficult for enterprises to monitor with the same rigor as endpoints and cloud workloads. Reconnaissance moves closer to attack Analysts said that CISOs should not dismiss JDY as just another botnet. “The reported JDY activity shows a clear focus on discovering, fingerprinting, and continuously mapping exposed services at scale, including shortly after public vulnerability disclosures,” Grover said. “That points to a more industrialized model of pre-exploitation reconnaissance, where compromised edge devices are used not merely for disruption or commodity abuse, but to generate timely targeting intelligence for follow-on operations.” That means the compromised SOHO and IoT devices may not be the final target. Instead, they provide the scanning layer used to identify exposed enterprise infrastructure, including routers, firewalls, VPNs, cameras, and other internet-facing systems. Devashri Datta, a cybersecurity researcher, said CISOs should treat JDY as evidence of a shift in how reconnaissance is being operationalized. “If JDY is sitting in your risk register under ‘routine botnet management’, your defensive playbook will fail before it starts,” Datta said. “JDY isn’t designed to DDoS anyone, steal credentials, or mine cryptocurrency. It is a centrally controlled, high-performance scanning engine.” Patch timelines come under pressure The scanning activity also raises questions about whether conventional vulnerability management timelines are still workable for perimeter systems exposed to the internet. “Traditional SLA-driven patching is no longer defensible for perimeter devices,” Datta said. The size of the botnet matters less than the speed of its targeting cycle, according to Sanchit Vir Gogia, chief analyst at Greyhound Research. “Fifteen hundred devices that find the right vulnerable systems within hours are worth more than a hundred thousand generating noise,” Gogia said. “Exploitation no longer begins when malicious code arrives. It begins when exposure is discovered.” The concern is that JDY may already have collected much of the information attackers need before a new vulnerability is disclosed. Datta said the botnet’s reconnaissance can include IP addresses, port configurations, protocol information, service banners, TLS versions, certificate metadata, and associated domains. That gives operators a head start when a critical flaw becomes public. Lumen said Black Lotus Labs observed a selective increase in scans of Fortinet equipment shortly after the disclosure of CVE-2026-35616, indicating the ability and intent to identify vulnerable devices before patches are widely applied. For CISOs, Datta said, the response requires pre-approved playbooks for perimeter devices, including accelerated patching, access control list changes, temporary disabling of exposed features, and lockdown of management interfaces. View the full article

The advent of Claude Mythos combined with the release of OpenAI’s GPT-5.5 have changed the threat model for CISOs. The arrival of those frontier AI models — and the ones soon to follow — makes it much easier to discover and chain vulnerabilities at a speed and scale that will require most cyber departments to rethink their strategies and operations. Experts polled by CSO on the impact of these capabilities say defenders should assume AI will make initial compromise more likely and that they should focus less on trying to patch everything perfectly and more on limiting blast radius through stronger identity controls, least privilege, and internal segmentation. Wild frontier Although access to Mythos remains restricted to a limited number of trusted partners, comparable AI-based vulnerability discovery platforms are in the works, and few experts think access to sufficiently capable AI models will be kept from attackers for long. Anthropic itself has now released to the public the “Mythos-class” Fable 5 AI model, with extra cybersecurity guardrails. Noe Ramos, vice president of AI operations at Agiloft, says CISOs should operate on the assumption that attackers will get access to frontier AI-style capabilities within months if not sooner. “Whether through jailbreaks, fine-tuned open-weight derivatives, or purpose-built black-hat versions, determined threat actors are resourceful and motivated,” says Ramos. “Frontier AI capabilities tend to diffuse faster than the security community expects and slower than the headlines suggest. Defenders should plan for the former.” Rather than jailbreaking frontier models it is more likely that attackers will gain access to capable vulnerability discovery platforms by fine-tuning open-weight models on offensive security data and running them locally. “We see people out there that are starting to work on replicating the results of Mythos with existing infrastructure and open source models that they don’t have to run through the clouds,” Martin Roesch, lead developer of the Snort intrusion detection system turned head of cloud at AI-driven security company Vectra AI, tells CSO. “This kind of industrial-scale vulnerability discovery and potential exploit generation is not something that most of the world is really prepared for in terms of the downstream implications of the effects that it’ll have on the defendability of organizations,” Roesch concludes. Will Barker, cybersecurity advisor at managed detection and response vendor Huntress, agrees that research is showing that AI-driven vulnerability discovery is no longer something only frontier models can do. “Smaller open-weights models are already finding the same types of zero-days and exploit chains,” says Barker. These findings imply that the model itself is not always the biggest differentiator. “The real value comes from everything around it: how the work is orchestrated, how findings are validated, how noise is filtered, and how quickly humans can turn those findings into action,” Barker says. Vulnerability discovery compressed A junior security researcher with API access to a frontier model can find vulnerabilities without the reverse-engineering work that used to take an experienced team. “Logic flaws are where this hits hardest,” says Nik Kale, principal engineer and member of the Coalition for Secure AI (CoSAI). “Traditional scanners never caught them well because the code isn’t broken, just strategically wrong. A frontier LLM reads a hardcoded trust assumption like it’s reading a paragraph. That’s the gap that opened, and it isn’t closing.” Frontier AI has meaningfully compressed discovery time for well-understood vulnerability classes: SQL injection variants, common misconfigurations, things that pattern-match against known CVEs. Raphael Peyret, a former product manager at Google turned startup advisor at SHA/RP, argues that the barrier to creating a reliable exploit from a vulnerability has been lowered rather than removed. “In many cases, finding the weakness is no longer the bottleneck,” says Peyret. “But novel zero-days in hardened targets are a genuinely different problem, and that still takes human expertise.” Matthew Bidwell, founder at Newzino.com, backs up this assessment. “The binding constraint for attackers has shifted from finding bugs to operationalizing them: turning a hypothetical flaw into a working exploit, chaining it against a real target, evading detection, [and] persisting,” he says. The more meaningful shift in the vulnerability discovery landscape is economic rather than technical, according to several experts. “Attackers are running roughly the same playbook they always ran,” Peyret notes. “What’s changed is the unit cost of running a credible campaign, and it’s dropped substantially.” Other experts agreed that AI is turning vulnerability discovery from a scarce human craft into a scalable computational problem. “Mythos-class systems compress reconnaissance, target triage, payload customization, and social engineering into minutes,” says Noah M. Kenney, founder and principal consultant at Digital 520. “Jailbreaks and black-hat forks will happen, but the bigger risk is legitimate enterprise AI being turned against the enterprise that deployed it.” Attackers do not need Mythos itself; they need Mythos-like vulnerability discovery workflows, says Mudit Sinha, AI Lead at Lineaje. “Mythos may be expensive and restricted today, but the gap is closing fast through frontier models, specialized cyber models, and black-hat harnesses around general-purpose AI,” he says. Exploit pathways The historical bottleneck in offensive cyber operations was finding novel weaknesses. AI-native cyber systems are automating code reasoning, attack-path identification, and variant analysis at machine speed, according to Kai CISO Alfredo Hickman. “The constraint is shifting from ‘Can we find bugs?’ to ‘Can we reliably weaponize and scale them?’” he says. Louis Leung, a software developer and co-founder at InFlow Inventory, believes attackers’ real challenge remains turning a discovered weakness into a stable, stealthy, repeatable capability that survives modern defensive controls and produces operational impact. “The hard part is turning the bug into a stable working exploit that functions across real-world production environments, which come with modern defenses, monitoring, and patching solutions,” he says. “Attackers increasingly need to chain multiple weaknesses together in SaaS environments — like inventory and warehouse systems — more than they need to identify the first point of weakness.” Still, frontier AI models are likely to accelerate the ability to chain those weaknesses together, said Jon Yeoh, chief scientific officer at the Cloud Security Alliance, at the recent CSO Cybersecurity Awards and Conference. “We’re looking at taking like maybe three or four CVEs that were very low-level and chaining those to become something that’s high or critical,” he said. “That’s something we haven’t seen — just what the models themselves do with a simple prompt.” Opening Pandora’s Box Independent security experts were keen to avoid blaming Anthropic for opening a Pandora’s Box full of vulnerability discoveries, however. “I do think Anthropic is trying to do the right thing by getting organizations involved early, letting them battle-test, harden, and build some understanding of what this looks like in the wild before it’s widely available,” says Melissa Bischoping, head of threat research and intelligence at Tanium. “It’s not a perfect solution, but the spirit and intent are well-placed.” Bischoping, a SANS Technology Institute board member, warns that there are concerns whether organizational change control can move fast enough to action what Mythos finds before Mythos is out in the wild. “Agentic patch workflows are possible and can match pace with adversarial AI in a lot of cases, but [organizational] politics and change control don’t run at the speed of AI today,” says Bischoping. Countermeasures For defenders, the answer to the challenge posed by frontier AI models is faster vulnerability remediation. “Security teams need to stop treating vulnerability discovery as the hard part and start fixing aggressively,” argues Lineaje’s Sinha. “Known CVEs are the easiest place to begin: prioritize, validate exploitability, patch, test, and verify continuously. The same frontier models that can detect vulnerabilities often have some capacity to remediate them, but they need a harness around them: asset context, SBOMs, exploitability validation, patch generation, CI/CD checks, sandboxed testing, and human approval for risky changes.” AI Operations’ Ramos adds: “If AI surfaces vulnerabilities at a rate that outpaces human remediation, and Mythos suggests it will, then the strategic priority has to shift toward containment and resilience.” “Assume breach. Shrink blast radius,” Ramos concludes. View the full article

The advent of Claude Mythos combined with the release of OpenAI’s GPT-5.5 have changed the threat model for CISOs. The arrival of those frontier AI models — and the ones soon to follow — makes it much easier to discover and chain vulnerabilities at a speed and scale that will require most cyber departments to rethink their strategies and operations. Experts polled by CSO on the impact of these capabilities say defenders should assume AI will make initial compromise more likely and that they should focus less on trying to patch everything perfectly and more on limiting blast radius through stronger identity controls, least privilege, and internal segmentation. Wild frontier Although access to Mythos remains restricted to a limited number of trusted partners, comparable AI-based vulnerability discovery platforms are in the works, and few experts think access to sufficiently capable AI models will be kept from attackers for long. Anthropic itself has now released to the public the “Mythos-class” Fable 5 AI model, with extra cybersecurity guardrails. Noe Ramos, vice president of AI operations at Agiloft, says CISOs should operate on the assumption that attackers will get access to frontier AI-style capabilities within months if not sooner. “Whether through jailbreaks, fine-tuned open-weight derivatives, or purpose-built black-hat versions, determined threat actors are resourceful and motivated,” says Ramos. “Frontier AI capabilities tend to diffuse faster than the security community expects and slower than the headlines suggest. Defenders should plan for the former.” Rather than jailbreaking frontier models it is more likely that attackers will gain access to capable vulnerability discovery platforms by fine-tuning open-weight models on offensive security data and running them locally. “We see people out there that are starting to work on replicating the results of Mythos with existing infrastructure and open source models that they don’t have to run through the clouds,” Martin Roesch, lead developer of the Snort intrusion detection system turned head of cloud at security startup Vectra AI, tells CSO. “This kind of industrial-scale vulnerability discovery and potential exploit generation is not something that most of the world is really prepared for in terms of the downstream implications of the effects that it’ll have on the defendability of organizations,” Roesch concludes. Will Barker, cybersecurity advisor at managed detection and response vendor Huntress, agrees that research is showing that AI-driven vulnerability discovery is no longer something only frontier models can do. “Smaller open-weights models are already finding the same types of zero-days and exploit chains,” says Barker. These findings imply that the model itself is not always the biggest differentiator. “The real value comes from everything around it: how the work is orchestrated, how findings are validated, how noise is filtered, and how quickly humans can turn those findings into action,” Barker says. Vulnerability discovery compressed A junior security researcher with API access to a frontier model can find vulnerabilities without the reverse-engineering work that used to take an experienced team. “Logic flaws are where this hits hardest,” says Nik Kale, principal engineer and member of the Coalition for Secure AI (CoSAI). “Traditional scanners never caught them well because the code isn’t broken, just strategically wrong. A frontier LLM reads a hardcoded trust assumption like it’s reading a paragraph. That’s the gap that opened, and it isn’t closing.” Frontier AI has meaningfully compressed discovery time for well-understood vulnerability classes: SQL injection variants, common misconfigurations, things that pattern-match against known CVEs. Raphael Peyret, a former product manager at Google turned startup advisor at SHA/RP, argues that the barrier to creating a reliable exploit from a vulnerability has been lowered rather than removed. “In many cases, finding the weakness is no longer the bottleneck,” says Peyret. “But novel zero-days in hardened targets are a genuinely different problem, and that still takes human expertise.” Matthew Bidwell, founder at Newzino.com, backs up this assessment. “The binding constraint for attackers has shifted from finding bugs to operationalizing them: turning a hypothetical flaw into a working exploit, chaining it against a real target, evading detection, [and] persisting,” he says. The more meaningful shift in the vulnerability discovery landscape is economic rather than technical, according to several experts. “Attackers are running roughly the same playbook they always ran,” Peyret notes. “What’s changed is the unit cost of running a credible campaign, and it’s dropped substantially.” Other experts agreed that AI is turning vulnerability discovery from a scarce human craft into a scalable computational problem. “Mythos-class systems compress reconnaissance, target triage, payload customization, and social engineering into minutes,” says Noah M. Kenney, founder and principal consultant at Digital 520. “Jailbreaks and black-hat forks will happen, but the bigger risk is legitimate enterprise AI being turned against the enterprise that deployed it.” Attackers do not need Mythos itself; they need Mythos-like vulnerability discovery workflows, says Mudit Sinha, AI Lead at Lineaje. “Mythos may be expensive and restricted today, but the gap is closing fast through frontier models, specialized cyber models, and black-hat harnesses around general-purpose AI,” he says. Exploit pathways The historical bottleneck in offensive cyber operations was finding novel weaknesses. AI-native cyber systems are automating code reasoning, attack-path identification, and variant analysis at machine speed, according to Kai CISO Alfredo Hickman. “The constraint is shifting from ‘Can we find bugs?’ to ‘Can we reliably weaponize and scale them?’” he says. Louis Leung, a software developer and co-founder at InFlow Inventory, believes attackers’ real challenge remains turning a discovered weakness into a stable, stealthy, repeatable capability that survives modern defensive controls and produces operational impact. “The hard part is turning the bug into a stable working exploit that functions across real-world production environments, which come with modern defenses, monitoring, and patching solutions,” he says. “Attackers increasingly need to chain multiple weaknesses together in SaaS environments — like inventory and warehouse systems — more than they need to identify the first point of weakness.” Still, frontier AI models are likely to accelerate the ability to chain those weaknesses together, said Jon Yeoh, chief scientific officer at the Cloud Security Alliance, at the recent CSO Cybersecurity Awards and Conference. “We’re looking at taking like maybe three or four CVEs that were very low-level and chaining those to become something that’s high or critical,” he said. “That’s something we haven’t seen — just what the models themselves do with a simple prompt.” Opening Pandora’s Box Independent security experts were keen to avoid blaming Anthropic for opening a Pandora’s Box full of vulnerability discoveries, however. “I do think Anthropic is trying to do the right thing by getting organizations involved early, letting them battle-test, harden, and build some understanding of what this looks like in the wild before it’s widely available,” says Melissa Bischoping, senior director of security and product design research at Tanium. “It’s not a perfect solution, but the spirit and intent are well-placed.” Bischoping, a SANS Technology Institute board member, warns that there are concerns whether organizational change control can move fast enough to action what Mythos finds before Mythos is out in the wild. “Agentic patch workflows are possible and can match pace with adversarial AI in a lot of cases, but [organizational] politics and change control don’t run at the speed of AI today,” says Bischoping. Countermeasures For defenders, the answer to the challenge posed by frontier AI models is faster vulnerability remediation. “Security teams need to stop treating vulnerability discovery as the hard part and start fixing aggressively,” argues Lineaje’s Sinha. “Known CVEs are the easiest place to begin: prioritize, validate exploitability, patch, test, and verify continuously. The same frontier models that can detect vulnerabilities often have some capacity to remediate them, but they need a harness around them: asset context, SBOMs, exploitability validation, patch generation, CI/CD checks, sandboxed testing, and human approval for risky changes.” AI Operations’ Ramos adds: “If AI surfaces vulnerabilities at a rate that outpaces human remediation, and Mythos suggests it will, then the strategic priority has to shift toward containment and resilience.” “Assume breach. Shrink blast radius,” Ramos concludes. View the full article

I’ve spent the past two years working on incident response and threat intelligence, and the pattern I’m about to describe is one I keep seeing show up in cases that should have been caught at the email gateway. The kit families change. The lure templates change. The constant is that phishing-as-a-service operators are buying aged legitimate domains and redeploying them to steal credentials from enterprise and government targets. The most recent incident I worked involved a Sneaky2FA deployment running on 117 origin servers in Kansas City, Missouri, split across two hosting providers. The operator has been on the same infrastructure for over two years and runs lures against a mix of UK and US government, energy companies and US healthcare SMBs. The aged-domain tradecraft I’m about to walk through is one way this operator stays inside enterprise environments that should be filtering them out. The certificate transparency logs tell the whole story, and they explain why the reputation classifier didn’t catch it. How age-weighted reputation became the blind spot Most enterprise mail filters from major vendors, including Microsoft Defender for Office 365, Proofpoint, Mimecast and Cisco Talos, factor domain age heavily into their classification decisions. A freshly registered .com triggers immediate reputation penalties. A domain with years of stable hosting, consistent certificate issuance and clean DNS history gets treated as low risk. The logic made sense ten years ago, when newly minted abuse domains dominated phishing infrastructure and aged domains usually meant established small businesses. I work with several enterprise environments that pay for the most expensive tiers of email security and still see phishing lures land in users’ inboxes. When I trace those lures back to their parent domains, an increasing percentage show the same pattern. Long-stable cert history through some point in 2024 or 2025. A several-month gap with no new certs issued. Then certs start appearing again for subdomains that have nothing to do with the original brand. The reputation score on these domains is high. The infrastructure behind them is criminal. The filter doesn’t know the difference. What aged-domain acquisition actually looks like There are two reasonable ways for an operator to acquire an aged domain. They can drop-catch an expired registration, or they can hijack an active one through credential theft against the owner’s registrar account. Drop-catching is cheaper and lower-risk. Services like DropCatch, SnapNames and GoDaddy Auctions exist precisely to acquire domains the moment they expire, and a determined operator can pay $50 to $500 for a domain with a decade of clean history. The domain I want to walk through is one I documented in detail during the Sneaky2FA case: digitalscrapbookingfreebies.com. The certificate transparency record shows the takeover in full. From 2016 through July 2025, the cert history reads like a normal small-business cPanel-hosted blog. cPanel Inc. issued ECC certs every 60 to 90 days for the standard cpanel., mail., webdisk. and webmail. subdomains. Let’s Encrypt R3 issued certs for the apex and www. every 90 days. The subjects stayed stable across nine years. Someone was running a hobby blog providing free scrapbooking assets to a small audience, and the cert pattern reflects that. In April 2025, GoDaddy certs appear in the record. A new certificate authority showing up after eight uninterrupted years of cPanel-plus-Let’s-Encrypt is the first hard signal that something changed at the registrar or hosting level. By July 2025, the last legitimate-pattern cert will be issued. Then six months of silence, no new certs, no renewals. In December 2025, fresh Let’s Encrypt R13 certs surfaced for subdomains the original blog never had: beds, footboard, haushafin and locklear. By January 2026, another subdomain appeared: nativems-mfl09093004.digitalscrapbookingfreebies.com. That subdomain was the one I caught being actively used in phishing against a US state health agency. The original owner of the scrapbooking blog is almost certainly a victim, too. They probably let the registration lapse, the operator drop-caught it and the domain entered criminal use under a privacy WHOIS that obscures the new ownership. Their nine years of reputation-building goodwill now serve as a credential-theft operation. What made this case generalizable is that the same operator also runs a second-tier-2 lure domain acquired through fresh registration. The two strategies serve different targeting profiles. The operator uses fresh registrations when the subdomain itself can carry the credibility, like an SSO-themed subdomain mimicking a corporate authentication endpoint where the parent domain isn’t doing much work. The operator uses aged-domain acquisitions when the domain reputation itself has to do the work, when the lure is going through an enterprise mail filter that scores by age. The selection is contextual. Why your reputation classifier won’t catch this Reputation scoring assumes that domain history reflects domain ownership. When ownership transfers through drop-catch or hijack, that assumption breaks. The score doesn’t reset. The new operator inherits the trust without inheriting any of the work that built it. Most reputation systems also weigh the length of clean history more heavily than recent changes to ownership patterns, which makes the problem worse. A nine-year-old domain that changes hands quietly stays scored as a nine-year-old domain. The signals that would actually catch the takeover (a CA issuer change, a six-month cert gap, a sudden wordlist of new subdomains that has nothing to do with the original brand) aren’t features in most age-weighted classifiers. A better detection approach has to weigh hosting-pattern stability. A domain whose hosting infrastructure changes abruptly is more suspicious than a domain whose pattern continues uninterrupted, and the events you want to fire on are concrete: a new CA appearing after years of stable issuance, a gap in cert renewals followed by new issuance or a CDN change with no legitimate ownership reason. Most reputation systems don’t track any of this because the score is a single number rather than a stability metric. Subdomain wordlist anomaly is the second axis. When a long-stable domain about scrapbooking suddenly issues certs for a subdomain named nativems-mfl09093004, the disconnect between the original brand and the new naming is detectable behaviorally, even when every other signal fails. The third piece is certificate transparency monitoring. CT logs are public, queryable and updated within hours. I reconstructed the entire digitalscrapbookingfreebies.com takeover timeline from public CT data alone. No commercial threat feed was required. Security teams who subscribe to CT log feeds for their blocklist candidates can surface operator-deployed subdomains within hours of issuance, which is often well before they show up in any commercial threat feed. If I were running enterprise email security tomorrow, the first thing I’d change is to stop treating domain age as a primary signal. Aged-domain acquisition is documented tradecraft now. Sekoia has surfaced it. Centripetal has surfaced it. My own research on this Sneaky2FA case adds another example. Any reputation system that weights age heavily has a known bypass, which means age should be one signal among several, not the dominant one. The detection logic that does work is the one I described above: hosting-pattern stability, subdomain wordlist anomaly and CT log monitoring. A nine-year-old hobby blog suddenly hosting Microsoft-themed authentication pages is detectable behaviorally, even when domain age fails the analyst. Several CTI vendors are starting to surface this as a capability. Ask yours where they are on it and get a real answer, not a marketing one. CT log monitoring is cheap and surfaces operator infrastructure within hours of issuance, which is one of the higher leverage moves a small security team can make. The operators figured out the blind spot. They’re going to keep buying aged domains for as long as those domains keep working. Closing the gap doesn’t take a new product line. It takes treating the signals we already collect with appropriate weight. The full research from the Sneaky2FA case, including methodology, IOCs and the detection rules I wrote, is available on my GitHub. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security teams’ patching practices have come under intense pressure over the past year, as active exploitation is up, time-to-exploit windows are accelerating, and vulnerabilities have become attackers’ top initial access vector of choice. Last year, organizations fully remediated only 26% of the vulnerabilities that attackers were actively exploiting in the wild — down from 38% the year before, according to Verizon’s 2026 Data Breach Investigations Report. The median time to close those known dangerous gaps stretched to 43 days, while attackers have trimmed their side of the equation to days, sometimes hours. That’s the backdrop against which the US Cybersecurity and Infrastructure Security Agency issued Binding Operational Directive 26-04. The directive reflects growing recognition that patching based primarily on severity scores is no longer sufficient in an AI-driven environment where defenders face more vulnerabilities than they can realistically remediate at once. During a media briefing announcing the directive, Chris Butera, acting executive assistant director for cybersecurity at CISA, described the initiative as the culmination of more than a decade of lessons learned from federal vulnerability management programs, adversary activity, and the agency’s growing understanding of AI’s impact on cyber operations. “Prioritizing IT and security operations attention on the most at-risk assets is particularly important now given advancements in artificial intelligence, which allow threat actors to find and exploit vulnerabilities in these assets,” Butera said. “Defenders cannot afford to take weeks to patch systems that can be autonomously exploited en masse.” In a companion blog post, Butera and Jonathan Spring, CISA’s senior technical advisor, argue that defenders are struggling to keep pace with a rapidly growing volume of vulnerabilities. AI is assisting researchers and adversaries in identifying flaws in software, vastly increasing the pace at which new vulnerabilities are discovered and forcing organizations to rethink how they prioritize remediation efforts. Butera and Spring argue that defenders need greater clarity and speed when deciding what to patch. Their prescription: patch smarter, not harder. Beyond CVSS: Why severity scores are no longer enough The directive builds on CISA’s Known Exploited Vulnerabilities program, which already identifies vulnerabilities actively being abused by attackers. But BOD 26-04 goes further by introducing a decision framework that considers four key factors: whether the vulnerable system is publicly exposed to the internet, whether the vulnerability is listed in the KEV catalog, whether an attacker can automate exploitation, and how much control an attacker would gain after exploitation. During the briefing, Butera said those four characteristics — public exposure, known exploitation, exploit automation, and post-exploitation impact — represent the conditions most closely associated with meaningful risk to federal systems. Vulnerabilities exhibiting three or more of those attributes must be patched within three days, while lower-risk vulnerabilities can be addressed on longer timelines or, in some cases, deferred until the next major system upgrade. The change reflects a broader shift in how security practitioners think about vulnerability management. For years, organizations have relied heavily on severity scores such as CVSS to determine patching priorities. But those scores often fail to predict whether attackers will actually exploit a flaw. “The directive used to be based on just severity score, which we as an industry have come to find is not a good predictor of exploitation,” Sasha Romanosky, a senior cybersecurity policy researcher at RAND, tells CSO. “This BoD looks to be updated to account for both impact and exploitation, which I think is the right approach.” Jerry Gamblin, FIRST EPSS SIG member and founder of RogoLabs, is even more enthusiastic about the BoD. “BOD 26-04 is a massive step in the right direction and validates what data-driven teams already know: Patching every CVSS High or Critical is mathematically impossible,” he tells CSO. “By formalizing the use of the KEV catalog alongside advanced predictive data like EPSS, CISA is helping drive the industry toward practical, risk-based operational maturity.” The operational burden of continuous risk assessment Perhaps the most notable operational change is that remediation timelines become dynamic. A vulnerability’s required response time can change as circumstances change, with internet-facing and actively exploited vulnerabilities receiving the highest priority. During the briefing, Butera said that this flexibility is one of the directive’s greatest strengths. In an analysis of one federal civilian agency, CISA found that only about 1% of vulnerability instances required remediation within three days, while more than 60% could be deferred until the next system update. That finding highlights the agency’s central argument: Vulnerability management has become a prioritization problem as much as a patching problem. “We really believe we should be able to free up some time to patch the most urgent vulnerabilities faster while allowing for more regular patch cycles for some of the lower-risk vulnerabilities,” Butera said. Rather than forcing agencies to expend resources remediating thousands of vulnerabilities of varying importance, the framework concentrates attention on the small subset of flaws most likely to result in compromise. What the directive gets right — and what it leaves out Romanosky notes, however, that the directive’s treatment of impact is relatively narrow, focusing largely on whether exploitation grants an attacker partial or complete control of a system. “What about integrity impacts that change data, or completely deny access to a system, such as a DDoS attack on DNS or wiping out a database?” he says. “Those impacts would also seem important.” Still, he acknowledges that if policymakers must simplify risk decisions across the federal government, prioritizing vulnerabilities that provide adversaries control over systems is a reasonable place to start. The directive also places significant emphasis on internet-facing systems, which could raise questions about risks deeper inside enterprise networks. Butera and Spring address that point directly in their blog post, arguing that CISA does not typically observe threat actors compromising core networks through software vulnerabilities alone. Instead, attackers frequently rely on valid credentials, misconfigurations, and other “living off the land” techniques. KEV is useful — but is it enough? Cybersecurity professionals outside government should pay close attention because federal vulnerability management often foreshadows broader industry practice. The directive formalizes ideas that many security leaders have advocated for years: CVSS scores alone are insufficient; asset context matters; internet exposure matters; active exploitation matters most. Michael Roytman, co-founder and CTO of Empirical Security, views the directive as a milestone in that evolution. “The federal government finally retired the ‘patch everything on the list’ mandate and replaced it with risk-based prioritization,” Roytman tells CSO. “Eleven years ago, prioritizing by exploitation probability was a heresy we had to defend in conference hallways. Today, it’s a binding federal directive.” But he also argues that the framework’s reliance on the KEV catalog highlights one of its limitations. “KEV lists are binary and retroactive,” Roytman says. “When AI compresses the gap between patch and exploit to hours, waiting for the KEV entry means you find out you were wrong from the incident report.” Romanosky raises a similar concern, describing KEV as a valuable but inherently backward-looking source of information. “KEV is a great program for DHS and the public, but it is, at best, evidence of past exploitation,” he says. Both experts suggested that predictive signals deserve a larger role in future vulnerability prioritization efforts. Romanosky points specifically to the Exploit Prediction Scoring System (EPSS), which estimates the likelihood that a vulnerability will be exploited in the future. “The concern, of course, is that vulnerabilities age, and so what may have been exploited last year or last month may no longer be used in active exploitation today,” Romanosky says. “So EPSS would provide a better signal.” Roytman takes the argument a step further. Drawing on research conducted alongside Verizon’s DBIR team, he said that recency matters enormously when assessing exploitation risk. According to Roytman, 82% of KEV entries involve vulnerabilities whose exploitation was first reported more than a year ago. “Twelve months of inactivity means the chance of exploitation falls from 99% on the first day down to 5%,” he says. He also argues that KEV captures only a fraction of observed exploitation activity. “The KEV list covers only about 8% of observed exploitation,” Roytman said. “We’re tracking 17,800 CVEs compared to CISA’s 1,600.” How AI could force another rethink of vulnerability management Butera and Spring argue that artificial intelligence is already accelerating vulnerability discovery and increasing pressure on defenders. BOD 26-04 is intended to help agencies automate and scale vulnerability management while focusing scarce resources on the risks that matter most. But the directive’s four-factor framework was built on the vulnerability landscape as it exists today — and AI may render that landscape unrecognizable relatively quickly. Romanosky points to a structural gap in the current model: because the framework relies heavily on CVE identifiers, defenders may encounter newly discovered flaws that require urgent attention before they’ve been formally cataloged. “As more vulnerabilities are discovered quicker with AI tools, we might expect a whole set of new vulnerabilities that haven’t yet been assigned CVE IDs that need to be patched super quick,” he says. That’s not a hypothetical concern. The CVE assignment process — run by MITRE and a network of numbering authorities — was built for a slower discovery cadence. It can take days or weeks for a vulnerability to receive an identifier, go through NVD analysis, and appear in tools that practitioners actually use. If AI compresses the window between discovery and exploitation to hours, that pipeline becomes a liability. Roytman sees the directive’s four-factor model as a starting point rather than an endpoint — one calibrated to average federal risk rather than the specific conditions of any individual organization. “The risk in CISA’s table is the average risk across the federal enterprise,” he said. “The risk in an enterprise environment is a different number that depends on controls, telemetry, prevalence, and ultimately a local model specific to that enterprise.” Romanosky agrees that another revision may be inevitable. “I might expect another revised BOD — or some other directive — to account for what may be a new continuous stream of vulnerabilities,” he says. In that sense, BOD 26-04 may be less a destination than a waypoint: the federal government’s best current answer to a problem that AI is guaranteed to make harder. View the full article

IT software provider Ivanti fixed two vulnerabilities in Ivanti Sentry, a secure mobile gateway appliance formerly called MobileIron Sentry. The flaws could allow unauthenticated remote attackers to gain complete control of deployments. One of the vulnerabilities, CVE-2026-10523, credited to researcher Bryan Lam, allows attackers to bypass authentication and create arbitrary administrative accounts on appliances. The flaw is rated with a severity of 9.9 out of 10 on the CVSS scale. The second flaw, CVE-2026-10520, is a command injection issue that can lead to remote code execution with root privileges on the underlying OS. Because the vulnerability can be exploited remotely without authentication, it is rated with the maximum CVSS severity score of 10. Ivanti Sentry is an in-line gateway that manages, encrypts, and secures traffic between mobile devices and back-end enterprise servers such as Microsoft Exchange. It works together with Ivanti Endpoint Manager Mobile (EPMM) to enforce access restrictions and device verification. As such, the appliance is typically deployed at the enterprise network edge and is accessible from the internet. Both vulnerabilities were reported privately through Ivanti’s responsible disclosure program, and the company is not aware of public exploitation at this time. But attackers, including state-sponsored cyberespionage groups, have exploited vulnerabilities in Ivanti products and network-edge appliances many times in the past. Furthermore, researchers from security firm watchTowr have posted a detailed analysis of CVE-2026-10520 and the exploit is trivial to execute. The researchers released a Python script that enables organizations to test whether their deployments are vulnerable. Ivanti Sentry customers are advised to upgrade their deployments to versions 10.5.2, 10.6.2, or 10.7.1 as soon as possible. View the full article

June’s Patch Tuesday security updates have arrived, with SAP fixing four critical vulnerabilities and Microsoft addressing over 200 CVEs. Microsoft’s to-do list includes fixes for three zero days, 32 patches rated as ‘critical’, and a batch of other high-risk vulnerabilities that need urgent assessment. There’s also one older flaw under exploit, and some patches affecting enterprise products for which Microsoft says exploitation is likely. Adobe, too, fixed critical vulnerabilities in enterprise software. Vulnerability surge It’s a record haul for Patch Tuesday CVEs — and that’s not counting the other exploited vulnerabilities Microsoft has patched out-of-band since its May update. Microsoft recently told customers it expects the number of vulnerabilities in monthly updates to continue rising, influenced by the growing use of AI tools. As a May post by the Microsoft Security Response Center put it: “As larger releases settle in as a norm, the way we deliver and decide on updates remains consistent. Patch Tuesday continues as our predictable rhythm for on-premises software,” Going forward, customers should brace themselves for more out-of-band updates, it added. According to Nirwan Dogra, a Senior Software Engineer at Microsoft Security, May and June 2026 represent a new norm that will challenge traditional, slower test-and-deploy patching. “The 200+ CVE count isn’t an anomaly. It’s the new baseline. AI-assisted vulnerability discovery (fuzzing, static analysis, variant hunting) is compressing the timeline between ‘a bug exists’ and ‘bug is found’ dramatically,” he said via email. Ominously, according to Dogra, AI tools used were also resulting in more flaws being uncovered in components previous seen as too complex for manual audit such as hypervisor code and Kerberos. He recommended that organizations move towards risk-based vulnerability prioritization, automated patching pipelines, and a focus on the flaws that were likely to be exploited. Dustin Childs, Head of Threat Awareness for TrendAI’s Zero Day Initiative (ZDI) agreed: “We are heading into a high-stakes summer for cybersecurity. June’s record-shattering drop of 210 Microsoft vulnerabilities is a stark warning that AI is supercharging flaw discovery at an uncontrollable scale,” he said. Microsoft’s high-priority fixes Three vulnerabilities are rated as zero days because they have been publicly disclosed. Two are connected to adversarial disclosures affecting Windows by the researcher Nightmare Eclipse which have attracted a lot of attention: CVE-2026-45586 (CTFMON) and CVE-2026-50507 (BitLocker bypass). The third is CVE-2026-49160, a CVSS 7.8-rated denial of service zero day vulnerability in the Windows HTTP Protocol Stack used by various Windows services. Security teams should also note the patch for CVE-2026-42897, an Exchange Server flaw under active exploitation originally disclosed in May. This was originally addressed using workarounds but has now been patched. The list of 15 vulnerabilities where exploitation is said to be “more likely” is headlined by CVE-2026-47291, a dangerous CVSS 9.8-rated kernel-level RCE flaw in http.sys that attackers could use to target multiple important enterprise applications, for IIS, WinRM, or Windows Admin Center. Also worth paying attention to are a series of ‘high’ rated Hyper-V VM escape flaws, CVE-2026-47652, CVE-2026-45641, and CVE-2026-45607. Anyone running on-premises networks will also be interested in CVE-2026-47288, an RCE affecting the Active Directory Kerberos core, and CVE-2026-45648, a CVSS 8.8 affecting Active Directory Domain Services (AD DS). Four critical SAP vulnerabilities SAP’s Security Patch Day haul for June comprises 15 patches across a range of core enterprise products including, prominently, NetWeaver, Commerce Cloud, SAP S/4HANA, and the Business Objects Business Intelligence Platform. Four of these are rated ‘critical’, the most eye-catching of which is CVE-2026-27671, a CVSS 9.8 memory corruption vulnerability in Application Server ABAP and ABAP Platform. The problem here, said Jonathan Stross, SAP security analyst at security company Pathlock, is that it “requires no authentication and can affect confidentiality, integrity, and availability at the same time. A successful exploit can undermine the trustworthiness of the entire ABAP instance and everything connected to it.” “This is one of the most serious notes in the batch because the attack requires no authentication and can affect confidentiality, integrity, and availability at the same time. A successful exploit can undermine the trustworthiness of the entire ABAP instance and everything connected to it. Not far behind it is CVE-2026-44748, a CVSS 9.9 XML Signature Wrapping in SAML Authentication vulnerability in the SAP NetWeaver Application Server ABAP and ABAP Platform. This allows authenticated attacker with low-level user privileges to capture a signed SAML message and modify and submit an XML payload with a forged identity data. The final critical-rated flaws are CVE-2026-22732, a CVSS 9.1 Spring Security weakness within SAP Commerce Cloud and SAP Data Hub, and CVE-2026-40128, a CVSS 9.0 directory traversal vulnerability in the Application Server Java (Web Container). This month’s update also patches two vulnerabilities marked ‘high’, the CVSS 7.4 CVE-2026-29145, addressing multiple weaknesses in Apache Tomcat within SAP Commerce Cloud, and CVE-2026-44751, a missing authorization check affecting Application Server ABAP of SAP NetWeaver and ABAP Platform. Adobe patches enterprise vulnerabilities Adobe’s June update addresses 123 vulnerabilities across Reader, ColdFusion, Experience Manager Forms, InDesign, InCopy, Substance 3D Sampler, Content Credentials SDK, Dreamweaver, Format Plugins, and Adobe Campaign Classic. Of note are the two CVSS 10-rated CVEs (APSB26-66) in the Adobe Campaign Classic enterprise marketing platform, the seven mostly ‘critical’ or ‘high’-rated CVEs affecting ColdFusion (APSB26-64), and a total of 20 CVEs affecting Reader (APSB26-63). It’s also a busy month for InDesign, which features 12 vulnerabilities (APSB26-58), and Experience Manager which features three (APSB26-57). View the full article

The long-running feud between Microsoft and security researcher Nightmare Eclipse has entered a new chapter. Eclipse, who has spent the past several months publicly releasing unpatched Windows vulnerabilities while sparring with Microsoft over vulnerability disclosure practices, has published exploit code for a new zero-day flaw dubbed RoguePlanet. The researcher said their exploit uses a race condition problem affecting Microsoft Defender, giving attackers less than a hundred percent odds at success, which can potentially allow SYSTEM-level privilege on even freshly updated Windows. As before, the exploit arrives just after Microsoft issued its June 2026 Tuesday patches, where the company issued fixes for over 200 security flaws, including 32 critical ones. “The timing is a giveaway, MiniPlasma was released on May 13, 2026—exactly one day after Microsoft’s May Patch Tuesday cycle, ensuring defenders have no official vendor patch for weeks,” Agnidipta Sarkar, chief evangelist at ColorTokens, had said about Eclipse’s previous “MiniPlasma” disclosure. The exploit was dropped in a new GitHub repository, “MSNightmare,” surely a pointed reference to Microsoft, after GitHub (owned by Microsoft) removed Eclipse’s original repositories recently. Several earlier Eclipse disclosures were reportedly incorporated into real-world attacks shortly after exploit code became available, prompting warnings from Microsoft and multiple security vendors. The bug allows code execution through SYSTEM access In a June 9 blog post titled “RoguePlanet, a quick history,” Eclipse wrote of an initial iteration of the Windows Defender bug. While technical details remain scarce, the blog did mention that it has to do with getting a victim to open a “.vhd(x) on a remote SMB server.” Doing that, the writeup explained, would result in “Defender overwriting its own files and obviously the end outcome was an RCE.” A rough interpretation of the description is that the bug allows executing malicious metadata from a specially crafted virtual hard disk (.vhd) image stored on a remote Server Message Block (SMB) server. Eclipse’s PoC exploit ultimately spawns a SYSTEM shell, allowing arbitrary code to be executed by a potential attacker. A mid-May patch to Defender reportedly sealed the initial attack path detailed by Eclipse, making “junction attacks useless,” which had them re-write RoguePlanet to work around the fix. The current version of the exploit allegedly works against Windows 11 (official channel + Canary) and Windows 10 with the June 2026 patch installed. The PoC code, however, gave out against Windows Server installations since standard users “Cannot mount an ISO image”. While Eclipse was “too drained” to redesign an exploit for this exception, they are certain an exploit is possible. The feud behind the flaws Microsoft recently removed Eclipse’s GitHub accounts and also disabled their Microsoft Security Response Center (MSRC) access. Following the ban, GitLab also suspended the researcher’s secondary mirrors. In a May 27 blog post, Microsoft criticized the lack of coordinated vulnerability disclosure and threatened legal action, stating that the public disclosures aided attackers and involved a digital crimes unit coordinating with law enforcement. “The vulnerabilities known as RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma were not responsibly disclosed,” the company wrote on Eclipse-disclosed bugs. “Uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable and have real-world consequences.” Cybersecurity analyst Kevin Beamount called Microsoft’s response a “dumpster fire of their own making.” Writing of a previous researcher going by the name “SandboxEscaper,” who similarly disclosed Microsoft bugs and published exploit codes, Beaumont pointed to Microsoft’s precedent for hiring such researchers in 2019. “I’m making the point that Microsoft has very publicly hired somebody for doing the same thing Microsoft’s latest blog alleges is criminal behaviour,” Beaumont said. Microsoft did not immediately respond to CSO’s request for a comment. Eclipse announced its return on GitHub on June 9. “Yes, it’s GitHub again, Microsoft forgot that even if they banned my GitLab and GitHub accounts, they cannot unwrite my code. Once it’s public, you can’t remove it.” View the full article

AI agents given access to corporate email and business applications could become a new phishing target for attackers, according to cybersecurity researchers, after a test agent built on OpenClaw was tricked into sharing cloud credentials and customer data with an external attacker. Varonis Threat Labs said it built an OpenClaw AI agent called Pinchy to test whether autonomous agents could fall for the same kinds of phishing attacks that have long targeted employees. Varonis tested the agent in a controlled Google Workspace environment, giving it access to a Gmail inbox with mock AWS credentials, CRM exports, internal conversations, and calendar invites. The test used two configurations: a generic productivity profile and a stricter profile that included email safety instructions telling the agent to be cautious of phishing and verify sender identities before acting on sensitive requests. Varonis said the agent still failed in some scenarios, particularly when requests appeared to come from colleagues and were framed as routine or urgent business tasks. “In some cases, Pinchy not only failed at spotting the phishing attacks, it also performed risky actions that could potentially compromise a real-world organization,” the cybersecurity firm said in its report. In one test, Pinchy forwarded AWS IAM keys, database passwords, and SSH access details to an external Gmail account after receiving what appeared to be a routine request from a colleague for staging credentials. In another test, an attacker asked the agent to send the latest customer export for a quarterly business review presentation. Pinchy retrieved and forwarded a CRM export containing details on 247 enterprise customers, including company names, contact information, contract dates, customer tiers, and roughly $1.28 million in monthly recurring revenue data. But the results were not entirely negative. According to Varonis, the agent performed better against more technical phishing attempts, including a malicious OAuth consent flow disguised as a timesheet platform. In that case, Pinchy inspected the redirect address, identified the destination as suspicious, and stopped before granting consent. “That contrast is what makes the earlier failures structurally important,” Varonis said. “The agent had enough technical reasoning to recognize sophisticated phishing infrastructure. The weak point was social trust and identity verification.” The findings come as companies move AI agents beyond chat interfaces and into workflows where they can retrieve documents, process messages, and act across business software. An architecture problem The OpenClaw test points less to a failure of the AI model itself than to the way the agent was configured and deployed, said Devashri Datta, a cybersecurity researcher. “The security tests actually proved that the AI models did their jobs well on a purely technical level,” Datta said. The bigger problem was that the agent treated email as both a source of information and a source of instructions, creating what Datta described as a classic IT mistake: mixing the data lane with the control lane. “It didn’t hand over a password because someone asked nicely; it executed what looked like a legitimate operational task,” Datta said. “In any secure system, you never let the data path give administrative orders.” Other analysts said the model should not be taken out of the equation entirely. The risk is not confined to one layer of the technology stack, said Keith Prabhu, founder and CEO at Confidis. The test showed problems in the model’s ability to judge trust and in the way agent frameworks and enterprise governance handled autonomous access. “Historically, security architectures segregate any orchestration pipeline into authorization, execution, auditing, and escalation,” Prabhu said. “However, this is collapsed into one single pipeline in AI agents, which may lead to them becoming victims of such phishing attacks.” Enterprises need enforceable controls Enterprises should treat AI agents as high-privilege identities, because they can ingest untrusted content while also taking actions across business systems, according to Sunil Varkey, a cybersecurity adviser and former CISO. That combination raises the stakes for enterprises, particularly when agents can read emails, documents, web pages, and SaaS comments while also sending messages, exporting data, calling APIs or updating records, he said. “Frameworks like OpenClaw often lack robust enforcement of identity verification, tool-level permissions, and resistance to prompt injection,” Varkey said. “However, the decisive factor in the Varonis tests was over-privileged access, missing human oversight, and absent runtime guardrails.” Akshat Tyagi, associate practice leader at HFS Research, said enterprises should focus not only on what an agent can access, but also on what it is allowed to send outside the organization. “Instructions are not controls,” Tyagi said. “If an agent can email sensitive data outside the company just because someone asked convincingly, the problem is not the model alone.” AI agents should have their own identities, with access that can be limited and monitored, Tyagi said. Requests involving credentials or customer data sharing should trigger human review rather than be left to the agent’s judgment. View the full article

When Ram Shankar Siva Kumar launched Microsoft’s AI red team in 2019, the discipline barely existed. “The running joke used to be that people who used to work in AI red teaming, you can round them up in a 14-foot catamaran,” he tells CSO. At the time, Microsoft’s approach looked familiar to anyone in cybersecurity: Attack machine learning systems the same way security teams attacked everything else. Identify weaknesses, emulate adversaries, and uncover vulnerabilities before products reach customers. Then GPT-4 arrived. “The tool that we had changed; actually, it broke,” Siva Kumar says. The attacks his team had developed against earlier machine learning systems no longer worked against large language models. The tools had to be rebuilt. The methodologies had to be newly devised. Even the definition of the job had to be rebuilt. “We had to retool completely, and we also had to rethink what it means to red team an AI system,” he says. That rethinking is still under way. Today, AI red teaming has become one of the fastest-growing specialties in cybersecurity, with dedicated teams at Microsoft, Anthropic, OpenAI, Google, and Nvidia. But the field is grappling with a more fundamental question than which tools to use: What exactly is the job? Not your father’s penetration test The most basic difference between testing traditional software and testing AI reshapes everything else: AI is not deterministic; it’s probabilistic. “The same attack might only work one time out of 100 times or 10 times out of 100 times or 90 times out of 100 times,” Dane Sherrets, staff innovation architect at HackerOne, tells CSO. That changes how security teams evaluate risk. Instead of asking whether a vulnerability exists, they must also determine how frequently it appears, under what conditions, and whether it can be reliably reproduced. Pete Bryan, technical lead of the AI red team at Microsoft, thinks the probabilistic nature of AI systems fundamentally changes the testing process. Systems must be evaluated repeatedly, under varying conditions, to understand how they behave and whether risky outputs emerge consistently. The challenge is not only that AI behaves differently from traditional software. It is also capable of things traditional software could never do. Tom Gillis, SVP/GM of the infrastructure and security group at Cisco, points to frontier models discovering vulnerabilities in complex software systems at a pace that would have seemed implausible a few years ago. “They’re able to find weird interdependencies,” he tells CSO. “I change the state of this little piece, which changes the state of that piece, which changes the state of this piece, which leads to a memory overflow.” Modern models can analyze enormous codebases and identify chains of interaction that eventually lead to exploitable conditions — relationships human researchers miss even after years of scrutiny. That capability cuts both ways. The same reasoning power that makes AI useful for security testing makes AI systems themselves a new kind of target, one that requires different methods to probe. ‘Teenager with a potty mouth’ Traditional red teams spend most of their time modeling sophisticated adversaries: nation-states, cybercriminal groups, advanced persistent threats. AI red teams still care about those actors — but the roster of relevant threat actors has grown considerably. “One of the enduring personas that we also focus on is what my team lovingly likes to call a teenager with a potty mouth,” Microsoft’s Siva Kumar says. The phrase captures one of the defining realities of the generative AI era. Many of the most significant jailbreaks and prompt injection attacks were not discovered by elite offensive operators. They were found by curious users experimenting with prompts — people who had no particular expertise but plenty of creativity and time. “In 2019, if we had had this interview, I’d have said, ‘Hey, my job is to emulate nation-state adversaries and to emulate advanced persistent threats,’” Siva Kumar says. Those adversaries still matter. But AI systems can fail in response to ordinary users asking unexpected questions, creatively manipulating prompts, or simply interacting with the technology in ways its developers never anticipated. Ian Swanson, AI security leader at Palo Alto Networks, sees this reflected in how enterprises think about the problem. “What that really means is we need to behaviorally test AI for security, safety, and maybe even brand reputational type risks,” he tells CSO. The question is no longer simply whether an attacker can break into a system. It is whether the system itself can behave in ways that create risk — regardless of who is doing the asking. Safety moves in alongside security That reframing has expanded AI red teaming well beyond its cybersecurity origins. When Microsoft’s team launched in 2019, its focus was largely on the confidentiality, integrity and availability of machine learning systems — the traditional CIA triad. Generative AI dramatically enlarged that mandate. Trust and safety concerns now sit alongside conventional security ones. Misinformation, dangerous knowledge domains, manipulation risks, and questions about autonomous AI behavior all fall within the remit of many AI red teams today. “The composition of my team has commensurately increased to kind of meet the AI moment,” Siva Kumar says. His team now includes a psychologist, a linguist, and a specialist in bioweapons — expertise that would have seemed out of place in a traditional security organization. Bryan sees the expansion as a natural consequence of AI’s role in society. “AI red teaming has a much broader scope,” he says. “We’re worried about those engineering technical elements, but we also encompass the socio-technical risks of the safety side.” Those expanded sets of worries mean evaluating harms that traditional cybersecurity teams rarely encountered: misinformation amplification, psychosocial risk, content that can cause harm without any attacker ever being involved. “We need skillsets that are much broader — people who think deeply about psychosocial harms or misinformation amplification — to cover the full remit of AI safety and security,” Bryan says. AI red teaming’s growing remit has even attracted Washington’s attention. President Biden’s 2023 executive order formally defined AI red teaming and required safety testing results for the most powerful models to be shared with the government before deployment. President Trump later revoked the order, leaving standards development largely to industry and voluntary frameworks. Red teaming the whole car One of the most common mistakes organizations make when they begin testing AI systems is focusing exclusively on the model. HackerOne’s Sherrets uses a car analogy. The model is the engine. But the AI system is everything connected to it — the databases, the APIs, the customer records, the payment systems, the internal workflows. “What I encourage people to do is red team the entire car,” he says. “We need to understand not only the engine, but also all of the other pieces that connect to that engine and how they operate together, because how they connect and operate together could also have vulnerabilities.” Weaknesses often emerge not from the model itself but from the interactions between components. Sherrets points to an Air Canada case to make the point. The airline’s customer service chatbot invented a bereavement refund policy that did not exist. A customer relied on it. The airline ended up in court. Nobody had hacked the system. Nobody had exploited a vulnerability in the conventional sense. The chatbot behaved incorrectly — and the organization was held responsible for what its AI said on its behalf. As organizations deploy AI assistants across customer service, sales, HR, and internal operations, that kind of failure becomes an increasingly significant risk category. The system does not need to be attacked to cause harm. It needs only to be wrong, at the wrong moment, in front of the wrong person. The agent problem For much of the generative AI era, red teamers worried primarily about outputs. Would the model hallucinate? Would it leak sensitive information? Would it generate harmful content? Agents introduce a different category of risk entirely. Agentic AI systems do not just generate text. They retrieve information. They invoke APIs. They process refunds. They access databases. They perform tasks on behalf of users with real-world consequences. A vulnerability that causes a chatbot to say something wrong is a communications problem. A vulnerability in an agent that executes business processes is an operational one. The shift extends beyond testing AI systems themselves. Cisco’s Gillis argues that increasingly capable AI models are accelerating the pace of change across enterprise environments, making static security approaches obsolete. “This idea of hardening your infrastructure and then hoping it never changes for 18 months, that is over, permanently dead, gone in this post-Mythos environment,” he tells CSO. The implication is that security testing can no longer be a periodic exercise. As AI systems become more autonomous, organizations must continuously evaluate how those systems behave in production environments. “We need to test the behavior to make sure agents are doing the right things,” Swanson says. Microsoft’s Bryan believes agentic systems are forcing a convergence between traditional cybersecurity red teams and AI red teams that will define the field’s next phase. At Microsoft, the two teams remain separate organizations — but they work increasingly closely together, because the systems they now test combine conventional software risks with AI-specific safety concerns in ways that neither team can address alone. “Agentic AI is really the intersection of all of the cybersecurity risks that come with traditional software systems along with all of the AI security and safety risks,” he says. AI is a team sport, too Bryan points to Microsoft’s decision to open-source AI safety testing tools as a recognition that AI risk is not a problem model providers can solve on behalf of their customers. Enterprises deploying AI need their own testing capabilities. Not every organization will maintain a specialized AI red team — but every organization deploying AI needs to understand its risks. “Like cybersecurity, which has always kind of been a team sport, AI safety and security is really a community-driven piece,” Bryan says. “Everyone has their role and responsibility.” Bryan also sees the long-term trajectory of the field bending toward a different kind of convergence. “I think there will just become a point where having the AI for red teaming almost kind of becomes redundant, and that just is the red teaming,” he says. “Everyone is using AI to improve their work regardless of the area.” What will remain distinct is the challenge of testing AI systems themselves — probabilistic systems that expand in scope with each new capability and that can cause harm without anyone intending them to. Five years ago, AI red teaming was a niche specialty practiced by a handful of researchers. Today, it encompasses cybersecurity, safety, misinformation, autonomy, and governance. Tomorrow it will look different again — shaped by whatever the next generation of AI systems turns out to be capable of. View the full article

UK Prime Minister Keir Starmer’s speech on Monday insisting that tech companies create device controls to somehow block children from viewing or creating sexually explicit imagery has raised alarms among CISOs, who worry that the same technology could undermine enterprise security. Starmer gave tech firms three months to create and implement such restrictions voluntarily, at which point he said he would push for legislation to make it mandatory. Behind the technical and logistical hurdles for tech firms to clear, such as how a device would determine that an image was inappropriate, and how it could reliably determine the subject’s age, is the issue of whether this process would interfere with encryption protections for enterprises worldwide. And that comes down to whether the required data analysis happens on the device or in the cloud. Starmer did not go into a lot of detail, preferring to let technology companies craft their own plans, but in this case the details matter. Analysts and consultants said that there has been a push for everything to happen on-device, which would avoid any encryption problems; if the inspected data never leaves the device, the encryption protection would stay intact. But this plan for the process to stay on the device seems highly unlikely for multiple reasons. The first problem is device capabilities and hardware age. Although Apple and Google engineers would be working with the latest devices, much of the UK population is using much older and less capable hardware, analysts said. Although a 2-, 3- or 4-year-old phone might still be able to handle the additional load, it would likely suffer a dramatic slowdown sufficient to make users decidedly unhappy. That would mean that even if the execution of the data analysis began on the device, it would likely have to be shifted to the cloud for performance reasons. And once it moved into the cloud, the encrypted data problem begins. Trying to do this scanning on-device in the UK would fail, said Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. “It will make unusable the majority of devices used in the UK today. It just can’t work on-device.” However, Villanustre observed that on-device analysis for this kind of effort, which would need to scan everything that gets downloaded to the phone in search of prohibited images, might be viable in a few years, once the typical device becomes much more powerful. But not today. Creates new risks Leading secure messaging app provider Signal also issued a strong statement opposing Starmer’s proposal. “The UK governmentʼs demand that all content on all devices sold or used in the UK be scanned on the presumption of nudity, using a dystopian combination of age verification and content scanning, will not safeguard children. It endangers us all, whilst strengthening Apple, Google and Microsoft’s market dominance and their control over our most personal information,” Signal said. “Once created, [the program] will be expanded, forming a dangerous tool that will be wielded both in the UK and abroad to censor and surveil whatever they might consider ‘threats’ or ‘harmful content.’” Signal has aggressively fought against such programs before. Similar privacy campaigns have also been launched in other parts of Europe. The long held fear is that moving encrypted data to the cloud, regardless of whether it remains encrypted or is converted to clear text, creates opportunities for attackers to access the sensitive data. “The mechanism that flags and reports a match to external authorities creates a new, built-in exfiltration path,” said Jeff Valdes, a director at consulting firm Acceligence. Could do more harm than good Sanchit Vir Gogia, chief analyst at Greyhound Research, argued that the UK proposal is likely to do far more damage than good. He pointed to the short three month timeframe as evidence of a lack of good faith. “Legislation of this complexity cannot be drafted in a quarter. The deadline is a pressure instrument, not a delivery schedule. Child safety is the destination. Device-wide inspection is the wrong vehicle,” Gogia said. “Apple and Google already run on-device nudity detection in bounded contexts, and it works: a child can be warned, an image blurred, a sharing attempt interrupted.” Gogia pointed to another logistical problem, which is that some devices such as tablets are often shared between family members, which makes reliable age determinations all but impossible. “The deeper flaw is that the policy assumes a stable mapping between device, person, and age, and that mapping does not exist in real households,” Gogia said. “A device cannot know its holder has changed. The only architecture that survives this is default-child with recurring adult verification, which is surveillance arriving through the back door of household economics.” In addition, he noted, “Children disproportionately inherit the old, out-of-support handsets the mandate cannot reach. Forcing churn manufactures electronic waste and punishes the families least able to buy new.” Carmi Levy, an independent technology analyst, agreed that the computing overhead alone for such an effort could make this a deal-killer. “The compute requirements, particularly in light of the need to execute this kind of filtering in real time, would be immense. It is futile to assume this capability can ever be rolled out at scale without running into massive concerns on several fronts,” Levy said. “Simply deciding how to tune the filters is an almost impossible task. Although the overall definition of nudity, namely not wearing clothing, is generally agreed upon, the line where it becomes inappropriate for minors is neither static nor universally established. So it’s wildly optimistic to assume that a single threshold would be workable at the scale proposed by Prime Minister Starmer.” Nidhi Luthra, a director at Acceligence, added that the logistical and technological roadblocks are also a big problem. “Technically, parts of this can work,” she said, but vendors would have to deal with age verifications, drifts in the models and false positives, and there is also the “lack of contextual information that truly would have let this work.” Puts CISOs in ‘an impossible bind’ The UK proposal also puts enterprise CISOs and IT directors who need to protect sensitive data in an impossible bind, Gogia said. They “can govern device management and conditional access. What they cannot govern is a mandatory inspection capability that updates according to political appetite rather than enterprise risk appetite,” he pointed out. “The proposal does not automatically create a breach inside Signal, WhatsApp, or Teams, but it creates the conditions for a new class of breach around them. The weakness need not live in the messaging protocol. It can live in the mandated inspection layer, the classifier update mechanism, the age-assurance workflow, or the logs that enforcement inevitably generates.” Regime change could lead to abuse Another common concern is that governments change hands, so limited capabilities granted today to one government might be used very differently by a future government. Brian Jackson, principal research director at Info-Tech Research Group, noted, “the current government may only use it to detect nudes, but what is to stop a future authoritarian government from using it to detect unfavorable political commentary? Creating a back door means there is potential for third parties — hackers — to exploit that back door to gain access to the user’s communications. This is exactly what encryption and on-device security measures are supposed to prevent.” He added, “Apple’s Communication Safety feature, Google’s Family Link, and a range of parental control tools already use on-device AI to detect and restrict explicit imagery on children’s devices. The government is not filling a gap the market failed to address. It is proposing to transfer control of an existing capability from the device owner to the state. Parents can deploy this protection right now, on their terms. That is where the decision should sit.” Ryan O’Leary, research director for privacy and legal technology at IDC, said the current proposal only involves the UK, and there’s no way to determine whether other governments will try something similar. He noted that the EU’s GDPR was widely expected to go global when it launched in 2016, but in ten years, it hasn’t. O’Leary said that if this proposal is enacted in the UK, he would advise IT and cybersecurity executives to be extra cautious when sending team members to the region. “It would essentially be ‘China rules’” such as air gapping systems and traveling with disposable data-limited burner phones, O’Leary said. “It’s an exceptionally big deal if it goes through,” but, he added, the chance of it happening is very low. “It seems like the technology companies will call his bluff.” View the full article

AI-generated code is riddled with security flaws, yet enterprises are shipping more of it than ever before. Why? Perhaps they’re over-confident, lack true visibility into security risks, or are simply choosing to ignore the problem and hope it goes away. It’s a dangerous game to play at the dawn of the agentic AI era, as underscored in a new report from app security company Checkmarx. The survey of thousands of security leaders exposes an underlying naivete about AI-built code and its vulnerabilities, even as tools like Anthropic’s Mythos are uncovering security flaws orders of magnitude faster than any human security team could ever hope to. “Mythos-class models collapse the window between a vulnerability existing and a working exploit being available from months to minutes,” the report notes. Enterprises relying on traditional security tools and methods, it says, “cannot survive this reality.” Security as an afterthought Checkmarx’s survey of 2,350 CISOs, AppSec managers, and developers across 14 countries focused on how much AI-developed code enterprises are deploying, the vulnerabilities it introduces, how it impacts developer workflows, and overall sentiment about AI code and security posture. Today, nearly half of production code is AI-generated, and the majority of enterprises also report that at least half their codebase is made up of open-source components, according to the report. But the more AI-generated code that is pushed out, the more vulnerabilities are exposed. Enterprises who said 81% – 100% of their code is built by AI ship vulnerable code 3.4 times more often than businesses using AI more conservatively, relying on 20% or less AI code. Additionally, 70% of developers said that AI code generation created vulnerabilities in 2025, and almost all enterprises surveyed (93%) had at least one security breach as a direct result of in-house developed apps. Still, risk is becoming “normalized,” the report notes, with three-quarters of enterprises knowingly deploying vulnerable code as they face increased pressure for ROI. Startlingly, about 30% of respondents admitted they ship compromised code and hope the vulnerability won’t be found. Similarly, more than a third of organizations leave half of their known vulnerabilities unfixed for 90 days or more. The report points out that the organizational bottleneck isn’t detection, “it’s the human decision to ship anyway, suppress the finding, or defer to the next sprint.” Along with this, AppSec teams are often limited to reactive incident response as they deal with tool sprawl. And developers only continuously secure code a small percentage of the time (18%), even though nearly all are equipped with security tooling. Ultimately, developers are “set up to fail,” the report contends. They face significant pressure to deliver, and are forced to choose quantity and speed over security. Yet, even as they face significant consequences when it comes to post-mortems, performance reviews, escalation, and blocked releases, the tools that contribute to security issues, delivering low-value findings, unclear guidance, or late feedback, continue to go unfixed. “Developers remain accountable for outcomes, even when systems and workflows are not aligned to support them,” the report notes. Overconfidence, outdated practices Alarmingly, many enterprises seem to be deluded when it comes to their security posture. Of those that rate themselves as “highly mature” AI organizations, 42% often ship the most vulnerable code, and have breach rates “barely distinguishable” from other enterprises. “Confidence isn’t protecting them,” the report notes. “It’s blinding them.” Underscoring this, only 22% of organizations have formal AI governance, and developers still rely on manual code reviews to ensure their code meets compliance standards. The result is a mismatch between the speed of software creation and the speed of governance, the report notes. “Compliance frameworks are evolving, but many organizations are still attempting to govern AI-scale development with processes designed for a slower era of software delivery.” Strategic imperatives for enterprises Enterprises do seem to have wised up (a bit) after Anthropic’s Mythos proved capable of not only discovering vulnerabilities across major operating systems and browsers, but exploiting them 100 times faster than previous Claude models. And the subsequent Project Glasswing almost immediately surfaced thousands of previously-unidentified security flaws. Checkmarx’s survey, which, it should be noted, was conducted a month prior to Mythos’ arrival, found that enterprises are finally taking proactive measures, focusing more heavily on AI security threats overall, and investing more in DevSecOps practices, automation, and developer training. The report emphasizes the importance of prioritizing risk over code volume; vulnerabilities should not be considered isolated incidents. Also, it’s critical to embed security into developer workflows rather than treating it as a checkpoint. Enterprises must have systems that reduce noise, provide clear guidance, and allow them to take action when an issue arises. Security “must be integrated directly into how developers write, test, and ship code within the IDE, pipelines, and AI-assisted workflows where development now happens,” the report notes. Similarly, enterprises would benefit by reducing fragmentation and tool sprawl and defining ownership of the AI tools. By simplifying security stacks, they can align responsibilities and ensure consistent tool use, according to the report. Further, AI needs strong governance, and teams must move beyond outdated manual triage and “human-gated remediation.” AI can fight AI in a strong system built to prioritize, remediate, and resolve risk “without waiting for a human to approve each step,” the report notes. Ultimately, it says: “Progress depends on embedding intelligence directly into workflows, enabling risks to be prioritized, remediated, and resolved, all within the systems that they operate in.” This article originally appeared on CIO.com. View the full article

Anthropic unveiled two new powerful AI models built on its previously restricted Mythos architecture: Claude Fable 5, which is being made broadly available, and Claude Mythos 5, which remains limited to a small group of cybersecurity and infrastructure partners. Anthropic describes Fable 5 as the most capable model it has ever released to the public, outperforming previous Claude models across software engineering, scientific research, vision, and complex knowledge-work tasks. Anthropic says the model’s advantage grows as tasks become longer and more complicated, enabling users to assign larger projects to the system with less oversight and fewer detailed instructions. According to Dianne Penn, Anthropic’s head of product management, research, and labs, the goal was to make Mythos-level intelligence broadly available without exposing users to the risks that previously kept the technology restricted. “We wanted to be able to provide this level of intelligence for general users in a safe manner,” Penn told The Wall Street Journal. Safeguards may be broader than Anthropic suggests When Anthropic released Mythos in April, it argued that the model’s capabilities in areas such as vulnerability discovery and offensive cybersecurity created risks that justified restricting access to around 50 recipients. Just a week ago, Anthropic announced it was expanding Mythos access to 150 organizations. Now Anthropic says it has developed safeguards robust enough to support a broader release. Those safeguards work by routing certain categories of requests — including cybersecurity, biology, chemistry, and model-distillation-related queries — to the less capable Claude Opus 4.8. Anthropic says these fallbacks occur in fewer than 5% of sessions, meaning most users will effectively interact with the full Mythos-class model during ordinary use. Early testing by security researchers suggests the cyber safeguards may be broader than Anthropic’s description implies. Rob T. Lee, chief AI officer and chief of research at SANS Institute, tells CSO that his routine cybersecurity tasks involving incident response, detection, and basic forensic workflows were automatically routed from Fable 5 to Opus 4.8 during his initial testing. If those observations hold up under broader testing, it could indicate that Anthropic’s classifiers are broadly identifying cybersecurity-related requests rather than attempting to distinguish between benign and malicious cyber activity. The company describes the safeguards as intentionally conservative. Users may occasionally encounter false positives in which benign requests are routed to Opus 4.8, but Anthropic says it chose to prioritize safety over convenience while it continues refining the system. A significant portion of Anthropic’s latest announcement is devoted to explaining why it believes the safeguards are necessary. The company argues that Mythos-class systems have crossed a threshold where they could provide meaningful assistance to malicious actors. Unlike earlier AI systems that primarily offered information, Anthropic says advanced models are increasingly capable of carrying out portions of complex workflows, including activities associated with offensive cybersecurity operations. To address those risks, Anthropic has developed a series of AI-powered classifiers designed to identify potentially dangerous requests. If the system detects a request involving offensive cyber operations, advanced biological research, chemistry-related risks, or attempts to extract the model’s capabilities for use in competing systems, the request is redirected to Opus 4.8. Anthropic says extensive internal and external testing failed to uncover broadly effective jailbreaks that would consistently bypass the safeguards. Anthropic touts gain in coding, analysis, and autonomous work The Fable 5 announcement also focuses on software engineering, where Anthropic believes the model’s gains are particularly significant. During testing, Stripe, for example, reportedly used Fable 5 to complete a codebase-wide migration in a 50-million-line Ruby repository in a single day, a task the company estimated would have required more than two months of engineering effort if performed manually. Anthropic also says the model achieved state-of-the-art results on coding evaluations that measure not only whether software works but whether it meets the standards expected in production environments. The company further highlighted gains in financial analysis, document reasoning, chart interpretation, and vision tasks. Anthropic says Fable 5 can accurately extract information from complex scientific figures and perform sophisticated visual reasoning tasks, including reconstructing web application source code from screenshots. Expanded access for cyber defenders For a select group of users, Anthropic is also introducing Claude Mythos 5. The model is identical to Fable 5 but with certain safeguards removed. Through Project Glasswing, cybersecurity organizations and critical infrastructure providers will gain access to a version of the system with cyber-related restrictions lifted — Anthropic plans to gradually expand access through a broader trusted-access program developed in consultation with the US government. The company says Mythos 5 possesses what it describes as the strongest cybersecurity capabilities of any model currently available. Anthropic has previously highlighted the ability of Mythos-class systems to discover software vulnerabilities, assist with exploit development, and perform complex, multi-stage cybersecurity tasks. Those capabilities are precisely what prompted the company to restrict access to earlier versions of the technology. The move reflects a broader trend across the AI industry as vendors seek ways to commercialize increasingly powerful systems without making their most dangerous capabilities widely available. AI developers have spent the past year wrestling with the question of how to deploy models whose capabilities may provide substantial benefits to defenders, researchers, and enterprises while also creating opportunities for misuse. AI doesn’t replace the basics For security leaders, the announcement raises important questions about how quickly organizations can adapt to increasingly capable AI systems. The challenge is no longer simply obtaining access to advanced models but integrating them into security operations in ways that produce measurable benefits. The question of how well the safeguards are calibrated matters beyond individual workflows — it goes to the heart of whether organizations can actually operationalize these models effectively. Anthony Grieco, Cisco’s senior vice president and chief security and trust officer, said organizations should focus not only on gaining access to increasingly powerful models but also on deploying them effectively while maintaining strong security fundamentals. “The pace of frontier AI development is changing the security landscape in real-time, and defenders cannot afford to wait for the dust to settle,” Grieco said in a statement sent to CSO. “Whether the model is Claude Mythos 5, Claude Fable 5, GPT-5.5-Cyber, or the next breakthrough, the challenge is no longer just access to advanced AI, but how organizations operationalize it with the right harness, infrastructure, and agentic logic to turn speed into clarity and action.” At the same time, Grieco cautioned against viewing AI as a substitute for foundational security practices. “AI will raise the ceiling for what defenders can do, but security resilience remains the foundation that determines whether those gains translate into real protection,” he said. Even as AI models accelerate software engineering, analysis and security operations, organizations still need to execute on fundamentals such as patching, multifactor authentication, network segmentation, and zero trust architectures. View the full article

Check Point has issued emergency hotfixes for a pair of vulnerabilities affecting VPN deployments that still use the deprecated Internet Key Exchange version 1 (IKEv1) protocol, warning that one of the flaws is already being exploited in the wild. The more serious issue allows attackers to establish VPN sessions without a valid password, potentially giving them a foothold inside corporate networks. According to the company, attackers have been exploiting the vulnerability since at least early May, with activity accelerating in recent weeks. “To date, the observed exploitation has been limited to a few dozen targeted organizations globally,” Lotem Finkelstein, vice president of research at Check Point, said in a security blog post. “One case involved confirmed post-compromise activity associated with a Qilin ransomware affiliate.” The vulnerabilities affect customers using Remote Access VPN, Mobile Access VPN, and certain Spark Firewall products configured for IKEv1. While the said protocol has been considered legacy technology for years, it remains enabled in some environments for compatibility reasons. Check Point is urging affected customers to apply the newly released hotfixes immediately and, where possible, migrate from IKEv1 to the newer IKEv2 protocol. The deprecated protocol became an active risk The exploited bug, tracked as CVE-2026-50571, affects deployments that continue to accept IKEv1-based remote access connections. According to Check Point, attackers can exploit a logic oversight in how Remote Access and Mobile Access components validate certificates during the authentication process. Exploitation allows an unauthenticated attacker to establish a VPN connection without supplying a valid user password. While additional steps may be required to access internal resources or escalate privileges, security researchers note that bypassing the VPN login barrier provides attackers with a significant foothold inside targeted environments. The vulnerability was put under the “Improper Authentication” CWE tagged at CWE-287, with a CVSS score of 9.3 assigned to it. Affected Check Point Quantum software platform versions, which run on the Gaia operating system powering all Check Point products, include R80.20.X (EOS), R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.10.X, R81.20, R82, R82.00.X, R82.10. The second vulnerability, CVE-2026-50752, emerged during a broader security review conducted as part of Check Point’s investigation into the improper authentication flaw. Researchers reportedly used the company’s BLAST agentic application security platform to analyze the affected VPN components, leading to the discovery of additional weaknesses in certificate validation logic. Unlike CVE-2026-50571, the newly identified issue does not allow direct authentication bypass. Instead, it could enable a man-in-the-middle attacker to interfere with site-to-site VPN communications if specific conditions are met. This flaw received a CVSS score of 7.4, with no exploitation attempts observed in the wild yet. Mitigations and patches issued Affected organizations have received a set of resolutions to help with the problem, starting with an attack detection technique. “Search your Check Point SmartConsole logs for possible VPN certificate authentication attempts associated with the observed attacker infrastructure and certificate subject names,” Check Point said in an advisory that shared SmartConsole queries for scans around the time range, attacker IP address, and VPN/IKE activities. Additionally, the company listed three mitigation tips for protection outside and beyond patches. These include removing support for legacy Remote Access client connections, configuring Global properties for Remote Access VPN authentication to IKEv2 only, and setting the machine certificate authentication as mandatory. Lastly, and most effectively, the company issued a string of downloadable hotfixes corresponding to each affected version, which customers can download and apply for complete and immediate protection. View the full article

Cybercriminals are increasingly reshaping familiar social-engineering campaigns around the way employees use AI, with separate advisories from Microsoft and Google documenting how attackers are adapting scams to AI-powered tools, trusted digital services, and changing workplace behavior. Microsoft Threat Intelligence, in its advisory, said threat actors are “leveraging the wider global interest around AI itself as a social engineering lure,” impersonating platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude to distribute malware, steal credentials, and commit financial fraud. Google, in its latest Fraud & Scams Advisory, separately highlighted the evolution of traditional phishing into Adversary-in-the-Middle (AITM) and QR-code phishing attacks while documenting growing abuse of trusted cloud services, AI-driven investment scams, and impersonation campaigns. While Microsoft’s advisory focuses on AI-branded lures and Google’s examines broader fraud trends, both point to attackers evolving established social-engineering techniques to match the growing role AI plays in everyday enterprise workflows rather than relying solely on technical exploits. AI lures move into the mainstream “Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns,” Microsoft said in the advisory. The company added that despite the AI branding, the campaigns continue to rely on “longstanding tactics” such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains. Microsoft argued that AI-themed campaigns are becoming more than opportunistic attacks. “AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states,” the advisory said, citing campaigns that used ChatGPT-themed subscription renewal emails and fake DeepSeek V4 repositories employing stolen branding and search optimization to distribute Vidar Stealer malware. Google’s advisory reaches a similar conclusion from a different angle. “Scams continue to be a persistent global challenge, fueled by sophisticated transnational crime groups who seek to exploit people online for financial gain,” the company said, citing estimates that global fraud losses could approach $580 billion in 2025. The advisory describes Calendar Phishing campaigns that abuse trusted cloud productivity suites, AITM attacks that mirror legitimate login experiences, and cryptocurrency scams that persuade victims to execute malicious code under the guise of AI-powered investment guidance. Rather than introducing entirely new attack techniques, both advisories document cybercriminals adapting familiar phishing, impersonation, and malware campaigns to environments where AI tools and cloud services have become part of everyday work. Security shifts to the human layer Security researchers say the findings reflect a broader enterprise challenge as AI becomes embedded across business applications and employee workflows. “AI-enhanced phishing and impersonation, including deepfakes, voice cloning, and social engineering, ranks as the single most-cited AI-driven threat concerning enterprises today, with 58% of respondents flagging it,” said Sakshi Grover, senior research manager for Cybersecurity Services Research at IDC Asia/Pacific. “The attack surface has migrated from software stacks to the cognitive and behavioral layer — what employees believe, click on, and act upon when an AI-branded experience tells them to,” Grover said. Prabhjyot Kaur, senior analyst at Everest Group, said organizations should see the trend as more than another wave of shadow IT. “Shadow IT was a visibility problem. Shadow AI is a trust exploitation problem,” Kaur said, arguing that AI capabilities increasingly arrive through embedded SaaS features, browser extensions, copilots and productivity platforms that employees adopt as part of routine work. Building resilience beyond phishing For enterprise leaders, the challenge increasingly lies in adapting security programs to changing user behavior rather than responding to isolated phishing campaigns, analysts added. Apeksha Kaushik, senior principal analyst at Gartner, said adversaries are “capitalizing on the credibility of leading AI brands” to make social-engineering campaigns “hyper realistic and convincingly personalized” through deepfakes, impersonation, and disinformation. “Attackers are adapting to how employees interact with AI, targeting the human layer by manipulating trust and routine behaviors rather than seeking technical exploits,” Kaushik said. She said organizations should focus on long-term resilience instead of episodic response. “The strategic battle has shifted from blocking individual episodic attacks to managing the environment itself,” Kaushik said, arguing that stopping one deepfake or impersonation attempt offers only a tactical victory if the broader attack ecosystem continues to evolve. View the full article

Researchers from the University of Toronto developed a computer worm prototype powered by an AI agent that successfully self-replicated to different systems within a simulated computer network. The worm used a free large language model (LLM) running on local hardware and exploited a combination of older and new vulnerabilities, as well as misconfigurations that remain all too common in enterprise environments. At a time when CISOs and the security industry are concerned about the ability of frontier models such as Anthropic’s Mythos to find zero-day vulnerabilities in critical software, this experiment is a reminder that attackers don’t need cutting-edge AI to wreak havoc across typical corporate networks. In fact, using paid models accessible only via APIs would be a point of failure for an autonomous malicious system like a computer worm, because prompts constructed to bypass safety guardrails would quickly be detected and blocked by the AI labs. “We discovered that it is possible to create an AI-driven computer worm, using only small, free AI models, that can autonomously identify each machine’s unique weak points (including vulnerabilities just reported by industry and misconfigurations such as reused passwords) and exploit them, hijacking computing power to take over regular devices such as laptops, cameras, and everything else online, and then copying itself onto servers and networks to either steal data or launch new attacks,” the research team from the University of Toronto’s CleverHans Lab said in their report. “We did this without using the newest, most powerful AI models. There is no single defence against this new threat.” Building an agentic harness for offensive cyberattacks While frontier models such as Claude Opus and GPT 5.5 offer million-token context windows and can reason for tens of minutes and even hours at a time to solve a single task, this approach does not work for locally hosted LLMs running on a single GPU. Their context windows are much smaller and generally exhibit weaker instruction-following abilities for agentic tasks. Vibe-coding software developers who encountered these problems long ago have solved them by building custom harnesses and agentic frameworks that split complex software engineering projects into phases and steps, executed by multiple sub-agents in parallel that share results via some form of memory system, ranging from a markdown file to a database. The CleverHans Lab researchers adopted those lessons to build their own harness for offensive security purposes to compensate for local LLM limitations, complete with phases and task-specific nodes that make LLM calls with specialized prompts. “This core is supported by complementary systems: a hierarchical memory that preserves discoveries across independent LLM calls, tools and their handlers that encapsulate common action sequences and interpret execution results, a skill system that injects context-aware pentesting guidance on demand, and multi-agent coordination that shares intelligence across instances,” they explained in their paper. Agentic harnesses built for security research and penetration testing are not a new concept and have existed for a while. Open-source examples include RAPTOR, a framework of skills and agents for Claude Code designed for vulnerability discovery and exploit writing, and SecOpsAgentKit. “Previous models can perform close to, at, or beyond Mythos levels depending on capability by using harnesses,” Gadi Evron, CEO of AI security firm Knostic and one of the creators of RAPTOR, told CSO. “When new models come out, they can achieve in a prompt what previously took a harness, at which point new harnesses are built, and so on and so forth.” Simulating a vulnerable enterprise network The CleverHans Lab researchers created a network made up of virtual machines running different operating systems including Ubuntu (16.04-24.04), Debian (9-12), Alpine Linux, Rocky Linux 9, CentOS Stream 9, and Windows Server (2008 R2, 2019, 2022). These VMs simulated servers running a variety of web services, as well as IoT devices and industrial control systems that can be found on typical corporate networks. The researchers left an assortment of old and new — a few days old — vulnerabilities unpatched on the simulated systems, as well as common insecure configurations and generic flaws such as missing access control or SQL injection. The goal was to test the capability of their AI-powered worm to discover the systems, find the open ports, identify the exposed services, locate the vulnerabilities, exploit them, and then copy itself to the compromised system. The systems had both remotely exploitable flaws that would provide initial access, as well as local flaws and weaknesses that could be used to elevate the privileges to root and completely take over the machine. “These two classes evaluate complementary capabilities: CVEs test the agent’s ability to fingerprint software versions and dynamically adapt or compile raw exploit code to fit the target environment, whereas CWEs probe its capacity for open-ended, target-specific reasoning where no off-the-shelf exploit applies,” the researchers said. “To ensure the network reflects vulnerabilities encountered in the real-world, all targets are drawn from three authoritative threat taxonomies [the CISA Known Exploited Vulnerabilities catalog, the OWASP Top 10: 2025, and the MITRE ATT&CK framework] covering, respectively, vulnerabilities under active exploitation in the wild, prevalent web and software vulnerabilities, and adversarial techniques used after initial access to a network.” Furthermore, some virtual machines were equipped with GPUs that would allow the worm to replicate itself and then hijack the computing resources to run the model locally instead of relying on the LLM hosted by the researchers on an external system. Over the course of seven days and five generations of self-replication, the worm managed to spread to 27 of the 33 systems in the simulated environment. The worm correctly identified the vulnerabilities in 82% of the attempts and managed successful exploitation in 44% of those. Despite the exploitation rate being quite low, the parallel and swarm-like implementation where every compromised system became a new instance of the malicious agent, compensated and eventually led to an overall high success rate. This largely matches what security researchers from Forescout found in a study performed earlier this year that looked at how good models have become at discovering and exploiting vulnerabilities. While the research showed that the new generation of open-weight models had significantly improved their capabilities of both finding and exploiting vulnerabilities, the smaller variants of those models quantized to run locally on single-GPUs still performed poorly at such tasks. The researchers noted at the time, however, that by using specialized AI agentic frameworks like RAPTOR they were able to find new zero-days in OpenDNS. “Many of the open-source or generally commercially available models are already good enough that if used with the correct harness they can find vulnerabilities, exploit them, create malicious code and so on,” Daniel dos Santos, VP of research at Forescout, told CSO. “The new work from U of Toronto shows that similar models can also be used to create dynamically adapting worms.” Cybercriminals are aware of these advances in model capabilities too based on discussions Dos Santos’ team observed on underground forums, with more attackers focusing on open-source and commercial models instead of “underground” ones fine-tuned for cybercrime. Organizations running out of time While zero-day attacks receive a lot of attention and AI has put such flaws within the reach of more attackers than ever, the reality is that there is no shortage of systems on the internet and inside networks that are either misconfigured or vulnerable to known flaws for which patches or mitigations exist. The University of Toronto experiment shows that defenders need to be able to respond with similar speed, especially since their prototype shows that knowledge about new vulnerabilities can be integrated into the worm’s knowledge base within hours of public disclosure. The ability of the worm to hijack GPUs to run nodes further decreases the investment attackers need to make in running such AI-assisted attacks. “Organizations have endless technology and security debt, and with AI attacks on the rise, we no longer have time,” Evron said. “Change however is all about time, especially in the enterprise. The key is to start preparing right now. Soon, we won’t measure time to exploitation, but will need to construct new measurements, such as for the ability to handle regularly occurring, concurrent data breaches while minimizing impact on daily operations.” University of Toronto researchers call for enterprises to adopt AI-assisted penetration testing and fuzzing to discover exploitable weaknesses in their own infrastructure, but also to build the capability to deploy patches or mitigations faster, which is now a significant gap. They do, however, acknowledge some limitations of their prototype, such as the fact that it was noisy, leaving many behavioral signatures behind that could be detected by endpoint and network monitoring systems. Also their simulated network lacked basic network segmentation, which could be further improved with zero-trust architecture to prevent lateral movement and by minimizing the software dependencies and attack surface on every host system. “While vulnerabilities, exploits, and attack orchestration are now autonomous, the deeper meaning for defense is that many of our assumptions about building security programs are now challenged,” Evron said. “Until we get to mature defensive AI, we must empower our people with coding agents to bring them up to machine speed, and then defend these agents in turn.” View the full article

Threat actors are continuing their onslaught against software supply chains, now with malware named after death itself. The newly-discovered Hades Campaign is a “highly sophisticated” supply chain compromise that targets Python developer environments and runs as soon as infected packages are imported. It uses the popular Bun toolkit to silently execute multi-layer payloads that can extract sensitive data, move laterally across compromised systems, exploit common security frameworks, and even hijack AI gatekeeper analyzer systems via adversarial prompt injection. Notably, the campaign exploited the popular C++ library ensmallen, as well as packages in the computational biology, bioinformatics, and genotype-phenotype analysis ecosystems. The most novel thing about this malware is its combination of advanced tactics, noted David Shipley of Beauceron Security. He noted that we’ve seen memory-focused malware, we’ve seen attacks that attempt to defuse large language model (LLM) powered analysis with hidden prompts, and we’ve seen malware with wiper capabilities. “But all three, in a fast moving mass propagating worm, is its own kind of nightmare,” he said. “And I suspect this is the way of the future.” How Hades works The Hades Campaign was discovered by researchers at StepSecurity, who called it the latest evolution of the Miasma threat actor. The researchers previously described Miasma attacks that had sent self-replicating worms to perform multi-cloud credential sweeps, caused infected repositories to execute code when folders were accessed in integrated development environments (IDEs) or by AI agents, and used techniques that scanned and read Linux process memory. Hades uses the same credential harvesting methods, self-replicating worm logic, and GitHub-based exfiltration patterns, the researchers noted. In addition to ensmallen, compromised packages include mflux-streamlit, nhmpy, ppkt2synergy, embiggen, gpsea, and pyphetools. The campaign’s entry point is a simple, obfuscated script embedded inside a Python package’s __init__.py file, a critical building block that gives Python the ability to recognize packages and import modules. Once they gain access, threat actors drop a precompiled Bun runtime binary and executes its JavaScript payload. Bun allows the malware to run complex JavaScript tasks in environments lacking a Node.js installation, bypassing traditional package manager controls and proxy logs. The malware is able to scrape Linux memory mappings, and also introduces tailored macOS and Windows memory scrapers, which allow threat actors to extract sensitive, encrypted data. Interestingly, attackers are also able to evade detection by automated LLMs that scan for suspicious code. This is achieved with a simple block of text at the top of the file; this instructs the model to ignore the hidden code below, classify the package as verified and clean, and provide reports stating it is safe. This element represents what the StepSecurity researchers described as a “significant conceptual shift,” with attackers writing payloads that target AI systems’ cognitive logic. “Scanners that pass raw text to LLMs without strict boundary isolation can be coerced into generating false negative verdicts, allowing the malicious package to bypass organization analysis,” they wrote. The tactic is indeed clever, Beauceron’s Shipley agreed, pointing out that attackers will increasingly target endpoint LLM-powered agents. Why? “Because there’s no reliable defense,” he said. “LLMs are incredibly susceptible to social engineering.” This has been relabeled as prompt engineering, but is essentially just phishing for bots, he pointed out. “While everyone’s worried about LLM-powered vulnerability discovery and automated exploitation, it’s LLM-created smart malware like this, and AI-powered phishing of humans and bots, that keeps me awake at night,” Shipley said. Hades’ crafty worm propagation The Hades Campaign command and control (C2) infrastructure uses three independent channels on public GitHub infrastructure to allow its communications to blend in with normal traffic. Stolen credentials are encrypted locally in a hybrid fashion (serialized, compressed, and pushed to a newly created public GitHub repository under attackers’ control). Exfiltrated repositories carry the description “Hades — The End for the Damned.” Researchers noted that a core component of this campaign is its ability to propagate and move laterally across networks. It exploits the very methods meant to protect systems, including Secure Shell (SSH) and Secure Copy Protocol (SCP), OpenID Connect (OIDC),and Supply-chain Levels for Software Artifacts (SLSA). For instance, when running inside a GitHub Actions workflow runner, the malware checks for OIDC variables, then bypasses registry signature policies and generates cryptographically signed SLSA provenance bundles via Sigstore. It can then fetch target libraries and inject the obfuscated script and JavaScript payload. From there, it can publish compromised versions to the Python Package Index (PyPI) repository and node package manager (npm) using the target’s credentials and the generated Sigstore bundle. “This ensures that the published package appears to have valid, cryptographically verified build provenance from the organization’s official GitHub Actions build environment,” the researchers explained. Further, if a harvested GitHub token has write permissions, the malware will target repositories to extract secrets using GitHub Actions runners. This occurs “directly from the runner’s address space without ever writing them to disk or making a suspicious network connection,” the researchers noted. The malware also targets rule files and configuration directories for 14 different AI agents and systems, planting custom prompt instructions or executing hooks that trigger a bun run bootstrap command when the victim loads or consults the workspace with their AI assistant. Finally, it establishes persistence on the workstation and monitors for the presence of the stolen token; if that token is revoked, it executes a wiper process to erase the user’s files. This article originally appeared on InfoWorld. View the full article

OpenAI’s move to implement a Lockdown Mode that tries to limit data exfiltration by shutting down external capabilities is being seen as making the best out of a bad situation. But Lockdown Mode doesn’t block exfiltration as much as it slightly reduces it, and the reality of enterprises using multiple AI vendors for their agentic models further complicates an already dicey governance strategy. When activated within OpenAI products’ settings, Lockdown Mode limits web browsing to cached content, limits image support, disables Deep Research and Agent Mode, denies users the ability to approve Canvas-generated code to access the network, and prevents ChatGPT from downloading files for data analysis, though it can still operate on manually uploaded files, OpenAI said in a blog post. The company did not respond to a request for comment. That post included a frequently-asked-questions section in which OpenAI wrote its own questions. and then answered them. One notably asked “Is prompt injection a major risk?” with the response, “Prompt injection is not currently a major risk, but its impact could grow as attackers develop more sophisticated methods.” Consultants found that sentence baffling. “OpenAI’s own posture is telling. It calls prompt injection a frontier research problem, hard enough to warrant a containment mode, while saying in the same breath that it is not currently a major risk,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “A vendor does not build a panic room for a house it believes is safe. Lockdown Mode is the admission itself.” And the risk of AI-enabled data exfiltration was illustrated recently when some Instagram users’ personal data was stolen after Meta had turned over control of password changes for accounts to an AI agent. Still allows some exfiltration Gogia added that the Lockdown Mode is porous, as it will still allow some data exfiltration; he called the OpenAI effort “a model carrying a trusted user’s authority while acting on instructions hidden in untrusted content. Data can leave by a side door rather than be announced in the chat.” Tom Findling, CEO of Conifers.ai, also questioned whether OpenAI could block all of what it claims it can block. “It is yet to be seen whether [Lockdown Mode] can be breached or not. Is it Nirvana? Probably not, but this is likely the best they could have done, given the infrastructure they have today.” An executive with a major agentic cybersecurity firm, who asked to be not named, agreed with Findling: Lockdown Mode “is not going to be validated until someone tries breaking it. Almost every sandboxing solution out there, AI has been able to break out of,” he said. Debate over who has control Analysts and consultants disagreed over whether enterprises should use the OpenAI capabilities for isolation or use the enterprise’s own restrictions. “The question I immediately asked myself was whether organizations need OpenAI to do this for them. The answer, in my opinion, is no,” said Erik Avakian, technical counselor at Info-Tech Research Group. “Security professionals have been implementing similar concepts for years through control areas like network segmentation, least privilege, applying Zero Trust concepts and principles, application controls, and ‘air-gapping’ some environments.” Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, also has doubts. “So long as the LLM and associated components are provided as a service by OpenAI, customers can only partially control where those systems can reach out, so this lockdown mode seems to be the answer to that,” he said. “Yes, customers could use a secure gateway,” he added, “but if the LLM and/or agent sitting at OpenAI premises accesses other third party services, there would not be a way for the IT and/or cybersecurity team from the customer to restrict this. The most secure approach is always the deployment of the AI infrastructure on premises, but that’s just not viable for the majority of organizations.” Dennis Xu, a research VP with Gartner, flatly stated that enterprises need to rely on AI vendor provided cutoffs. “This is not something end user clients can do on their own. As this controls how traffic flows from OpenAI infrastructure, the ChatGPT application, going outbound, only OpenAI has the ability to control that flow. ChatGPT is a web/SaaS based application that cannot be air gapped,” Xu said. “In the shared responsibility model, this falls under provider responsibility. End user clients will need to rely on what is available from providers such as OpenAI. Without that, they have no control over this data flow. So if they like this OpenAI feature, they need to raise this as a feature request with other providers for them to implement into their solution.” That can get exponentially more complex if all AI vendors deploy such shutoff valves in different ways. Gogia noted that vendor-specific controls are useful tactically and weak strategically, because each vendor can only constrain its own product. “OpenAI can limit OpenAI but it cannot govern a local model in a business unit or an assistant embedded elsewhere,” he said. “Its own model shows the limit: in managed workspaces, apps and connectors remain governed by role-based access and Lockdown Mode does not automatically disable every app. The hard work does not vanish. It moves into governance.” Villanustre added that the result will be that customers may need to deal with “a patchwork of controls” until independent third party governance tools come to the rescue and support this cross-vendor management model. As well, Avakian said, “rather than relying on a single AI platform, organizations will likely use multiple models from multiple vendors, in which each will serve different business functions. We might soon find ourselves talking about AI trust zones, AI segmentation, AI least privilege, and AI governance frameworks the same way we talk today about network segmentation and Zero Trust architectures.” However, Carmi Levy, an independent technology analyst, said that the OpenAI move is an improvement, albeit an incremental one. “It is not a replacement for pre-existing best practices within any organization. Rather, it enables greater in-model protections before organizational limitations can be imposed. With different vendors incorporating different lockdown modes into their models, IT is challenged to update its own protocols to integrate with an increasingly diverse vendor landscape,” he said. “There’s no getting around the fact that this will add ongoing overhead to IT and cybersecurity operations, as different vendors continue to evolve their own protection-focused regimes.” Humans are the problem One of the reasons that Lockdown Mode can’t halt all exfiltration, even if it works perfectly, is the human factor, coupled with the tendency of autonomous agents to bypass rules. For example, let’s say that an end user works for a large publicly-held American company, and the user asks the agent to gather financial details about an upcoming quarter’s revenue and net income. Security and Exchange Commission (SEC) rules in the US make it illegal to selectively share that unannounced data with the public. If the agent finds a way to access internal emails and documents from Finance and shares the answer with the end user, and that end user then copies and pastes that information into an email sent to some investors, or possibly even a financial journalist, the user is in contravention of the rule; the model that supplied the data may not have even known that this disclosure was prohibited. Expands the attack surface Justin Greis, CEO of consulting firm Acceligence, noted that the most interesting thing about Lockdown Mode is that it acknowledges a reality many organizations are wrestling with: AI’s value often comes from its ability to connect to systems, access data, browse the web, and take action. “Those same capabilities also expand the attack surface. As AI becomes more integrated into critical business processes, the conversation shifts from maximizing capability to balancing capability with control,” he said. “The broader implication is that we’re likely moving toward a world where AI systems have configurable operating modes based on business context, data sensitivity, user privileges, and risk tolerance. That’s a much more nuanced model than the all-or-nothing approaches we’ve seen so far.” Greis would like the OpenAI option to offer IT granular functionality choices. “IT needs to have the availability to configure it and not just accept the default settings from OpenAI,” he said. For example, IT might want to customize based on connectors, or GPTs, or models, or zones, or regions. Another Gartner VP analyst, Nader Henein, said that OpenAI created Lockdown Mode “with a narrow set of clients in mind, specifically for non-classified government use, potentially for specific governments, the reason being that if an enterprise client has this level of concern regarding data sensitivity, they are not likely going to trust any provider, including OpenAI,” he pointed out. “Those clients are likely to seek on premises large language models, or large language models hosted in secure, trusted environments.” View the full article

Cisco warns customers of an actively exploited high-severity vulnerability in Catalyst SD-WAN Manager, an enterprise network management system that has been targeted by hackers multiple times in the past. Located in the command-line interface, the flaw allows authenticated attackers to escalate privileges to root and take over the entire system. The vulnerability, tracked as CVE-2026-20245, is rated 7.8 (high) on the CVSS scale instead of critical because it requires local access and netadmin privileges to exploit. These privileges can be obtained via stolen credentials or by exploiting authentication bypass flaws, such as CVE-2026-20245 or CVE-2026-20127, which were fixed in May and February, respectively. The older authentication bypass flaws were exploited by a cyberespionage threat actor Cisco Talos tracks as UAT-8616. It’s not clear whether the new vulnerability was exploited by the same group as part of its campaigns against enterprise SD-WAN deployments, but it was reported to Cisco by Google’s Mandiant division, which specializes in incident response. “This vulnerability is due to insufficient validation of user-supplied input,” Cisco said in its advisory. “An attacker could exploit this vulnerability by uploading a crafted file to the affected system. A successful exploit could allow the attacker to perform command injection attacks on an affected system and elevate their privileges as the root user.” Mitigation While a patch is not yet available, Cisco recommends upgrading to the latest available version to ensure the previous authentication bypass exploits don’t work. Customers should also check the configuration of their edge devices because the company has observed cases where exploitation of this flaw resulted in configuration changes. Before upgrading SD-WAN deployments, users are advised to save all relevant log files and issue the request admin-tech command to collect the admin-tech file from each of the control components. Cisco has published indicators of compromise that should be visible in the scripts.log file from /var/log/. However, it’s hard to distinguish malicious and legitimate command calls in the logs, so if the indicators of compromise are present in the logs, customers should contact the Technical Assistance Center. “If the logs show indicators of compromise and the system is confirmed to be compromised, applying the software update alone will not resolve the vulnerability,” the company said. “In such cases, follow the specific remediation steps that will be provided by the Cisco Technical Assistance Center (TAC) to help secure the system.” View the full article

A widely used JavaScript implementation of Google’s Protocol Buffers format is placing too much trust in untrusted data, exposing affected applications to remote code execution and other attacks. Researchers at Cyera have disclosed six vulnerabilities affecting “protobuf.js,” all stemming from the library’s handling of schema and metadata. Attackers could exploit an input validation oversight to insert malicious data and influence an application’s behavior. Protocol Buffers is a technology for packaging data in a compact, structured format to streamline the exchange of information between different applications. The protobuf.js library reportedly receives more than 50 million weekly downloads. It is commonly pulled into applications indirectly through dependencies such as gRPC tooling, Google Cloud libraries, and other frameworks, making it difficult for organizations to track. Researchers disclosed six CVEs covering remote code execution, denial-of-service (DoS) conditions, prototype pollution, prototype injection, and code-generation issues. “While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations,” Cyera researchers Assaf Morag and Vladimir Tokarev said in a blog post. Patches are available for both protobuf.js and protonufjs-cli, the project’s command-line code generation tools. Metadata capable of writing code The most significant of the bugs is a code-generation flaw tracked as CVE-2026-44291. According to Cyera, protobuf.js dynamically generates encoder and decoder functions and compiles them using JavaScript’s Function () constructor. Under specific conditions, an attacker can manipulate schema-derived information so that data intended to describe a message instead becomes executable code. The researchers demonstrated an attack chain in which prototype pollution is used to trick protobuf.js into accepting attacker-controlled values as legitimate protobuf types. Those values are then incorporated into the generated code and executed within the Node.js process. The impact extends beyond runtime applications. A separate code-injection issue, tracked as CVE-2026-44295, affects the pbjs command-line tool, where crafted schema names can be embedded into generated JavaScript files and executed when those files are later imported. While successful exploitation requires specific preconditions, such as the ability to influence protobuf schemas or descriptors, researchers noted that modern software increasingly exchanges schemas, descriptors, and configuration files across repositories, cloud environments, APIs, and third-party integrations, making those assumptions less restrictive than they once were. The remaining vulnerabilities are less severe. Researchers identified a prototype injection (CVE-2026-44292) flaw that can alter application behavior by tampering with inherited object properties, as well as denial-of-services (DoS) bugs (CVE-2026-44289, CVE-2026-44290, and CVE-2026-44294) that can crash or exhaust application resources using maliciously crafted inputs. Patching advised as supply chain risk looms The researchers noted that protobuf.js is often consumed as a transitive dependency, meaning organizations may be exposed without realizing the library is present in their software stack. As schemas move through automated development pipelines and software supply chains, components traditionally viewed as passive data can become a pathway for attacks. “Development teams routinely accept code contributions, integrate third-party components, and automatically process files through CI/CD pipelines,” they explained. “We found that under certain conditions, a malicious protobuf schema could be introduced into this workflow and ultimately executed within trusted build environments.” A compromise at this stage could have downstream impacts on products, customers, and business operations, they added. The vulnerabilities affect protobuf.js versions 7.5.5 and earlier, along with versions 8.0.0 and 8.0.1, as well as vulnerable releases of protobuf.js-cli. Patches are available in protobuf.js 7.5.6 and 8.0.2, while protobuf.js-cli users are advised to upgrade to versions 1.2.1 or 2.0.2. View the full article

A widely used JavaScript implementation of Google’s Protocol Buffers format is placing too much trust in untrusted data, exposing affected applications to remote code execution and other attacks. Researchers at Cyera have disclosed six vulnerabilities affecting “protobuf.js,” all stemming from the library’s handling of schema and metadata. Attackers could exploit an input validation oversight to insert malicious data and influence an application’s behavior. Protocol Buffers is a technology for packaging data in a compact, structured format to streamline the exchange of information between different applications. The protobuf.js library reportedly receives more than 50 million weekly downloads. It is commonly pulled into applications indirectly through dependencies such as gRPC tooling, Google Cloud libraries, and other frameworks, making it difficult for organizations to track. Researchers disclosed six CVEs covering remote code execution, denial-of-service (DoS) conditions, prototype pollution, prototype injection, and code-generation issues. “While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations,” Cyera researchers Assaf Morag and Vladimir Tokarev said in a blog post. Patches are available for both protobuf.js and protonufjs-cli, the project’s command-line code generation tools. Metadata capable of writing code The most significant of the bugs is a code-generation flaw tracked as CVE-2026-44291. According to Cyera, protobuf.js dynamically generates encoder and decoder functions and compiles them using JavaScript’s Function () constructor. Under specific conditions, an attacker can manipulate schema-derived information so that data intended to describe a message instead becomes executable code. The researchers demonstrated an attack chain in which prototype pollution is used to trick protobuf.js into accepting attacker-controlled values as legitimate protobuf types. Those values are then incorporated into the generated code and executed within the Node.js process. The impact extends beyond runtime applications. A separate code-injection issue, tracked as CVE-2026-44295, affects the pbjs command-line tool, where crafted schema names can be embedded into generated JavaScript files and executed when those files are later imported. While successful exploitation requires specific preconditions, such as the ability to influence protobuf schemas or descriptors, researchers noted that modern software increasingly exchanges schemas, descriptors, and configuration files across repositories, cloud environments, APIs, and third-party integrations, making those assumptions less restrictive than they once were. The remaining vulnerabilities are less severe. Researchers identified a prototype injection (CVE-2026-44292) flaw that can alter application behavior by tampering with inherited object properties, as well as denial-of-services (DoS) bugs (CVE-2026-44289, CVE-2026-44290, and CVE-2026-44294) that can crash or exhaust application resources using maliciously crafted inputs. Patching advised as supply chain risk looms The researchers noted that protobuf.js is often consumed as a transitive dependency, meaning organizations may be exposed without realizing the library is present in their software stack. As schemas move through automated development pipelines and software supply chains, components traditionally viewed as passive data can become a pathway for attacks. “Development teams routinely accept code contributions, integrate third-party components, and automatically process files through CI/CD pipelines,” they explained. “We found that under certain conditions, a malicious protobuf schema could be introduced into this workflow and ultimately executed within trusted build environments.” A compromise at this stage could have downstream impacts on products, customers, and business operations, they added. The vulnerabilities affect protobuf.js versions 7.5.5 and earlier, along with versions 8.0.0 and 8.0.1, as well as vulnerable releases of protobuf.js-cli. Patches are available in protobuf.js 7.5.6 and 8.0.2, while protobuf.js-cli users are advised to upgrade to versions 1.2.1 or 2.0.2. View the full article