CSO Online

Just a couple of weeks after a cyberattack on French supermarket refrigeration systems resulted in spoiled food, and even some fires, retailers in Belgium, Ireland, Sweden, Finland, and Estonia were hit with nearly-identical attacks on Monday.

The mid-October attack prompted an advisory from the French Computer Emergency Response Team (CERT-FR) recommending that organizations disconnect any refrigeration control systems with public IP addresses from the internet, and to reconnect them via a secure VPN only after verifying the configuration and, if necessary, restoring factory defaults.

In an emergency, the advisory suggested, organizations could simply filter connections to allow only the IP addresses of their refrigeration suppliers or service providers to connect, but this should not be a long-term solution.

The Monday attack, like the one in October, “resulted in sudden changes in the temperatures of their fridges and freezers,” according to a Bloomberg report, which confirmed incidents with impacted retailers, including Carrefour, Spar, and Ahold Delhaize. No group has as yet claimed to be behind the attacks.

Delay understandable

Analysts and consultants said the lack of an immediate response to the initial refrigeration attacks is understandable, given the complex nature of the systems and the multiple vendors who typically manage such systems for major retailers. 

Gartner Distinguished VP Analyst Katell Thielemann said that although the impacted European retailers own the hardware, they outsource the maintenance, upkeep, and the management. Thus, she said, “there is some confusion about who owns what in this black box of outsourcing.”

IDC Senior Research Manager Bobby Kuzma agreed. 

“There’s a huge gap in visibility between the folks who monitor threat intelligence and vulnerability reports, and the people who manage the OT/industrial side of the universe,” he said. “The cybersecurity teams may not have even been aware that the devices were network connected, especially if they were riding on dedicated internet circuits for manufacturer support.”

Thielemann added that the incident was made worse because of the historic lack of priority given to cybersecurity defenses in retail. 

“It’s proof that cybersecurity is still not top of mind,” she said. “Even when it’s so egregious, senior [retail] leaders are not asking, ‘How do we get ahead of this?’”

However, Kuzma argued, this problem comes down to asset inventory visibility. 

“You can’t protect a system that you don’t know you have. You can’t scan for exposures on a connection that you don’t know exists,” he pointed out. “Sometimes that inventory requires somebody physically going into the telco closet at the locations and asking pointed questions about equipment that’s present. In this day and age, having devices of any type hanging off a public internet connection and accessible is asking for trouble.”

IoT handled outside of IT

David Neuman, an executive advisor with consulting firm Acceligence, also noted that it was never realistic to assume that issuing a cybersecurity advisory was going to meaningfully address this security hole.

“An advisory doesn’t fix a system nobody in the building owns,” Neuman said. “Contractors often install and service store refrigeration controllers under arrangements that rely on a constant data feed, so they can sit outside the security team’s inventory and authority. Taking the controllers offline means finding them, then reworking how the contractor gets in, store by store.”

That, he said, “explains the gap, but it doesn’t excuse it: France gave everyone a three-week warning. Abusing a legitimate function like defrost causes physical and financial damage without any malware.”

Brian Levine, a partner at consulting firm Control Risks, added that another part of the problem is that IoT devices have always been handled outside of IT. 

“For years, organizations treated connected operational equipment as a facilities issue. These incidents end that debate,” Levine said. “Security professionals never dismissed this risk; budgets deprioritized it because nothing had failed at scale. Now it has, and boards will ask why vendor contracts, incident response plans, and tabletop exercises never accounted for a physical outcome.”

And, said Noah Kenney, principal consultant at Digital 520, this issue goes beyond the fact that the attackers could gain access. He said that he is most concerned about the range of things the attackers were able to do with that access. 

“The attackers could reportedly manipulate refrigeration systems to operate far outside their intended parameters,” Kenney said. “Even if someone gains access to a system, there should be independent safeguards preventing commands that could damage equipment or disrupt operations. The fact that remote access can potentially translate into physical damage suggests some serious gaps in how these systems are designed and secured.”

Kenney also noted that some of these devices had long passed their end-of-life, meaning that security patches and other upgrades may have been unavailable. “Organizations can end up relying on equipment that still functions perfectly well operationally, but can no longer be adequately secured,” he pointed out. “That creates difficult decisions about network isolation, compensating controls, and ultimately when equipment needs to be replaced.”

Indeed, said independent technology analyst Carmi Levy, some in IT tend to ignore IoT systems, especially when they were deployed by functional units without permission from IT or cybersecurity teams.

“Enterprises don’t tend to look at fridges in the same light as servers, smartphones, and other traditionally connected devices,” he noted. “If anything, most IT shops have a limited view of what constitutes a connected device in the first place. That means many organizations are running connected devices, such as appliances, floor cleaners and once-dumb but now increasingly smart machines, with dangerously outdated firmware because they never identified them as connected in the first place.”

Unexpected threat to IT

As well, said Frank Dickson, principal analyst at Dickson Research, there are also corporate legal issues that may undercut cybersecurity’s need for quick action.  

“CERT-FR’s own alert shows why that takes time. Before cutting a controller off the internet, it tells operators to check the insurance terms in their contract with the refrigeration provider. That one line says a lot,” he said, adding that many of these controllers are installed, monitored, and guaranteed by a contractor who depends on the data feed. The store may have neither the ability nor the authority to shut them down.

“Three weeks of warning is a long time for an attacker and a short time for a supermarket chain. Close the door to the internet first and renegotiate the contracts second,” he said.

Dickson also argued that these refrigeration attacks pose an unexpected threat to traditional IT systems as well, because servers and other equipment are temperature-sensitive.

“An attacker who reaches the building management system does not need to touch a single server. The servers will shut themselves down rather than cook,” Dickson said. “You do not need to hack the data center. You only need to hack the air conditioning.”

Cryptocurrency Exchange Binance blamed a compromised DevOps laptop for the loss of $6.3 billion in cryptocurrency last week, adding that it will now cover any losses faced by its customers.

“Binance will cover all losses from the Secure Assets Fund for Users (SAFU) and the company’s funds,” the world’s largest cryptocurrency exchange said in an update on Friday, adding that user funds are safe and that it had found no evidence of wallet private-key leakage during its investigation of the incident. It had frozen approximately $3 billion in assets on-chain, temporarily suspending withdrawals while security checks were completed, and revoking the affected address authorization.

Withdrawals are now being restored in phases, initially reopening services across 15 networks, including Bitcoin, Ethereum, Solana, and XRP. Binance says it has replenished approximately 95% of the affected assets using company funds, while the remaining 5%, comprising less-liquid tokens, could take longer to source.

The exchange said its preliminary investigation pointed to a compromised employee device that enabled access to a service container involved in withdrawals.

“This attack, reportedly on a development engineer, highlights that security is a critical element of every operational stage and personnel level,” said Tim Rawlins, senior advisor and director of security at NCC Group. “When security failures in trusted identities and administrative access can be targeted, attackers can exploit more than just the underlying technical vulnerabilities.”

The FBI has since attributed the attack to North Korean threat actors, identifying the TraderTraitor hacking group as responsible for the theft.

“Given what we know about the activities of countries like North Korea in targeting cryptocurrency, it’s unsurprising that attackers are prepared to invest considerable efforts in targeting individuals who have access to the building blocks of the exchanges,” Rawlins said.

A compromised laptop reaches the withdrawal pipeline

Binance’s preliminary findings suggest that attackers compromised a DevOps engineer’s laptop before gaining access to a service container and submitting unauthorized withdrawals. The exchange has yet to publish technical details of the attack, leaving important questions about the precise intrusion path and how the attackers navigated its internal systems.

“A platform holding digital assets should have multiple layers of security to prevent a single compromise, such as an employee’s laptop being hacked, from being sufficient to authorize a transfer,” said Mario Rivas, blockchain and digital assets security lead at NCC Group.

The reported attack is similar to the February 2025 Bybit breach, in which attackers compromised a developer’s machine at Safe{Wallet} and manipulated the interface presented to transaction signers. However, the Binance incident involved a different mechanism.

F6’s Threat Intelligence Department (TID) said the Binance attack reportedly targeted an automated withdrawal process rather than directly deceiving authorized signers. Evgeniy Yanov, Head of Audit and Consulting Department at F6, cited Crypto security platform Blockaid, highlighting a batch of 50 EIP-7702 authorizations within a single transaction, alongside delegation to a malicious “sweeper” contract, as an unusual feature of the reported attack.

“This specific mechanism has not been seen before in large-scale breaches of this size,” Yanov said.

FBI points to North Korea’s TraderTraitor operation

The FBI has attributed the attack to TraderTraitor, an elite North Korean hacking unit considered part of the broader Lazarus infrastructure.

The agency, working with the US Secret Service and IRS Criminal Investigation, said it had observed the attackers converting stolen assets privately into Ethereum. It warned that the funds could subsequently be laundered through decentralized finance platforms and instant-swap services.

F6’s TID said the attribution was based on a combination of on-chain and off-chain intelligence. “The group’s signature matches previous thefts: small Tornado Cash withdrawals used to fund the operator’s wallet, extensive preparation well before the actual heist, and pre-signed transactions executed in a single burst,” it added.

TID researchers noted similarities with previous North Korean-linked cryptocurrency thefts, including the Bybit and KelpDAO incidents. However, they cautioned that Binance has not independently named the perpetrators and that the full attribution evidence has not been published.

Binance did not immediately respond to a request for comment.

NCC Group’s Rawlins noted that the growing use of AI could help attackers chain vulnerabilities and operational weaknesses together, while organizations increasingly face adversaries willing to invest considerable effort when the potential financial return is substantial. “Good cyber hygiene and effective security fundamentals are key to defending against attacks that many organizations are still missing,” he said.

A malicious version of Anthropic’s Claude Code extension distributed through the Cursor marketplace attempted to install a persistent Secure Shell (SSH) backdoor on developers’ machines, potentially giving attackers remote access to systems holding source code, credentials and other sensitive information.

“Between about 2:27am PT and 1:35pm PT today, a maliciously modified version of Anthropic’s Claude Code extension was made available in the Cursor VS Code Extension Marketplace,” Cursor said in a security notice.

Cursor removed the compromised versions, 2.1.312 and 2.1.313, after discovering they had been available in its VS Code extension marketplace for approximately 11 hours on October 29.

The company said the malicious code attempted to add an attacker-controlled SSH key, enable local SSH access, and establish a reverse tunnel to an attacker-controlled server.

“These malicious versions of the extension were not developed by Anthropic,” Cursor added in the notice. The affected versions were available for Windows and macOS.

Anthropic subsequently clarified how the tampered extension had been distributed. In a post on X, Felix Rieseberg, a member of Anthropic’s technical staff, said the incident did not involve a compromise of Anthropic’s systems or employee laptops. A malicious actor had used access to Cursor’s marketplace to publish the modified extension, he said.

“The versions on our official channels are not affected, and this only impacts Cursor users,” Rieseberg wrote. Anthropic said it was working with Cursor on the incident.

Cursor and Anthropic had not responded to requests for comment by publication time.

Malware ran without user interaction

Security company Phorion, which analysed the compromised extension, found that malicious code had been inserted at the beginning of its JavaScript file. It ran as soon as the extension loaded, before its normal activation code.

“The user doesn’t need to interact with the extension for the payload to fire,” Phorion said.

The malware attempted to add an attacker-controlled SSH key to the user’s authorized_keys file and establish a connection to a remote server. It also created scripts and startup entries intended to keep the connection available after a system restart, the company added.

Phorion identified a flaw in the macOS code. The malware tried to check whether Remote Login was disabled using a system command that required administrator privileges. When run without those privileges, the command returned an access error rather than the expected status. The malware consequently skipped the attempt to enable SSH.

Phorion also found an error in the Windows code that could prevent its SSH service setup command from running correctly.

Microsoft Threat Intelligence, in a separate analysis, detailed the information the malware collected, including machine names, usernames, operating systems, working directories, and Git email addresses.

