CSOonline

CISOs at government organizations and universities have an unexpected ally coming to their aid: OnlyFans models. For some time, hackers have exploited weaknesses in the websites of universities or government departments to host scams or malware, using content stolen from the OnlyFans website as bait to attract victims. Now, according to security researchers at Upguard, the fightback has begun: creators of adult content on OnlyFans are leveraging Google search results and the protection offered by copyright law to break up the traffic distribution systems created by bad actors. These distribution systems work in three stages: entry points using adult or other content to attract and capture web traffic, a routing system sends it to destination sites, and those sites monetize the traffic through scams and malware. It has proved to be a lucrative business for the scammers. Google recognizes the approach and calls such actors SEO parasites as they benefit from the reputations of other organizations — in particular government or academic sites, which Google views as having high authority. Since the creators of OnlyFans content are also the copyright holders, they are able to issue Digital Millennium Copyright Act (DMCA) take-down notices for the stolen content posted by the bad actors to other sites. Upguard was able to track this through Google’s DMCA Transparency Report, and through the Lumen Database, another tracker of takedown notices, to which it was granted research access. “This allows us to identify likely compromised sites: government and university domains advertising unlicensed adult content,” Upguard said. The OnlyFans creators’ action has two benefits for the operators of the affected websites: The adult content associated with their domain disappears from Google search results, no longer affecting their reputation — and if they receive takedown notices for such content they can check their webservers for the vulnerabilities that enabled the bad actors to post it there in the first place. View the full article

The European Union is stepping up its actions against US tech giants under the Digital Markets Act, which is intended to ensure fair competition between digital platforms. On Thursday, the European Commission issued two rulings to limit Google’s dominance. The Commission ordered Google to open up the Android operating system to AI assistants other than its own Gemini, ensuring that they had the same access to applications and operating system services. A second ruling ordered Google to share search data that only it is big enough to collect with other search engines. Google has hit back at the measures, warning that they could create security issues for users. “Today’s decisions risk undermining vital privacy and security guardrails for millions of Europeans. We have repeatedly offered solutions to safeguard users while satisfying the DMA’s goals, but these rulings discount extensive evidence of user harm,” said Kent Walker, Google’s President of Global Affairs, in a company blog post. The EU move doesn’t just cause problems for Google but for CISOs as well, warned Roman Stanek, CEO of Good Data AI. “Enterprise security has always leaned on a simple assumption, that apps are boxes, and the OS decides what crosses the box. But once multiple agents get equal system-level reach, access to screen context, cross-app actions, background execution, that assumption breaks. “CISOs need to stop treating ‘AI assistant’ as a single, well-understood permission and start treating it as a category risk, one they have to govern like they govern app stores and MDM policies today. That requires device policies that name which agents can hold system-level permissions, not just which apps are installed. It means DLP and conditional access rules that account for an agent reading and acting on data, not just an app requesting it.,” he said. This article first appeared on Computerworld. View the full article

The upper ranks of corporate security are seeing a high rate of change as companies try to adapt to the evolving threat landscape. Many companies are hiring a chief security officer (CSO) or chief information security officer (CISO) for the first time to support a deeper commitment to information security. Follow this column to keep up with new appointments to senior-level security roles and perhaps gain a little insight into hiring trends. If you have an announcement of your own that you would like us to include here, contact Peter Sayer, executive editor of news, at [email protected]. New CISO appointments in July 2026 Datavault AI appoints Barry Childe CISO Barry Childe, a co-founder of quantum encryption company Arqit, has joined Datavault AI as CISO. Childe previously served as a distinguished engineer at HSBC, and held other senior technology roles at Barclays Capital and VMware. Jason Cradit joins EverLine as CISO and CTO Critical infrastructure technical services provider EverLine has hired Jason Cradit as CISO and CTO. Cradit has previously held leadership roles in consulting, software, and infrastructure operations, and founded software vendor Pivvot. New CISO appointments in June 2026 Infoblox names Henrik Smith CISO Former Amazon executive Henrik Smith has joined security platform vendor Infoblox as CISO. Smith most recently served as head of security for devices and systems at Amazon, and prior to that was vice-president of security at Salesforce.Former Amazon executive Henrik Smith has joined security platform vendor Infoblox as CISO. Smith most recently served as head of security for devices and systems at Amazon, and prior to that was vice-president of security at Salesforce. GitLab hires Chaim Mazal as CISO Chaim Mazal, previously chief AI and security officer at Gigamon, has joined GitLab as CISO. He’s been a GitLab customer for over eight years, and moved into the CISO role after serving on the company’s advisory board. Paras Malhotra joins Starburst as CISO Enterprise intelligence platform Starburst has hired Paras Malhotra as CISO. He previously served as senior director of information security at Datadog and, prior to that, held a variety of security roles at AWSAmazon Web Services. Socure hires Mark Carter as CISO Mark Carter has joined identity infrastructure provider Socure as CISO. He has previously worked as CISO at Navan, Tesla, and Vimeo. SolarWinds appoints Justin Henkel as CISO IT management software vendor SolarWinds has named Justin Henkel its new CISO. Henkel was previously deputy CISO at OneTrust, and before that spent 25 years as an intelligence officer in the US Air Force. New CISO appointments in May 2026 Backstory names Victor Chang CISO Backstory, formerly People.ai, has appointed Victor Chang as CISO. Chang has previously served as CISO at Amdocs, among other senior security roles. Adam Dimopoulos is Entrust’s new CISO Entrust has appointed former Synchrony VP of Information Security Adam Dimopoulos as its new CISO. Dimopoulos has also previously worked in advisory roles at Microsoft and Gartner. New CISO appointments in March 2026 Kathy Wang joins micro1 as CISO Frontier AI model training company micro1 has hired Kathy Wang as CISO. She was most recently CISO at hospitality software developer Otelier, and has previously held top cybersecurity roles at Discord and GitLab. Green Impact Exchange names John Visneski CISO John Visneski has joined stock exchange operator Green Impact Exchange as CISO. He was previously CISO at MGM Studios, and following that company’s acquisition by Amazon became head fo security for mergers and acquisitions. His cybersecurity career began with the US Air Force, where he served as cyber advisor to the Secretary and Chief of Staff of teh Air Force. New CISO appointments in January 2026 Julien Mousqueton joins Cohesity as field CISO for Europe Data security firm Cohesity has hired Julien Mousqueton as field CISO for Europe. His previous role was as CTO at IT service provider Computacenter. He is a reservist advisor for OFAC, the French national police force’s anti-cybercrime division, and created the real-time ransomware activity-tracking platform ransomware.live. View the full article

Most organizations I work with have invested heavily in cloud security. They have endpoint detection tools, SIEM platforms, cloud security posture management, and skilled security teams running on a 24/7 shift. And yet, when I ask them a simple question — who has admin access in your Salesforce tenant right now? — The room goes quiet. Nobody knows. Not because they are negligent. Because they genuinely cannot see it. That is the SaaS blind spot. Figure 1: The Blind Spot and what SSPM covers.Ashish Mishra SaaS: Numbers speak volumes I ask this question in almost every engagement: how many SaaS applications does your organization run? The answers I get range from 30 to maybe 50. The real number, once someone counts, is usually north of three hundred. AppOmni’s 2024 research put it even higher — 49% of Microsoft 365 organizations believed they had fewer than ten apps connected to their tenant when the actual average was over a thousand. Here is the part that concerns me more than the count. Of all those applications, security teams have clear sight into maybe one in 10. The rest — where your customer records live, where your source code sits, where your financial reports get shared — nobody is watching. Not because the team is careless. Because the tools they have were never built to look there. The following incidents will discuss these realities. Salesforce in 2023 In April 2023, KrebsOnSecurity broke the story — Salesforce Community sites were quietly leaking sensitive data belonging to government agencies, banks, and healthcare providers. No sophisticated attack technique. Just the right API endpoint and a misconfigured guest user profile. The exposed records included Social Security numbers, account details, and home addresses. Salesforce was clear in its response: this was not a platform vulnerability. Administrators had misconfigured guest access policies, and nobody had checked. Guest user profiles in Salesforce Communities can be granted access to data records. When administrators set those permissions too broadly — often without realizing it — unauthenticated external users can query that data straight through the API. Over 150,000 companies were potentially sitting in that window before anyone raised the alarm. The pattern is always the same. Configuration made under time pressure, default set slightly too permissive, nobody looks at it again. SaaS applications accumulate these quiet exposures over months and years. GitHub in 2022 In April 2022, GitHub disclosed that an attacker had used stolen OAuth tokens — issued to Heroku and Travis CI — to access and download private repository contents from dozens of organizations, including npm. GitHub’s own systems were never touched. The tokens came from third-party applications that users had authorized to connect to their accounts, and those applications had been quietly compromised. The entry point was not GitHub. It was not even the organizations that lost their data. It was the CI/CD tools those organizations had connected to GitHub months or years earlier — tools that had been granted broad read and write permissions that were never revisited. That is the OAuth problem in plain terms. The moment you authorize a third-party application; its security posture becomes your problem too. Most organizations have dozens of these connections sitting open across their SaaS platforms — and no one reviewing them. Figure 2: The 2022 GitHub breach chain.Ashish Mishra Microsoft in 2023 The Microsoft case from 2023 is the one I bring up when people assume this only happens to careless organizations. Wiz Research found that Microsoft’s own AI team had exposed 38TB of internal data — private keys, passwords, and more than 30,000 internal Teams messages — through a single misconfigured Azure access token. The token was supposed to share one training dataset on GitHub. Instead, it opened an entire storage account to anyone who found the link. What gets me about this one is the timeline. That token had been sitting there since October 2021. Nearly two years, inside Microsoft, before anyone caught it. If a team with that level of resources and expertise can leave a door open for two years, the idea that “we’d notice” is not much of a security strategy. And it’s worth noting — this wasn’t a database leak. It was Teams messages. The same collaboration tools your employees use every day are just as exposed as the platforms holding structured records. Why traditional security tools miss this Cloud Security Posture Management tools — CSPM — are designed to monitor infrastructure configuration: virtual machines, storage buckets, network rules, and IAM policies at the infrastructure level. They do an acceptable job at that layer. What they do not do is look inside SaaS applications. CISA’s Secure Cloud Business Applications (SCuBA) guidance specifically calls out the gap between infrastructure security tools and SaaS-layer visibility as one of the most under addressed areas in enterprise cloud security. This is the gap SSPM was built to close. Instead of watching infrastructure, it watches the configuration of the SaaS applications themselves — permissions, sharing settings, who has access to what. And the distinction is not just academic. Infrastructure misconfigurations tend to expose systems. SaaS misconfigurations tend to expose data — directly, quietly, and often without any detectable attack activity at all. Figure 3: The six core visibility capabilities of SSPMAshish Mishra What security teams should do now You do not need to deploy a full SSPM platform tomorrow to start closing the gap. There are practical steps that move the needle immediately. Audit connected OAuth applications across your primary SaaS platforms. Revoke any integration that cannot be justified by a current business need. Common source of public data exposure: Review guest and external sharing permissions in Salesforce Communities and Microsoft SharePoint. Check whether legacy authentication protocols are disabled in Microsoft 365. Legacy auth bypasses MFA and becomes a potential entry point in enterprise environments. Establish a quarterly access review for high-privilege accounts in SaaS applications. Most organizations run annual reviews at best — that is not frequent enough for platforms that change configuration daily. A map of which SaaS applications hold sensitive data, and which have no security team ownership at all. That list will be longer than you expect. The core issue is not that organizations are careless. It is that they have built security programs around the perimeter and the infrastructure, and SaaS applications grew up inside that perimeter without ever being brought into scope. The data is there. The access is there. The misconfiguration is often there too. What has been missing is the visibility to see it. SSPM closes that gap. But even before a formal tool is in place, simply asking the question — what can the applications we already run see and share? — is a meaningful first step. In my experience, the answer surprises almost every organization that takes the time to look. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Threat actors are now abusing an ordinary font file to deliver low-detection malware capable of stealing credentials and establishing persistence on compromised Windows systems. According to a new research from Fortinet’s FortiGuard Labs, a global phishing campaign is actively using heavily obfuscated JavaScript and a Lua-based loader posing as a TrueType Font (TTF) file to evade security and drop RATs and infostealers. A TTF file is a standard font file used by operating systems and applications to display text. The campaign has been deploying malware families such as Agent Tesla, Remcos, XWorm, and a Snake Keylogger variant known as Best Private LOGGER, since at least late March 2026. “In these attacks, the threat actor impersonates several well-known companies, using the guise of business cooperation to launch phishing attacks,” FortiGuard researchers said in a blog post. Talking about how a new attack technique seems to still rely on conventional phishing tricks, Shane Barney, CISO at Keeper Security, said, “The most sophisticated technical evasion in the world still starts the same way: someone opens an email from what looks like a trusted company and acts on it.” “The obfuscation layers, the Lua loader disguised as a font file, the fileless execution chain – all of it exists to survive detection after that human decision has already been made, and organizations would do well to keep that in their sightline,” he added. Business and payment-themed phishing lures used According to the researchers, victims receive phishing emails impersonating well-known companies and using business collaboration or payment-related themes to trick recipients into opening compressed archives. These archives contain the obfuscated JScript that establishes persistence before dropping either a legitimate Autolt executable or a LuaJIT interpreter, along with a malicious script packaged within a .ttf extension. The fake font file functions as a Lua-based loader that runs multiple de-obfuscation steps before decrypting and executing shellcode directly in memory. “Security controls cannot treat a file extension as proof of file type or intent,” said Jason Soroko, senior fellow at Sectigo. “Each component (of the campaign) may appear less suspicious when reviewed alone, while the combined sequence leads to in-memory execution of RATs and infostealers.” Some of the new variants, the researchers pointed out, are getting more sophisticated by introducing segmented shellcode encryption, Vectored Exception Handler (VEH)- based runtime decryption, AMSI and ETW bypasses, API unhooking, and other anti-analysis techniques designed to evade endpoint defenses. The final malware payload is delivered using Donut shellcode, allowing execution without writing the payload to disk. Protection requires targeted mitigations and routine security hygiene Fortinet’s findings confirm the attackers’ endgame to be stealing credentials and maintaining long-term access. The malware families observed, including Agent Tesla, Remcos, XWorm, and Best Private LOGGER, are all focused on credential theft, surveillance, or remote access. Barney said organizations should resist focusing exclusively on the loader’s technical sophistication and instead strengthen the systems attackers eventually want to compromise. In his opinion, identity and access controls are what it comes down to, as signature-based detection often fails against the loader sophistication of this grade. “Limiting what any given set of credentials can reach, enforcing least privilege, requiring re-authentication for sensitive systems, and monitoring for anomalous session behavior will not stop every phishing email from landing, but they significantly constrain what an attacker can accomplish after one succeeds,” he explained. Soroko, on the other hand, recommends focusing controls on the technical indicators. He urged organizations to restrict Windows Script Host, Autolt, and LauJIT wherever they are not operationally required, monitor for behaviors such as process injection, remote memory allocation, and shellcode execution, and use Fortinet’s published indicators for threat hunting. The indicators of compromise (IOCs) Fortinet shared include the command-and-control (C2) addresses, file hashes, and filenames. Soroko warned against relying solely on hashes or C2 infrastructure because the loader has changed over time. “The stronger approach is to detect the stable behavior across versions, then test controls against the complete chain,” he said. View the full article

