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