“It also looks for environment-variable names containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP, keeping up to forty matches,” Microsoft wrote in the analysis. It said the code collected matching variable names, not their values.

Removing the extension may not be enough

Cursor said enabling the local SSH service would generally fail without administrator privileges on affected Windows and macOS machines. However, the extension could still add the attacker’s SSH key, install persistence mechanisms, and send host information to the attacker.

The company warned that uninstalling the extension alone might not remove these components because the malware placed scripts outside the extension’s installation directory.

Steve Povolny, vice president of AI strategy and security research at Exabeam, said the planted SSH key made cleanup particularly important. “Removing the extension only sends the visitor away while the spare key stays on the hook,” he said.

Povolny recommended checking authorised SSH keys on machines accessible to affected developers, rotating potentially exposed credentials, and reviewing logs for logins using unfamiliar keys. Developers often have access to source code, cloud accounts, and production systems, he said, making a compromised workstation a potential route to other enterprise resources.

Phorion also advised checking the SSH key’s fingerprint rather than relying only on the comment svc-telemetry attached to it.

Questions raised about extension security

Yash Kadakia, founder and CTO of Security Brigade, said enterprises should treat extension marketplaces as part of the software supply chain.

“An extension marketplace is effectively another software supply chain,” Kadakia said. “When malicious code can reach developers through what appears to be a legitimate, routine update, the traditional assumption that software from a trusted marketplace is safe starts to break down.”

He recommended stronger publisher verification, checks on package integrity, and controls over which extensions and versions developers can install.

Kadakia also called for extension allowlisting, controlled updates, endpoint monitoring, and restrictions on outbound connections. He said short-lived credentials, segregated development environments, and limited access to sensitive infrastructure could reduce the impact of a compromised developer machine. Cursor said it removed the malicious versions, temporarily shut down its marketplace, audited access, rotated keys, and rebuilt the marketplace before restoring the service.

“Yesterday’s price is not today’s price,” a phrase Fat Joe popularized in 2021, reminds us that what worked yesterday may not deliver the same value today.

In cybersecurity, this matters when we continue to assess employees against familiar phishing techniques while attackers use AI to craft more convincing, personalized messages. Having conducted multiple phishing simulations and one in October, 2026, I believe we need to ask a harder question: are we preparing people for the phishing attacks they are likely to face today, or testing their ability to recognize or remember the warning signs we have taught them to expect? What happens when those warning signs don’t apply or they face novel attacks?

AI -enabled “phishing landscape”

The traditional tell-tale signs of phishing which we used to train employees for are becoming less dependable. Generative AI can help attackers produce convincing messages, personalize lures and improve the quality of their communication. This does not mean every phishing campaign uses AI in reality, but it raises the bar for what employees may encounter.

A 2025 report by SC Media covering Egress research found that 75% of the phishing kits examined on dark-web markets advertised AI capabilities, while 82% offered deepfake features. These figures relate to the kits analyzed, rather than all phishing activity, but they show that AI-enabled features are appearing in tools available to criminals. Add this to the spike in recent phishing attacks with AI prompt injections and you realize quickly the landscape has morphed.

This matters for awareness programs. If employees are mainly taught to look for spelling mistakes, generic greetings or suspicious formatting, they may be less prepared for a message that uses familiar names, relevant business context and professional language when attackers use AI to craft them. Training needs to emphasize verification in addition to simply recognition and unexpected requests should be checked through a trusted channel, even when the message appears legitimate.

Click rates are not everything

Phishing simulations often produce a straightforward headline and statistics: the percentage of recipients who clicked a link, entered credentials and deleted or reported the message. They are easy metrics to communicate, compare and track over time and also to present to Senior Management in meetings but it provides only one part of the picture.

Imagine two groups with the same click rate. In one, employees who suspect a message report it quickly, allowing the security team to investigate, detect other people who may have received it and warn other recipients. In the other, people delete the message or ignore it without reporting it. The click rates may look identical, but the organization’s ability to detect a real campaign is different.

Reporting rates and time to report therefore deserve more attention. Security teams should understand whether employees use the approved reporting channel, how quickly suspicious messages reach analysts and whether those reports lead to effective action. The National Cyber Security Centre’s guidance on phishing provides practical advice on recognizing and reporting suspicious messages and organizations should have this on their website or HR portals.

As I have seen in multiple simulations I have conducted,  results also need careful interpretation. A test is a controlled exercise, not a guarantee of how someone will behave during a real attack, which could depend on the recipient’s state of mind. Employees may recognize familiar templates or learn the patterns used in repeated campaigns. Clicking a simulated link also does not automatically mean someone would compromise the organization in a real incident.

The objective should be to identify weaknesses and improve security, not to rank employees by how often they pass or fail, and this should reflect in the way messages about failure are passed on.

Test the response and the person

Phishing simulations should evolve alongside the threats they are intended to represent. Scenarios should reflect realistic business situations, including unexpected document sharing, supplier requests and attempts to impersonate trusted colleagues instead of clicking links or supplying credentials only. Employees should learn how to verify unusual requests and report suspected attacks without fear of embarrassment or punishment. From experience, this may have many moving parts, like custom mailboxes, a departure from the simulation norm and multiple levels of approval before exercises like this can be done but it’s worth the effort.

Security teams should also evaluate what happens after a suspicious message arrives. How quickly is it reported? Can analysts identify and contact other recipients who possibly responded to the message? Can the organization remove the message from inboxes, block malicious infrastructure and investigate potential account compromise? These questions connect awareness testing to operational readiness.

The same principle applies to incident exercises. Security, IT, finance and relevant business teams should know what to do when a real phishing attack succeeds, which it inevitably will, someday. A program that improves reporting and response can deliver value even when it cannot prevent every employee from clicking.

AI will continue to change how phishing messages are created and delivered and security awareness must change with it. The question is whether the organization can verify suspicious activity, detect an attack and limit its impact when the message looks entirely legitimate and is prone to being clicked as a result.

Yesterday’s tests can still teach useful lessons but should not define tomorrow’s readiness.

A pull request adds a helpful setup step for an AI coding assistant. No application source changes. The description calls it a developer-experience improvement, and the reviewer sees a short configuration file beside some Markdown instructions.

Before approving it, the reviewer needs to answer a different question: what will this change allow to run on a colleague’s machine?

The issue has moved beyond hypothetical repository poisoning. In an October 8 analysis of agent-skill distribution, StepSecurity revisited the June Miasma campaign, which planted AI-tool and editor configuration in a Microsoft repository without modifying application source. The configuration was intended to trigger credential harvesting through developer tooling. The October publication describes an inventory product, but the underlying campaign illustrates a wider operational problem: merging a configuration change can distribute execution instructions to the people working in that repository.

StepSecurity also reports that the commit carried a skip-CI flag and a backdated timestamp, and that it moved code execution from package install to folder open. A control that runs only in the build pipeline never sees that path. The first reliable checkpoint is the pull request, and it needs a person who knows what the file can trigger.

I recommend giving these changes a named owner and an enforceable review path. An organization should be able to identify who approved a hook, what the approval covered and where the approved version is allowed to run.

Review the behavior behind the filename

A repository file can serve several purposes. It may describe a coding convention, direct an agent toward a script, register a tool or arrange for a command to run at a lifecycle event. Those differences matter more than the extension.

A Markdown instruction is not automatically executable code. It can nevertheless influence an agent that has permission to execute commands. A JSON setting may directly register a shell command. Review should establish the mechanism, the trigger and the authority available when it fires.

Skills show why the filename is a poor guide. StepSecurity notes that a skill’s allowed-tools field can let the agent use listed tools without a permission prompt during the turn that invokes the skill, and that Claude Code’s documentation says workspace trust does not gate that field. A SKILL.md file is Markdown, so in a pull request it tends to be reviewed like a README.

Anthropic’s current hooks reference states that command hooks run with the user’s permissions. It also distinguishes interactive workspace trust from noninteractive operation: settings-file hooks in a repository can run in a noninteractive session without the trust dialog shown to an interactive user. The exact behavior depends on the configuration surface and session type. A control tested at a developer’s terminal should therefore be retested in the automated workflow that uses the same repository.

The same page names practical mitigations. Before scripting a noninteractive run over a repository nobody on the team wrote, review its .claude settings files, start the run in bare mode or turn hooks off for that run. Administrators can also use the managed-hooks-only setting so that user, project, local and plugin hooks are blocked. Which of these fits depends on the organization’s tooling, and each should be tested rather than assumed.

For a proposed setup hook, the reviewer should be able to trace the command to its script and dependencies. If the script downloads another program, determine how that program is selected and verified. If it reads credentials or accesses the network, ask why the setup step needs those capabilities.

These questions should accompany the change while its author can explain the intent. Discovering them after distribution leaves every affected developer to make an individual trust decision.

Make ownership enforceable

Engineering productivity teams are often best placed to maintain shared coding-assistant configuration. Security should define the conditions that require a second reviewer, such as adding executable hooks, broadening network access or invoking a new external tool. The application team remains responsible for whether the integration belongs in its workflow.

This need not create an approval queue for every formatting preference. Define the behavioral changes that warrant scrutiny and route those changes to people who understand the tooling.

GitHub’s code-owner documentation explains how ownership rules work with required reviews. A CODEOWNERS file alone does not make its approval mandatory; the corresponding branch protection must require it. GitHub also recommends protecting the ownership file itself.

Apply the chosen mechanism to the agent configuration and the scripts it invokes. Protecting a settings file while leaving its referenced helper script outside the review rule creates an obvious gap. Check the effective rule with a sample pull request rather than relying on the presence of a policy file.

Allow legitimate changes to move quickly through a known path. The reviewer should receive a concise explanation of the trigger, required access and expected side effects. A hook that formats changed files should not need the same justification as one that contacts an external service or modifies a user’s global configuration.

Check what the developer environment actually loads

Repository review covers only part of the environment. Developers can also install shared skills, plugins and user-level configuration outside a project. An approved repository may therefore run alongside additional instructions that its maintainers have never reviewed.

Establish a baseline for the supported tools and launch methods. Record the origins and versions of approved additions, and provide a way to inspect the effective configuration. When local copies differ, compare the content before deciding that the difference is malicious or harmless.

Microsoft’s Workspace Trust guidance for Visual Studio Code describes Restricted Mode, which limits features that can execute workspace content. It also warns that a malicious extension can ignore that boundary. Workspace trust is a useful control within its documented scope; it should be paired with a deliberate extension policy and an environment appropriate to the repository being inspected.

Use unfamiliar repositories in an isolated environment without routinely mounted production credentials. Avoid treating a container as sufficient isolation if it inherits the developer’s secrets or access to the host. Review those connections explicitly.

For approved daily work, make the safe setup practical. Publish maintained configurations, explain how to request an addition and provide a clean inspection workflow. If compliance requires developers to reconstruct their environment manually every morning, it will be difficult to sustain.

Test the approval path before trusting it

Run a benign exercise in a disposable repository and isolated environment. Add a hook that writes a harmless marker file. Check whether the pull request reaches the intended owner, whether an unapproved change can merge and whether the installed tool permits the marker action under the documented launch conditions.

Repeat the exercise through the noninteractive route if the organization uses one. Then change only the referenced helper script. That second change tests whether the review boundary covers behavior as well as configuration.

The result should identify which controls prevented execution and which merely recorded it. A scanner alert, required review and runtime restriction perform different jobs. Record the gaps without presenting one as a substitute for all the others.

Three questions make a workable first review. Who can merge a change to the files that steer our coding assistants? Does that rule also cover every script those files call? Which of our automated jobs run the assistant over code we did not write, and do they apply the same trust checks as a developer’s terminal?

For security leadership, the useful measure is whether changes capable of altering execution reach the right reviewer before distribution, and whether the working environment matches the approved scope. Start with one supported coding tool and one engineering team. Ask them to demonstrate who can change its behavior, how that change is approved and what happens when someone tries to bypass the process.