Shadow IT has long been a major problem for CISOs, but the biggest problem may be coming from the executive suite’s hunger for unsanctioned AI. Nearly two-thirds of senior decision-makers admit to using unapproved AI tools, compared to just 31% of lower-level employees, according to a survey by Microsoft solutions partner TrustedTech. The use of shadow AI is prevalent among senior executives even though three in four employees acknowledge security or data privacy risks related to the practice. “Most shadow AI users are not ignorant of the risk,” TrustedTech says in a white paper. “They are deliberately choosing to use these tools anyway. This is not a training issue. It is a culture, incentives, and alternatives issue.” In many cases, the problem is driven by a lack of approved tools, the report adds. “People use shadow AI because what their employer hands them is worse than mainstream AI tools, or because nothing has been approved in the first place,” the report says. “That doesn’t change until the sanctioned tools are genuinely worth using.” A question of authority The use of shadow AI by CEOs and other C-suite executives can create major problems for CISOs, CIOs, and other IT executives because they may not have the authority to put the kibosh on it. It also presents a challenge for IT leaders to provide the AI tools that employees and executives want to use. When executives use shadow AI, CISOs are in a difficult position, because governance only works when it’s modeled from the top, says Andy Nolan, VP of technology at TrustedTech. “If senior leaders bypass approved AI tools or policies, it sends an implied message that speed matters more than security and compliance,” he adds. “Employees notice that behavior, and it becomes much harder to ask the rest of the organization to follow standards that leadership isn’t following themselves, first.” Another major problem is that executives often work with highly sensitive information, including financial data, strategic plans, intellectual property, and customer information, he notes. But CISOs and CIOs also can’t solve the problem by becoming the AI police in every situation, Nolan says, because their role is to help the business innovate safely. “That requires executive alignment, clear governance, and providing secure AI tools that people actually want to use,” he adds. “When leadership embraces those solutions, the rest of the organization is almost sure to follow.” All risk, no reward The use of shadow AI by senior executives puts CISOs and CIOs in an impossible position, agrees Amit Maloo, CISO at AI procurement provider Ivalua. CISOs and CIOs are held accountable for the risk exposure but have no visibility into the problem, he says. “When senior leaders use ungoverned AI tools for business decisions, those decisions still have consequences, such as financial commitments, contract reviews, and data sharing,” he adds. “But there is no audit trail, no permissions model, or no way to reconstruct what happened or why.” Part of the problem is that approved AI options often don’t meet the needs of users, Maloo says. “AI policies alone aren’t enough; organizations need to pair governance with usability,” he adds. “If approved AI tools don’t meet the pace of business, employees at every level, including leadership, will find their own solutions. Successful organizations will be those that make the secure path the easiest path.” IT leaders can’t solve the problem with more governance, he notes. “Policies and restrictions slow shadow AI down, but they don’t stop it, especially when the people using it are senior enough to absorb the disciplinary risk,” Maloo adds. “What CIOs can do is focus on providing tools that grant users full access to the necessary systems and data, eliminating the need to choose between a capable but ungoverned tool and a safe but limited one.” Speed over security The TrustedTech data echoes a June report from employee monitoring software vendor Teramind, which found that more than two-thirds of C-level executives prioritize speed over security when using AI tools, notes Nik Kale, a principal engineer and product architect at Cisco, and member of the Coalition for Secure AI. In addition, the Teramind report found that two-thirds of enterprise AI activity runs through personal accounts on platforms for which the company already owns licenses, he notes. “People are paying for the governed version and using the ungoverned version of the same product, so the problem isn’t the tools,” he says. “The approved path is slower, buried in procurement, or disconnected from where the work actually happens, and speed wins every time under a deadline.” The problem then isn’t with the AI tools, but with the friction involved, he says. “People aren’t going around the front door because the room is locked,” Kale adds. “They’re going around it because the front door is slower.” In many cases, the use of shadow AI exposes a couple of shortcomings in enterprise processes, adds Matthew Scavetta, chief technology innovation officer at IT solutions provider Future Tech Enterprise. Many organizations don’t do a good job of making employees aware of the AI tools available to them, he says, and many organizations don’t offer training on the sanctioned applications, which drives users to pick products they are familiar with. “If you don’t solve problems for people quickly or make people aware of which tools they can use safely, they will find a workaround,” he adds. “AI tools are no different than anything else.” Shadow AI use by executives puts IT leaders in an incredibly difficult position, he says. “CIOs, in particular, are under more and more pressure each year to keep up with what’s possible as tech influencers keep preaching about the potential of these tools,” Scavetta says. “CEOs and board members are constantly getting swept up in the hype; meanwhile, there are more and more case studies coming out showing how little ROI some organizations have realized. It’s a never-ending game of balancing possible with practical.” View the full article

Zoom has identified, and patched, a critical security hole that “may allow an unauthenticated user to conduct an account takeover via network access.” The issue is especially significant given Zoom’s extensive reach; it reportedly has more than 300 million daily active users, including 470,000 paying business customers. Given that reach, Zoom has been impacted by many other security incidents and France recently tried banning its use by French government users. Zoom security bulletins released Tuesday revealed the bug, and three other security issues, which Zoom patched on Wednesday. The company originally said that the takeover issue impacted Zoom Desktop Client for Windows before version 7.0.0, Zoom VDI Client for Windows before version 7.0.10 and 6.6.15 and 6.5.18 in their respective branches, and Zoom Meeting SDK for Windows, but on Wednesday, without explanation, it removed Meeting SDK for Windows as an affected product. The other three holes were less severe, but still significant, and they all involved privilege escalation. They impacted Zoom Workplace for Windows before version 7.0.5, Zoom Workplace VDI Client for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Workplace VDI plugin for Windows before 6.5.17 and 6.6.14 in their respective branches, Zoom Rooms for Windows before 7.0.5 and Remote Control for Zoom Contact Center for Windows before version 7.0.0. A second privilege escalation issue impacted Zoom Rooms for Windows before version 7.1.0, and another impacted Zoom Workplace VDI Plugin for Windows before version 6.6.14. Zoom did not immediately reply to a request for comment. ‘As bad as it gets’ Frank Dickson, group VP for security at IDC, said the nature of the reported hole is alarming. This bug “is about as bad as it gets, short of a worm. It is exploitable over the network, low complexity, zero privileges required, no user interaction needed,” he said, pointing out that exploitation is easy once technical details leak or someone reverse-engineers the patch, which is not as challenging as it once was, thanks to AI. “Yesterday’s script kiddies have been empowered,” he said. Dickson said the only good news is that Zoom discovered the hole itself, and that “no in-the-wild exploitation has been reported by any outlet as of Thursday.” Consultant Brian Levine, executive director of FormerGov, agreed with Dickson’s characterization of the hole, but said a potentially bigger issue is the high level of sensitive data that Zoom accesses. “An attacker with unfettered access to a Zoom account may be able to listen to recordings of sensitive meetings, to eavesdrop on future meetings, and to impersonate the organization in an effort to social engineer its clients and partners. Thus, given that ubiquity of Zoom in large enterprises, this vulnerability is pretty concerning,” Levine said. He’s encouraged, however, that Zoom found the flaw itself, which indicates its security team is “actually doing the hard, unglamorous work of auditing its code.” Giuseppe Trotta, principal security researcher at Malwarebytes, has a theory about what was behind the Zoom disclosure. “Because the vulnerability requires zero privileges and absolutely no user interaction, the remote network attack vector is highly suspected to involve the mishandling of deep links, such as custom URL schemes like zoommtg:// or zoomworkplace://,” he said. This led him to think that if the Zoom Workplace client for Windows fails to properly sanitize and validate incoming arguments passed via these special browser-to-desktop links, an unauthenticated attacker could craft a malicious string that could trick the desktop application into exposing or redirecting the user’s active session tokens directly to an attacker-controlled server, achieving a seamless and completely silent account takeover. “Watch out for Zoom links and invites if you are on Windows or VDI and haven’t updated yet,” he advised. Mike Wilkes, enterprise CISO at Aikido Security, offered kudos to Zoom for discovering the critical flaw, but he wanted to know how such a severe bug got into its software initially. “This vulnerability raises questions about why the defect was not caught by design review, fuzzing, or pre-release abuse-case testing,” Wilkes said. “A historical defect in Zoom’s product/security relationship has been prioritizing ease of use over security risk.” All four bugs important Justin Greis, CEO of consulting firm Acceligence, said that the two types of holes reported by Zoom, account takeover and escalation, are both important, but for different reasons. “The critical vulnerability is significant because it has the characteristics security teams worry about most,” Greis said, but the privilege escalation holes “are certainly important to patch as they primarily increase the impact of an attack that has already begun. The critical vulnerability has the potential to be an initial entry point, which is why it deserves the most attention.” Greis also applauded Zoom’s response, saying that it “reflects a reasonably mature security program.” He pointed out that no complex software platform will eliminate vulnerabilities entirely. “The differentiator is whether vendors are continuously investing in offensive testing, finding weaknesses before attackers do, and moving quickly to develop and distribute fixes,” he said. This article originally appeared on Computerworld. View the full article

The US Cybersecurity and Infrastructure Security Agency (CISA) has urged organizations to immediately secure Microsoft SharePoint deployments after warning that three vulnerabilities affecting the on-premises collaboration platform are being actively exploited. A recent advisory from the federal cybersecurity watchdog asked administrators to patch vulnerable servers, review Microsoft’s mitigation guidance, and assume that internet-facing SharePoint instances remain attractive targets for attackers seeking an initial foothold into enterprise environments. While applying patches remains the immediate priority, security experts caution that organizations should view the advisory as more than another Patch Tuesday exercise. “This is what separates an IT incident from a business crisis,” said Chris Boehm, field CTO at Zero Networks. “One compromised SharePoint box is a ticket. That same box, with a clear path to your domain controllers, backups, and file shares, is how you end up with an encrypted infrastructure and a disclosure event. Segmentation stops the first from becoming the second.” CISA’s advisory highlights CVE-2026-332201, CVE-2026-45659, and the newly added CVE-2026-56164, all of which have now been confirmed as exploited in the wild and added to the agency’s Known Exploited Vulnerabilities (KEV) catalog. Exploitation tells a different severity story The latest addition to CISA’s KEV catalog is CVE-2026-56164, an elevation-of-privilege vulnerability affecting Microsoft SharePoint Server. Although assigned a CVSS score of 5.3, the flaw can be exploited remotely without authentication, making it significantly more dangerous in practice than its severity rating alone suggests. Microsoft has released security updates for supported SharePoint versions and recommended enabling the Antimalware Scan Interface (AMSI) integration to help detect malicious requests associated with exploitation attempts. CISA also advised organizations to follow Microsoft’s incident response guidance, hunt for indicators of compromise, and rotate SharePoint machine keys where appropriate, acknowledging that patching alone may not fully remove attacker persistence from already compromised servers. Older vulnerabilities remain active entry points Alongside the newly disclosed flaw, CISA reiterated the urgency of addressing CVE-2026-45659, an insecure deserialization vulnerability allowing RCE that Microsoft had marked as “exploitation less likely” in its advisory in May. Another old bug CISA flagged is CVE-2026-32201, an improper input validation flaw that allows spoofing over a network. Both of these flaws are being actively exploited in the wild. CISA called out organizations failing to catch up with SharePoint updates, adding that attackers are increasingly targeting N-days rather than relying exclusively on newly discovered zero-days. On concerns of patching speed, Boehm noted resilience is becoming an architectural challenge as much as an operational one. “Stop measuring this in patch speed,” he said. “That’s a race you eventually lose. Some of these landed as zero-days with no fix on day one, and the window between disclosure and exploitation keeps shrinking. So the board-level question isn’t whether a server gets compromised. Assume one will. It’s how much of the business a single-owned system can take down with it.” Boehm argued that limiting network reachability through segmentation should sit alongside patch management and threat hunting as a core defensive strategy. Reachability, he said, is a control that organizations own, not patch timing. CISA has given Federal Civilian Executive Branch (FCEB) agencies three days to remediate CVE-2026-56164 under Binding Operational Directive (BOD) 22-01. View the full article

The Cybersecurity and Infrastructure Security Agency (CISA) and four international cybersecurity agencies have published guidance urging software manufacturers and online service providers to establish coordinated vulnerability disclosure (CVD) programs, saying structured engagement with security researchers can help improve vulnerability management and product security. Published jointly with the US National Security Agency (NSA), Japan Computer Emergency Response Team Coordination Center (JPCERT/CC), the Netherlands’ National Cyber Security Centre (NCSC-NL), and the UK’s National Cyber Security Centre (NCSC-UK), the guidance, “Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers,” outlines how organizations can build public programs for receiving, assessing, and responding to vulnerability reports involving software, hardware, and network products. According to the guidance, a well-defined CVD program enables software manufacturers and online service providers to better assess potential risk, improve vulnerability management processes, and make informed decisions that strengthen product security. CISA said the guidance supports its Secure by Design initiative, which encourages technology providers to build more secure products and take greater responsibility for identifying and remediating vulnerabilities. “Coordinated vulnerability disclosure is foundational to building a secure software ecosystem,” Chris Butera, CISA’s acting executive assistant director for cybersecurity, said in a statement. “The practices in this guide help protect customers, strengthen products, and support CISA’s Secure by Design initiative, which encourages companies to be transparent and responsible in how they build and maintain their technology,” Butera said. Building an effective disclosure program The guidance recommends that organizations publish a clear vulnerability disclosure policy describing how researchers can report vulnerabilities, what testing activities are permitted, how reports will be handled, and what researchers should expect throughout the assessment process. CISA said maintaining communication with researchers helps keep the process transparent and builds trust between vendors and the security research community. Piyush Sharma, co-founder and CEO of cybersecurity firm Tuskira, said the guidance addresses a key operational requirement for both researchers and security teams. “CISA is right to emphasize that vulnerability disclosure requires a clear process,” Sharma said. “Researchers need to know where to report a flaw, while security teams need defined ownership to validate, prioritize, and remediate findings.” Andrew Costis, engineering manager of the Adversary Research Team at AttackIQ, said establishing a reporting channel is only the beginning of the process. “Creating a clear path for researchers to report vulnerabilities is a great first step, but the real work starts once that report lands,” Costis said. “Security teams have to understand what the weakness could give an attacker access to and how urgently it needs to be addressed.” According to CISA, security researchers can help software manufacturers and online service providers identify weaknesses before they are exploited, but only if organizations provide a clear and safe mechanism for reporting vulnerabilities. Prioritizing vulnerabilities at scale The guidance comes as AI-assisted vulnerability discovery is increasing the volume of security findings that enterprise security teams must assess and remediate, according to Sharma. “The challenge is that AI-assisted vulnerability discovery is increasing the volume of disclosures faster than most organizations can manually assess them,” he said. Sharma said organizations should avoid treating every disclosed vulnerability as equally urgent and instead determine whether a flaw creates a reachable attack path, identify exposed assets, and evaluate whether existing controls can interrupt an attack while remediation is underway. Costis echoed that view, saying vulnerability management should focus on exploitability rather than severity scores alone. “Vulnerabilities can’t be treated as isolated findings or prioritized on severity alone,” he said. “Teams need to understand how a weakness connects to the rest of their environment and whether it creates a viable path to critical systems.” Where patches are unavailable, Sharma said validating compensating controls can significantly reduce enterprise risk until remediation is completed. Costis said organizations should also verify that remediation has eliminated exploitable attack paths rather than simply confirming that a vulnerability has been patched. “Closing a ticket is one thing,” he said. “Proving the attack path is broken, and the fix holds against real-world adversary behavior is another.” View the full article

Most security leaders I know working on AI robotics are being shown the same kind of video. A humanoid folds a shirt, sorts a bin, walks a warehouse aisle and a vendor uses the clip to move an embodied AI system from pitch to purchase order. Someone then has to sign off. Robot demos create procurement momentum before security teams receive the artifacts needed to evaluate the system as cyber-physical infrastructure. Before the book, I prepared cloud infrastructure operating in China and the United States for cybersecurity compliance audits and for the Multi-Level Protection Scheme, China’s mandatory security-grading regime that determines whether a system is allowed to operate. That work taught me a lesson I carry into every AI conversation now. You cannot secure what you cannot see into, and the buyer rarely sees in. A demo makes it worse. It shows one task, completed once, under conditions the vendor chose. None of what a security team must evaluate is on screen. This used to be a research-lab problem. It is now a procurement line item. The risk changed when embodied AI moved from a research demo to a purchase order. Vendors are asking security teams to approve embodied AI before the category has audit evidence, logging norms, supplier transparency or a shared-responsibility model. Embodied AI puts a model inside a machine that operates in the physical world: a robot, an arm, a humanoid. Once a model gains motors, sensors and a body, it ceases to be a software endpoint and becomes a cyber-physical system. It inherits hardware, firmware, a supply chain, an installer and a set of remote-access paths. Every one of those is an attack surface that the demo video doesn’t show. An embodied system is sold like software and behaves like a fleet of networked machinery on your floor. Evaluate these systems across five questions: provenance, access, integrity, evidence and accountability. Here is what each means. Evaluation question #1: Provenance What is inside, and who controls it? A humanoid is an assembly of actuators, lidar units, battery packs, joint modules and controllers, most from a supply chain the buyer never vetted, each running firmware the buyer cannot read. Software teams already fought this fight, which is why the software bill of materials became standard practice. Lack of transparency creates systemic risk. Embodied systems raise the stakes because the firmware now lives in dozens of parts that move. The risk does not depend on whether the robot is Chinese, American, German or Japanese. It depends on how much of the system the buyer can see: the hardware, firmware, remote-access paths and maintenance relationships behind it. China installs more industrial robots than any other country and sits near the center of the battery supply chain, as well as parts of the lidar and machine-vision supply base, which these systems draw on. Lidar, short for Light Detection and Ranging, uses pulsed laser beams to map an environment in 3D; machine vision handles optical inspection and guidance. Much of that lineage traces to suppliers your team has no relationship with. This is the hardware and firmware version of the third-party risk NIST’s supply chain guidance was written for, except that the component has motors. Demand a hardware and firmware bill of materials, then use it. Flag unsigned firmware. Map which supplier holds update authority for each part. Require a way to verify integrity, and treat any component you cannot identify as unmanaged. Evaluation question #2: Access Who can reach the fleet? Someone installs these machines, someone services them and the vendor pushes software updates. Where teleoperation is part of the support model, treat it as a privileged remote-access path, not a convenience feature. Each is a standing path into a machine that moves and lifts. Security teams have seen this story before. Operational Technology (OT) security went mainstream once industrial systems joined IT networks, and the recurring failure is unmanaged remote access that nobody inventoried. According to one industry survey, roughly half of attacks on OT assets originate in an IT network breach. SolarWinds showed why a trusted update channel deserves scrutiny when one delivered a backdoor to thousands of networks. Embodied systems add the harder part. The compromised endpoint can move. A remote operator on that channel can drive a machine and push code to every unit at once. Treat the fleet like high-value OT. Inventory every remote path, segment it from the production network, default to deny, require signed and verified updates, apply privileged-access controls to vendor maintenance, and treat an always-on teleoperation link as a backdoor until it is governed. Evaluation question #3: Integrity Whether the machine can be made to misperceive or misbehave. Researchers have shown that lidar spoofing can cause an autonomous system to brake for an obstacle that is not there or miss one that is. The same class of sensor and model manipulation, on a humanoid sharing a floor with people, produces motion, not a wrong answer on a screen. This is where safety engineering and security part ways. Functional safety stops hazardous motion when a component fails. It plans for accidents. Security plans for an adversary. A hardwired safety circuit can stay independent of the control plane, and a good one does. What it does not tell you is how an attacker reached that control plane, altered the model’s inputs or seized the fleet-management path. Ask the vendor to threat-model sensor spoofing and model manipulation as a path to physical motion. Then ask how you will even know it happened. A spoofed sensor does not announce itself. It shows up as a machine acting incorrectly with confidence. Picture the failure in plain terms. A warehouse robot takes a routine vendor update that changes how it navigates. The buyer cannot verify the firmware, cannot identify the supplier of the sensor module and has no logs to distinguish a spoofed sensor from a model error. The machine keeps moving, and no one can say why. Evaluation question #4: Evidence Whether the claims are true. You have not found an independent audit of embodied-AI field performance, so the uptime and reliability numbers come from the vendor. You are buying a claim, not a track record. Require independently verified uptime, intervention rate and incident history from a named deployment you can call. “Cutting-edge” is not a control. Evaluation question #5: Accountability Who owns the risk when it fails? Cloud taught security teams shared responsibility the hard way, after years of arguing which side of the line a breach fell on. Embodied AI arrives without that model, and the stakes are physical: the machine can injure someone. In my compliance work, the question that decided everything was always who is accountable when this thing breaks. Put it in the contract. Define the responsibility boundary, an incident-disclosure timeline, a right to audit and liability for physical harm. A vendor who will not commit in writing is showing you who bears the risk. These five questions share one root. For a decade, the security question was whether you could trust what a model generates. The embodied question is who can reach the machine and what they can make it do. A demo answers neither. Before any embodied system reaches your floor, make these five demands of the vendor. Provenance. A hardware and firmware bill of materials with named suppliers, integrity verification and a vulnerability-disclosure record. No bill of materials, no deal. Access. A full map of who installs, who services and every update and teleoperation path, with segmentation, default-deny and signed updates required. Integrity. A threat model for sensor spoofing and model manipulation that treats the failure as physical motion, plus logging that a defender can use. Evidence. Independently verified uptime, intervention and incident history from a named deployment you can call. Accountability. A contract that defines the responsibility boundary, incident-disclosure timelines, audit rights and liability for physical harm. The robot demo is built to make you feel the future has arrived. My job, and now yours, is the unglamorous question behind it. Ask what the machine’s attack surface looks like once it is bolted to your floor, wired to your network and updated by someone you have never met. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

A few years ago, I was retained to conduct a digital risk review for the chief executive of a mid-sized financial services firm. The brief was standard. Assess what was publicly available about the executive, identify exposure and advise on remediation. The AI tools I used completed the substantive reconnaissance in under ten minutes. What came back was a synthesized profile. Board memberships and the dates they started. A pattern of public commentary that revealed which policy positions the executive held strongly and which ones he would likely bend on under pressure. A philanthropic interest that explained which causes he would respond to if someone framed an ask around them. None of this information was sensitive in isolation. But assembled into a single, queryable narrative, it was something an attacker could use immediately. What I was looking at was a publicly accessible query to a general-purpose AI tool. And that is the problem most executive protection programs have not yet confronted. The reconnaissance phase for a targeted social engineering attack now takes minutes, not days, and the inputs required are trivial. AI-aggregated executive data has become an attack surface. Most security programs have not yet adapted to it. The reconnaissance phase has effectively collapsed Traditional OSINT work against an executive target required skill and patience. A competent analyst could build a useful profile over several days by working through search engines, corporate filings, social platforms and archived media. That work was a meaningful barrier. It took time and it required judgment about which sources to trust. It also left trails if the attacker was careless. AI aggregation removes all three constraints. The speed advantage is obvious but it is not the most important change. The more significant shift is synthesis. A search engine returns documents. An AI tool returns a coherent narrative with inferred relationships and interpreted significance. When I query a major AI platform for a senior executive by name, I get a structured account of their career arc, their professional relationships, their areas of visible influence and frequently their personal interests, relationships and public-facing affiliations. The MGM Resorts incident reported in 2023 illustrated the principle at scale. Attackers reportedly identified an MGM executive on LinkedIn, used that public profile information to impersonate them in a call to the IT help desk and obtained access credentials within minutes. The OSINT required was minimal and the manipulation was straightforward. What AI tools have done since is make that kind of reconnaissance faster, more complete and available to actors who lack the manual tradecraft to run it themselves. As the Verizon Data Breach Investigations Report consistently documents, the human element is present in the majority of confirmed breaches, and social engineering remains one of the most reliable initial access vectors. The accessible nature of AI tools is also expanding the threat population. Attacks that previously required a skilled analyst to design now require only a motivated actor with internet access. That changes the volume and targeting calculus. Executives who were previously too obscure to justify a sophisticated manual attack are now viable targets for anyone with a grievance and a query box. What should CIOs and CISOs do about it? The instinct in many organizations is to route anything involving an executive’s public profile to the comms or PR function. That instinct made sense when the risk was reputational. It no longer covers the exposure. What follows is how I advise clients to structure this work. Monitor regularly The starting point is establishing visibility into what AI tools are actually returning about your executive population. Not a one-time audit conducted during a board meeting and forgotten. The profiles shift continuously as new content is indexed, old content is reweighted and the models are updated. Assign ownership to run structured queries across the major platforms, including ChatGPT, Gemini, Perplexity and the Microsoft Copilot stack, on a regular cadence. Document what you find and track changes. Treat the output the same way you would treat a vulnerability scan as something to be prioritized and acted upon. Reduce the available attack surface Work with each executive to identify content that expands their AI-indexed profile without serving any legitimate business purpose. This includes legacy conference bios that contain personal details, social posts that reveal schedule patterns or family context and board announcements that, in aggregate, map an executive’s full professional network. For some of this content, removal is possible and worth pursuing with a targeted effort. The more important conversation is around future behavior. Executives who habitually overshare on LinkedIn or in conference panels need to understand, concretely, what that sharing enables. Family member exposure is a consistent blind spot. An attacker who cannot pressure an executive directly may look for leverage through a spouse, a sibling or a child. Executives rarely consider their family members’ public digital footprint as part of their own security posture. It is. Shape the narrative where reduction isn’t possible Public company executives, board members with mandatory disclosure obligations and individuals whose public profiles are central to their organizations’ credibility cannot simply go dark. The objective shifts from reduction to shaping in these cases. The goal is to ensure that what AI tools synthesize from the indexed content is professionally bound and does not inadvertently surface high-value pretext material. This is a joint exercise between security and communications, with security defining risk boundaries and communications executing the strategy. Train executives on what their own profile looks like The most effective single intervention I have seen in executive briefings is also the simplest. Open a browser and query an AI platform on the executive in the room. Let them see the output. The reaction is consistent. They are surprised by the synthesis, uncomfortable with specific details that surface and immediately more engaged with the rest of the conversation than they were before. Abstract threat briefings about social engineering risks rarely land with senior leaders who feel they understand their own security position. Demonstrated evidence of their AI-mediated profile lands every time. As covered in the context of executive-targeted attacks, awareness is a prerequisite for the behavior change that makes protection programs effective. Integrate this into the executive protection program This work belongs alongside endpoint security, credential management and physical protection in a unified executive protection program. When it remains a communications function, it lacks the reporting structure, budget authority and operational discipline that security work requires. Assign an owner with a security mandate. Include AI exposure in the risk register. Report on it at the same cadence as other executive protection metrics. The organizations that have done this well have not created a separate program for it. They have extended an existing one. What effective executive protection programs now include The organizations that have integrated AI exposure into their executive protection work share a few characteristics that distinguish them from those still treating it as a communications edge case. They treat the executive’s public information footprint as a managed attack surface with a named accountable party. Someone is responsible for it, the same way someone is responsible for endpoint patching or identity governance. They include AI-assisted reconnaissance as a starting condition in red team exercises. Before any social engineering simulation begins, the red team runs the same queries an attacker would run. The pretext they design is based on what those queries return. Their executive protection briefings include an AI profile review as a standing agenda point. Physical security considerations, credential exposure and public information risk are reviewed together because they are connected. An attacker who knows an executive’s schedule from their public-facing content can time a credential reset attempt or a vishing call with equal precision. The executive I reviewed several years ago had no idea what his AI-indexed profile contained or what it enabled. Most of the executives I work with today are in the same position. By the time you finish reading this, it is likely those queries have already been run on someone in your organization. The question is whether your program is positioned to detect it and respond in time. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security experts are calling on enterprises to revise their vulnerability management strategies and move towards “just in time” patching in response the increased pace of vulnerability exploitation. Attackers are turning to AI to increase the rate of vulnerability exploitation and supply chain compromise so that traditional forms of vulnerability management are no longer keeping pace. Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA at managed security services vendor Huntress, recently told CSO that “organizations need to shift their vulnerability management program to a risk-based, continuous [approach], tied to real-time exploitation intelligence — not scheduled patch cycles that leave exploitation windows wide open for days and weeks.” Wild frontier Frontier AI tools such as Claude Mythos have signaled a structural shift for cybersecurity, readily surfacing vulnerabilities at a huge scale — a development that, as government security assurance organizations such as the UK’s National Cyber Security Centre point out, is likely to lead to a surge in patches. “Most organizations already struggle to fix known issues quickly, so a spike in AI-driven discovery could easily overwhelm teams and widen the gap between finding problems and fixing them,” Andrew Woodford, CTO at network security vendor Titania, tells CSO. “In many ways, this just exposes a problem that’s already there.” Shane Fry, CTO at cybersecurity vendor RunSafe Security, argues that patching as a security strategy has been in crisis for years, and AI-accelerated vulnerability discovery has simply pushed it over the edge. Some experts contend that virtual patching — a technique that involves blocking exploit attempts at a security layer rather than fixing vulnerable code — represents a sound mitigation strategy, but Fry has reservations about the approach. “While virtual patching will play a role going forward, its effectiveness is limited and leaves security teams chasing a gap they will never be able to close,” Fry says. Instead, security teams need to shift toward mitigation-first approaches that make it impossible for attackers to exploit bugs in software. “Removing entire classes of exploits upfront takes the heat out of the patch gap, and allows patching to become strategic rather than reactive,” Fry argues. ‘Assume Autonomy’ The conventional patch management model was designed around a world where vulnerability discovery happened at human speed: A human researcher finds a flaw, reports it, a CVE gets assigned, vendors ship a fix, enterprises test and deploy it — a process that can take weeks. AI-powered vulnerability discovery blows this model out of the water. “If offensive AI can identify, validate, and exploit vulnerabilities without human authorization, a 43-day median patch time, as noted in Verizon’s DBIR, is the least of your problems,” argues Rik Ferguson, vice president of security intelligence at Forescout. “An AI system doesn’t wait for a proof-of-concept to circulate on GitHub or a CVSS score to land in a dashboard. It finds the flaw, confirms exploitability, and moves.” Ferguson advocates a change of approach toward what he describes as “Assume Autonomy.” “The question is what compensating controls you put in place between discovery and remediation, and how you constrain what an attacker can do with access they’ve already acquired,” Ferguson explains. Just-in-time patching fits in with this philosophy and is a desirable goal but may be difficult to achieve in practice especially for the many enterprises that struggle with asset management. “Just-in-time patching is sound in principle: prioritize and deploy fixes as exploitation intelligence emerges rather than waiting for the scheduled window,” Ferguson says. “But achieving it has some real-world requirements: continuous asset visibility, knowing precisely what you have, where it is, and what its current exposure status is.” For example, Ferguson adds, “you can’t patch just-in-time against a vulnerability in a device you didn’t know was on your network.” Virtual patching Gunter Ollmann, CTO at pen testing as a service firm Cobalt, notes that just-in-time patching makes sense if and when a patch is available — but that’s not always possible. “The major problem lies in the discovery of new vulnerabilities in code or systems that the business has no rights or capabilities to fix themselves, and they have a dependence upon third parties to develop the fix or patch — and are therefore subject to external SLA [service level agreement] turnarounds,” Ollmann explains. In such cases, enterprises will need to deploy virtual patches capable of blocking or deflecting the exploitation vectors of the vulnerable system. “Businesses are in desperate need of quickly deciphering a new vulnerability and dynamically creating an appropriate blocking rule — or rules — for their layered defenses,” Ollmann says. Virtual patching may mitigate security threats particularly in operational technology (OT) and IoT environments where applying a vendor patch to a running production system risks unplanned downtime or safety system interruption but only serves as a stop gap, Ferguson tells CSO. “A network-layer control that blocks exploitation of a known flaw, while you work through the testing and deployment cycle for the actual fix, is a compensating control,” notes Ferguson, who warns that virtual patches come with multiple drawbacks. “Virtual patches require accurate detection signatures, they don’t remediate the underlying vulnerability, and they can create a false sense of closure that delays proper patching indefinitely,” Ferguson argues. “The risk is that temporary becomes permanent. The underlying vulnerability stays open, and the virtual patch becomes the reason nobody revisits it.” Just-in-time risk reduction Douglas McKee, director of vulnerability intelligence at Rapid7, advocates what he describes as just-in-time risk reduction rather than just-in-time patching because of the practical difficulties with the latter. “In the real world, especially in OT, medical devices, and business-critical systems, you can’t always patch the second a CVE drops,” McKee argues. “You still need testing, maintenance windows, rollback plans, and someone who actually owns the asset. However, the old monthly scan, report, and remediation cycle will not survive this pace.” Tips for modernizing vulnerability management The enterprise attack surface has expanded significantly of late, and patch management models haven’t kept up. In response, security leaders’ vulnerability management strategies have to become more of a continuous monitoring function, not a triage and remediation process. Modernizing enterprise approaches to vulnerability management involves “real-time exploitation intelligence integrated into prioritization, compensating controls deployed at discovery rather than at patch release, and visibility across the full asset estate that conventional patch management tools were never designed to cover,” Ferguson says. Rapid7’s McKee stresses that security teams need to separate “known vulnerable” from “actually reachable and exploitable in my environment.” This process can be achieved through a combination of asset inventory, internet exposure mapping, KEV tracking, vulnerability intelligence, ownership, and emergency change paths. “Prioritization based on risk factors like public exposure, known exploitation, automation potential, and technical impact is key,” McKee concludes. View the full article