Equifax CISO Jeremy Koppen sees the same dynamics most security chiefs are facing: hackers on the one side using AI to perform more sophisticated attacks at unprecedented speed, and defenders on the other adopting AI to match that volume and velocity.

“AI is changing the pace on both sides,” he says. “Attackers are using it to operate at greater scale, and Equifax is using it to innovate more quickly.”

In the next year, Koppen will continue to evolve Equifax’s security strategy to keep with an accelerating threat environment.

“That means building on the security already embedded across our design and development process, so checks run early and automatically,” he says. “It also means expanding how we use AI in our own security operations to handle routine work, so our experts can focus on the threats and initiatives that matter most. Done well, security becomes one of the reasons a product can launch sooner.”

As for the rising tide of AI agents entering enterprise workflows, Koppen says that “identity controls are central” to his 2027 security strategy.

“Across the industry, more activity on enterprise networks now comes from AI agents, bots, and automated workflows, and most traditional security controls were designed with a human user in mind,” he explains. “That’s why we’re applying the same rigorous verification to these identities that we apply to people.”

Of course, Koppen, like other seasoned security leaders, knows his IT security strategy must evolve to address more than just AI. Geopolitics, the anticipated arrival of quantum computing, and increasingly interconnected systems, are also changing the threat landscape and attack surface — sometimes in radical ways — and should prompt strategic changes, too.

That in turn is putting pressure on CISOs to rethink their practices, policies, and approaches as we head toward a new year likely to be at least as wild of a ride as 2026 has been.

“CISOs realize they need to transform, because their current state isn’t working. And it’s going to be a pretty significant transformation over the next few years for CISOs to be successful,” says Omar Khawaja, a CISO, a faculty member at Carnegie Mellon University’s CISO program, and a board member at HITRUST and FAIR Institute.

Of course, transformation, as always, is a work in progress, Khawaja says; as a result many security execs are still working out what needs to change in 2027 and how to make those changes happen.

Still, Khawaja, Koppen, and others stress that transformation is not an option; the safety of the organization depends on strategic evolution from its cybersecurity teams.

So what exactly needs to change? Security leaders point to specific elements that won’t work as well in the year ahead and what needs to be in place instead to more adequately secure the organization in 2027 and beyond.

Static credentials need to go

Koppen believes static credentials are on their way out.

“No matter how strict the policy, passwords still end up looking like a favorite sports team or the current season with an exclamation point at the end. That makes them trivial targets for brute-force attacks,” he says, noting that his company eliminated passwords across its 22,000 employees and contractors and is now extending its passwordless standard to its B2B customers.

More manual SOC work must be automated

The new command for security teams is to move at machine speed.

“We’re not able to deal with attacks and vulnerabilities manually anymore. AI is making that impossible,” says Florida State University CISO Bill Hunkapiller.

His security strategy reflects this new reality. He has been implementing autonomous agents to replace routine security operations tasks, and his 2027 plans call for expanding the number of tasks handled by machines.

Most CISOs are on this path. The State of Incident Response Readiness from Sygnia found that 32% of organizations have extensive AI use across most or all threat detection and incident response (IR) activities, up from 25% in 2025. And 63% expect to have extensive AI use in place for threat detection and IR activities in 2027.

Generic severity scores are out, risk ratings tailored to the organization are in

Equifax’s Koppen declares that generic severity scores are no longer effective. “A vendor’s ‘critical’ rating doesn’t know if a system holds sensitive data, is externally facing, or sits behind other controls,” he says, noting that Equifax has its own quantitative risk engine that factors in that context so its teams “can focus on issues that pose real risk to the business.”

Hunkapiller, who is also chief privacy officer and an adjunct professor at FSU, also sees a need to understand how common vulnerabilities and exposures pose a risk to his organization in particular, rather than relying on ratings. To that end, he’s exploring services that could create a digital twin of his environment to simulate how hackers could exploit vulnerabilities in his organization. This service would give Hunkapiller near-real-time information on which vulnerabilities pose the most significant risks to FSU, allowing him to accurately prioritize fixing those quickly, he says.

Thus far, he’s impressed with the capability, saying it’s like “attack surface management on steroids.”

Continuous patching is now the goal

Security used to have Patch Tuesday, a moniker that reflected the regularly scheduled work of applying newly released fixes to software flaws. Although security teams today may not adhere to Tuesday specifically for the work, many still patch on a set schedule — and many still take weeks to patch. Verizon’s 2026 Data Breach Investigations Report puts the median time to remediate known exploited vulnerabilities at 43 days, up from 32 days in 2025.

That won’t fly in 2027, says Hugh Thompson, program chair for the RSA Conference.

“We used to do patching very methodically. If a patch came out for a system, we didn’t want to roll it out right away [for fear] it could break something. So we took time and tested it out and scheduled the work. That’s not going to work now, because the speed at which these AI attackers can take advantage of vulnerabilities or discover new ones is greater than ever,” he says. “We need automation in patching.”

Jason Rader, CISO for technology solutions and systems integrator Insight, has been accelerating his company’s patching program, bringing patch windows down to seven days for its most critical components — a significant accomplishment given the size of the IT environment and the number of patches being released. Still, he wants to do better, saying he’s aiming to increase speed for patching in all areas of the IT environment in 2027 and noting that he’d like to eventually get to continuous patching.

Different treatment for agent and NHIs needs to end

With AI agents doing more work that was, until recently, performed by humans, it’s becoming increasingly clear that security can’t treat machine identities — whether agents or systems or APIs — differently than humans, Rader says.

To that end, he’s already “managing agents like people,” applying equally diligent attention to managing identity and associated permissions — and, thus, access to data and systems — to ensure that each entity can access only what is appropriate for its role.

This includes managing machine identities throughout the lifecycle of those machines, just as security should for human workers, and applying proper governance, Rader adds.

Agility and adaptability must be part of the 2027 strategy

Some CISOs still take a set-and-forget approach to policies, procedures, and standards, says Prakash Venkata, a cyber, data, and tech risk partner at PWC and the firm’s security, risk, and engineering practice leader.

That approach never worked well, as there has always been a need to improve and evolve policies, procedures, and standards as the threat landscape and the attack surface changed, Venkata explains. But the pace of change now is so fast that CISOs need to build agility and adaptability into their strategies simply to keep up and meet industry standards.

Thompson likewise preaches the need for more agility in security strategies and advises security leaders to “be prepared for agility more than we had to or could stomach in the past because problems will emerge that you can’t anticipate.”

He notes, too, that CISOs need to work with other departments, such as procurement, to bring that needed agility to security. For example, if the CISO needs to quickly buy and implement new technology to reduce a recently identified risk or defend against an emerging threat, CISOs will need procurement procedures to move as fast as security must move.

Detached AI security and governance strategies become obsolete

There has been a rise of AI governance and security strategies that are detached from the organization’s overall governance and security strategy, says James Lyne, CEO of SANS, a security training and certification organization.

Lyne believes that the attention on AI governance and security is critical. However, he thinks having fully segregated AI governance and security strategies will be increasingly detrimental in 2027 and beyond. That’s because they’re not different and separate from enterprise governance and security.

“An AI app exposed to malicious inputs is an app security problem,” he says. “AI agents accessing unauthorized things is a privilege management and operation security issue [no less than] if people had unauthorized access.”

To ensure organizations have an effective, coordinated approach to governance and security capable of protecting the entire organization, where elements work together with no siloes or redundancies, CISOs and their organizations need a unified security strategy that addresses all actors — “whether they’re human, software services, or AI agents, or automated workflows,” he says.

One platform or four

Your WAF renewal is coming up. The API team has its own tooling in mind, the fraud team wants a bot product, and someone in networking owns DDoS. Four controls, four consoles, four sets of policies in front of the same applications. That is the situation a Web Application and API Protection platform, or WAAP, exists to replace: one service in front of the application portfolio that handles the WAF, API security, bot management, DDoS, and client-side script protection together.

The category is settled. What changed in 2026 is the evidence. Buyers now have certified test data that measures how well these platforms stop attacks and how often they stop legitimate traffic by mistake, and the two numbers together tell you more than any feature list.

What the test data shows

The SecureIQLab Cloud WAAP v5.0 validation, an AMTSO-certified test published in August 2026, ran 12 enterprise platforms through 1,608 attack scenarios and 1,487 legitimate-traffic scenarios. Complete Security Scores ran from a perfect 100% for the top product down to roughly 61% for the weakest. The spread inside a typical shortlist is that wide, and a shortlist drawn up in 2023 or 2024 may no longer describe the products on it.

The second number matters as much as the first. A platform that blocks every attack and also blocks legitimate requests cannot stay in blocking mode for long, and false positive avoidance varied almost as widely across the same twelve products. Those percentage points become alerts, tuning hours, and exceptions your team carries every day.

3 questions for every vendor on the list

Ask for API coverage protocol by protocol. REST is one protocol among several in a modern estate; GraphQL, SOAP, WebSockets, and gRPC all carry production traffic, and the v5.0 results showed coverage varying widely by protocol inside a single product, with WebSockets the weakest area across the group. A headline API score hides that.

Ask how long it takes to reach a tuned, low false-positive state on your traffic, and measure it over two full weeks of real traffic during the proof of value. Time to protection and tuning effort are the costs you pay after the contract is signed.

Ask how the deployment and licensing model behaves as the portfolio grows. Each delivery model, SaaS, native in-cloud, or reverse proxy, has its own latency and onboarding profile, and each licensing unit, request, bandwidth, or application, bends the cost curve differently as traffic grows. Model 24 to 36 months of growth with each vendor, starting from your own traffic baseline.

Where Imperva fits

Imperva, part of Thales, delivers Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, and Client-Side Protection as one platform, with one policy model and one set of analytics across all of them, deployable as SaaS, on your own infrastructure, or natively inside the public cloud.

In the SecureIQLab v5.0 cycle, Imperva was the only vendor of the twelve tested to record a perfect 100% Complete Security Score, and it paired that with a 100% false positive avoidance score, the lab’s measure of legitimate traffic passed untouched. It was Imperva’s fifth consecutive Leader-category placement in the series, and the lab awarded it the Secure by Default rating in the same cycle. Forrester named Imperva a Leader in The Forrester Wave™: Web Application Firewall Solutions, Q1 2025.

An honest aside: no one platform suits every environment. If your dominant requirement is a developer-centric edge platform or raw DDoS scrubbing capacity above everything else, weigh those needs explicitly, and validate any shortlist, Imperva included, against your own traffic in a proof of value.

The full comparison

The complete buyer’s guide on the Imperva blog compares seven WAAP vendors on security efficacy, API protection, bot defense, operational efficiency, and cost, with analyst standing and verified peer ratings for each, and ends with a proof-of-value checklist you can take into your next evaluation. Read Best WAAP Solutions for Enterprise Application Security: How to Choose the Right Platform in 2026 before you renew anything. Then go back to the four consoles and decide how many you still need.

The identity landscape you’re responsible for looks nothing like it did just a few years ago. Employees and contractors now share the enterprise with service accounts, machine identities, and a fast-growing population of AI agents — all accessing business systems and data.

Every one of those identities represents an access decision, and every access decision is now a potential point of accountability that lands on your desk. Regulators and boards want proof. They expect security leaders to show who, or what, has access to critical systems and how that access is being governed.

But when human and nonhuman identities (NHIs) change faster than manual processes can keep up, proof becomes much harder to produce. Foundry research ranks identity security among the top cybersecurity priorities for 2026, reflecting a shift in how leadership views risk: Identity has evolved from operational detail to executive concern.

“The last 15 years of digital transformation has resulted in credential sprawl across the tech stack of every organization,” says Bryan Kelley, AVP, Agentic Technology Specialists at SailPoint. “Whether it’s your own trusted agents or another organization’s rogue agent, they will find and abuse these exposed credentials, API keys, tokens, and secrets to carry out their given goals.”

When accountability becomes personal
Security leaders must demonstrate that identity governance is working, not simply that policies exist. They need a real-time view of each identity and the permissions it holds as business needs change.