Attacks targeting developer ecosystems are increasing in frequency and sophistication, with Node.js developers firmly in this week’s crosshairs, as multiple npm packages belonging to the open-source AsyncAPI and Jscrambler Code Integrity were poisoned with malware following compromised development credentials. The incidents highlight the cascading effect of software supply chain attacks in which stolen credentials are then used to perpetrate additional compromises. Security researchers advise organizations to completely rebuild from clean images any developer machines that have installed a poisoned package — and to rotate all npm tokens, source control access, cloud credentials, CI/CD secrets, SSH keys, signing keys, and browser sessions. Affected packages include: [email protected], [email protected], [email protected], [email protected], [email protected], @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected] and @asyncapi/[email protected]. However, packages that list any of the above poisoned packages as dependencies may also be impacted, including those from the same projects, such as jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2, and jscrambler-metro-plugin 9.0.2. Vulnerable GitHub Actions workflow used as entry point The attack against AsyncAPI, an open-source reference specification and toolset for implementing event-driven architectures and asynchronous APIs, occurred on Tuesday and was independently detected by multiple security companies monitoring the npm registry, including Upwind, Socket.dev, Wiz, StepSecurity, and Aikido Security. According to the researchers’ analysis, attackers took advantage of a known configuration vulnerability in a GitHub Actions CI/CD workflow that had been reported in April. The flaw involves the pull_request_target event, which executes whenever a new pull request is made. When triggered, the workflow automatically checks out and executes the developer’s submitted pull request code in the Actions container, but this is done in the context of the base repository with full access to secrets. The AsyncAPI project had a proposed fix since May 17, but the fix had not yet gone through the full review and was not merged into the main branch. “At 05:08 UTC, the attacker opened PR #2155 containing a markdown file with obfuscated JavaScript hidden after approximately 1,000 bytes of whitespace,” researchers from Wiz explained in their report. “The payload was designed to scan the GitHub Actions runner’s environment for secrets and exfiltrate them to a dead-drop URL on the rentry.co pastebin.” When a GitHub Actions workflow is triggered and is executed in an environment, a temporary GITHUB_TOKEN is generated to allow for authenticated git commands against the repository. Other tokens might also be included. In this case, the attackers managed to obtain a token associated with asyncapi-bot, a service account that had access across the entire AsyncAPI organization on GitHub. This allowed them to perform malicious code commits in two separate repositories. Those commits then triggered automated build workflows that generated and published the npm packages. The payload bundled in the packages shares some similarities with a malware framework called Miasma that was used in previous supply chain compromises. However, the malware code appears to be significantly different from previously documented variants. The first-stage code downloads a secondary trojan payload that has variants for Linux, Windows, and macOS. This is a modular malware framework with credential theft capabilities that targets passwords and cookies saved inside browsers, SSH keys, npm and GitHub tokens, AWS credentials, macOS Keychain, and cryptocurrency wallets. The trojan communicated with a command-and-control server and can accept remote commands to perform file operations, list directories, and exfiltrate data. Jscrambler compromised via leaked npm credential The Jscrambler attack happened over the weekend on July 11 with attackers publishing multiple trojanized versions in two waves. Jscrambler Code Integrity is a client-side security library designed to protect JavaScript-based web and mobile applications against tampering and reverse engineering. Jscrambler published an advisory in response to the incident in which it clarified that the attackers published malicious versions of the package using a npm publishing credential. However, unlike the AsyncAPI case, how that credential was leaked in the first place is not clear. Initially the attackers released new package versions with two malicious scripts that get executed at install time using a preinstall hook in the configuration script. The scripts also execute platform-specific binaries for Linux, macOS, and Windows embedded in an obfuscated container. Because preinstall or postinstall hooks are common ways to deliver malware in npm packages, they are automatically checked by security tools. To avoid detection, the attackers pivoted to a method that involved injecting the malicious code directly in the dist/index.js and dist/bin/jscrambler.js files. This changed the malware execution from package installation time to when the package gets imported into other projects or the Jscrambler CLI is invoked. The embedded malware executables for different platforms are written in Rust and, according to Socket.dev’s analysis, were “a broad, developer-focused credential and secret harvester” that targeted browser-extension crypto wallets, API keys from AI coding assistants and MCP servers, cloud credentials for AWS, Azure and GCP, authentication tokens for messaging applications (such as Discord, Slack, and Telegram), password stores from browsers, Steam, and KDE. View the full article

Attackers who already have administrator privileges on a Windows machine have newer ways to slip past endpoint security without exploiting a vulnerable driver or modifying trusted binaries. Bitdefender researchers have warned against three techniques that abuse Windows Bind Links, a legitimate filesystem virtualization capability, to occupy security tools with clean files while malicious ones execute undetected. The techniques can be used “to blind EDR sensors and bypass built-in Windows defenses such as AMSI and AppLocker,” the researchers said in a blog post shared with CSO ahead of its publication on Wednesday. Dubbed File Binding, Process-Binding, and Silo-Binding, the techniques exploit the way Windows’ Bind Filter driver “bindflt.sys” redirects file paths in memory. While Microsoft reportedly assessed the issues as low severity because exploiting the techniques requires admin privileges, Bitdefender argued its importance by comparing the threat to Bring Your Own Vulnerable Driver (BYOVD) attacks. Microsoft did not immediately respond to CSO’s request for comment. Three attack paths from one weakness Bitdefender’s research focused on Bind Links, a Windows feature designed for legitimate virtualization scenarios such as Windows Sandbox, Windows containers, and Store applications. Bind Links operate entirely within “bindflt.sys,” allowing one file path to transparently resolve to another without creating a visible filesystem object or modifying the original file. Bitdefender demonstrated how attackers can progressively weaponize this capability. The first technique, File-Binding, redirects trusted DLL or file paths to attacker-controlled replacements. The researchers showed PowerShell loading what appeared to be a legitimate amsi.dll, but the Bind Link instead served a malicious DLL that exported identical functions while silently disabling malware scanning. Process-Binding extends the concept to executable files. Here, the researchers said, Windows reports a trusted executable like “winever.exe” is running, while the operating system actually executes another binary, such as cmd.exe. Because many security products rely on executable paths for allowlisting, signatures, and process identity, the mismatch can trick both security policies and analysts. The most sophisticated of the three, Silo-Binding, leverages Windows silos, the isolation technology in Windows containers, to present different filesystem views inside and outside an isolated environment. The researchers demonstrated a potential malware executing inside the silo as a trusted application, while security tools operating outside the silo read them as legitimate files. Bitdefender demonstrated bypasses against AppLocker, Windows Firewall, Sysmon, and even executed Invoke-Mimikatz under a trusted process identity to evade detection. A potential post-compromise attack vector Addressing Microsoft’s low-severity assessment, the researchers noted these techniques to be effective post-compromise evasion attacks, rather than a remote code execution vulnerability. “Every Windows 10 RS4+ and Windows 11 system is exposed once an attacker has administrator access on it,” they said. “Every AV and EDR that trusts the image-file path returned by standard process-notification routines is affected.” Bitdefender also disclosed a related privilege escalation scenario involving Docker Desktop, where members of the “docker-users” group could leverage Bind Links to reach SYSTEM privileges. Following the disclosure, Docker reportedly updated its documentation to clarify the security implications of the group’s permissions. While Windows 24H2 introduces a veto mechanism that can block bind-link creations, the researchers described it as only a partial mitigation because it is limited to newer systems, applies only in certain scenarios, and can be bypassed. Instead, they recommended resolving the real backing file rather than trusting process paths, revalidating file identity whenever a file is reopened for hashing or scanning, and enumerating active bind-link mappings to detect silo-scoped abuse. View the full article

The White House is expanding the use of AI beyond cyber threat detection into vulnerability management, launching a new program that aims to help government agencies and critical infrastructure operators identify, prioritize, and remediate software vulnerabilities faster. Called Gold Eagle, the initiative will act as a centralized clearinghouse for cybersecurity vulnerabilities, coordinating vulnerability reporting, verification, and remediation across federal agencies, open-source software communities, and operators of critical infrastructure, the White House said in a statement. “This new model will leverage frontier AI capabilities to continue advancing faster than adversaries, reduce duplicative scanning efforts, and deliver prioritized and actionable threat and remediation information to defenders across the Federal government and the private sector,” the statement added. The initiative stems from President Donald Trump’s June 2 executive order on advanced AI innovation and security, which directed federal agencies to expand the use of frontier AI to strengthen cybersecurity while working more closely with the private sector. The administration said the program has already begun receiving vulnerability reports from multiple industries and coordinating validation and remediation efforts. For enterprise security leaders, the announcement signals a government effort to move beyond traditional vulnerability disclosure toward coordinated vulnerability response. A move toward coordinated vulnerability response Prabhjyot Kaur, senior analyst at Everest Group, said Gold Eagle should be viewed as “a significant evolution” of existing vulnerability disclosure and government-industry coordination mechanisms rather than a replacement for them. “Its potential significance lies in creating a more operational clearinghouse that can consolidate vulnerability findings, reduce duplicative scanning, validate exposure across sectors, and coordinate remediation with critical infrastructure operators and open-source software communities,” Kaur said. The more meaningful shift, she said, is from largely distributed vulnerability disclosure processes toward centralized prioritization and coordinated action. Whether the initiative changes enterprise vulnerability management, however, will depend on execution, including industry participation, information-sharing protocols, and whether it can shorten the time between vulnerability discovery, validation, and remediation. The White House said Gold Eagle has already begun receiving and prioritizing vulnerability reports from multiple industries, coordinating scanning verification, and supporting remediation efforts using existing federal authorities and resources. AI can accelerate prioritization, not replace judgment The administration said the initiative is designed to help government and industry reduce duplicative vulnerability scanning and accelerate remediation by using AI to prioritize findings. Treasury Secretary Scott Bessent said the program reflects closer collaboration between the government and the private sector to protect financial institutions and other critical infrastructure. “Treasury, along with our partner agencies, will continue to harness frontier AI capabilities to stay ahead of our adversaries and defend the American people from emerging threats,” Bessent said in the statement. Kaur said AI is likely to deliver the greatest value in vulnerability triage and prioritization. “It can correlate findings from multiple scanners, remove duplicate alerts, link vulnerabilities to known exploitation activity, assess internet exposure, and combine technical severity with asset criticality and potential business impact,” she said. However, she cautioned that AI-generated prioritization is only as reliable as the underlying asset inventories, vulnerability data, and threat intelligence. “AI should therefore support, rather than replace, human validation, compensating-control analysis, and enterprise-specific risk decisions,” she said. Apeksha Kaushik, senior principal analyst at Gartner, said the initiative reflects a broader shift toward measuring cybersecurity performance by reducing actual risk exposure rather than simply increasing patch counts. By helping unify and accelerate vulnerability coordination between government and industry, the initiative could address long-standing challenges around fragmented reporting and inconsistent disclosure practices, enabling enterprises to respond more quickly and efficiently to vulnerabilities, she said. Execution will determine enterprise impact The announcement outlines Gold Eagle’s objectives but provides few operational details about how organizations will participate, how AI will validate or prioritize vulnerabilities, or how the initiative will work alongside existing coordinated vulnerability disclosure and vulnerability management programs. Kaur said CISOs should view the initiative as an additional source of vulnerability intelligence rather than a replacement for enterprise risk management. “The biggest takeaway is that vulnerability response is moving toward faster, more intelligence-led, and more coordinated prioritization across government and industry,” she said. Even if government coordination improves the quality and timeliness of vulnerability intelligence, enterprises will continue to own remediation decisions, Kaur added. “Government coordination may improve the quality and timeliness of intelligence, but enterprise context must continue to determine the final remediation priority.” View the full article

Two vulnerabilities found in Anthropic’s Claude for Chrome extension remain exploitable months after they were reported to the company, a research by Manifold Security noted. According to the researchers, the flaws can allow a malicious browser extension to trigger Claude into performing privileged actions, including reading Gmail messages, Google Docs content, and Calendar entries on behalf of a user. In a new blog post, the researchers said the issues are reproducible in Claude for Chrome version 1.0.80, released on July 7, and remain unresolved eight releases after they were first reported in May. “Anthropic shipped v1.0.73 through v1.0.80 in the weeks following our report,” the researchers added. “The internal tracking issue covering this class of vulnerability was marked ‘resolved’ in the weeks following our report.” However, the content script and side-panel handlers in the latest version remain “byte-identical” to v1.0.72 the researchers originally tested. Researchers drew parallels with the earlier ClaudeBleed disclosure, where the issue was found exploitable despite Anthropic announcing a fix. Anthropic did not immediately respond to CSO’s request for comment. Synthetic clicks trick trusted AI The first vulnerability stems from how Claude for Chrome handles user interaction before executing privileged actions. According to Manifold, the extension’s click handler does not verify whether an approval click originated from a real user through the browser’s “event.isTrusted” property. Meaning, another browser extension capable of injecting scripts into Claude.ai can generate synthetic clicks that Claude accepts as legitimate. In default configurations, the attack can automatically trigger one of Claude’s predefined browser tasks before presenting an approval dialog. However, if users have enabled the extension’s “Act without asking” mode, Claude may execute those actions silently, allowing an attacker to retrieve Gmail content, Google Docs data, or Calendar information, the researcher noted. Rather than exploiting a flaw in Chrome itself, the attack abuses the trust placed in Claude as an authorized browser agent. Manifold demonstrated an exploit in six lines of JavaScript. The researchers said the flaw can simply be fixed with one added line, “if (!n.isTrusted) return;” at the top of the click handler. A problematic privilege mode The second finding focuses on how Claude’s side panel initializes its permission model. Manifold found that loading the panel with “?skipPermissions=true” parameter makes the extension enter a privileged mode meant to bypass repeated confirmation prompts. While the researchers did not identify a direct external path to control this parameter today, they argued that the design creates a latent security risk because privileged behavior depends on a URL value rather than user-controlled inputs. Any future vulnerability capable of influencing that parameter could inherit elevated privileges without requiring additional security checks, the researchers noted. To address both findings, Manifold recommends validating genuine user interactions before executing privileged actions, avoiding URL-driven privilege transitions, and strengthening the authentication of internal extension workflows. View the full article

With the World Cup in full swing, stadiums across North America are currently accommodating thousands of fans every match day. That said, the stadiums’ biggest security challenge isn’t of a physical nature. It is not hyperbolic to say that football stadiums are some of the most chaotic endpoint environments in enterprise IT. On game days, tens of thousands of unmanaged, unknown devices connect to stadium networks, alongside payment systems, digital displays, operations platforms and venue staff devices. This creates a massive attack surface with a potential for serious disruptions, such as payment outages at concessions, delays in live streaming and interruptions to other venue operations. In this article, we’ll examine the World Cup stadiums’ unique cyber environments, while also providing steps that venues can take to harden their connectivity and ensure that their networks are protected. For World Cup stadiums, real-time visibility is far more important than device control Given that stadiums like Dallas’s AT&T Stadium, Mexico City’s Estadio Azteca and New Jersey’s MetLife Stadium can all accommodate over 80,000 soccer fans per game, it is impossible to control all these fans’ devices. Hence, network segmentation and real-time visibility are key. The fan-device layer obviously must remain entirely separate from the payment systems and operational infrastructure. All fan devices need to be relegated to the public WiFi, and treated as hostile by default. Although this segmentation is technically a form of device control, real-time visibility is truly the only way to maintain a Zero Trust environment within these stadiums. Continuous monitoring across networks, endpoints and identity systems is vital To achieve a Zero Trust architecture inside these massive football venues, it is important to have identity-centric zero-trust solutions firmly in place. With so many vendors, stadium personnel and operations workers requiring different levels of access to different systems, a robust identity security solution is crucial. All modern football stadiums require adaptive MFA, single sign-on, and conditional access based on users’ roles, locations, time of access request and device type. Without a robust identity access tool in place, a bad actor could compromise a single user’s credentials and gain access to payment systems or other operational technologies within the stadium. Besides an effective identity security tool, stadiums require network visibility and endpoint protection. All operational endpoints inside the arenas, including point-of-sale terminals, digital displays and staff devices, need to be managed and monitored via a robust endpoint management platform. With such a tool, IT teams can correlate telemetry across all network activity, which helps them to isolate compromised devices before a bad actor can execute malicious lateral movements. With real-time traffic visibility, IT personnel can detect anomalies, monitor network performance across all segments and receive alerts whenever unusual traffic patterns emerge. Although stadiums can’t control 80,000 fan devices per se, empowered IT workers can observe everything from the network level. Automation can help to ensure timely patching and audit readiness A unified log management and security analytics tool is vital in the World Cup setting. During a high-stakes event like the World Cup, SIEM platforms pull real-time logs from all the devices, endpoints, applications on the network. By using an effective patch management software in conjunction with a SIEM platform with automated alerts, stadium IT personnel can automatically patch hundreds of endpoints, while also accelerating incident response time. The very best SIEM tools will also use behavioral analytics to conduct real-time threat detection; if any anomalous activity is flagged on the network, automated alerts are triggered and incident response workflows will commence. SIEM tools also help when it comes to building out compliance reports and maintaining audit readiness. The IT departments inside these enormous football stadiums require a host of different compliance reporting capabilities, including PCI-DSS for stadium payment systems, SOC 2 compliance for third-party vendors handling fan data, ticketing and other operations, as well as GDPR compliance for loyalty programs, identity verification, WiFi registration and any biometric data captured within the stadium. Key steps that stadium IT personnel should take during the World Cup Firstly, a Zero Trust environment should be maintained inside all the stadiums. The 2026 World Cup contains far more integrated technologies than ever before. Today’s in-stadium technologies are borderline futuristic; referees wear body cameras, and there is even motion sensors embedded inside all World Cup game balls. Given this ultra-high-tech environment, all users, APIs and devices need to be continuously authenticated and treated as hostile-by-default. Secondly, in such a high-stakes, highly integrated environment, real-time monitoring and centralized visibility is crucial. With centralized visibility across the network, IT personnel can effectively conduct deep traffic flow analyses, identifying which devices are attempting to communicate with which systems. This way, all lateral movement attempts can be identified, and any fan-device that tries to reach a payment or operational technology segment can be flagged. Thirdly, IT teams should conduct incident simulations. Given the complex environment of broadcasting infrastructure, digital ticketing systems, POS, WiFi and commercial cellular networks, it is vital that IT personnel test their incident response processes to ensure they avoid service disruptions and prevent data leaks during matches. The bottom line: The 2026 World Cup stadiums require robust cybersecurity solutions From a cybersecurity perspective, the 2026 World Cup is a unique event. With matches taking place across sixteen different cities in three different countries (not to mention the currently heightened geopolitical tensions), there is a strong potential for state-backed cybercriminals and hacktivist groups to target stadium infrastructure. It is vital that stadium IT personnel are equipped with adequate cyber solutions, including robust SIEM, IAM, patch management and network management tools. There’s no reason to give bad actors a free kick. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Ask any medical doctor, and they’ll tell you that prevention is better than cure. It’s more cost-effective and it has better outcomes. The same is true in cybersecurity. But we believe that our industry has veered too far away from this simple concept. We observe that most new tools are detection-focused, and we are calling for cyber innovators and venture capital to re-emphasize and invest resources into blocking rather than just discovering problems. The reasons that cybersecurity relies on detection are understandable, and they are based on the history of networked systems. Early systems were fragile. Recovery was slow and downtime was costly. So, the first security controls were designed to restrict unauthorized access. They blocked execution and prevented exploitation, because if an attack succeed – such as a computer virus running successfully – the consequences might have been irreversible. When the internet exploded in the 1990s, prevention solutions multiplied. Vendors developed firewalls and antivirus platforms to stop threats before they started. But attackers adapted, of course, and networks grew more complex. Perimeter controls were no longer good enough on their own. The cyber industry responded with intrusion detection systems and later with Security Information and Event Management. Detection got a boost from large-scale log aggregation and analytics. This was a great complement to prevention. But it was never meant to replace it. Detection didn’t reduce risk Security today focuses on visibility, alerting and response. Executives use metrics like mean-time-to-detect and mean-time-to-respond, and compromise is often assumed to be inevitable. But as detection improves, this has not caused a proportional decline in compromise rates. IBM’s Cost of a Data Breach Report consistently shows that faster identification and containment reduce financial impact. But the average global cost of a breach is still millions of dollars – because detection does not prevent the initial compromise. The initial problem continues to come from the usual places: known vulnerabilities, stolen credentials or misconfigurations. In other words, detection reduces impact in the short term, but it does not reduce structural risk. The limits of a detection-first model When we gather for industry forums like the RSAC Conference, the topics include automation, AI-driven response and operational resilience. These are certainly important, but they have limits. Detection produces false positives and noise. The volume of alerts begins to outpace human capacity to sift through it for the genuine issues. Alert fatigue is real, and talent shortages continue. We observe that the ratio of detection tools versus prevention tools is getting bigger. RSAC Conference runs the largest startup competition in cybersecurity. Over the past three years more than 500 new cybersecurity companies have entered the competition, and we estimate that more than 70 percent of these companies are shipping detection tools, not prevention tools. Detection activates only after a failure has occurred, and unfortunately modern adversaries now operate at machine speed. Vulnerabilities are attacked through automation, and artificial intelligence generates phishing campaigns at a massive scale. As AI lowers barriers to entry and speeds up capabilities, the attack surface will expand even more. Advances in some of the frontier AI models, such as Anthropic’ s Mythos and OpenAI’s GPT-5.5, may unearth previously unknown zero-day risks while chaining together various low-risk vulnerabilities. If that’s not enough, quantum computing raises concerns about cryptographic resilience. Relying primarily on faster alerting is not the best response to all these threats that will simply multiply faster. Prevention changes the economics On the other hand, prevention changes defensive economics. To shrink the problem space, a professional can do these things: enable phish-resistant multifactor authentication (MFA), block malicious execution, segment networks and proactively manage vulnerabilities. As exposure decreases, alert volume declines. Detection becomes more effective because noise is reduced. Research shows that organizations have fewer high-impact breaches when they have mature identity governance, proactive patching and zero trust principles. Preventative maturity correlates with reduced incident severity and lower long-term costs. It doesn’t require perfection to be valuable. We think that security leaders, therefore, should reconsider how to define success. Reducing dwell time – the time an attacker is inside your systems – is important. Reducing entry points is fundamental. But when budgets favor post-compromise visibility over preventive architecture and governance, cybersecurity is not fulfilling its original mandate. AI will only amplify the imbalance, as capabilities that once required years of training can now be deployed quickly. Offensive toolkits are readily available. Achieving a better balance We believe that scalable prevention architectures and capabilities present a better path forward than expanding analyst headcount. Cyber threats will accelerate and detection will remain essential. But our profession shouldn’t be defined by how efficiently we observe compromise. It should be defined by how effectively we reduce the likelihood of compromise in the first place. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security engineers play a pivotal role in enterprise cybersecurity, because they are the professionals who design, build, and deploy security systems to protect an organization’s data, applications, systems, networks, and other IT components against a variety of cyber threats. Finding not just qualified security engineers, but the best and brightest available, needs to be a priority for CISOs and others overseeing security at their organizations. That’s especially true with the rapid rise of AI and the threats that brings to the enterprise. Here are some of the key skills and traits of elite security engineers to look for when hiring — or to acquire in order to uplevel your cybersecurity career. Acumen with AI-powered tools These days, AI-related skills are in demand regardless of domain, and this certainly applies to security engineers. There’s a wealth of solutions leveraging AI in the market, tools that engineers can add to their defense arsenal. “AI is transforming security engineering from reactive alerting to predictive threat detection,” says Praveen Margabandhu, digital engineering anchor at financial services firm Navy Federal Credit Union. “AI-driven anomaly detection now identifies behavioral patterns that indicate fraud or compromise before traditional threshold-based systems would fire. This shifts the security engineer’s role from incident responder to threat model designer.” AI-powered tools have taken over a large portion of the detection and triage work that used to be the core of a security engineer’s day, says Maruf Ahmed, cofounder and CEO of global tech staffing firm Dexian. “Vulnerability scanning runs on its own now,” he says. “Threat flagging that used to require a team pulling through logs for hours happens in minutes.” This has freed up capacity on most security teams and changed what the day-to-day work looks like, Ahmed says. “With detection increasingly automated, the engineer’s value sits more in interpreting what gets flagged and deciding what to do about it,” he says. Keen understanding of emerging and established AI threats Engineers must also have a thorough understanding of the risks AI presents, including AI-enhanced cyberattacks using large language models (LLMs) to automate and scale highly personalized social engineering attacks, craft sophisticated malware, and generate deepfakes. Other AI threats they need to be aware of include prompt injections, data and model poisoning, disclosure of sensitive information, model theft, supply chain compromises, and excessive agency. “The same generative tools that help security teams work faster are available to adversaries, and it shows,” Ahmed says. “Phishing campaigns read better and land more precisely than they did a year ago. Social engineering is harder to catch when the language is polished and tailored to the target, and security engineers are now defending against threats built with the same class of technology they use on the defensive side.” That has raised the bar for what reliable detection looks like, Ahmed says. “The objective shift I hear most from clients is about trust in their own systems,” he says. “Two years ago, the priority was visibility — making sure you could see across your environment. Most organizations have that now. The harder problem is knowing whether what those tools are telling you holds up under scrutiny and having people on the team who can stand behind those findings in front of a regulator or a board.” Appreciation of performance and business goals The best security engineers understand how performance and security intersect, says Margabandhu, who leads performance engineering across Navy Federal Credit Union’s digital banking infrastructure, including real-time fraud detection, identity and access management, and cybersecurity infrastructure resilience. “A fraud detection system that is secure but too slow to catch transactions in real-time is not secure at all,” Margabandhu says. “Elite engineers optimize for both simultaneously.” Engineers must be able to put things in business context, Ahmed says. “An engineer who can work across domains, validate AI outputs, and learn new tools fast is valuable. But that value compounds when the person also understands what the organization is trying to protect and why,” he says. Security engineers who understand the business make better risk decisions, write more effective policies, and generate less friction with the teams around them, Ahmed says. “That is the profile employers are hiring toward right now, and it is where the talent shortage is most pronounced,” he says. Systems mindset “One of the biggest misconceptions in cybersecurity hiring is that elite security engineers are defined purely by technical certifications or tool familiarity,” says Juan Mathews Rebello Santos, an independent cybersecurity researcher and ethical hacker. “Technical skill absolutely matters, but the strongest engineers I’ve worked with consistently share a combination of analytical thinking, operational adaptability, communication ability, and deep systems understanding,” Santos says. Elite security engineers understand how infrastructure, cloud services, identity systems, applications, APIs, networks, users, and business operations connect, Santos says. “Modern attacks rarely target a single isolated component anymore,” he says. “Threat actors chain together weaknesses across environments. Engineers who can understand those relationships holistically are significantly more effective at both prevention and incident response.” Cross-disciplinary fluency and broad stack know-how Being an elite software engineer today means having a range of technology experience and knowledge. “Organizations want engineers who can work across more of the stack than they used to,” Ahmed says. “A role that might have asked for deep specialization in one area now expects someone who can move between cloud infrastructure, application security, and compliance without needing a handoff at every boundary.” The attack surface has continued to get wider, and the job descriptions for security engineers has followed suit. “That cross-domain fluency matters because security incidents rarely stay contained in one layer,” Ahmed says. “The engineer who can follow a problem from the network through the application to the data governance framework resolves it faster, with fewer people involved.” The strongest security engineers bridge infrastructure, application, and business domains, Margabandhu says. “They can speak to a CISO, a developer, and a cloud architect in the same conversation,” he says. “An engineer who can explain what an authentication problem means for fraud exposure moves faster in a room full of executives than one who can only describe it in infrastructure terms. I’ve watched technically brilliant people lose that race repeatedly.” Having the ability to communicate technical risk clearly to non-technical leadership can mean the difference between success and failure of attacks. “Many security failures today are not caused by lack of tooling, but by misalignment between technical teams and business decision-makers,” Santos says. “Elite engineers can explain operational risk, prioritization, and security tradeoffs in language executives understand.” Deep understanding of third-party risk and non-human threats Threats can come from anywhere, including supply chains and non-human combatants. Third-party cybersecurity risks are on the rise. The 2026 Global CISO Leadership Report by executive search firm Hitch Partners, based on a survey of more than 625 information security executives across the US and Canada, says 43% put third-party risks as the No. 1 priority. “Most teams are still better at securing what they own than securing what they depend on,” Margabandhu says. “The mental shift from perimeter thinking to dependency thinking is real and not everyone has made it. The engineers who treat every API call, every credentialed vendor, every third-party model as part of their attack surface approach design differently.” Another growing source of potential threats are not human. Machine identities now outnumber human identities by ratios exceeding 100 to 1 in most enterprise environments, with some sectors closer to 500 to 1, according to the ManageEngine Identity Security Outlook 2026 report. This includes service accounts, API keys, automation tokens, and AI agents, any one of which can present data governance and security risks. Many organizations are still managing machine identities through manual processes that weren’t designed for scale, Margabandhu says. “Engineers who understand non-human identity governance are rare and increasingly important. This is not a future problem.” Willingness to keep learning Security engineers need to have a desire to never stopped learning. “That sounds obvious until you work with people who’ve been doing this for 15 years and are still operating from the same threat models they built in 2012,” Margabandhu says. “Security changes fast enough that standing still is the same as going backwards.” The security engineers who keep up aren’t reading one report a year. “They’re genuinely curious about what attackers are doing right now, this month, and they adjust how they think accordingly,” Margabandhu says. “That quality is harder to hire for than most technical skills, because it’s not on a resume.” With AI presenting new and more sophisticated threats, keeping up with the latest developments is perhaps more important than ever. “Strong engineers are naturally investigative,” Santos says. “They actively study attack techniques, test assumptions, reverse engineer failures, and continuously adapt their understanding of risk.” The best security engineers are often the people who remain intellectually uncomfortable because they know the landscape is always evolving, Santos says. Employers have started paying closer attention to how fast someone can learn, Ahmed says. “The threat landscape and the defensive toolkit are both moving faster than any certification program can track, so hiring managers are probing for adaptability in interviews: how candidates have responded to recent shifts, whether they have picked up unfamiliar platforms on their own, how they work through problems they have not seen before,” he says. View the full article