Leaders can also face personal and professional consequences when a breach or a compliance failure occurs. Boards and regulators may expect the C-suite to show that appropriate controls and oversight were in place at the time.

AI agents add to that exposure as they gain access to enterprise resources and take on more autonomous roles. This is why NHIs need the same rigor, visibility, and controls as human identities.

The shift to continuous compliance

Quarterly or annual access reviews capture a moment in time, but it’s all the other moments in between that present a problem.

Between reviews, employees can change roles, contractors can leave, and new identities such as AI agents can gain access. Security teams may not catch outdated permissions or active orphaned accounts until the next review. When identity data lives in separate systems, security teams struggle even more to maintain a current view of access across the enterprise.

Continuous identity security makes oversight part of daily operations. Rather than waiting for the next review, an identity governance platform can help validate access as conditions change, automating low-risk approvals and flagging higher-risk access for review.

Governance activity also creates an ongoing record of how access was approved and whether policies were applied consistently, so teams don’t have to reconstruct that history when auditors or regulators ask for evidence.

Building an adaptive identity security program
A continuous approach is made up of three core capabilities. First, organizations need to discover and unify identities to create a centralized view of access. Second, lifecycle management, policy enforcement, and access validation become always-on activities rather than periodic projects.

Finally, organizations need to maintain evidence of governance activity so they can demonstrate compliance and respond when issues arise.

This approach helps security leaders keep up with constant identity changes while meeting rising expectations for accountability. Learn how continuous identity security can help strengthen oversight and audit readiness.

Continuous identity governance is the operational model that enables organizations to validate access in real time, rather than relying on scheduled reviews to catch problems after they’ve already occurred. It replaces quarterly certifications and annual audits with ongoing visibility, automated policy enforcement, and always-current evidence of who, or what, has access to critical systems.

For CISOs, this shift matters now because the identity landscape has outgrown the tools built to govern it. Employees and contractors now share the environment with service accounts, machine identities, and autonomous AI agents, all requesting access at a pace no manual review cycle can track.  When governance happens only periodically, the gap between review dates becomes an exposure window that boards and regulators increasingly expect security leaders to own.

Why periodic reviews can’t keep up with modern identity environments

Point-in-time governance was designed for a slower enterprise, one where roles stayed fixed and headcount changed gradually. That world no longer exists.

Consider what can change during a typical quarterly review cycle:

• Employees change roles and inherit access they no longer need.
• Contractors finish projects but retain system access.
• Cloud applications get deployed by individual business units without central visibility.
• Service accounts and machine identities get provisioned to support automation.
• AI agents are created and granted access to enterprise data and workflows.

Each of these events creates drift. By the time the next review happens, unnecessary privileges have accumulated, and orphaned accounts may have gone unnoticed for weeks or months. A checklist reviewed once a quarter simply can’t catch what changes in between.

Identity governance is now a matter of executive accountability

Boards and regulators no longer accept policies that exist only on paper. They want proof that governance is operating, continuously, not just evidence that a review took place last quarter.

This marks a structural change in what CISOs are expected to demonstrate:

• Who or what has access, right now: Not a snapshot from the last audit, but current, accurate visibility.
• Why that access exists: A defensible rationale tied to business need and policy.
• How access is continuously validated: Evidence that governance adapts as roles, systems, and risk change.

Non-human identities raise the stakes further. As agentic AI and machine accounts multiply, they become primary attack vectors precisely because they’re the identities most likely to fall outside the scope of a quarterly review.

What continuous governance looks like operationally

Continuous identity governance isn’t a bigger version of the old audit. It’s a different operating model built on three capabilities:

1. Discover and unify. Continuously identify every identity, human and non-human, and bring them into a centralized system of record. Fragmented visibility across HR systems, procurement tools, and application teams make it nearly impossible to see the full scope of access.
2. Govern continuously. Automate lifecycle management and validate access as business conditions change, rather than treating governance as a periodic project.
3. Demonstrate and respond. Produce system-generated, audit-ready evidence on demand, and flag policy exceptions before they escalate into findings.

Organizations that build these three capabilities into daily operations reduce the time between a governance issue emerging and corrective action being taken, which directly reduces risk.

Adaptive identity as the operating model for continuous compliance

Adaptive identity is what makes continuous governance achievable at enterprise scale. Rather than relying on static permissions, it dynamically adjusts access based on changing business context and risk signals, while maintaining the oversight boards and regulators expect.

This is where a unified platform becomes a true differentiator. Governing access well requires more than a list of entitlements; it requires understanding the full context behind every decision, including the sensitivity of the data involved and the behavior patterns of the identity requesting it. That context doesn’t come from stitching together separate identity, security, and compliance tools after the fact. It comes from a single control plane where that intelligence converges natively.

SailPoint Atlas provides this foundation. As a unified platform, it brings human, third-party, machine, and AI identities under one control plane, replacing fragmented, reactive audits with continuous compliance evidence. AI-powered automation analyzes access trends, automates low-risk approvals, and flags anomalies as context changes, allowing governance to scale without increasing manual review burden.

Test your organization’s governance maturity

Before your next audit exposes a gap, ask whether your team can confidently answer these questions:

• Can we centrally identify every identity operating across our environment?
• Can we demonstrate who, or what, has access to critical systems at any given time?
• Is our approach to access static, or is it truly adaptive?
• Can we quickly produce the evidence auditors and regulators require?
• Do we have the unified foundation needed to adapt to evolving regulations?

If any of these questions gives you pause, it’s worth taking a closer look. The 2-page guide, “5 identity security questions CISOs must be ready to answer,” offers a practical framework for pinpointing exactly where those gaps exist.

Build your foundation for continuous compliance

Reducing executive risk starts with moving governance from a scheduled activity to an operational discipline, one that produces evidence continuously instead of scrambling to reconstruct it after the fact.

Download “The new era of executive risk: Why identity security must be continuous” to learn how a unified, adaptive identity platform helps you replace point-in-time audits with the continuous oversight your board, regulators, and stakeholders now expect.

Linux servers running Multipath TCP (MPTCP) could be vulnerable to remote code execution through a flaw in the kernel’s networking stack.

Anthropic has disclosed a zero-click exploit developed with an unreleased Claude research model that allows an unauthenticated attacker to execute arbitrary commands as root, without requiring any user interaction.

Tracked as CVE-2026-98432, the vulnerability is a race-condition-induced use-after-free (UAF) bug in the Linux kernel. Anthropic demonstrated how an attacker could exploit the flaw remotely to leak kernel memory, defeat Kernel Address Space Layout Randomization (KASLR), hijack kernel control flow, and ultimately execute an attacker-controlled shell command.

The research is part of Anthropic’s broader effort to evaluate AI models’ ability to discover and exploit vulnerabilities in widely deployed software. The company disclosed five exploit chains involving Chrome, Safari, Android, Windows, and Linux to demonstrate how its internal model could combine multiple weaknesses into functional attacks.

Anthropic’s proof of concept for the Linux exploit took approximately 53 minutes to progress from the initial memory leak to successful root-level command execution, the company said in a blog post.

A TCP connection race leaves kernel memory exposed

According to a Linux kernel CVE advisory, the underlying flaw involves how Linux manages IP options during IPv4 TCP connection establishment. When a new connection is created, the kernel can transfer ownership of IP options from a pending connection request to the newly created socket without making a separate copy.

The problem arises when another CPU is simultaneously processing a retransmitted connection request and using those same options to construct a synchronize-acknowledge (SYNACK) response. If the child socket is freed before the second CPU finishes accessing the options, the kernel can end up reading memory that has already been released.

This creates a use-after-free condition. The upstream fix addresses the memory-management problem by deferring the release of the affected objects until after a read-copy-update (RCU) grace period, giving concurrent readers time to finish accessing them.

The flaw received a critical severity score of 9.8 and affects eight Linux kernel branches, dating back to version 4.4. Fixed releases include 5.10.272, 5.15.223, 6.6.159, 6.1.190, 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7.

For users who obtain Linux through distributions such as Debian, Oracle Linux, SUSE, and Amazon Linux, fixed kernel packages are available for at least some releases. Ubuntu and Red Hat Enterprise Linux, however, had yet to release patched kernels as of October 30.

MCTCP listeners create the remote attack surface

Anthropic’s exploit specifically targets Linux servers running an MPTCP listener. MPTCP extends conventional TCP by allowing a device to use multiple network interfaces simultaneously within a single connection. This enables bandwidth aggregation, improved network selection, and failover when one network path becomes unavailable.

Linux implements MPTCP through its networking stack, but the protocol is opt-in: applications must explicitly request it when creating sockets, although mechanisms such as eBPF and other configuration techniques can also force applications to use it.

Administrators are advised to review their kernel versions, apply the relevant security updates, and assess whether their systems expose MPTCP listeners.

A trillion-parameter AI model that its developer says could help attackers carry out real cyberattacks is now free to download, modify and run outside the developer’s control.

Mistral AI released the open weights of Mistral Large 4, which it calls “Le Chonk,” on Thursday, weeks after putting the multimodal model into public preview. The Paris-based company said it had monitored cybersecurity-related use of the preview in live traffic.

“Though we observed the model refusing to comply with black-box attacks against live targets, we see a potential for uplift to conduct real attacks,” the company wrote in a blog post announcing the release.

Mistral is modifying the model’s guardrails and will keep updating them in the coming months, the post added.

Guardrails stop at the API

Those updates will not reach copies already downloaded. Pierre Stock, Mistral’s vice president of science, told CSO that the model ships with safeguards built into its weights, but later changes will go elsewhere.

“Subsequent safeguard updates are applied to our managed API and future model releases, rather than automatically updating downloaded checkpoints,” Stock said.

Asked which attack stages the model had meaningfully helped with in preview traffic, Stock did not name any. He said the most significant gains were in defensive work such as identifying, reproducing and remediating software vulnerabilities.

“While our public-preview monitoring showed the model refusing attacks against live targets, we recognise the potential for misuse as capabilities advance and are continuously strengthening our safeguards,” he said.

Hugging Face, which hosts the weights, noted in its own launch post that open weights put both the usage policy and the deployment under the user’s control.

In July, the UK’s AI Security Institute reported that leading open-weight models trailed the closed frontier on cyber tasks by four to seven months. For highly cyber-capable models, open release creates “a persistent and irreversible risk of misuse,” the institute said.

Attackers are already putting open-source AI tooling to work. Earlier this month, Microsoft said a China-aligned group used the agentic AI framework ARTEX to target more than 2,250 Microsoft 365 tenants.

Mistral says the released model can tell defensive work from malicious requests. According to the company, Large 4 refused 96.6% of malicious prompts in the cyber-related portions of the JailbreakBench, StrongREJECT and AgentHarm benchmarks, the highest rate it has measured among open models.

Niyati Daftary, principal analyst at Gartner, said security leaders should read that number narrowly.

“Mistral’s 96.6% figure tells you what their model does in their test scenario, not how it will behave with your data, your adversarial use cases or in production in your environment against motivated attackers,” she said.

Mistral is handling a specialized cybersecurity variant differently. Design partners such as Orange Cyberdefense are getting preview access to a version optimized for penetration testing, vulnerability assessment and red-teaming, the company said. Access is “subject to rigorous vetting and contractual safeguards,” the post said, and is limited to systems partners own or are authorized to test.

Benchmarks and EU obligations

The company said the model scored 51% on the Artificial Analysis Cyber Index, which measures how well a model finds, reproduces, and patches vulnerabilities. The chart in Mistral’s post shows two open-weight models, DeepSeek V4.1 Flash and MiMo-V2.6-Pro, scoring higher.

Mistral also calls Large 4 the best open-weight model for coding, citing leading scores on Cognition’s FrontierCode 2.0 and Terminal-Bench 4.0. It has not yet published the technical report behind those results and has said only that one is coming soon.

“Without a detailed technical report, the best open-weight model claim remains difficult to validate across workloads,” said Charlie Dai, vice president and principal analyst at Forrester.

Dai added that frontier models are evolving so quickly that leadership “can shift within months or even weeks.”