Passkeys have been around for some time, but enterprise-wide adoption to this point has been slow for a number of reasons. But soon, many Microsoft customers won’t have a choice. Starting September 1, Microsoft will roll out passkeys as the default authentication method in its cloud-based identity and access management (IAM) service Entra ID. And following a transition period, Microsoft-provided SMS and voice authentication will officially end on February 1, 2027. With this move, Microsoft seems to be underlining the urgent need for a more secure authentication standard, as attackers up their game with AI. This is an “important milestone,” because it moves passwordless authentication from an optional security enhancement to the expected standard, noted Ensar Seker, CISO at SOCRadar. “That shift is significant as attackers increasingly rely on AI to automate phishing campaigns, generate convincing login pages, and conduct large-scale credential theft.” Microsoft’s six-month passkey roll-out Passkeys require users to authenticate via a fingerprint, facial scan, or lock screen mechanism, rather than a password. They can be stored on physical USB keys (like YubiKey), or as digital credentials on computers, phones, or in cloud accounts. This method, Microsoft contended, reduces reliance on phishable authentication tools like SMS and voice, and hardens protection against credential theft. Passkeys “work better for users and worse for cyberattackers,” Nadim Abdo, Microsoft corporate VP for identity and network access engineering, wrote in a blog post. Microsoft’s announced timeline for rolling out passkeys is relatively aggressive: September 1, 2026: All SMS or voice-enabled users will be “auto-enabled and nudged” to register a passkey upon multifactor authentication (MFA) sign-in. September 18, 2026: Pricing, commercial terms, and a list of supported telecom providers will be shared for scenarios that still require SMS or voice authentication due to regulation or technical or operational challenges. October 30, 2026: Enterprises still using SMS and voice must select and configure a supported telecom provider through the Microsoft Security Store. From then on, they will be responsible for any telecom-related costs. February 1, 2027: Microsoft-provided telecom delivery for SMS and voice authentication ends as a native Microsoft Entra capability. After February 1, enterprises that require SMS or voice for MFA must register a passkey before sign-in. There will be no opt-out option. It’s important to note that these dates apply to public cloud-hosted Entra ID. Support for other cloud environments will follow a separate timeline; additional guidance and dates are to come. While SMS and voice have served their purpose well, Abdo said, bringing MFA to billions of users who otherwise would have had none, the threat environment has changed in “speed, scale, and sophistication,” necessitating this move to passkeys. The benefits of passkeys SOCRadar’s Seker pointed out that passkeys fundamentally change the attack surface because, unlike with passwords, there is no transmission of shared secrets that can be stolen by threat actors. Authentication requires possession of the user’s device, along with biometric verification or a PIN. “Even highly convincing AI-generated phishing pages cannot simply trick users into handing over a passkey the way they can with passwords or one-time codes,” he said. So why haven’t we seen widespread enterprise adoption? Identity ecosystems are “fragmented,” Seker noted, and many enterprises still rely on legacy applications that only support passwords. They also struggle with cross-platform compatibility, lifecycle management, recovery processes, shared accounts, and employee onboarding and offboarding. Further, “until recently, many organizations viewed passkeys as a consumer technology rather than an enterprise identity strategy,” he said. Microsoft’s move changes that equation, because Entra sits at the center of many organizations’ identity infrastructure, Seker noted. Default settings are typically the strongest drivers of security adoption, so when passwordless authentication becomes required rather than optional, organizations are far more likely to deploy it at scale. Its biggest benefit would be a “dramatic reduction” in credential-based attacks, Seker said. He pointed out that most successful compromises still begin with stolen credentials obtained through phishing, infostealer malware, password reuse, or adversary-in-the-middle attacks. Passkeys “eliminate or significantly reduce” many of those attack paths, while reducing password fatigue and the help desk costs related to password resets. In addition, rather than trying to continuously improve users’ ability to detect increasingly sophisticated phishing attempts, passkeys remove the credential from the equation altogether, Seker noted. “That represents a more sustainable long-term security strategy than relying solely on user awareness training.” Still, passkeys are not a silver bullet, as they do not stop endpoint compromise, session token theft, malicious insiders, or attackers who already have control of a trusted device. Enterprises must complement passkeys with endpoint protection, continuous monitoring, conditional access policies, and identity threat detection, Seker advised. How enterprises can prepare To prepare for the shift to passkeys, Microsoft advised enterprises to review their authentication policy and identify the groups still using SMS or voice authentication. They should then select the best authentication method for user devices and workflows, and ensure all employees are given passkeys and security keys. Entra ID supports both synced passkeys (those stored in platform credential managers like iCloud Keychain and Google Password Manager), and device-bound passkeys such as Microsoft Authenticator passkeys, Entra passkey on Windows, or FIDO2 security keys. Seker advised enterprises to evaluate support for FIDO2 and passkeys across their identity infrastructure, and to develop clear enrollment and recovery procedures. They should also educate users on what’s changing, how passkeys work, and how they can complete registration. Further, Seker said, it’s important to establish secure device management practices and to continue enforcing least privilege, conditional access, and risk-based authentication policies throughout the transition. Ultimately, he pointed out, the move is crucial. “Over the next several years, organizations that continue relying primarily on passwords will likely face higher operational risk as AI continues to lower the cost and increase the effectiveness of credential-based attacks,” he said. This article originally appeared on Computerworld. View the full article