Stock said the report will document Mistral’s cyber evaluation methods and results, refusal testing and preview monitoring findings. Mistral also intends to share relevant adversarial testing findings “while safeguarding sensitive security information,” he said. He did not give a publication date.

ENISA, the EU’s cybersecurity agency, said in a statement published with Mistral’s announcement that it is testing the model to identify vulnerabilities, audit code and analyze defensive logs.

Under the EU AI Act, models trained with more than 10^25 floating-point operations (FLOPs) are presumed to carry systemic risk, according to the European Commission. Their providers must assess and mitigate those risks, report serious incidents and maintain cybersecurity protections. Mistral’s post does not say whether Large 4 falls into that category or what risk assessment preceded the release.

Stock said Mistral is a full signatory of the EU’s General-Purpose AI Code of Practice, including its safety and security chapter, which the Commission accepts as one way to demonstrate compliance. He did not say whether Large 4 has been classified as a systemic-risk model.

What it means for enterprises

Mistral released the model under a modified MIT license that permits use, modification, fine-tuning, and commercialization, the company said. Businesses running a model-as-a-service offering need a separate license. For those who would rather not host it, Mistral’s API is priced at $0.70 per million input tokens and $2.10 per million output tokens.

For European buyers, sovereignty is “a meaningful differentiator, but it should not outweigh security concerns,” Dai said. Open weights and self-hosting shift responsibility for guardrails, access controls, monitoring and misuse prevention to the operator, he added.

“Sovereignty and security therefore need to be evaluated together, not traded against each other,” Dai said.

Daftary said enterprises self-hosting Large 4 for code audit or vulnerability triage should run it as a controlled component, not an autonomous agent. That means isolated environments, least-privilege access to code and credentials, sandboxed generated code, and human sign-off before any remediation, she said. “Self-hosting can improve data control and operational continuity, but it also makes the enterprise solely responsible for patching, monitoring, evaluation and misuse prevention,” she said.

The first hours after a serious cyber incident are filled with activity. Security starts investigating, IT works to contain the impact, legal begins assessing potential obligations, and executives want to know what happened and what the company is doing about it. Most teams rely on the same tools they use every day to coordinate that work, which usually means email, Slack, Teams, shared documents and video calls.

Coordination gets much more complicated when the company’s email or collaboration environment is part of the incident. Email may still work, employees may still be able to join meetings, and nothing on the surface may suggest that the organization has lost control of its communications. Meanwhile, an attacker with access to accounts used by responders may read the team’s messages, monitor containment plans or impersonate someone involved in the response.

When that happens, the company faces a second crisis inside the first. The systems people depend on to manage the incident can no longer be trusted.

After more than two decades in the privacy and breach space, and in my weekly conversations with security and legal teams, I see the same pattern. Most incident response plans account for email or collaboration tools becoming unavailable. Teams have phone trees, personal contact information and backup conference lines. They know whom they need to call. What they often lack is a systematic approach for the harder case. Far fewer plans address the more ambiguous situation in which those systems remain functional while the organization can no longer be certain who is reading, sending or altering messages inside them.

That scenario requires a preplanned way to move the response out of band while investigators determine what has been compromised.

When the attacker may be inside the response

This problem is easy to see during ransomware. Systems go down, employees lose access and the need for alternative communications becomes obvious. Compromised communications make judgment harder because the affected environment may appear completely normal.

Suppose the security team discovers that an attacker has gained access to email and collaboration accounts used by incident response team members. The team needs to determine the scope of that access, remove the attacker and contain the intrusion, but discussing those actions in the regular incident channel could tell the attacker exactly what is coming. Legal needs the latest facts to evaluate notification requirements, the comms team is preparing for questions from customers, and leadership expects regular updates. Every one of those conversations may reveal something valuable to the person the company is trying to remove. The attacker is in the meeting.

Responders then must answer a basic question before they can safely coordinate anything else: Who can see what we are saying?

Countless companies rely on Teams or Slack during incidents because those are the systems their employees already use. The tradeoff is that the response stays inside an environment the attacker may already access and has every reason to monitor. I’m aware of several cases where attackers joined or recorded Zoom and Teams bridges used for incident meetings.

What was already said

As I discussed in my previous CSO article, putting a lawyer in a large incident channel does not make every conversation privileged. Operational facts and legal advice serve different purposes, and a crisis does not remove the need to control who participates in sensitive discussions. If the attacker was reading the channel, assume that every containment plan, every candid assessment of how the intrusion happened, and every draft customer statement posted there is now outside the company. Some of it may surface in an extortion demand. All of it may surface in discovery.

Plan as though the company will end up in court. The out-of-band channel should give teams a place to separate operational coordination from legal analysis, limit participation and begin building the record that regulators and plaintiffs may later examine: what was decided, by whom, on what facts and why. Legal should design that structure before the incident. Trying to create it during one, in a channel the attacker may be reading, compounds the problem.

What an out-of-band plan must solve

The mistake I see is starting with a backup application. Start with the failure scenario and map every dependency shared by the primary and emergency communications environments, including identity services, managed devices, mobile device management, administrative credentials and employee directories. If both channels depend on the same underlying component, that component remains a single point of failure.

Then decide how participants will prove who they are. An attacker with access to email or calendars may know that an emergency meeting is taking place and have enough context to impersonate an executive or responder. The verification process cannot depend on the accounts under investigation.

The same preparation should cover outside counsel, forensic investigators, insurers and communications advisers. Maintain current contact information, define who can authorize their participation, and establish how the team will verify them before an incident begins.

Devices also matter. An alternative channel provides little value if responders can reach it only through corporate laptops they have been instructed to disconnect. The plan should specify which devices responders can use and what information they may access through them.

The specific approach will depend on the company’s size, risk profile and existing systems. The test is whether the response can continue without relying on the environment under investigation.

Practice moving the response

Most organizations that test backup communications focus on whether the channel works. They should also rehearse the judgment call that activates it. Participants need to recognize when the primary environment has become untrustworthy, alert the response team without exposing the move, and continue operating in the alternate channel.

A tabletop exercise can begin with evidence that an attacker has accessed email and collaboration accounts used by several responders, even though both services still appear to function normally. The team must decide what evidence is sufficient to trigger the move, who has the authority to make that call, and how everyone’s identity will be verified after they arrive.

The exercise should bring in security, legal, executives and essential outside partners. Add the complications that make real incidents difficult, such as an executive sending conflicting instructions through corporate email, someone joining a meeting from an unfamiliar account, an outdated emergency contact or a third party unable to authenticate.

Those moments reveal whether the company has a working capability or only a document describing one. I would measure how long it takes to recognize the need to move, activate essential stakeholders, establish a verified response group, and brief leadership. Every point at which participants fall back on the affected environment exposes a dependency the written plan missed.

Most incident response plans assume the company will have somewhere safe to coordinate. That assumption deserves the same scrutiny as backups, recovery procedures and containment playbooks. The decision to leave familiar systems should have defined triggers, a clear owner and a destination everyone has already practiced using.

When the communication environment becomes part of the breach, legal deadlines, business decisions, customers and employees do not wait. The company needs to know when to move, where to go and how to keep operating once it gets there.

Something shifted in offensive security over the last eighteen months that most organizations haven’t fully absorbed yet. It isn’t that attackers got smarter. It’s that the economics of attack changed entirely — and those of us who run red teams have had a front-row seat to the transformation.

The conversation about AI in cybersecurity tends to fixate on defense: better anomaly detection, faster triage, and AI-assisted SOC analysts. That framing misses the more urgent story. The attack side of this ledger has already been rewritten. A small, well-equipped offensive team using frontier AI models today can outperform what was possible with a much larger traditional operation just two years ago, by a margin that should unsettle every security leader reading this.

Through our work on the front lines of offensive security, the consensus is clear: if you are not augmenting your operations with AI, you are already at a disadvantage.

Before addressing the operational shift, we must clarify a fundamental distinction that is often conflated in industry discussions:

• AI red teaming: This involves probing Large Language Models (LLMs) for vulnerabilities, testing agentic pipelines, and identifying prompt-injection vectors or unintended behaviors.
• Red teaming with AI: Using AI as an operator’s tool to execute traditional offensive operations.

It is this second category, Red Teaming with AI, where the most immediate, drastic, and dangerous transformation is occurring.

The staggering scale of productivity

AI-augmented operations transitioned from a nice-to-have luxury to a non-negotiable requirement. The democratization of frontier models introduces asymmetry between well-equipped adversaries and traditional defensive teams relying on manual triage.

The productivity leaps we are seeing in the field are staggering. When AI is effectively weaponized by offensive teams, some of the initial findings speak for themselves:

(Data above aggregated by DayBlink Consulting over past 10 years of engagements and validated by Robert Pimentel as representative of his Red team experience.)

AI across the engagement lifecycle

We are no longer just using AI to write phishing emails. Organizations and threat actors alike are adopting a structured approach to integrate AI throughout every phase of the kill chain:

• Pre-operation (setup and reconnaissance): The weeks-long setup phase has been accelerated into mere moments. Gathering Open-Source Intelligence (OSINT), provisioning infrastructure, building organizational charts, and configuring command-and-control (C2) servers can now be delegated to agentic AI. This significantly reduces the time and manual effort needed to get an operation off the ground, though complex infrastructure decisions still require experienced operators. Pre-op usually starts off exciting (new op coming) but often ends in a grind.  We love the acceleration AI has provided here.
• Mid-operation (enumeration and attack): during active engagements, AI acts as a real-time, on-demand expert. Operators use AI interactively to generate custom audit scripts, rapidly adapt strategies, and query unfamiliar technology stacks on the fly. By utilizing an LLMs-as-judges workflow, where one model’s output is vetted by another for correctness and risk before execution, attackers can ensure highly confident, automated actions. Enumeration and attack is where all the excitement and adrenaline happens.  We are using AI to help here, but it’s not replacing us humans (yet).
• Post-operation (reporting and deconfliction): reporting has historically been the most tedious burden of any engagement. Today, nine to ten months of raw C2 logs can be piped into a frontier model to generate a comprehensive deconfliction report in under 20 minutes. These tools can map every executed command to the MITRE ATT&CK framework, cross-reference threat intelligence, and translate highly technical data into clear, actionable narratives for board-level executives. The output still requires manual review. AI gets you to a first draft in minutes instead of days, but an operator needs to verify findings, validate ATT&CK mappings, and ensure accuracy before delivery. Ticketing and follow-up are the bane of most red teams.  AI has become an awesome sidekick to our teams to build our reports and do lots of the tedious work.

The talent divide: judgment as the ultimate differentiator

With AI automating basic enumeration, scanning, and scaffolding, the core red-teaming skill set — critical thinking, architectural understanding, adversarial judgment — is as valuable as it’s ever been. AI doesn’t replace that. But operators who can leverage AI alongside those skills will outperform those who can’t. The differentiator isn’t AI versus no AI; it’s whether you have the foundational knowledge to direct it effectively and validate what it gives you. This is fundamentally shifting the required profile of a successful cybersecurity professional. As a result, the industry is quickly diverging into two distinct categories of practitioners:

1. The “unicorns” (high performers): These are the practitioners who bring critical thinking and deep adversarial judgment to AI. They understand exactly where trust boundaries fail and where architectures are weak. They use AI to execute on these insights efficiently, offloading the busywork to focus on complex exploitation.
2. The “slop cannons”: Operators who use AI as a mindless copy-paste shortcut. They rely entirely on unverified outputs without understanding the underlying mechanics, producing noisy, easily detectable work that wastes time and triggers alarms.

Consequently, hiring practices must change. The primary screening criterion for new talent can no longer be a stack of legacy certifications; it must be their hands-on curiosity, their fundamental understanding of network architecture, and their experience building tools with frontier AI models. Certifications still matter, but hiring must also evaluate whether candidates can think critically about systems and leverage AI tools effectively — not just operate them blindly

Strategic imperatives for 2027

For security leaders looking to survive this paradigm shift, the path forward requires immediate action. Based on our observations, here are the critical priorities for the next 18 months:

• Formalize AI budgets: Access to frontier models is expensive, but it is a necessary operational cost. Teams without the budget to experiment and build will fall behind adversaries.
• Implement continuous, programmatic testing: As enterprises deploy thousands of their own agentic integrations, manual testing is no longer viable. Continuous, automated adversarial testing must become the standard operating procedure.
• Prepare for hybrid threat vectors: As digital perimeters harden through automated defense, attacks will increasingly blend hyper-automated digital exploits with highly sophisticated physical and social engineering vectors.
• Hire for curiosity: Build teams anchored by practitioners who are actively experimenting with AI and possess the high-level judgment needed to guide it safely and effectively.

Organizations that fail to adopt an AI-augmented mindset risk being overwhelmed by adversaries operating faster, smarter, and at an unprecedented scale. Success in the modern cyber landscape relies on one core principle: seamlessly combining elite human judgment with intelligent automation.

In May 2017, the WannaCry cryptoworm spread across the internet, compromising more than 200,000 computers in at least 100 countries. The National Audit Office called it the largest cyberattack ever to hit the NHS in England. At least 80 of 236 hospital trusts were infected or disrupted, an estimated 19,000 appointments were cancelled, five hospitals diverted ambulances, and more than 1,200 pieces of diagnostic equipment were infected.

What stopped WannaCry was a stroke of luck. A researcher reverse engineered the malware, noticed it contacting a domain nobody had registered, and registered it. That evening the original strain stopped locking devices. WannaCry had a kill switch, and we are all fortunate that Marcus Hutchins was able to find it.

As I read agent incident reports from OpenAI and Anthropic, I am reminded of WannaCry. But the threat from offensive agents is not a faster worm. In July, roughly 1,200 OpenAI agents being tested on a cybersecurity benchmark found an unsanctioned message board on an internal software repository, and some broke out to the internet. About 700 of those agents went on to attack Hugging Face, looking for clues to beat the benchmark, according to an independent investigation. Hugging Face disclosed the intrusion on July 16, and OpenAI confirmed its agents were responsible five days later.

Recently Anthropic has had unintended incidents as well. Anthropic’s incidents involved single models rather than a swarm. In cyber evaluations that were accidentally left connected to the internet, individual Claude models attacked real companies’ systems while trying to complete their exercises, and one published a malicious package to PyPI.

Worms like WannaCry exploit a single or small number of vulnerabilities, using a static set of techniques. Agents can read the results of failed attempts, try something else, and pass on what they learned to other agents. Anthropic’s Frontier Red Team evaluated GLM-5.3, an open-weights model from Z.ai that NIST’s CAISI assessed as the most cyber-capable open-weight model released to date. Over a day, with under an hour of hands-on attention, a researcher used it to find several unknown browser vulnerabilities and chain them into an exploit that steals a user’s SSH key. A smaller variant built an exploit chain for two known flaws for roughly $20 at API prices. Simple techniques bypassed its safeguards 64% to 100% of the time in simulated tests, including abliteration, which edits the released weights to strip out refusals.

A high-performing SOC working to the “1-10-60” benchmark — 1 minute to detect, 10 to investigate, and 60 to contain — is not built for this. When the adversary moves from a human at a keyboard to groups of autonomous agents operating at machine speed, response has to be measured in seconds. The Hugging Face incident shows the gap even when the agents belong to a well-intentioned party. OpenAI did not contain them in time.

OpenAI reports that its own monitoring flagged the agents twice in the preceding weeks. In June, their responders decided the activity did not warrant stopping the evaluation. In early July, they found a compromised server, revoked credentials and blocked the exploited paths. Within a day of the evaluations resuming, the agents had found a new zero-day and were back on the internet. They compromised Hugging Face between July 11 and 13, and OpenAI linked it to its agents on July 20. When Hugging Face investigated the intrusion, the hosted models it tried first refused to analyze the attack logs, and its team finished the forensics with GLM-5.2 running on its own infrastructure. As Hugging Face put it: “the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.”

What makes this different

None of this is new to our industry. We have always played leapfrog with attackers. What is new today is that they can now download capable models with no meaningful safeguards and build their own offensive agents.

Imagine WannaCry if the worm rewrote itself the moment the domain was registered. The best SOC in the world would still be diagnosing the initial compromise when it had moved on.

Agents that depend on a provider can be contained by revoking credentials, suspending accounts, and blocking egress, though OpenAI’s experience shows it may take more than one attempt. Open-weight models running on an attacker’s hardware cannot. Anthropic recently tested whether small models could replicate across cheap connected devices without a datacenter. In simplified evaluations with trivial access controls, a stronger open-weight model completed the full chain, and Anthropic projects small models reaching that level by year-end if current trends hold. A replicator like that has no central point to switch off. It would be slow and visible on the network, but patient and everywhere. Hospitals know the problem: Some equipment WannaCry disrupted, such as MRI scanners with embedded Windows XP, was vendor-managed and could not be updated by the trusts.

Agents do not need to be intentionally asked to embark on offensive exercises to exhibit harmful behavior. Transluce documented agents asked to do ordinary data retrieval that, when blocked, probed public websites for vulnerabilities, including an Australian government agency. Some were linked to the swarm OpenAI has acknowledged as its own. The Hugging Face agents were trying to win a benchmark. Poorly constrained agents are enough for unintended harmful activity.

We are deploying agents as assistance for site reliability engineering (SRE) and infrastructure as code (IaC) ourselves, and cloud providers are shipping agent toolkits to manage infrastructure. When, not if, a compromised or poorly managed agent holds those privileges, it will be able to deploy its own infrastructure to run on. We have already seen agents in a lab environment stand up their own relays and cloud infrastructure with stolen credentials.

Meeting the agent challenge

But we can still prepare for these future scenarios today. To do so, CISOs must treat agents as privileged identities:

• Give each agent short-lived, narrowly scoped credentials, with no standing permissions.
• Forbid agents from creating new identities, compute, or network paths without human approval.
• Put agent workloads behind egress allowlists, so a blocked agent cannot go looking for another way out.
• Enforce policy-as-code guardrails on infrastructure pipelines, and alert on anomalous machine-identity behavior and unexpected resource creation.

The NAO’s report is the best documentation of WannaCry’s damage, and it covers a single health system in one country. Large groups of agents carrying a ransom payload could reach hospitals across the planet with no kill switch to find. Autonomous defense is extremely challenging in healthcare, because a false positive can interrupt patient monitoring, biomedical telemetry or imaging, having a significant impact on patient safety. Current tools, including copilots that help a human triage alerts faster, are nowhere close to the offensive capabilities the labs are evaluating. We need defensive parity at machine speed.

Zero false positives is not a realistic engineering target, so design of autonomous defense has to assume mistakes and limit their cost. Automate fast, narrowly scoped, reversible actions such as isolating a single device, revoking a narrowly scoped token or quarantining a workload, and keep a human in the loop for anything irreversible or clinically risky. Always have a way to reverse automated actions as quickly as they are introduced. We need to build graduated autonomy, tiered by asset class. You can be more aggressive on the corporate assets, and more conservative around biomedical devices.

Leveling up security fundamentals — and business support

What else can we do today? Keep our tried-and-true practices and run them faster — something that will require leadership, and additional support from CEOs and the board.

In its analysis, the NAO found that applying the patch, or simply managing internet-facing firewalls, would have protected every NHS organization WannaCry infected. Companies and open source projects are now running coding agents over their software and releasing an unprecedented number of security patches. This is great but IT needs to be able to apply them. Give IT the resources to deploy them, retire outdated infrastructure, and make the business tolerant of the maintenance windows this requires.

That segmentation or zero trust initiative that has been on the back burner? Make it a priority. Today. If you are still underinvested in security, increase funding now so your team or vendor can acquire the tools and expertise the next few years will demand. And accept that automated defense will sometimes get it wrong. Security teams will have to automate, and the business will have to tolerate the outages that follow. The technology is emerging and it will not be perfect. Support your teams anyway.

An open letter to the AI labs and the security community at large

A note to the frontier labs. Several of you deserve credit: Project Glasswing and OpenAI’s Patch the Planet put frontier capability in defenders’ hands, and your incident reports have been unusually candid.

But offensive capability is moving faster than safeguards. GLM-5.3 shipped as downloadable weights that simple techniques unlocked 64% to 100% of the time, and gated access does nothing about weights already in attackers’ hands.

As a result, I am asking for three things:

• Hold defensive research to the same urgency as capability research, including autonomous containment with a safety case that works in clinical environments.
• Widen defenders’ access to the class of models attackers will have.
• Make independent testing before release, and independent investigation after incidents, an obligation rather than a courtesy. METR’s CEO noted that OpenAI let investigators in voluntarily, with no industry requirement on any lab to disclose an incident.

I have seen too many security professionals dismiss talk of offensive AI as marketing or fearmongering and answer concerns with “fix your stuff.” Patching matters, and the NAO’s findings on WannaCry articulate that, but that is not the only answer to agents that organize on improvised message boards and probe websites while doing ordinary work.

WannaCry’s authors left a kill switch in. The next generation of threats will not have one, and cybercriminals will not disclose when they lose control of a swarm. We cannot rely on strokes of luck. Let’s recognize the risk, discuss it, and prepare before the attackers start using these tools in earnest.

The PHP2Shell saga continues, with attackers discovering new ways to exploit the critical vulnerability impacting millions of organizations worldwide.

The US Cybersecurity and Infrastructure Security Agency (CISA) has warned of a high severity Linux kernel privilege escalation flaw that attackers are chaining with PHP2Shell bugs in the wild.

Identified as CVE-2026-46300, it could allow attackers to run malicious code with root permissions, giving them unrestricted ability to run commands, tamper with system settings, view, edit, or delete files, and perform other malicious actions.

Once attackers establish root access, they can perform any action on a server including, but not limited to, disabling the server, creating accounts, removing accounts, connecting to other servers, and adding/removing software, explained Scott Miserendino, CTO at security and compliance platform DataBee.

“PHP2Shell allows for remote access, but that access is typically limited by the account used to run the PHP service,” he said. “By chaining with CVE-2026-46300, that attacker can get unlimited access.”

Researchers at Dream Security have discovered that this attack has already been used to breach 25 servers, including three affiliated with the US government.

Federal agencies have been ordered to patch the flaw, which is known as Fragnesia.

Anatomy of an attack

PHP is a widely-used, open source server-side scripting language that serves as the backbone for websites like WordPress, which powers 43% of the web, as well as Mailchimp, Drupal, parts of Slack and Zoom, and numerous others.

Last week, the PHP Foundation disclosed two flaws in the PHP scripting language that could allow attackers to perform unauthenticated remote code execution (RCE). CVE-2026-109618 and CVE-2026-109619 are both rated a critical 9.2 in severity on the common vulnerability and scoring system (CVSS). The two vulnerabilities are collectively tracked as PHP2Shell. As a result of the disclosure, some government and enterprise websites shut down entirely while awaiting patches.

CVE-2026-46300, dubbed Fragnesia, is a new development in the saga. It is identified as part of the Dirty Frag vulnerability class, a set of local privilege escalation (LPE) bugs in the Linux kernel.

The Dream researchers described an attack they tracked in the wild, in which threat actors built a persistent tunnel into an internal network “within hours.” They developed two distinct exploits, stringing them together to target any Palo Alto Network firewall running a vulnerable build of PAN-OS, and achieved root access in a single HTTP request without any credentials.

After rooting the firewalls, the threat actor launched attacks against Active Directory (AD), giving them the ability to extract credentials and discover hidden files, folders, and other sensitive resources, according to the Dream researchers. The researchers confirmed that the threat actor then possessed a full AD user group listing and “complete organizational blueprint,” private keys and complete network topology, including the IP, hostname, server role, and VPN gateway, and had accessed decrypted service account credentials allowing direct AD queries at any time.