Earlier this month Microsoft warned that, because the latest AI models can now help discover vulnerabilities, CSOs will see a higher volume of security updates every month. It wasn’t kidding. Today the company issued a record number of patches, with 59 rated as critical. And Microsoft is now recommending that customers accelerate their patching schedules to more quickly deal with critical flaws. “Normally we have to wait for October or November to determine if we’ll break the previous [annual] patch volume record,” which was 1,245 vulnerabilities found in 2020, commented Satnam Narang, senior staff research engineer at Tenable. But not this year. Tenable counted 569 CVEs that were patched officially as part of this month’s Patch Tuesday, excluding the server-side updates not requiring user intervention, smashing last month’s record of 198 fixes It’s probable, he said, that by the end of this year, Microsoft will have found over 3,000 common vulnerabilities and exposures (CVEs). Today’s volume of holes is “striking,” he added, “but it reflects how good these tools have become at finding bugs, not how many of those bugs actually pose a risk to organizations.” Separately, SAP released 20 new and updated security patches, including a critical memory corruption vulnerability in NetWeaver Application Server ABAP, SAP Kernel, and frontend services tied to SAP GUI for HTML, which has a CVSS score of 9.9. Microsoft patches Among the huge number of CVEs that Microsoft found were three zero-days that need to be patched, including two that have been exploited in the wild. Those two are both elevation of privilege vulnerabilities: CVE-2026-56155, an Active Directory Federation Services (AD FS) flaw that allows attackers with limited access to elevate privileges to administrator, and CVE-2026-56164, a Microsoft SharePoint Server vulnerability. The third is CVE-2026-50661, a security feature bypass in Windows BitLocker, which was noted as having been publicly disclosed. “We surmise that this could be related to a flurry of zero-day vulnerabilities disclosed by the researcher known as Nightmare Eclipse or Chaotic Eclipse,” Narang said, “though no official confirmation was made. We also know that the researcher promised to drop something on Patch Tuesday.” While these were the most noteworthy flaws this month, Narang said, for CSOs the July patches prove that the state of the Exploitability Index, which rates how likely a vulnerability is to be exploited, must shift, given the machine speed of exploit discovery. For example, he pointed out, in May, Microsoft originally tagged CVE-2026-45659, a SharePoint vulnerability, as exploitation less likely. However, the vulnerability was added to the US Cybersecurity & Infrastructure Security Agency’s list of known exploited vulnerabilities on July 1. He added that Anthropic’s Red Team’s own findings for known vulnerabilities (n-days) revealed how fragile the monthly Patch Tuesday system has become, with its Mythos Preview model being able to produce proof-of-concept exploits for 13 of 14 vulnerabilities that were rated as Exploitation Less Likely or Exploitation Unlikely. “What this means is that our way of looking at Patch Tuesday has changed, because the exploitability index is centered around humans, not AI tools, and as these tools continue to improve, defense needs to improve alongside it,” Narang said. Dustin Childs, head of threat awareness at TrendAI’s Zero Day Initiative, agreed. “To call this record-breaking is a massive understatement,” said Childs. “This is the ‘Mother of All Releases’. The bug apocalypse has fully descended upon us, with July’s numbers pushing the year-to-date CVE count past every single full-year total of the last 20 years. Security teams need to take an extended break from their regularly scheduled activities to eat this elephant one byte at a time, starting immediately with active exploits in Active Director FS and SharePoint.” He particularly drew attention to a near-perfect 9.9 CVSS flaw in Windows VMSwitch (CVE-2026-57092) that allows low-privileged attackers to escape virtual machine boundaries for full host compromise. Jack Bicer, director of vulnerability research at Action1, agreed that IT leadership should prioritize immediate remediation of the actively exploited Active Directory Federation Services elevation of privilege vulnerability and the SharePoint Server elevation of privilege vulnerability . After that, he said, priority should be given to these critical vulnerabilities: Active Directory Certificate Services Elevation of Privilege Vulnerability (CVE-2026-54121), which introduces the possibility of attackers impersonating trusted systems and potentially compromising AD through certificate abuse; a Windows Active Directory Domain Services remote code execution vulnerability (CVE-2026-49164) which enables unauthenticated remote code execution against one of the most critical components within Windows enterprise environments; a Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central remote code execution vulnerability (CVE-2026-55944); a Microsoft Exchange Server spoofing vulnerability (CVE-2026-55008); Microsoft SQL Server remote code execution vulnerabilities (CVE-2026-54118 and CVE-2026-54117); and multiple Windows DHCP Server vulnerabilities. These holes create opportunities for attackers to compromise financial systems, communication platforms, databases, and core network infrastructure, Bicer pointed out, systems which often provide direct access to sensitive business information and frequently serve as high-value targets for ransomware operators and advanced threat actors. There are also important security updates for Microsoft Defender, Bicer added, noting that vulnerabilities affecting endpoint protection software deserve immediate attention because successful exploitation undermines one of the organization’s primary defensive controls. IT teams must prioritize AJ Grotto, a research scholar at the Centre for International Security and Co-operation and former Senior White House Director for Cyber Policy, said that Microsoft’s July Patch Tuesday “is a stark reminder that security teams are now operating in an era of vulnerability volume and velocity. With 570 vulnerabilities patched, including three actively exploited zero-days, the biggest concern for CSOs isn’t just the number of flaws, but the concentration of risk around identity systems, collaboration platforms, and privilege escalation pathways. The actively exploited vulnerabilities in Active Directory Federation Services and SharePoint are especially concerning because they target technologies that sit at the center of enterprise trust and access.” He added, “for CSOs, the challenge is no longer just defending against threat actors, it’s keeping up with an accelerating cycle of vulnerabilities and updates across the Microsoft ecosystem in the AI era. Security leaders should think critically about diversifying their vendors to protect their enterprise and save time and money on patching an increasing list of bugs that nearly tripled month-over-month.” “While the sheer number of [Microsoft] vulnerabilities might seem alarming on the surface,” said Nick Carroll and Rain Baker of the Nightwing ShadowScout threat intelligence team, “this can actually be seen as a positive sign for enterprise security. It means vendors are finding and fixing flaws before adversaries can weaponize them en masse.” And Josh Taylor, lead cybersecurity analyst at Fortra, noted that 26 of the Microsoft vulnerabilities have a CVSS base score above 9.0, and 13 of those sit at 9.8. “That matters,” he said, “but CVSS is still only one part of the risk story. The real triage problem this month is the mix of exploited issues, a publicly disclosed BitLocker flaw, and a massive concentration of vulnerabilities in Windows and Office.” He said, “for patching teams, this is the kind of month that rewards discipline. The right move is not panic, it is sequencing: put exploited issues and exposed infrastructure first, then let the normal validation process do its job.” Others increasing their patch cadence too Chris Goettl, vice-president of product management at Ivanti, noted many software vendors in addition to Microsoft are increasing their security update cadence. For example, Cisco Systems has just shifted to a risk-based, twice-monthly disclosure model (the first and third Wednesday of each month), Mozilla is on a near weekly security update march, and Oracle’s new Critical Security Patch Update (CSPU) program has been delivering targeted critical-severity fixes on the 3rd Tuesday of non-CPU months since May. Nightwing also noted that Adobe issued 12 separate security bulletins for products in its first twice-monthly bulletin. Administrators must treat today’s Priority 1 ColdFusion update (APSB26-82) with urgency, as it patches a critical 9.9 CVSS path traversal vulnerability (CVE-2026-48318). It’s one of 11 ColdFusion vulnerabilities patched. Additionally, retail and web administrators should immediately prioritize Adobe Commerce (APSB26-73), which resolves a 9.6 CVSS flaw allowing unrestricted uploads of dangerous file types (CVE-2026-48356). SAP vulnerabilities Jonathan Stross, senior product manager for cybersecurity research and innovation at Pathlock, said the most critical of the SAP fixes is Note 3747367, a memory corruption vulnerability in NetWeaver Application Server ABAP, with a CVSS score of 9.9. The vulnerability affects the ABAP Application Server, SAP Kernel, and frontend services tied to SAP GUI for HTML. According to SAP, an authenticated attacker can trigger logical memory-management errors that may lead to unauthorized data access, data modification, or system unavailability. The likely attack scenario involves a compromised account or malicious insider abusing a crafted request that reaches the vulnerable code path. “Because a successful exploit can impact confidentiality, integrity, and availability at the platform level, while potentially destabilizing a core ABAP system, organizations should treat this as the highest-priority patch in the July release,” Stross said. Prioritize the critical ABAP kernel issue, plus the AppRouter request smuggling note, and the Commerce Cloud sample-credential issue first, he said, because these are the most likely to produce direct security impact in real environments. But do not treat the updated notes as noise, he added. The July overview includes three re-released items that still matter operationally, and this should be reflected in patch planning and change records. The attack surface is distributed: ABAP, Java, BTP, Commerce, SAProuter, UI5, and supporting libraries all appear in the same monthly cycle, so patching needs coordinated platform ownership. Thomas Fritsch, an SAP researcher at Onapsis, described the SAP Security notes in detail and noted that SAP teams who can’t immediately install the NetWeaver memory corruption fix can, as a temporary workaround, disable all ICF nodes with a specific property in transaction SICF. However, since the workaround will disable opening transactions in SAP GUI for HTML, it is not an option for all customers and it is strongly recommended to install the patched ABAP Kernel version. Patching should become continuous “AI is likely to expose new classes of weaknesses, and will introduce some of its own through AI-assisted development,” commented Gene Moody, Field CTO at Action1. “Logically, with that in mind, the future of updating must become more continuous, more adaptive, and less tied to a fixed calendar. Discovery will not follow business logic; it will be swift and unforgiving. We must accept that, and be just as diligent in our defense, because the cost of failure is higher than the inconvenience of change.” He added, “in my crystal ball, I see a future where Microsoft and others move steadily away from scheduled monthly patch cycles in favor of rolling updates for most security issues in as close to live time as they can be researched and released. That would be a win for the entire industry. Faster patch creation and delivery, paired with more agile practices on the customer side, would finally start to align patching with the pace of modern discovery and exploitation.” “What needs to happen is simple,” he said. “Patching on a calendar is no longer a safe assumption in today’s threat landscape. Patching where and when needed versus scheduled is the only path forward.” View the full article

A newly documented phishing-as-a-service platform distributed through Telegram is lowering the technical barrier to Microsoft 365 account takeovers by giving less-skilled attackers automated tools to evade some authentication controls and retain access after compromise. The platform, called Forg365, uses AI-assisted lure creation alongside device-code abuse and adversary-in-the-middle techniques, according to research published by security company ZeroBEC. Forg365 was offered with a five-day free trial, followed by subscriptions priced at $400 per month or $3,800 per year, the researchers said. Customers can build phishing lures and control email delivery through a single operator panel. They can also manage captured account data and monitor compromised Microsoft 365 mailboxes. The service includes templates that impersonate widely used business platforms such as DocuSign, Adobe Acrobat Sign, SharePoint, and OneDrive. “Phishing-as-a-service has been around for quite a few years,” said Jonathan Ong, senior analyst for managed security services at Omdia. “But the degree to which AI is integrated into Forg365 and enables users is what makes it concerning.” Forg365’s significance lies in the industrialization and productization of the operator workflow, according to Devashri Datta, a cybersecurity researcher. “It integrates AI-assisted lure creation, evasion, and post-compromise mailbox operations into a subscription service distributed through Telegram,” Datta said. How Forg365 works ZeroBEC said the campaign it investigated began with an email built around a business-document and remittance-approval pretext. The message relied on legitimate cloud and email services before sending the recipient through several redirects. Forg365 classified visitors before deciding whether to display a device-code phishing page, an adversary-in-the-middle flow, or a harmless decoy. In the device-code attack, the victim is directed to a legitimate Microsoft authentication process and persuaded to enter a code that authorizes a session controlled by the attacker. The involvement of genuine Microsoft infrastructure can make the request appear credible. The platform can also relay authentication through an adversary-in-the-middle attack and capture session information. ZeroBEC said suspicious visitors were diverted to a benign page, helping the operators conceal the phishing flow from researchers and automated security tools. Complicating incident response A browser extension called ForgCookie allows attackers to generate and refresh Microsoft single sign-on cookies from their own browsers, ZeroBEC said. Forg365 also advertises tools for keeping sessions active and monitoring a compromised inbox. Read-only access to the mailbox can then be shared through a password-protected link. As a result, resetting a password may not remove the attacker. Stolen refresh-token material or an attacker-controlled session could remain usable after the password is changed. Any devices registered during the compromise must also be investigated. “CISOs should treat two controls as co-equal priorities rather than sequential ones,” Datta said, referring to tightly restricting device-code authentication and deploying phishing-resistant MFA such as FIDO2 or WebAuthn passkeys. Organizations that do not require device-code authentication should consider blocking it in Microsoft Entra ID, said Keith Prabhu, founder and CEO of Confidis. This can disrupt the device-code component of a Forg365 campaign, although it would not stop attacks that rely on adversary-in-the-middle techniques or stolen session cookies. Companies that still depend on device-code authentication should identify legitimate uses before imposing a broader restriction. Exceptions may be needed for some command-line tools, conference-room systems or other devices with limited input capabilities. Deploying phishing-resistant authentication may also require hardware security keys or managed smartphones and could increase support requests during the transition, Datta said. After detecting a compromise, response teams should revoke active refresh tokens and terminate existing sessions. Prabhu also recommended reviewing and revoking unauthorized OAuth permissions. Because ForgCookie runs in the attacker’s browser, defenders should look for repeated silent sign-ins and non-interactive Microsoft Graph activity from unfamiliar addresses, according to ZeroBEC. Mailbox forwarding rules and delegated access should be reviewed for unauthorized changes, Prabhu said. Such changes could allow attackers to monitor communications or retain access after a password reset. “IR teams should audit newly registered devices and remove any that cannot be attributed to the user,” Datta said. Teams should also check whether an attacker enrolled an unauthorized authenticator application or passkey during the compromise, she added. ZeroBEC found that some devices registered during its investigation had names beginning with “Forg365,” giving defenders a possible indicator of compromise. View the full article