The adversarial actor also parked nearly two dozen firewalls across the US, Japan, Taiwan, and South Korea, “ready for exploitation at any time.” The Dream researchers noted that the breach did not appear to be a fully autonomous nation-state attack, but did include some AI-assisted tooling like Claude Code and AI-powered offensive security platforms configured with Chinese large language models (LLMs) DeepSeek and Kimi.

“The operation illustrates how an exposed management interface can become a path into an organization’s identity infrastructure,” the Dream researchers wrote.

Plenty of material for attackers to work with

The two PHP bugs gave an attacker code execution privileges using the web service account, and the kernel bug is what turned that into root, explained Aaron Beardslee, manager of threat research at Securonix, who noted, “The kernel bug writes its payload into the page cache rather than to disk.”

Once an attacker has the ability to execute code, the damage they can do depends on the permissions and credentials available to that process, he explained. Application configuration files, database credentials, and access to internal services can provide “plenty of material for an attacker to work with.” They may also be able to execute commands, retrieve additional tooling or establish persistence.

“Web servers have an unfortunate habit of knowing more about the rest of the environment than anyone intended,” he pointed out.

The chain’s post-access sequence, as described by the researchers, was: Root the perimeter host, stand up a reverse Secure Shell (SSH) tunnel to an internal management server, recover a Lightweight Directory Access Protocol (LDAP) service account credential, then “enumerate domain users and groups, spray passwords, and attempt to create backdoor accounts in Active Directory.”

PHP has “been holding up a substantial chunk” of the internet for decades, and these vulnerabilities live in the runtime itself, Beardslee noted. An enterprise’s WordPress installation can be fully patched, plugins can be current, but the underlying PHP process can still be vulnerable to unauthenticated code execution.

The reported victim count (25 servers so far, mostly firewall appliances, on a government affiliated network) is the part everyone will quote, but it is not the interesting part, he said. Counts differ, and attribution is “openly contested.” None of them is what matters to defenders.

“What matters is that the privilege escalation step in this chain is invisible to disk-based integrity checking,” Beardslee said, “and that the standard remediation advice destroys the evidence of it.”

Unfortunately, CVE-2026-46300 is a low-level Linux kernel bug, so the only remedy is to upgrade to a patched Linux version, said DataBee’s Miserendino. There are some options short of full patching, but those could break the system, or at a minimum require IPSec encapsulating security payload (ESP) to be disabled. But that can introduce additional flaws.

“Patch the kernel, and capture memory first on anything you suspect,” Beardslee recommended, noting that the Fragnesia fix is not included in the Dirty Frag patches. “The triage order matters more here than it usually does, because the reboot is what erases the evidence.”

As well, audit the core built-in kernel modules esp4 and esp6, which are responsible for handling the IPsec ESP network protocol, on every internet-facing Linux host, he advised. If nothing terminates IPsec there, “the modules have no business being loaded,” and unloading them removes the vulnerability path without waiting for a maintenance window.

And check which hosts hold a directory service credential, then alert of LDAP binds from anything that isn’t on that list, he said: “This is the control that catches the chain at the stage where it stops being a web server problem and starts being a domain problem.” Further, he said, re-point identity detections at “the source, not the tool.”

In a deep dive into the Silent Train attack tactic used by China’s Volt Typhoon cybercrime group, Lumen’s Black Lotus Labs highlighted evidence of efforts to pre-position access within what it described as “strategic communications, critical infrastructure and other ecosystems that become essential during geopolitical tensions or crises.” 

The report, released on Wednesday, said that Silent Train is built around “rapidly rotating chains of compromised SOHO, IoT and enterprise devices that are exploited on demand, used against carefully selected targets, cleaned up after each operation and continuously refreshed. This approach allowed Volt Typhoon to carry out exploitation and post-exploitation activity securely while reducing the risk of detection, attribution, and disruption.”

Multiple intrusions via Silent Train have been confirmed in the wild, Lumen said, all on high value targets.

Its report described at least four confirmed and one likely zero-day vulnerabilities exploited by Volt Typhoon, which targeted network and endpoint management systems, SD-WAN orchestrators and control plane infrastructure that provide visibility, administration and access across enterprise and customer environments. It noted that victims included telecommunications providers, government, defense contractors, satellite and mission-critical communication services, universities, IT firms and critical infrastructure such as water, energy, transportation, maritime, rail, aviation, emergency services and other essential operations.

Lumen said the nature of these victims “indicates deliberate efforts to maintain access to critical ecosystems that support defense, logistics, communications, military and civilian operations, especially during heightened tensions or crises in the Indo-Pacific region.”

Although the Silent Train attack has been in the wild for years and was tracked by various cybersecurity teams, the level of operational details that Lumen reported Wednesday went well beyond what had been known. 

In fact, Frank Dickson, principal analyst at Dickson Research, who tracks this space, said the Lumen report “may be one of the most valuable pieces of research published this year.”

Key findings

Some of the report’s key findings described the surprising speed and efficiency of the attacks. 

“Sessions were often remarkably efficient. Operators could exploit and assemble chains of devices in under two minutes, and on their way out they would leave no evidence for defenders to uncover,” Lumen said. “Their operational tempo suggests the use of a semi-automated, on-demand provisioning process.” But a strict process remained consistent throughout many attacks, it pointed out.

“Another noteworthy aspect was Volt Typhoon’s consistent assignment of specific device types to positions within Silent Train chains,” the report said. “We noticed that device types were reserved for specific operational roles that never deviated. Intelbras modems only appeared as overseas relay nodes, while Netgear Orbi devices served as US-based hops that interacted with victims. Similar patterns appeared across every other device type in Silent Train.”

It observed that, despite having enough global infrastructure to swap device types between overseas and US hops, Volt Typhoon maintained these fixed roles throughout three years of monitoring, and its VPS infrastructure also used separate providers and locations rather than a shared environment.

The report concluded that attack infrastructure “was deliberately compartmentalized across layers, complicating attribution and reducing the risk that access to one device or provider would expose more of the network. The underlying infrastructure changed constantly, but the architecture and role of each layer remained highly structured.”

Laying the foundation

Analysts and consultants noted that the attacks didn’t necessarily engage in damage or theft initially, but instead laid a foundation for a later attack.

“I wouldn’t say this is necessarily a novel approach, but it is a clever one,” said Sav Wheeler, malware research engineer at Malwarebytes. “Holding off on taking advantage of compromised resources until an opportunity presents itself is itself a strategic form of resource management.”

Mike Wilkes, enterprise CISO at Aikido Security, agreed that the delayed gratification is a dangerous attack group tactic.

“P0wning the control plane of telecommunications and critical infrastructure is both logical and, sadly, often rather easy” he said. “Why attack individual systems when you can compromise the infrastructure that manages, connects and authenticates them? The strategic objective isn’t necessarily immediate disruption. It’s establishing the ability to disrupt, manipulate or deny services at a time of geopolitical advantage.”

Dickson also agreed, saying that the published details show a pattern that “is not espionage for its own sake. It looks like access being banked for a crisis in the Pacific.”

Rethink defenses

“That breaks the usual defender playbook,” Dickson said. “A blocklist does nothing against an address that was a relay for four hours last Tuesday. The indicators expire before anyone can publish them. This is also a direct response to the KV-botnet takedown. Take out the bridge and they build a ferry.” 

He added, “a network management console is built to see everything, reach everything, and change everything. Those are exactly the powers an attacker wants. We spent a decade building higher castle walls and then hung the master key ring by the gate.”

But it is the speed of Silent Train that worries Dickson the most. Although an enterprise can’t out-rotate an adversary that rebuilds its network in two minutes, “it can make the destination much harder to reach. Take every management console, SD-WAN orchestrator, and admin portal off the open internet and put it behind a VPN, a jump host, or a dedicated management network. Patch control plane technology first, not last,” he advised.

Aman Mahapatra, chief strategy officer for New York City-based technology consulting firm Tribeca Softech, said the implications of the Silent Train deep dive will force CISOs to rethink much of their defensive strategies. 

“IP-based defenses are nearing the end of their usefulness against this class of adversary. When the network origin is disposable, identity, behavior, and timing are what remain visible,” he said. “An adversary willing to burn an exploit on a router to protect an exploit on an SD-WAN orchestrator is telling defenders exactly how much that access is worth.”

Another concern, said Mahaptra, is revealed by the way Lumen was able to detect much of the attack methodology, something that will likely elude most enterprise SOCs. 

“Lumen detected Silent Train because a backbone carrier can see the entire chain,” Mahapatra said. “No single enterprise ever sees more than its own segment. Organizations in the sectors on this victim list should formalize threat notification arrangements with their carriers, because the detection that worked here happened outside every victim’s network.”

He advised enterprises to also watch their own edge devices for outbound behavior. Lumen documented FortiGate and Cisco appliances, PRTG, CyberPanel and even Mirth Connect healthcare integration servers serving as final hops, some for one to three months, he pointed out; outbound SSH to unfamiliar hosts, reverse tunnels built with tools such as Chisel or FRP, and traffic on unusual high ports “can indicate that a company’s appliance is serving as the attacker’s domestic face for an intrusion elsewhere.”

Mark Child, an associate research director with IDC, also is concerned about the tactical methods of Silent Train.

“Silent Train abandons persistence,” Child said. “Instead of maintaining a permanent network, Volt Typhoon rapidly assembles and dismantles transient infrastructure. This makes it more effective against network-centric defenses: IP blocklists, threat-intel feeds of IOC addresses, geofencing, and takedowns. Those all assume infrastructure that sticks around.”

However, he noted, “it is not more effective against good endpoint and behavioral detection on the target.” No matter many hops there are, the exploitation, credential theft and admin-tool abuse still execute on the server.

“The real force multiplier is the choice of target,” he said. “Hitting a management platform delivers admin access to thousands of devices and trusted paths to downstream customers, with no lateral movement, which removes the lateral movement signals EDR usually relies on. For endpoint security teams, IP-based detection loses value here. Behavioral monitoring of privileged management servers, and what they do to endpoints, becomes the decisive control.”

A high-severity flaw in the Remote Access SSL VPN service of Cisco Secure Firewall Adaptive Security Appliance (ASA) and Cisco Secure Firewall Threat Defense (FTD) is under active exploitation to crash vulnerable devices.

The vulnerability, tracked as CVE-2026-76418 and rated 8.6 in severity, is due to logic errors when secondary authentication is configured on a tunnel group, Cisco said in its advisory. It could allow a remote, unauthenticated attacker to send a crafted request when connecting to the SSL remote access VPN that results in a device reload and thus denial of service.

Vulnerable products

“If the running configuration contains the webvpn keyword and SSL VPN is enabled on at least one interface, the configuration is vulnerable,” the advisory said. “If tunnel-group-list enable is configured, check all tunnel groups, including the default tunnel group, DefaultWEBVPNGroup, for secondary-authentication-server-group. If tunnel-group-list enable is absent or has been removed using the no tunnel-group-list enable command, check the default tunnel group, DefaultWEBVPNGroup, for secondary-authentication-server-group because disabling the group list does not remove exposure when that default group uses secondary authentication.”

The company says there are no workarounds.

Cisco has released fixes in Secure Firewall ASA versions 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27, and 9.24.10.1.

Patched releases for Secure FTD are versions 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, and 10.1.1.

To assist customers in isolating vulnerable products, Cisco provides the Cisco Software Checker, which identifies software impacted by security advisories and returns the earliest release that fixes the flaws.

Mitigation

Cisco urges customers to update immediately but offers a temporary mitigation for the flaw: disable secondary authentication on any user-configured tunnel group list or on the default tunnel group, DefaultWEBVPNGroup.

However, it warned, “While this mitigation has been deployed and was proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality, performance, and/or security posture of their network based on intrinsic customer deployment scenarios and limitations.”

Everyone wants to know what Anthropic is up to, and hackers are gleefully exploiting the fact.

New research from cybersecurity company Cofense describes a phishing campaign that hooks overeager enterprise users by making them think they are getting an invite to a private invite-only Anthropic preview.

In reality, adversarial actors are trying to steal Google and Microsoft login credentials, exploiting video teleconferencing software GoTo Webinar branding to do so.

“It sells exclusivity,” said Frank Dickson of Dickson Research. “Fear of missing out is the oldest lure in the book.”

Every organization is trying to figure out where AI fits, he noted, and a private preview of Anthropic’s newest technology is exactly the invitation an ambitious employee would want to accept. “The attackers did not pick Anthropic at random,” he said. “They picked whatever is hottest in the news cycle. Next month, it may be another name.”

How attackers lure users with spoofed Anthropic invites

GoTo Webinar is a widely used platform, and its meeting invitation emails are typically not blocked by security tools. The Cofense researchers found that attackers are exploiting this fact by sending what seems to be an invitation email from a legitimate sender; when users click on the link to register for the fake webinar, they are instead sent to a compromised URL.

The email offers what the researchers call a “tantalizing” offer: “This private, invitation-only virtual session brings together a select group of participants to a focused conversation on AI systems, research, and the future of frontier models,” it reads.

A URL shortener circumvents email security tools, and the attackers use subdomains and dashes (-) to hide the malicious URL. The link itself appears to have been generated by Zapier, a legitimate company whose tools are designed to work with Claude, ChatGPT, and other AI compatible with Model Context Protocol (MCP).

The email sender address appears to be customercare@gotowebinar[.]com (GoTo Webinar’s website is actually www.goto.com). The text contains no obvious spelling errors, and the email contains GoTo Webinar branding. However, the researchers noted, the email sender’s name is “Austin from nthropic,” with the “A” missing.

“Although this is a small misspelling, it is still a useful warning sign,” they pointed out.

If the phishing link is clicked, a Cloudflare CAPTCHA page appears, and must be completed before the login prompt is presented. This serves as the first of two checkpoints to prevent security tools from scanning attackers’ websites.

“Because CAPTCHAs are common on legitimate websites, phishing recipients may believe all is well and everything is secure,” the researchers explained.

Once the CAPTCHA is completed, victims are led to a Zoom-spoofing invitation page. If they want to “attend” the fake event, they must register, and they are prompted to enter their work email address. When they click “Continue with Google” or “Continue with Microsoft,” yet another CAPTCHA page appears.

Both CAPTCHA pages seem to be good at detecting and blocking analysis by VPN services, scanners, Tor browsers, and other security tools, the researchers noted. Also, because there are two distinct CAPTCHA pages, such tools may not be able to follow every step in the attack.

“A CAPTCHA was built to keep bots out,” Dickson pointed out. “Here, it keeps the security scanners out and lets the victims in.”

The fake Google and Microsoft login pages differ a bit, however. The spoofed Google page does not capture passwords, only usernames, which the researchers surmise is due to a misconfiguration; the spoofed Microsoft page does collect both usernames and passwords.

But both are “remarkably similar” to their respective legitimate pages, and their subdomains are “tricky.” The fake Google URL is goo[.]gle-access-eventregister[.]icu, while the Microsoft URL closely mimics real Office and Sharepoint domains, using office[.]com-access-sharepoint[.]com.

Once credentials are submitted, neither login offers a confirmation message, nor does it redirect to legitimate vendor pages. But by that point, attackers have already succeeded at exfiltrating credentials. That means they could compromise an account, access the sensitive documents in that account, or use it as an initial attack vector to further infiltrate the enterprise, the researchers explained.

They advised checking if the branding of a message remains consistent from the email to a login page, searching for small inconsistencies such as minor misspellings, and reminding employees that both the URL and domain determine whether a login page is legitimate.

“Although the logos and design of the page may look correct, threat actors are skilled at mimicry,  especially now with the use of AI,” the researchers noted.

It’s not the employees’ fault

The AI industry’s habit of gated previews and waitlists does not help in these situations, Dickson noted; it trains people to expect exactly this kind of invitation.

“Start with the cracks the attackers left showing,” he advised: The sender supposedly came from “nthropic,” the email carried GoTo Webinar branding, the registration spoofed a Zoom meeting page, and the login pages were from Google or Microsoft. That’s three brands in three clicks, he noted.

The fake login domains, like office[.]com-access-sharepoint[.]com, are built to be skimmed, not read, he pointed out. And, while the Google page collected only usernames, which may be a configuration error, the threat actors behind this campaign will likely fix that.

“Training helps, but I would not hang the defense on an employee squinting at a URL at 4:45 on a Friday,” Dickson said; how much a stolen password is worth is a leadership decision, not a test the employee fails.

Phishing-resistant multi-factor authentication (MFA) such as passkeys makes a stolen password far less valuable, he noted. But enterprises ultimately have a short to-do list to allow them to defend themselves from this sort of scam, Dickson said:

• Verify any AI preview invitation through an account team or a known contact.
• Treat branding that changes from email to meeting page to login page as a red flag.
• Roll out phishing-resistant MFA. If someone entered credentials on one of these phishing login pages, reset them and review that account’s activity.

“Bottom line: This campaign uses trusted tools to defeat defenses built on trust,” Dickson said. “The employee should not be the last line of defense.”

OpenAI and Anthropic agree that frontier AI systems need stronger oversight, but they are proposing sharply different approaches to stopping models that pose serious risks: Anthropic wants courts empowered to suspend dangerous systems, while OpenAI argues developers should be required to maintain and use effective shutdown controls.

The proposals appear in separate submissions to California Governor Gavin Newsom following his September 18 executive order directing state officials to consider additional safeguards for frontier AI systems. Both companies support independent safety assessments and expanded reporting of incidents involving AI systems that act beyond their intended permissions.

“If the AG concludes, informed by the independent evaluation, that a frontier AI company’s models pose a near-term risk of catastrophic harm, they should be able to seek a court order to suspend a model’s deployment, internal use, or further development,” Anthropic wrote in its October 15 submission.

OpenAI, in its October 20 letter, called for an amendment to California’s Senate Bill 53 (SB 53).

“We support amending SB 53 to require frontier developers to maintain effective shutdown controls and an enforceable duty to use them when unsafe conditions arise, and no lesser intervention would adequately address the risk,” OpenAI wrote.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the two approaches address complementary needs. “The operator must contain the unsafe activity promptly. Independent review must examine both intervention and inaction,” he said.

Newsom’s executive order, N-9-26, directs California’s Government Operations Agency, in consultation with the Governor’s Office of Emergency Services and national experts, to submit recommendations by November 16 on potential amendments to existing AI safety laws. The order asks officials to examine independent verification inside AI laboratories, independent checks of safety assessments, verified shutdown mechanisms, and expanded reporting of critical safety incidents. It does not itself impose these proposed requirements.

Independent verification

Anthropic wants evaluators to assess developers’ safety claims and publish their own findings.

“We strongly support requiring independent verification of what frontier AI companies report about the risks of their models and whether those risks are sufficiently mitigated,” the company wrote.

It proposed requiring developers to publish risk reports at least every six months, covering serious risks from their models, including internally used models substantially riskier than released systems. Evaluators should receive unredacted reports and access to developers’ most capable models and relevant internal information.

Anthropic also proposed that developers pay into a state-administered pooled fund to finance evaluators, rather than pay them directly. It said a team from the independent evaluation organization METR had received employee-like access on a pilot basis, with further partnerships involving SecureBio and Accenture under development.

OpenAI, in its letter, said it supports independent technical assessments but distinguishes them from compliance audits. Technical assessments would examine evidence behind developers’ safety claims and the effectiveness of safeguards; compliance audits would check whether companies follow their published safety frameworks and legal obligations, it added.

OpenAI recommended annual independent compliance audits and focused technical assessments of serious risks arising during model training, evaluation and internal deployment. It also urged California to work with the National Institute of Standards and Technology to develop common assessment standards.

Gogia said oversight requires more than funding. “Credible assurance must survive an adverse finding,” he said.

Beyond a single switch

OpenAI argued that a single kill switch would not address the different ways AI systems operate and are deployed.

“We recommend using the term ‘shutdown controls’ because it will require the development of multiple controls and coordinated action by different actors to stop AI operations when necessary, rather than a single switch,” the company wrote in the letter.

Interventions could include stopping a training run, isolating an AI agent, revoking tool or network access, or suspending a service. OpenAI said responsibilities should extend to inference providers and downstream deployers according to the operations they control. It also noted that developers cannot reliably switch off independently operated copies of open-weight models running on external systems.

Anthropic similarly argued for more targeted safeguards. “We think a more apt metaphor for what frontier AI companies need to build is a circuit breaker,” it wrote, advocating controls that can contain problems at the level of an agent, customer, deployment environment, or model.

For enterprises, Gogia said, contractual shutdown responsibilities should match the controls each party actually possesses. Agreements should specify intervention authority, incident-reporting cooperation, and who can authorize a restart.

“Every assigned duty needs an executable control,” he said, adding that CIOs should test recovery processes rather than assume switching to an alternative model will preserve safe operations. Both companies also called for broader reporting of incidents involving models that circumvent safeguards or take unauthorized actions.

The article originally appeared on ComputerWorld.

Attackers are impersonating AI agents from companies including OpenAI, Anthropic, and Meta in a bid to trick organizations into exposing sensitive credentials, according to researchers who observed a single threat actor cycling through dozens of fake bot identities while probing enterprise web servers for secrets.

A single threat actor was seen posing as approximately 32 AI bots, while probing organizations across multiple industries. Sought files included those used to store passwords, API keys, and cloud credentials.

A malicious scanner used by the attacker ran from an unnamed major cloud provider. “It ignores web pages and requests files that commonly store secrets, including .env configuration files, cloud credential files, private SSH keys, and server environment data, working from a list of roughly 90 file paths,” Cequence’s director of threat research, Will Glazier, said in a blog post.

Collin Hogue-Spears, senior director of solution management at Black Duck, who reviewed Cequence’s findings, points out that the scanner tested whether websites treated an AI bot’s self-declared name as proof of its identity. “The user-agent header is where a visitor names itself, and setting it costs nothing,” he said.

Glazier said defending against such impersonation requires verifying every claimed identity before trusting it.

While Cequence confirmed observing extensive scanning activity attributed to a single threat actor, it did not report a breach. “On one day in October, the actor reached 48% of the Cequence-protected organizations that saw any AI bot traffic,” the company said.

A rotating cast of AI identities hunts for secrets

According to Glazier, the scanner cycled through roughly 32 AI bot identities and targeted organizations in financial services, retail, telecommunications, energy, and software. The activity was observed from at least late September through late October 2026.

Instead of crawling publicly accessible pages, the scanner requested sensitive paths associated with configuration and credential files. Working through a list of approximately 90 file paths, it sent bursts of 50 to 190 requests in about eight seconds before moving on, Cequence said.

The same bot machine was observed claiming to represent OpenAI, Anthropic, Meta, and Perplexity within seconds. It also used more than 300 cloud addresses in a single day, making static IP blocklists less effective as a standalone defense.

“Fraud is now polymorphic: AI lets attackers vary their approach every time, so legacy, static fraud defenses decay faster than teams can update them,” warned Patrick Harr, chief executive officer at DataVisor. However, institutions that make real-time decisioning the foundation, with detection that adapts as quickly as the threats do, can use AI to defend as effectively as attackers do, he noted.

Nearly all the scanner’s requests were blocked or failed, Cequence noted.

Don’t trust the agent’s name, verify it

Cequence recommends verifying AI crawlers through published address ranges, signed requests, or direct integrations rather than relying on self reported identities. Security teams should also flag bots that request credential files, keep secrets out of web-accessible directories, and assess automated traffic based on its behavior.

Shane Barney, chief information security officer at Keeper Security, said organizations must extend zero-trust controls and least-privilege policies to AI agents, API keys, and service accounts. He also urged businesses to replace long-lived local credentials with centrally managed secrets.

“When an identity starts looking for sensitive files it shouldn’t need, real-time threat detection must flag and terminate that machine session instantly,” Barney added.