Seventy-one percent of organizations say AI has access to core business systems. Only 16% govern that access effectively, according to the 2026 CISO AI Risk Report. Ask your IR team three questions: Where is your AI system inventory? What happens if a production model starts generating harmful outputs? Who has the authority to take it offline? I’ve spent 14 years in security — energy, banking, telecom, manufacturing. Red team work, detection programs and the last several years focused on AI risk and ShadowAI. What I see consistently: Organizations have AI in production, they have an IR playbook and they think those two things are connected. They’re not. The CISO who thinks their IR playbook covers AI incidents probably hasn’t tested it. The ones who have tested it know it doesn’t. Two kinds of AI incident — and why that split matters more than the list AI incidents surged 56.4% from 2023 to 2024, reaching 233 documented cases. Most IR frameworks — including NIST SP 800-61, MITRE ATLAS and the GLACIS AI Incident Response Playbook — provide you with a taxonomy of six incident types and stop there. While useful, it misses the more important split: Failures the model causes on its own, versus failures caused by a human. Your detection approach, your containment logic and your legal exposure are very different between those two groups. Model-originated failures — degradation, bias, hallucinations — happen when the system does exactly what it was built to do, just badly. The Epic Sepsis Model, deployed across hundreds of US hospitals, had a sensitivity of only 33% at external validation. It missed two-thirds of actual sepsis cases and flooded physicians with false alerts, as a 2021 JAMA Internal Medicine study found. No one attacked it. It just quietly stopped working while every dashboard stayed green. Externally induced failures — adversarial attacks, data poisoning, privacy breaches — happen when someone corrupts the inputs or the training environment. Tesla’s Autopilot phantom braking cases, investigated by NHTSA across hundreds of thousands of vehicles, show what adversarial input failures look like in a safety-critical system. These two groups need different primary defenses and their own playbooks. Then there is the hybrid case, which carries the most legal exposure right now. Hallucinations are model-originated but they land in court like human errors. When Air Canada’s chatbot invented a bereavement fare policy, the airline was held liable. When a US federal court let Mobley v. Workday proceed, it accepted that an AI hiring platform could be directly liable as an ‘agent’ of the employers using it. Neither failure looked like a security incident. Both ended up as legal ones. If your legal team is not on your IR call tree, your playbook is already incomplete. The CIA triad doesn’t cover a hallucination The CIA triad — confidentiality, integrity, availability — does not apply to most AI incidents. When Air Canada’s chatbot made up a policy, nothing was unavailable, nothing was changed without authorization, nothing was disclosed. The framework simply doesn’t reach it. When the Epic Sepsis Model missed two-thirds of cases, there was no breach, no intrusion, no indicator of compromise. By every traditional IR metric, the system looked fine. This is not an edge case. Classical IR frameworks assume deterministic failures with static indicators of compromise — an assumption that breaks down against probabilistic systems. Microsoft’s Security Blog said it well in April 2026: A model may produce harmful output today and something completely different from the same prompt tomorrow. The root cause is not a line of code. It is a probability distribution, and as Microsoft’s Security Blog put it, you cannot patch a probability distribution. The numbers confirm the gap. Average AI incident detection time is 4.5 days. Sixty-seven percent of AI incidents come from model errors, not adversarial attacks — yet security budgets keep funding perimeter tools built for the latter. We are looking for the wrong signals, with the wrong tools, for the wrong failure modes. What a mature AI IR capability looks like I get asked this at every conference I speak at. Here is the short answer: Three things that mature teams have in place before any incident occurs. First, an AI Bill of Materials (AIBOM) for every production system. Think of it like a software SBOM, but for AI: It documents the base model, training datasets, third-party dependencies and the full component stack. Without it, you don’t know what your AI is made of — and you can’t investigate a data poisoning incident or a supply chain compromise without that baseline. The OWASP GenAI Security Project released an open-source AIBOM generator in December 2025 that produces output in CycloneDX format aligned with SPDX standards. It is practical to implement now. Second, a model card for every production AI system — not a document in a shared drive nobody opens, but something your IR team can pull up in the first ten minutes of a response. Training data provenance. Model version. Known performance limits, including which subpopulations showed weaker accuracy in testing. Access controls. Blast radius if it fails. Most organizations I work with have model documentation written for data scientists that no one in security can use at 2am. That is not documentation. That is liability. Third, a named data scientist on the IR call tree. Not someone to brief after the incident — someone with authority to interrogate model behavior in real time. Traditional IR has a network engineer on call. AI IR needs the same logic applied to the people who understand how the failing system works. A fourth thing that very few teams have: A documented rollback threshold for each deployed model. A pre-agreed definition of what anomaly rate, drift metric or fairness deviation triggers containment or a fallback switch. Teams without this spend the first hours of an AI incident debating whether what they are seeing is actually a problem. Teams with a threshold spend those hours responding. Four things to do before the next incident Rewrite your detection triggers. Output anomaly scoring, data distribution monitoring for drift and behavioral tracking of model API usage need to be in your detection layer. They will not come from your SIEM. This is instrumentation work at the AI system level. Redefine containment. For most AI incidents, ‘isolate the system’ is the wrong first move. Switching to a rule-based fallback while keeping the service running may cause less harm than taking the system offline and triggering a business escalation. Each deployed model needs pre-defined rollback criteria and a named fallback. Write those down now. Get legal in the room before the incident. Mobley v. Workday means both the AI vendor and the deploying organization can carry liability for bias incidents. Air Canada means you cannot disclaim what your AI says to a customer. If your legal team is learning about an AI incident from a press inquiry, something has already gone wrong. Build your AI inventory and treat it like your asset register. Start with the AIBOM for your highest-risk systems — those with access to customer data, financial decisions or clinical workflows. The GenAI-IRF framework gives you a structured taxonomy for this work and the GLACIS AI Incident Response Playbook maps it to NIST SP 800-61 and MITRE ATLAS procedures your team can adapt without starting from scratch. Forty-two percent of organizations have already had a suspicious or confirmed AI incident, and more than half say their security posture is catching up, inconsistent or reactive. Updating your playbook isn’t optional. Fix it before you need it. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Enterprises have worked for years to improve detection and response times in the face of increasingly sophisticated attacks that relied on manual hacking and living-of-the-land techniques. AI is now threatening to undo those efforts. An increasing number of threat actors are automating all phases of attacks, including lateral movement by using LLM-powered agents, severely reducing the time from initial access to deep environment compromises. “The real shift is speed, scale, and orchestration: familiar cloud attack techniques were executed faster and across more surfaces than defenders could comfortably contain,” wrote researchers from security firm Sygnia last week in a report about an AI-assisted cloud environment compromise they investigated. Sygnia’s report came on the heels of research from Sysdig about a cyber intrusion and extortion campaign conducted end to end by an autonomous AI agent. Actions undertaken by the agent included harvesting credentials, mapping internal services, and establishing persistence. What both incidents show is that AI attacks have graduated beyond LLM-written malware scripts and phishing lures to handling all stages of attack chains, including parts that previously required human reasoning and hands-on command execution adapted to the environment. Last month researchers from the University of Toronto revealed that they managed to create an AI-powered self-replicating worm capable of autonomously finding and exploiting weaknesses in dozens of simulated systems. The researchers achieved this by leveraging an open-weight AI model and building an attack harness to keep it on track. While it may not be surprising to security experts that this level of AI-assisted attack automation is already happening in the wild, it’s very unlikely that many companies have had time to adapt their defenses. “What this exposes is a truth that all security personnel must come to terms with: Most breaches won’t hinge on advanced AI, but on unpatched systems, exposed services, and weak identity controls,” Gidi Cohen, CEO and co-founder of AI security startup Bonfy.ai, tells CSO. “AI just makes those gaps impossible to ignore. The organizations that will struggle aren’t the ones lacking AI defenses; they’re the ones still relying on human-speed security in a machine-speed threat environment.” No need for zero-days As aptly demonstrated by the U of Toronto study, AI agents don’t need sophisticated zero-day vulnerabilities to break into environments, because many environments have systems and applications with known flaws and generic weaknesses. The attack documented by Sysdig, which its researchers dubbed JadePuffer, exploited a year-old vulnerability (CVE-2025-3248) in Langflow, ironically a tool for building AI agents. In the new attack documented by Sygnia, attackers exploited a weakness in a web application that enabled them to find a stored AWS key. From there they quickly made their way through the victim’s cloud environment with the help of AI automation. “The threat actor was not exploiting a single misconfiguration; they were chaining weaknesses across application services, AWS resources, source-control repositories, CI/CD workflows, runtime components, and data stores, while rapidly executing credential discovery, secrets harvesting, cloud enumeration, deployment-pipeline abuse, runtime modification, database access, and operational disruption,” the researchers said. As with the JadePuffer case, the attackers documented by Sygnia were focused on extorting money from the victim. To achieve this, they compromised as many AWS instances as possible, exfiltrated data but also set up multiple persistence points in the AWS environment. The goal was to put pressure on the victim by demonstrating that despite recovery efforts they still had access to the environment. Speed is the new game Once sophisticated attackers break into an environment they often spend weeks or even months slowly moving to other systems. This is in part because it takes time for a human team to gain a thorough understanding of the environment and to find where the most valuable systems are. This activity is also often trial-and-error: The attackers perform reconnaissance to discover the network’s topology, find exploitable weaknesses in additional systems, and search them for stored credentials that could provide access to more targets, all while using existing OS tools or common system administration techniques that won’t trip malware and intrusion detection systems. Active threat hunting is one way to counter such techniques that are designed to evade automated detection. When threat hunting, human analysts inspect the organization’s network and systems manually for signs of compromises that might have been missed by tools. This is a slow but effective defensive technique — but only if attackers operate with the same time constraints. “Traditional incident response often relies on the assumption that attacker progression will generate enough observable signals for defenders to investigate and contain activity before access materially expands across the environment,” Sygnia’s researchers wrote in their report. “The observed attack pattern challenged this assumption. Forensic traces showed rapid, repeated activity consistent with automated or AI-assisted workflows for credential harvesting, permission analysis, vulnerability discovery, and attack-path mapping, allowing the intrusion to progress across multiple stages in a compressed time frame.” And it wasn’t a case of simple automated scripts going through an attack playbook either, but workstreams that showed clear signs of environment adaptation. Every new access was rapidly assessed and resulted in actions tailored for that specific system, whether an EC2 instance, S3 bucket, SQL database, or a CI/CD runner on GitHub. Prevention is back in the spotlight The obvious answer to AI-assisted attacks is AI-assisted defense. But simply the presence of AI-powered features in detection and response products is not a guarantee for thwarting such fast and adaptive attacks. Organizations must ensure all these tools and workflows are well integrated into a coordinated process across their different teams. Moreover, these attacks show the value of defense-in-depth actions such as continuous validation of configurations, fast patch deployment, frequent secrets rotation, network segmentation, IP-based access control rules, implementing the principle of least privilege for credentials, restricting administrative privileges, enabling multi-factor authentication, and isolating cloud workloads. Sygnia also recommends building automated response playbooks that can be quickly adjusted and deployed when potential signs of compromise are detected. “The skill floor for running a ransomware operation dropped to the cost of running an agent,” Dray Agha, senior manager of tactical response at security firm Huntress, tells CSO. “Very mediocre cyber criminals can now ‘level up’ their impact from AI. That should worry defenders more than any single new technique, as it means more attackers, more often, against more of the long tail of unpatched, exposed infrastructure.” View the full article

Global security agencies say enterprises must clean up their act as Russian government-sponsored attackers exploit weaknesses in routers. According to a new multinational cybersecurity advisory, cyberattackers continue to exploit inadequately-protected and/or poorly-configured network devices via age-old tactics. Threat actors scan for weakened devices, typically routers, allowing them to “opportunistically” compromise critical infrastructure networks, according to the bulletin from 19 federal agencies across North America, the UK, Europe, and Australia. They then transfer configuration files to servers they control. These files, containing plaintext or weakly-encoded information like credentials, or details about the organization’s network, hold most of the potential value, noted Seva Ioussoufovitch, a senior research analyst at Info-Tech Research Group. “It might sound simple, but this tactic has been exploited for well over a decade, and is clearly still effective,” he said. How SNMP attacks work To begin their attack, state-sponsored cybercriminals send requests via the standard Simple Network Management Protocol (SNMP) framework that supports device-network information exchange, which allows them to scan for weak, insecure devices still using older SNMPv1 or SNMPv2 protocols that accept common or default “community strings” for authentication. These strings are typically shared passwords, with predictable, public defaults that might have been left untouched by admins. Additionally, many of these devices may remain in their basic router configurations. Using spoofed IP addresses, threat actors instruct SNMP agents running on these devices to copy their configurations to a file (typically “config.bkp” or “output.txt”), then transfer that file to virtual private servers (VPSs) that they control. In addition, cybercriminals are exploiting common vulnerabilities and exposures (CVEs) in Cisco devices, as well as in the Cisco’s Smart Install (SMI) tool. Actors have exploited, at the very least, CVE-2018-0171 (published in 2018) and CVE-2008-4128 (published in 2008), according to the bulletin. Both of these targeted Cisco routers, giving remote, unauthenticated attackers the ability to execute arbitrary code, take unauthorized actions, or cause a denial of service (DoS). Notable groups using this method are known to the security community as “Berserk Bear,” “Crouching Yeti,” “Dragonfly,” “Energetic Bear,” “Ghost Blizzard,” and “Static Tundra.” According to the bulletin, the industries most vulnerable to Russian state-sponsored cyber actors include communications, energy, financial services, defense industrial bases, healthcare and public health facilities, and government services and facilities. A set-and-forget approach, even in 2026 The problem with router hygiene is that devices are susceptible to a “confluence of typical enterprise shortcomings” when it comes to operationalizing security, noted Info-Tech’s Ioussoufovitch. “Many organizations still take a set-it-and-forget-it approach to routers, and don’t track them like they would an endpoint,” he said. Compounding this risk is the fact that routers are typically critical to business continuity, which increases the necessity of keeping their security up-to-date. To make things worse, in some cases, it might also be unclear who’s in charge of device security. “Security points to the network team and they’re pointing right back at security,” Ioussoufovitch noted. As well, many organizations continue to rely on legacy hardware that may be unsupported, but that the business is unwilling to replace. Ultimately, Ioussoufovitch said, “network security just doesn’t seem to be receiving the same amount of attention as the usual areas of focus (like endpoints).” Recommendation: Move away from older protocols and devices immediately Specifically, the agencies urged security teams and network admins to upgrade to SNMPv3, enforce secure passwords, disable Cisco Smart Install, and block SNMP and common file transfer methods “at the firewall.” Enterprises should immediately disable SNMPv1 and SNMPv2, which are “legacy protocols and should no longer be needed on current devices.” In instances where they are still deemed necessary, shift from default settings to grant read-only access (no read-write access). SNMPv3 should be employed with authPriv configured to the “most modern encryption standard,” the bulletin advised. SNMPv3 adds strong authentication and data encryption unavailable in previous versions, and has more securely encoded parameters to authenticate and encrypt data. “Moving to SNMPv3, which offers stronger authentication and encryption, is a clear, actionable step security teams need to prioritize now,” Ioussoufovitch agreed. The government agencies urged enterprises to use strong, unique passwords for local accounts on network devices, and to monitor for unusual credentials that do not match standard naming conventions, or misconfiguration in logs or intrusion detection systems (IDS). Networks should support multi-factor authentication (MFA), and admins should enforce allow lists for management protocols like SNMP. Additionally, enterprises should update network device software, retire end-of-life devices, and disable Cisco Smart Install on all machines once initial configuration is complete, as this introduces serious security issues when it inadvertently remains enabled, the agencies said. Network security must improve across the board The advisory is a signal that enterprises may be underinvesting in network security, noted Ioussoufovitch. Admins and security leaders should be asking these questions: Do they have decent network detection and response capabilities in place? Are they applying analytics and anomaly detection to network traffic patterns? Have they incorporated micro-segmentation across the enterprise environment to limit risks posed by any individual router? “Getting at least some of these proactive measures in place, while taking a more disciplined approach to the tracking and replacement of EOL devices, can help security and network teams finally start making some headway against these types of threats,” said Ioussoufovitch. David Shipley of Beauceron Security agreed that enterprise networking equipment security must be improved, but said that’s more on the vendors than the critical infrastructure providers. Vendors should be shipping products that are secure by default; customers shouldn’t have to be going back and turning these features on. He added that it would be great to see Salt Typhoon-proof levels of device security and authentication. “Right now, it’s been trivial for them to pwn networking gear,” he said. While the guidance is important and will help, Shipley said, “building better and shipping secure by default would do even more.” View the full article