CSOonline

US President Donald Trump signed an executive order aimed at strengthening cybersecurity defenses and establishing a voluntary framework for cooperation between the federal government and developers of advanced artificial intelligence models, reviving portions of a broader AI initiative that he abruptly shelved less than two weeks ago. The order, “Promoting Advanced Artificial Intelligence Innovation and Security,” directs federal agencies to accelerate deployment of AI-enabled cybersecurity capabilities, establish a government-industry vulnerability-sharing initiative, and create a process for evaluating the cyber capabilities of frontier AI models. The move follows an unusual reversal by the administration. On May 21, Trump canceled a planned signing ceremony for what had been described as a much broader AI executive order after expressing concerns that the proposal could hamper innovation and weaken America’s competitive position against China. The cancellation highlighted growing tensions within the administration between officials concerned about the cybersecurity implications of increasingly capable AI models and others who argued that even voluntary government review mechanisms could become barriers to innovation and weaken US competitiveness against China. Reports at the time indicated the abandoned proposal would have created a voluntary process allowing developers of advanced AI systems to provide the federal government with access to models before public release so that national security officials could evaluate their cybersecurity implications. The new executive order preserves many of those cybersecurity provisions while emphasizing that it does not create mandatory licensing, preclearance, or permitting requirements for AI developers. A compromise between innovation and security On his first day in office, Trump dismantled many of the AI governance initiatives established under former President Joe Biden, arguing that regulation could slow innovation and undermine American leadership in the global AI race. Yet as AI systems become increasingly capable, national security officials have raised concerns about the potential impact of advanced models on cyber operations, critical infrastructure, and intelligence activities. The executive order attempts to reconcile those competing priorities. It repeatedly emphasizes innovation and American technological leadership while acknowledging that advanced AI capabilities present national security risks that require government attention. “The United States continues to lead the world in Artificial Intelligence because of the enormous talent and innovation of our AI industry, and because we refuse to stifle this innovation with overly burdensome regulation,” the order states. At the same time, it notes that advanced AI capabilities introduce “new national security considerations that require coordinated action.” The result is a framework that focuses narrowly on cybersecurity and national security concerns while avoiding the broader governance, safety and oversight provisions that characterized Biden’s 2023 AI executive order. Hardening federal and critical infrastructure systems A significant portion of the order is devoted to strengthening the cybersecurity of federal networks and critical infrastructure systems. Within 30 days, the Committee on National Security Systems, an intergovernmental body that establishes cybersecurity policies, directives, and standards for National Security Systems (NSS), must prioritize the cyber defense of national security systems, while the Department of War, the administration’s renamed Department of Defense, is directed to prioritize the protection of its own information systems. The Cybersecurity and Infrastructure Security Agency (CISA) must also issue directives and guidance designed to strengthen civilian federal networks and accelerate the adoption of AI-enabled defensive technologies. The White House also wants advanced cybersecurity capabilities extended beyond federal agencies. The order directs CISA to facilitate access to cybersecurity tools and services for state and local governments as well as operators of critical infrastructure. The directive specifically identifies rural hospitals, community banks, and local utilities as organizations that should benefit from expanded access to cybersecurity capabilities, including advanced AI tools. The focus on smaller organizations reflects growing concern that many essential service providers lack the cybersecurity resources available to larger enterprises despite facing increasingly sophisticated cyber threats. Moreover, the order directs federal officials to identify grant funding that could support organizations developing advanced AI-based vulnerability detection technologies and expands federal hiring pathways for cybersecurity professionals. Creating an AI cybersecurity clearinghouse Another notable provision establishes an AI cybersecurity clearinghouse intended to improve coordination between government agencies, AI developers, and critical infrastructure operators. The Treasury Department will form the clearinghouse in consultation with the National Security Agency, CISA, and other federal officials. According to the order, the initiative will operate through voluntary collaboration with AI companies and critical infrastructure organizations. Its mission will include coordinating vulnerability scanning activities, validating discovered software vulnerabilities, prioritizing remediation efforts, and facilitating the distribution of security patches. The order also directs the clearinghouse to deconflict vulnerability-discovery efforts so participants are not duplicating work. The provision appears designed to create a more organized mechanism for vulnerability discovery and remediation at a time when AI systems are becoming increasingly capable of identifying software flaws and weaknesses across large environments. Establishing oversight of frontier model cyber capabilities One of the most consequential sections of the order concerns advanced AI systems, often referred to as frontier models. Within 60 days, the NSA, CISA, Treasury Department, National Institute of Standards and Technology, and other agencies must develop a classified benchmarking process for evaluating the advanced cyber capabilities of AI models. The process will be used to determine when a system should be designated a “covered frontier model.” The order does not define what capabilities would trigger the designation, instead directing federal agencies to develop classified assessment criteria and benchmarks for assessing advanced cyber capabilities. The NSA will ultimately be responsible for making determinations in consultation with other national security officials. While that approach gives the government flexibility as AI systems evolve, it also leaves unanswered questions about which future models could ultimately fall within the framework. The administration also plans to establish a voluntary framework through which AI developers can consult with the government regarding whether systems under development meet the threshold for designation as covered frontier models. Under that framework, participating companies may provide the government with access to covered frontier models for up to 30 days before those systems are released to other trusted partners. Earlier drafts reportedly called for reviews as much as 90 days before release, though some AI industry officials pushed for a shorter 14-day period, according to reports. The government and developers would also collaborate on selecting trusted organizations that could receive early access to the models to support cybersecurity research and critical infrastructure protection efforts. The provision effectively creates a structured mechanism through which federal agencies can gain insight into some of the most advanced AI systems before they become widely available. Although the process is voluntary, it closely resembles portions of the broader executive order that Trump declined to sign last month. Rejecting licensing and mandatory approvals While the administration retained some of the cybersecurity provisions reportedly contained in the earlier proposal, it also included language clearly intended to reassure AI developers and investors. The order explicitly states that nothing in the initiative authorizes the creation of “a mandatory governmental licensing, preclearance, or permitting requirement” for the development, publication, release or distribution of AI models, including frontier models. That language appears intended to address concerns raised by critics of the abandoned May proposal, who argued that even voluntary review processes could eventually evolve into de facto regulatory requirements. Targeting AI-enabled cybercrime The executive order also directs the Justice Department to increase its focus on cybercriminals who use artificial intelligence as part of their operations. Specifically, it instructs the Attorney General to prioritize enforcement of federal computer crime, identity theft, and fraud statutes against individuals who use AI to gain unauthorized access to computer systems or who use AI tools while committing cybercrime. The order references the use of AI agents to unlawfully access information that is later used for criminal purposes, reflecting growing concern among policymakers that increasingly autonomous AI systems could enable new forms of cybercrime. Collectively, the provisions in the new order preserve Trump’s opposition to broad AI regulation while creating new mechanisms for federal agencies to assess the cybersecurity implications of increasingly capable AI systems. The order signals that even an administration committed to minimizing AI oversight views frontier-model cyber capabilities as a growing national security concern. View the full article

Developers who pulled packages from Red Hat’s @redhat-cloud-services npm namespace over the weekend got a secret-stealing worm instead. Security researchers from several cybersecurity outlets are warning of a new supply chain attack compromising over 30 Red Hat Cloud Services-related npm packages to steal credentials, authentication tokens, and other secrets from developer environments. The campaign, which Wiz researchers are tracking as Miasma, is thought to be the latest evolution of Shai-Hulud, a self-propagating malware family that has repeatedly surfaced in software supply chain attacks targeting the npm ecosystem. “Investigation revealed that at least 32 package releases contained unauthorized modifications that do not match the corresponding source repositories,” Wiz researchers said in a blog post. “These packages cumulatively average ~80,000 weekly downloads.” The worm also appears to be expanding its ambitions. Wiz noted that Miasma includes new collectors for Google Cloud and Azure identities, extending its focus from credential theft to mapping and potentially exploiting cloud access available from compromised developer environments. By compromising packages associated with Red Hat Cloud Services, the attackers are targeting a software ecosystem that many organisations already trust. The good news is that most of the packages feared to be infected are already removed, the researchers noted. Shai Hulud came for trusted packages According to reports, attackers compromised npm packages published under Red Hat Cloud Services-related namespace and inserted malware capable of executing automatically during package installation. The malicious payload was designed to steal a wide range of credentials and secrets from infected environments. Researchers observed attempts to collect npm authentication tokens, environment variables, cloud credentials, and other sensitive information commonly stored on developer workstations and CI/CD systems. Wiz’s analysis found that the malware belonged to the Mini Shai-Hulud family, a credential-stealing threat that has repeatedly appeared in npm ecosystem attacks throughout the year. “The payload appears to be derived from the (Mini) Shai-Hulud malware open-sourced by TeamPCP,” the researchers said. “The observed modifications are largely cosmetic, with references to the Dune universe replaced by Greek mythology themes (i.e., ‘spartan’), while the underlying functionality and tradecraft remain substantially similar.” The malware variant was seen creating repositories containing the description “Miasma: The Spreading Blight.” Supply chain is the focus, again. While credential theft was an immediate objective, researchers say the campaign’s broader goal appears to have been persistence and expansion within software distribution ecosystems. According to Wiz, the malware actively searched for credentials associated with package publishing workflows. OX Security similarly noted that the code targeted secrets that could enable attackers to move beyond the initially compromised packages and gain access to additional developer accounts and repositories. Wiz also found that the attackers modified package publishing workflows to make the malicious releases appear legitimate. A GitHub Actions workflow requested GitHub OpenID Connect (OIDC) identity tokens and executed an obfuscated payload that published packages with valid SLSA provenance attestations. This allowed the compromised releases to carry trusted supply-chain metadata. The technique draws from TeamPCP’s earlier attack against TanStack, the threat actor behind open-sourcing the Mini Shai-Hulud malware. Parallels with the threat actor’s code were observed in the recent Megalodon campaign, too, indicating an active spill over from the months-old supply chain rampage. For affected organizations, the immediate priority is determining whether the malicious packages were installed and whether any credentials may have been exposed. The researchers recommended rotating potentially compromised secrets, revoking and reissuing npm publishing tokens, and reviewing repository and package publishing activities. Wiz researchers said “most” malicious versions were revoked at the time of publishing the disclosure. It also shared a list of indicators of compromise (IOCs) along with the names of infected packages for additional support. View the full article

Developers who pulled packages from Red Hat’s @redhat-cloud-services npm namespace over the weekend got a secret-stealing worm instead. Security researchers from several cybersecurity outlets are warning of a new supply chain attack compromising over 30 Red Hat Cloud Services-related npm packages to steal credentials, authentication tokens, and other secrets from developer environments. The campaign, which Wiz researchers are tracking as Miasma, is thought to be the latest evolution of Shai-Hulud, a self-propagating malware family that has repeatedly surfaced in software supply chain attacks targeting the npm ecosystem. “Investigation revealed that at least 32 package releases contained unauthorized modifications that do not match the corresponding source repositories,” Wiz researchers said in a blog post. “These packages cumulatively average ~80,000 weekly downloads.“ By compromising packages associated with Red Hat Cloud Services, the attackers are targeting a software ecosystem that many organisations already trust. The good news is that most of the packages feared to be infected are already removed, the researchers noted. Shai Hulud came for trusted packages According to reports, attackers compromised npm packages published under Red Hat Cloud Services-related namespace and inserted malware capable of executing automatically during package installation. The malicious payload was designed to steal a wide range of credentials and secrets from infected environments. Researchers observed attempts to collect npm authentication tokens, environment variables, cloud credentials, and other sensitive information commonly stored on developer workstations and CI/CD systems. Wiz’s analysis found that the malware belonged to the Mini Shai-Hulud family, a credential-stealing threat that has repeatedly appeared in npm ecosystem attacks throughout the year. “The payload appears to be derived from the (Mini) Shai-Hulud malware open-sourced by TeamPCP,” the researchers said. “The observed modifications are largely cosmetic, with references to the Dune universe replaced by Greek mythology themes (i.e., ‘spartan’), while the underlying functionality and tradecraft remain substantially similar.” The malware variant was seen creating repositories containing the description “Miasma: The Spreading Blight.” Supply chain is the focus, again. While credential theft was an immediate objective, researchers say the campaign’s broader goal appears to have been persistence and expansion within software distribution ecosystems. According to Wiz, the malware actively searched for credentials associated with package publishing workflows. OX Security similarly noted that the code targeted secrets that could enable attackers to move beyond the initially compromised packages and gain access to additional developer accounts and repositories. Wiz also found that the attackers modified package publishing workflows to make the malicious releases appear legitimate. A GitHub Actions workflow requested GitHub OpenID Connect (OIDC) identity tokens and executed an obfuscated payload that published packages with valid SLSA provenance attestations. This allowed the compromised releases to carry trusted supply-chain metadata. The technique draws from TeamPCP’s earlier attack against TanStack, the threat actor behind open-sourcing the Mini Shai-Hulud malware. Parallels with the threat actor’s code were observed in the recent Megalodon campaign, too, indicating an active spill over from the months-old supply chain rampage. For affected organizations, the immediate priority is determining whether the malicious packages were installed and whether any credentials may have been exposed. The researchers recommended rotating potentially compromised secrets, revoking and reissuing npm publishing tokens, and reviewing repository and package publishing activities. Wiz researchers said “most” malicious versions were revoked at the time of publishing the disclosure. It also shared a list of indicators of compromise (IOCs) along with the names of infected packages for additional support. View the full article

A Palo Alto Networks vulnerability that allows attackers to establish unauthorized VPN access into corporate networks is being actively exploited in the wild, weeks after the company disclosed the flaw as a medium-severity issue and said it was unaware of any attacks. However, according to Rapid7, threat actors began exploiting the bug within days of disclosure. “Rapid7 MDR identified successful exploitation across numerous customers, however we did not observe any indication of successful lateral movement from the devices,” the firm said in its analysis. The attackers reached the network but were not seen pushing deeper in the cases Rapid7 investigated, it said. The flaw, tracked as CVE-2026-0257, affects GlobalProtect, Palo Alto’s remote-access VPN platform. Rapid7 said attackers began exploiting it as early as May 17, four days after Palo Alto published fixes and mitigation guidance. The development marks a significant escalation from Palo Alto’s initial May 13 advisory, which rated the flaw medium severity and stated that the company was not aware of malicious exploitation at the time. By May 29, Palo Alto had updated its advisory, increasing the vulnerability’s CVSS score to 7.8, marking exploit maturity as “attacked,” assigning its highest urgency rating. “Palo Alto Networks has become aware of limited exploit attempts on unpatched PAN-OS devices without mitigations applied,” the company said in the update. Exploitation emerges quickly While the flaw does not provide remote code execution on the firewall itself, Rapid7 urged organizations to treat it as more serious than its assigned severity score might suggest. “While the assigned CVSSv4 score indicates a medium severity, due to the circumstances surrounding this vulnerability, Rapid7 urges that organizations treat this as a critical vulnerability,” the company said. Sunil Varkey, advisor at Beagle Security, said the vulnerability is particularly concerning because it enables what he described as a “fully credential-less authentication bypass.” “Attackers can create a forged cookie using the publicly available public key and directly establish a VPN session without any malware, phishing, or stolen credentials,” Varkey said. Because the resulting session appears legitimate, such activity can be significantly harder to detect than many traditional intrusion techniques, he added. While remote code execution flaws often attract the highest severity ratings, authentication bypass vulnerabilities affecting remote-access infrastructure can create comparable enterprise risk, according to Sakshi Grover, senior research manager for cybersecurity services at IDC Asia/Pacific. “In a modern zero-trust model, identity is the new perimeter,” Grover said. “A vulnerability that grants unauthorized authenticated access effectively compromises that perimeter, even without executing code on the underlying device.” The enterprise risk, she added, is less about what the vulnerability does directly than what access it enables afterward, including lateral movement, credential harvesting, and persistence under the cover of what appears to be a legitimate session. What caused the flaw The flaw lies in how PAN-OS handles authentication override cookies, Rapid7 said in the disclosure. The gateway decrypts a cookie with a private key, then trusts its contents without checking a signature. The cookie is a convenience feature, Varkey said. “Many organizations enabled authentication override cookies for a simple reason: improving user experience,” he said. “And now it needs to be re-examined seriously.” The bug bites only under one configuration, Rapid7 added. The cookies must be enabled, and the certificate that protects them must also serve another function, such as the gateway’s HTTPS interface. An attacker can then recover the public key and forge a valid cookie. The feature is off by default, but teams that switched it on years ago may not know they are exposed. That points to a wider lesson, Grover said. Risk often comes not from a flaw itself, but from how technology is configured and maintained over time, she said. Patch pressure grows The urgency surrounding the flaw increased further after the US Cybersecurity and Infrastructure Security Agency added CVE-2026-0257 to its Known Exploited Vulnerabilities catalog on May 29 and directed federal civilian agencies to remediate the issue by June 1. Rapid7 said organizations should review affected GlobalProtect deployments, verify whether vulnerable configurations are present, and apply available fixes as soon as possible. The incident also highlights a broader challenge for organizations pursuing zero-trust architectures. “Zero trust has not eliminated the perimeter; it has redistributed it,” Grover said. “Identity providers, VPN gateways, remote-access portals, SASE edges, and cloud access services have become the new control points attackers target.” Organizations continue to invest heavily in network security and zero-trust initiatives, she said, but legacy VPN infrastructure often remains deeply embedded in enterprise environments, creating a transition period that attackers are exploiting faster than many organizations can modernize. “This incident reinforces a hard truth: despite years of zero-trust discussions, perimeter security remains fragile when convenience overrides careful architecture,” he said. For CISOs, the lesson extends beyond patching. “The recurring pattern of edge-device exploitation is rarely the result of a missing security product,” Grover said. “More often, it reflects gaps in asset visibility, configuration governance, patch prioritization, and architectural modernization.” View the full article

A malicious npm package posing as a remote user interface for OpenAI Codex exfiltrated developer authentication tokens, after attackers allegedly published code to npm that was not visible in the project’s public GitHub repository. Researchers at Aikido said the package, called codexui-android, appeared to offer legitimate functionality while collecting authentication tokens and sending them to an external server. “AI developer tooling is becoming a high-value target precisely because the tokens are powerful and long-lived,” Aikido said. “A stolen Codex refresh_token goes beyond access to a chat interface — it’s persistent, silent access to whatever that account can do.” Aikido said the incident reflected a broader pattern in which attackers build credible and useful projects as cover for malicious activity. “The legitimacy is the attack vector,” Aikido said. “As AI tools proliferate and developers reach for productivity shortcuts, expect more of this.” The case exposes what some security experts describe as a growing blind spot in software supply chain security, where controls often focus on source code rather than the software artifacts ultimately distributed to users. The incident showed how attackers can use legitimate-looking projects to hide malicious activity, said Sunil Varkey, cybersecurity advisor and a former CISO. “In this case, the npm package looked completely legitimate: it had an active GitHub repository, useful features for OpenAI Codex users, and attracted around 27,000 weekly downloads,” Varkey said. “Yet the malicious code that stole sensitive tokens only appeared in the published version, not in the public source code.” Varkey said the risk was widened by a companion Android app that automatically pulled and executed the malicious npm package at runtime. “Most companies have great security tools for their source code, but the build and distribution pipelines are still total blind spots,” said Devashri Datta, a cybersecurity researcher. “If an attacker leaves their public GitHub repository completely clean but injects malware directly into the npm package, standard code audits won’t catch a thing.” Datta said enterprises should verify both the provenance of software packages and the consistency between published artifacts and their public source code, warning that seemingly benign source code may not accurately reflect what developers ultimately install. The enterprise risk For enterprises, the concern is less the package itself than the level of access now attached to AI developer tools. Aikido said the package stole access tokens, refresh tokens, ID tokens, and account IDs, with the refresh token posing particular risk because it does not expire. According to Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services, this means a single successful exfiltration translates into persistent, silent access to everything that the account can reach. Grover pointed to IDC forecasts that by 2028, half of enterprises deploying agentic AI across Asia Pacific excluding Japan will require an AI bill of materials to support continuous vulnerability scanning, license risk management, and compliance assurance. She said the codexui-android incident illustrates why organizations need better visibility into the components used by AI tools and the credentials those tools can access. “Most organizations still lack a complete inventory of what their AI tools can access, what credentials they inherit, and what external services they interact with,” Grover added. “Most enterprises have not yet applied the same least-privilege and behavioral monitoring disciplines to AI tools that they apply to human identities, and that asymmetry is what attackers are now actively exploiting.” View the full article

Discussion-based, low-stress simulations during which IT, legal, and other key leadership stakeholders walk through theoretical scenarios to test their preparedness for cyber incidents is a popular and highly useful tool. Yet unless tabletop training is properly handled, the results can be misleading and potentially destructive. When your organization’s incident response training consistently fails to meet its goals, it opens the way to an array of often unanticipated threats. Fortunately, running an effective tabletop isn’t as challenging as responding to the real deal. Here’s a rundown of the seven most common tabletop exercise mistakes to avoid. No clear set of objectives The biggest mistake is to run a tabletop without clear, measurable objectives tied to realistic business decisions, says Sharon Chand, Deloitte’s US cyber defense and resilience leader. “In practice, this usually shows up as a generic ransomware or insider-threat scenario, accompanied by vague goals and no firm agreement on what ‘good’ actually looks like,” she explains. “This causes the exercise to drift, while rewarding confident improvisation over real process quality, and leaves leaders unable to tell whether the incident response plan actually works.” Instead, Chand advises cyber and IT leaders to provide sharp guidelines and directives about what the tabletop seeks to accomplish. “When leaders treat the session as ‘let’s walk through a breach scenario’ instead of ‘let’s test escalation, legal notification, executive decision rights, and recovery prioritization,’ the exercise quickly devolves into a discussion theater rather than a readiness test,” she says. Testing scenarios you already know how to handle Ayush Raj Jha, a senior software engineer at Oracle Health, recalls a time when he was involved in tabletops where every incident was a clean, well-defined ransomware event with obvious decision points. “Everyone performed great, yet three months later we had a real partial failure in our multi-region DR setup, where the failure was ambiguous,” he says. Two systems reported conflicting health statuses, and nobody could agree on whether we had actually failed over or not. “That scenario,” Jha says, “had never been in any tabletop.” The damage isn’t that people panic; it’s that they freeze because the real incident doesn’t look like the practice one, says Jha, who recommends making the scenario deliberately ambiguous from the start. “Give people incomplete information and conflicting signals and see how they make decisions under uncertainty,” he advises. “Because that’s what real incidents actually look like.” Failing to design business-relevant hazards Many IT leaders view regular tabletop exercises as a routine obligation rather than as an essential security task, says Jason Stading, a director with technology research and advisory firm ISG. As they minimize the exercise’s importance, these individuals fail to design scenarios around their organization’s real risks, decision points, and people. “In practice, this usually shows up in two ways: choosing a scenario that’s not realistic or relevant to the organization, and failing to include the right stakeholders in the exercise,” he says. When an indifferent scenario fails to address to the organization’s real-world hazards, participants often get stuck on debating whether something could happen instead of focusing on what they should be doing next, Stading says. A better approach, he states, is thoughtful, collaborative planning conducted before the exercise starts. “The scenario should be built around the organization’s actual environment, business priorities, past incidents, and realistic threats seen in the industry,” Stading recommends. The participant list should include everyone who would be involved in a real event, such as security, IT, legal, communications, HR, operations, and perhaps even executive leaders. “After each exercise, leaders should capture where decisions stalled, where ownership was unclear, and which voices were missing, and then use these lessons to improve the next scenario,” he says. Losing stakeholder buy-in due to lack of technical detail Essential stakeholders often don’t bother to participate in training simulations because they view the attack chain as either impractical or implausible given the project’s sub-par architecture and environment. “The stakeholders simply view the activity as a waste of time,” observes Blake Cifelli, senior incident response advisory consultant at security services provider GuidePoint Security. “Everything presented in the simulation should make sense at a technical level and logically connect to one another,” he advises. “For a tabletop, much like any other assessment, you get as much out of it as you put in,” Cifelli says. “If you view the exercise as a compliance checkbox and put in only a minimal amount of effort for customization and participation, you will hit the security baseline, but your response team and program won’t benefit much from it.” Emphasizing recall over decision-making A common mistake is treating tabletop exercises as scripted, compliance-driven activities instead of realistic, decision-driven simulations, says Ensar Seker, CISO at threat intelligence and digital risk monitoring software firm SOCRadar. “Many organizations design scenarios with a predefined ‘happy path,’ in which participants are subtly guided toward expected answers instead of being forced to deal with the ambiguity, conflicting signals, and incomplete information, conditions that define real incidents,” he says. Such an approach can create a false sense of readiness, Seker says. “Teams may appear coordinated during the exercise, but when a real incident occurs, they struggle with uncertainty, escalation timing, and cross-functional communication,” he notes. “In effect, the organization tests process recall instead of decision-making under pressure, which is where most failures actually occur.” Favoring the conceptual over the practical Michel Sahyoun, chief solutions architect at managed cybersecurity service provider NopalCyber, warns against creating tabletop scenarios that are too theoretical and devoid of rich, real-world detail. “For example, an exercise might be framed around a ransomware incident, but provide very few concrete details,” he says. This often results in participants who tend to respond in abstract, high-level terms rather than engaging with the specific actions and decisions required in a real incident response. Highly detailed scenarios can create the kind of friction points you want to test, Sahyoun says, noting that when the moderator introduces specifics, such as a compromised domain controller, encrypted file shares tied to finance, or an alert triggered at 2:00 a.m. on a holiday weekend, teams can become confused. “When facing this type of situation, participants must grapple with incomplete information, competing priorities, and time pressure,” he advises. “This is where gaps in tooling, unclear ownership, and breakdowns in communication start to surface.” The fundamental problem with a theory-driven approach is that it creates a false sense of preparedness, Sahyoun says. It’s possible for a team to arrive at a highly complex solution yet still get lost in the details. Which systems get isolated first? Who has the authority to take them offline? What happens if those systems support critical business functions? Who drafts the stakeholder communication, and how quickly can it be approved? “Without these details, participants aren’t truly testing their readiness; they’re just validating that they understand the playbook at a conceptual level,” Sahyoun says. Overlooking the interconnected nature of incident response Aparna Himmatramka agrees that generic scenarios build false confidence. But the Amazon security engineering manager adds that false confidence also stems from not stress-testing the handoffs and interdependencies specific to your business. “Your security team walks away thinking they can handle an incident, but they never actually get to practice navigating the specific dependencies, communication chains, and system interdependencies that would actually be in play during a real breach in your environment,” she says. Then what happens when a real incident hits? “Well, the response plan falls apart at exactly the points the tabletop never touched — such as the handoff between your cloud team and your SOC, the escalation path when your M&A integration environment is compromised, or the decision tree when a third-party vendor is the entry point,” she says. “You’ve trained your team for a scenario that doesn’t exist at your company.” Engineer the scenario from your actual risk register, Himmatramka advises. “Identify the top three to five threats specific to your organization, map them against your real architecture and team structure, and build the exercise around them,” she says. More on tabletop exercises: Tabletop exercises explained: Definition, examples, and objectives How to conduct a tabletop exercise 4 tabletop exercises every security team should run Tabletop exercise scenarios: 3 real-world examples 6 tips for effective tabletop exercises Security simulations: This is only a test View the full article

Oracle has released the first security fixes in its new monthly Critical Security Patch Update (CSPU) cycle, designed to address urgent vulnerabilities that can’t wait for the company’s quarterly patching. The initial batch addresses 35 flaws, including several for which exploit code is publicly available. In total, there are 11 flaws rated ‘critical’, 18 rated ‘high’, and 6 ‘medium’. The most important on paper are 10 critically-rated flaws, including those affecting Oracle REST Data Services (CVE-2026-46840, CVE-2026-46775, CVE-2026-46839), Oracle E-Business Suite (CVE-2026-46822), the Oracle Universal Work Queue portal (CVE-2026-46824), and Oracle Payments (CVE-2026-46817). Despite the high CVSS scores for those bugs, patching teams will probably want to start with a clutch of older but still serious flaws for which proof-of-concept (PoC) exploit code reportedly exists: CVE-2025-15467, CVE-2025-58050, and CVE-2026-25646 in Oracle Communications Unified Assurance network management, and CVE-2026-2332 in Oracle REST Data Services. All relate to open source components embedded in Oracle products, and one, CVE-2025-58050, was first made public last August, underlining how long it can take to patch supply chain flaws in modern platforms. Another priority fix should be CVE-2026-46840, with a perfect CVSS rating of ’10’. It’s a vulnerability in the backend-as-a-service component of REST Data Services versions 24.2.0 through 26.1.0. REST Data Services is a gateway that exposes corporate databases via APIs. This flaw makes that interface easily exploitable by an unauthenticated attacker via HTTPS, resulting in a takeover of the gateway, making it a high priority for attackers. Also deserving to be on the high priority list are the two flaws affecting the REST Data Services core, CVE-2026-46775 and CVE-2026-46839. Rated CVSS 9.9, all that stops these from being CVSS 10 flaws is the need for network credentials to exploit them. Oracle ‘third Tuesday’ Announced at the beginning of May, the monthly CSPU is meant to be a smaller update patching high-severity flaws ahead of the larger, more general Critical Patch Updates (CPUs) updates that will continue to be released on a quarterly basis. The initial CSPU was released last Thursday. In its update notes, Oracle said that the CSPU “provides targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption.” Despite the publicity around automated AI vulnerability hunting systems such as OpenAI’s Trusted Access for Cyber program or Claude Mythos, both of which Oracle has said it has access to, none of May’s vulnerability discoveries were attributed to these systems. The change to a monthly update cycle brings Oracle into line with software vendors such as Microsoft and Adobe, and appears to be a reaction to the growth in the volume of more serious vulnerabilities now being reported. In the future, the company will release CSPUs on the third Tuesday of each month, with the first four scheduled for June 16, July 21, August 18, and September 15. Oracle cloud customers are patched automatically. View the full article

Oracle has released the first security fixes in its new monthly Critical Security Patch Update (CSPU) cycle, designed to address urgent vulnerabilities that can’t wait for the company’s quarterly patching. The initial batch addresses 35 flaws, including several for which exploit code is publicly available. In total, there are 11 flaws rated ‘critical’, 18 rated ‘high’, and 6 ‘medium’. The most important on paper are 10 critically-rated flaws, including those affecting Oracle REST Data Services (CVE-2026-46840, CVE-2026-46775, CVE-2026-46839), Oracle E-Business Suite (CVE-2026-46822), the Oracle Universal Work Queue portal (CVE-2026-46824), and Oracle Payments (CVE-2026-46817). Despite the high CVSS scores for those bugs, patching teams will probably want to start with a clutch of older but still serious flaws for which proof-of-concept (PoC) exploit code reportedly exists: CVE-2025-15467, CVE-2025-58050, and CVE-2026-25646 in Oracle Communications Unified Assurance network management, and CVE-2026-2332 in Oracle REST Data Services. All relate to open source components embedded in Oracle products, and one, CVE-2025-58050, was first made public last August, underlining how long it can take to patch supply chain flaws in modern platforms. Another priority fix should be CVE-2026-46840, with a perfect CVSS rating of ’10’. It’s a vulnerability in the backend-as-a-service component of REST Data Services versions 24.2.0 through 26.1.0. REST Data Services is a gateway that exposes corporate databases via APIs. This flaw makes that interface easily exploitable by an unauthenticated attacker via HTTPS, resulting in a takeover of the gateway, making it a high priority for attackers. Also deserving to be on the high priority list are the two flaws affecting the REST Data Services core, CVE-2026-46775 and CVE-2026-46839. Rated CVSS 9.9, all that stops these from being CVSS 10 flaws is the need for network credentials to exploit them. Oracle ‘third Tuesday’ Announced earlier this month, the monthly CSPU is meant to be a smaller update patching high-severity flaws ahead of the larger, more general Critical Patch Updates (CPUs) updates that will continue to be released on a quarterly basis. The initial CSPU was released last Thursday. In its update notes, Oracle said that the CSPU “provides targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption.” Despite the publicity around automated AI vulnerability hunting systems such as OpenAI’s Trusted Access for Cyber program or Claude Mythos, both of which Oracle has said it has access to, none of May’s vulnerability discoveries were attributed to these systems. The change to a monthly update cycle brings Oracle into line with software vendors such as Microsoft and Adobe, and appears to be a reaction to the growth in the volume of more serious vulnerabilities now being reported. In the future, the company will release CSPUs on the third Tuesday of each month, with the first four scheduled for June 16, July 21, August 18, and September 15. Oracle cloud customers are patched automatically. View the full article

Enterprises using the lightweight, open-source Flowise platform to power self-hosted AI workloads have a new near-max severity issue to worry about. Researchers at Obsidian Security have detailed a one-click remote code execution (RCE) vulnerability affecting self-hosted Flowise deployments through its implementation of Model Context Protocol (MCP) stdio servers. The problem is essentially a sandboxing failure of attacker-controlled MCP configurations, leading to server-side code execution. “Post-auth RCE in Flowise can be triggered with a single click via a malicious chatflow import before any save or run,” the researchers said in a blog post. “The official patch relies on input validation that is trivially bypassed and fails to address the root cause.” Flowise is commonly used to develop internal AI assistants, retrieval-augmented generation (RAG) applications, customer-facing chatbots, and autonomous agents connected to business systems. The flaw does not affect Flowise Cloud, as stdio MCP is disabled there. For the rest, where the feature is enabled and is absolutely necessary, there is a security and functionality tradeoff developers need to understand and actively review server configurations for possible threats, the researchers explained. Once-click RCE affects everything Flowise can reach The vulnerability, tracked as CVE-2026-40933, affects Flowise’s implementation of MCP stdio servers. MCP’s stdio is designed to launch local server processes and communicate with them through standard input and output streams, allowing AI agents to interact with files, Git repositories, databases, browsers, and local credentials. According to Obsidian Security, the issue stems from Flowise allowing users to configure MCP stdio servers containing arbitrary commands. Because those commands are ultimately executed by the underlying operating system, an attacker can achieve remote code execution with the privileges of the Flowise process. In containerized deployments, the researchers noted, this can effectively provide root-level access to the environment hosting the platform. The flaw has been assigned a 9.9 CVSS rating, with a successful compromise potentially exposing API keys, databases, cloud resources, SaaS applications, and other assets accessible through Flowise. Researchers said the fixes fall short The disclosure details a series of remediation efforts by Flowise aimed at restricting how MCP stdio commands can be configured and executed. According to Obsidian, however, each iteration relied primarily on command validation and filtering mechanisms that can be bypassed under certain conditions. “Flowise appeared to acknowledge the risk and hardened Custom MCP over several rounds,” the researchers noted. “#5232 introduced CUSTOM_MCP_SECURITY_CHECK, a default-enabled validation layer for Custom MCP configurations.” While the checks reduced obvious command execution paths, they did little to change the underlying threat of allowing users to supply stdio MCP configurations, they said. Obsidian’s reporting of the flaw triggered further hardening of the feature with flag validation in updates #5741 and #5943. These, too, did not entirely remove the threat. When requested to treat stdio MCP as unsafe by default and require explicit opt-in, Flowise reportedly said they wanted to “limit what we know is bad without completely disabling features that users may rely on.” Obsidian shared a proof of concept (POC) exploit code on how the current protections by Flowise could still be bypassed for successful RCE. The only complete mitigation recommended by the researchers is turning off MCP stdio by setting “CUSTOM_MCP_PROTOCOL=sse”. For those who can’t, without obstructing operations, pinning trusted packages where possible, and reviewing imported chatflows from untrusted sources might help, the researchers added. View the full article

CISOs acknowledge that no organization is completely safe, but many also admit their security measures aren’t where they’d like them to be. One-third of CISOs surveyed for Proofpoint’s 2025 Voice of the CISO Report said the data within their organization is not adequately protected, and 58% said their organizations were unprepared to respond to a cyberattack. Meanwhile, only 67% believed their organizations offered adequate budget, staff, and tools to meet their cybersecurity goals. Such figures indicate that critical cybersecurity gaps remain in many, if not most, organizations. As adversaries lean into automation and artificial intelligence, the pressure is mounting to address security gaps that could be exploited. Here are six critical security gaps that demand CISOs’ attention, according to their IT security leader colleagues and industry observers. 1. The perception gap Although CISOs have become more business-oriented in recent years, many still view their primary job as protecting digital systems when they should see it as ensuring business resilience, says Errol Weiss, CSO with Health-ISAC. “CISOs still think of a bad day from the IT perspective; they still think of security as an IT problem,” he notes. “They need to shift from protecting systems at all costs to instead building resilience and thinking about the downstream impacts when something fails.” Weiss notes that part of the reason this gap persists in many organizations is because business continuity, which is at the heart of resilience, usually falls to executives other than CISOs. “The business continuity piece has traditionally been someone else’s problem, but now it has to become a focus for the security organization,” he says. When CISOs think broadly about how digital threats could impact the business, rather than focus on how attacks impact the IT environment, they get a more accurate view of the top risks and can better access the blast radius of an incident, Weiss explains. That in turn enables CISOs to more effectively prioritize defensive moves and remediation action, making it more likely that an incident can be contained and not have unexpected follow-on impacts that stymie business operations. The 2024 cyberattack on Change Healthcare, the consequences of which rippled through the entire healthcare industry, shows why CISOs need to close this gap in perspective on cyber threats and risk, he says. 2. The gap between the speed of threat actors and security The 2025 Year in Review report from threat intelligence firm Cisco Talos stated that “the 2025 threat landscape was defined by an unprecedented acceleration in the speed of vulnerability exploitation, with adversaries weaponizing new security flaws like React2Shell and ToolShell almost immediately upon disclosure.” Most security teams aren’t moving as fast, creating an agility gap between them and the threat actors, says Buck Bell, director of security strategy at IT services provider CDW. “Most of the gaps we see today are execution gaps,” he adds. Many security programs still feature legacy thinking, including “some static security measures in a world that needs real-time adjustments,” he says. Monthly penetration testing and patch Tuesdays, for example, are relics of an older era yet remain in some security departments. “The reality is that organizations today need to execute at a higher velocity,” he adds. Bell says leading CISOs are adding speed to their operations by adopting AI, automation, and practices such as continuous threat exposure management (CTEM). 3. The gap between the speed of the business and security Similarly, some CISOs also need to increase their speed and agility so that security can move as quickly as the business does. As professional services firm PwC notes in its 2026 CISO Outlook, “The CISO role is at a pivotal moment. As technology accelerates and new threats emerge, you’re expected to lead at the pace of change. AI, quantum computing, and a hyperconnected world are reshaping risk — and your business is watching.” Chirag Shah, global information security officer and data protection officer at software company Model N, knows that business is the pacesetter these days. “Business wants to run faster, and if they’re wanting to run faster, that means we at security and compliance have to run with them,” he says. But he also knows security struggles to keep up. “We’re always playing a catchup game,” he adds. Shah has taken action to add speed, such as upskilling security staffers on AI so they’re ready to work with the business on their priority projects. Chris Cochran, field CISO and vice president of AI security at SANS Institute, says CISOs who adopt frameworks and standards and who collaborate with their security colleagues can also add speed by learning and deploying proven tactics that can quickly expand and scale as the business changes. 4. The gap between existing and needed skills CISOs have long struggled to get the talent they need. In the past, the issue centered mainly around getting enough people to fill roles; now they’re more concerned that security pros don’t possess the updated skills they need to succeed. According to the SANS 2026 Cybersecurity Workforce Research Report, “the cybersecurity workforce is undergoing a fundamental transformation. Organizations are rebuilding their teams from the top down as artificial intelligence disrupts traditional entry points while regulatory compliance demands create new frameworks for skills validation. This convergence is producing a widening skills gap that organizations struggle to close, even as they increasingly recognize that having the right abilities matters more than simply adding headcount.” It further states that “the need for specialists in new roles nearly doubled year-over-year, while additional hiring for existing skills increased substantially.” Here, CISOs’ concern has accelerated, with 60% of security leaders identifying this skills gap as their primary workforce challenge in 2026 (up from 52% last year) — and compared to 40% who said headcount shortages were their chief issue. Beth Miller, global field CISO at software maker Mimecast, says it’s not just a skills gap within security that plagues CISOs but a gap in needed security skills throughout the organization. “You can have a fully skilled security team, but if you don’t have security skills in the business, too, you still will have a gap,” she says. Closing the gap requires “investing in the human layer across the organization,” she adds. SANS Institute’s Cochran made similar observations, saying CISOs need to build a culture of continuous learning and training. “Closing the gap comes down to one word: intention,” he says. 5. Gaps in securing AI deployments CISOs lag in securing AI deployments for several reasons. To start, Mimecast’s Miller says, “the mandate around AI is moving faster than CISOs are prepared for. The pattern we’re seeing in our and other organizations is that leadership announces an AI adoption initiative, it’s top down, and it’s often tied to competitive pressure or board expectations. And then within weeks business units are building AI tools, connected to data, and integrating AI into existing systems, and CISOs are finding out about these [initiatives] during or after implementation.” There are also the AI deployments happening from the bottom up, often without any leadership involvement or knowledge at all. “Shadow AI is happening industry wide,” Model N’s Shah says. And while security or IT may find those deployments after the fact, that discovery doesn’t erase the security gap on its own. Experts also cite the challenges of, first, developing the right security controls for AI as the technology evolves and, second, getting everyone to buy into and then follow those controls and governance frameworks as they morph with the technology’s evolution. Those dynamics inevitably create gaps between what’s needed to secure AI and what controls are being implemented. “It’s a governance gap masquerading as an IT problem,” Miller adds. The SANS report found that only 54% of surveyed organizations had AI security policies in place and only 20% had comprehensive governance frameworks ready, with about 75% either implementing or still building governance structures. SANS concluded that “AI security governance is still in early days.” Other experts acknowledged as much, saying that CISOs need to lean on observability tools, executive influence skills, AI-related security awareness and training, emerging AI security best practices, and new AI governance frameworks to close what seems to be a yawning gap in many organizations. 6. The legacy gap Jason Lish, Cisco’s global CISO, says many business leaders have adopted a “set-it-and-forget-it mentality” with technology, resisting moves to modernize IT as long as systems perform and aren’t differentiating. That challenges not only CIOs as they try to integrate AI and other new technologies into legacy tech, but also CISOs as they seek to implement modern security practices and technologies, Lish explains. And it’s becoming a more acute security problem as threat actors become more skillful at using AI to exploit out-of-support systems and legacy tech that can’t implement modern security controls. A 2026 study from National Association of State CIOs and Deloitte & Touche found that CISOs listed legacy infrastructure as one of the top three barriers to meeting cybersecurity challenges, along with the increasing sophistication of threats and insufficient funding for cybersecurity. “CISOs should be thinking about a risk-based approach here,” Lish says, “going to the board or the C-suite and saying, ‘These are the most critical pieces of legacy equipment or devices we need to replace’ and help them understand the risk of not doing so. The CISO has to be the one to provide that prioritization.” View the full article

The CSO30 ASEAN & Hong Kong Awards return in 2026, as an important moment to recognise the cybersecurity leaders and teams who are making resilience measurable across the region. In a landscape shaped by rapid threat evolution, board-level scrutiny and rising expectations of business continuity, these awards spotlight the people and programmes that are turning security into an enterprise capability, not just a control function. On our fifth consecutive run this year, this awards programme is a regional benchmark for cybersecurity maturity across ASEAN and Hong Kong, and a unique platform for organisations to showcase their most impactful achievements, gain regional and global visibility, and join a distinguished community of Chief Information Security Officers(CISOs) and Chief Security Officers(CSOs) who are redefining the role of cybersecurity. Globally respected, the CSO30 ASEAN and Hong Kong Awards celebrate not just individual leaders but the collective efforts of teams that drive transformation, cyber resiliency and business continuity. This year, you and your team could stand alongside the past winners which include this region’s most influential organizations, to be a recognise force in the ASEAN and HK cybersecurity landscape. Calling on CISOs and CSOs to nominate themselves, their peers and their teams now. If your organisation has strengthened its cyber posture, shifted strategic decision-making, or built stronger ecosystem partnerships in the past year, this is the moment to put that work forward. This year’s awards spans three nomination pathways: CSO Leadership – Individual Online Form CSO Transformation – Individual Online Form Ecosystem – Team Online Form Together, these categories reflect the full scope of modern security leadership, from board-level influence and enterprise transformation to ecosystem collaboration and measurable resilience. Individual Leadership nominations are expected to show how a cybersecurity leader has delivered real value, changed the way the organisation is protected, influenced executive decision-making, and prepared the business to respond to emerging cyber risks while ensuring long-term resilience and continuity. The Transformation category goes further, asking for a cybersecurity-led project from the past one year that changed how the organisation is protected, overcame key challenges, delivered quantifiable impact, and contributed to the wider cybersecurity community. Ecosystem Team nominations must show how a project shaped and strengthened the cybersecurity agenda across the organisation, its partners and even the broader country context, with clear challenges, outcomes and quantifiable value. If you lead a cybersecurity team that has delivered measurable impact, or if you know a peer whose leadership deserves broader recognition, nominate them. If you are a CISO or CSO whose work has materially improved your organisation’s resilience, nominate yourself. The region needs to see the leaders and teams setting the standard for security maturity, operational continuity and business trust. The deadline for nominations: 31 July 2026. Awards Gala website: https://event.foundryco.com/cio-100-asean-and-hk/ Due to the sensitive nature of cybersecurity work, project details will not be published, which gives nominees the confidence to submit meaningful work without exposing sensitive information. The CSO30 ASEAN & Hong Kong Awards matter because we recognise a kind of leadership the region increasingly depends on – decisive, collaborative, strategic and resilient. We give visibility to the people and teams making cybersecurity a stronger part of business performance and long-term continuity. Media Contact: Estelle Quek Editorial Director, CIO ASEAN & CSO ASEAN CSO ASEAN View the full article

The CSO30 ASEAN & Hong Kong Awards return in 2026, as an important moment to recognise the cybersecurity leaders and teams who are making resilience measurable across the region. In a landscape shaped by rapid threat evolution, board-level scrutiny and rising expectations of business continuity, these awards spotlight the people and programmes that are turning security into an enterprise capability, not just a control function. On our fifth consecutive run this year, this awards programme is a regional benchmark for cybersecurity maturity across ASEAN and Hong Kong, and a unique platform for organisations to showcase their most impactful achievements, gain regional and global visibility, and join a distinguished community of Chief Information Security Officers(CISOs) and Chief Security Officers(CSOs) who are redefining the role of cybersecurity. Globally respected, the CSO30 ASEAN and Hong Kong Awards celebrate not just individual leaders but the collective efforts of teams that drive transformation, cyber resiliency and business continuity. This year, you and your team could stand alongside the past winners which include this region’s most influential organizations, to be a recognise force in the ASEAN and HK cybersecurity landscape. Calling on CISOs and CSOs to nominate themselves, their peers and their teams now. If your organisation has strengthened its cyber posture, shifted strategic decision-making, or built stronger ecosystem partnerships in the past year, this is the moment to put that work forward. This year’s awards spans three nomination pathways: CSO Leadership – Individual Online Form CSO Transformation – Individual Online Form Ecosystem – Team Online Form Together, these categories reflect the full scope of modern security leadership, from board-level influence and enterprise transformation to ecosystem collaboration and measurable resilience. Individual Leadership nominations are expected to show how a cybersecurity leader has delivered real value, changed the way the organisation is protected, influenced executive decision-making, and prepared the business to respond to emerging cyber risks while ensuring long-term resilience and continuity. The Transformation category goes further, asking for a cybersecurity-led project from the past one year that changed how the organisation is protected, overcame key challenges, delivered quantifiable impact, and contributed to the wider cybersecurity community. Ecosystem Team nominations must show how a project shaped and strengthened the cybersecurity agenda across the organisation, its partners and even the broader country context, with clear challenges, outcomes and quantifiable value. If you lead a cybersecurity team that has delivered measurable impact, or if you know a peer whose leadership deserves broader recognition, nominate them. If you are a CISO or CSO whose work has materially improved your organisation’s resilience, nominate yourself. The region needs to see the leaders and teams setting the standard for security maturity, operational continuity and business trust. The deadline for nominations: 31 July 2026. Awards Gala website: https://event.foundryco.com/cio-100-asean-and-hk/ Due to the sensitive nature of cybersecurity work, project details will not be published, which gives nominees the confidence to submit meaningful work without exposing sensitive information. The CSO30 ASEAN & Hong Kong Awards matter because we recognise a kind of leadership the region increasingly depends on – decisive, collaborative, strategic and resilient. We give visibility to the people and teams making cybersecurity a stronger part of business performance and long-term continuity. Media Contact: Estelle Quek Editorial Director, CIO ASEAN & CSO ASEAN View the full article

>The CSO30 ASEAN & Hong Kong Awards return in 2026, as an important moment to recognise the cybersecurity leaders and teams who are making resilience measurable across the region. In a landscape shaped by rapid threat evolution, board-level scrutiny and rising expectations of business continuity, these awards spotlight the people and programmes that are turning security into an enterprise capability, not just a control function. On our sixth consecutive edition this year, this awards programme is a regional benchmark for cybersecurity maturity across ASEAN and Hong Kong, and a unique platform for organisations to showcase their most impactful achievements, gain regional and global visibility, and join a distinguished community of Chief Information Security Officers(CISOs) and Chief Security Officers(CSOs) who are redefining the role of cybersecurity. >> Globally respected, the CSO30 ASEAN and Hong Kong Awards celebrate not just individual leaders but the collective efforts of teams that drive transformation, cyber resiliency and business continuity. This year, you and your team could stand alongside the past winners which include this region’s most influential organizations, to be a recognise force in the ASEAN and HK cybersecurity landscape. Calling on CISOs and CSOs to nominate themselves, their peers and their teams now. If your organisation has strengthened its cyber posture, shifted strategic decision-making, or built stronger ecosystem partnerships in the past year, this is the moment to put that work forward. This year’s awards spans three nomination pathways: CSO Leadership – Individual Online Form CSO Transformation – Individual Online Form Ecosystem – Team Online Form Together, these categories reflect the full scope of modern security leadership, from board-level influence and enterprise transformation to ecosystem collaboration and measurable resilience. Individual Leadership nominations are expected to show how a cybersecurity leader has delivered real value, changed the way the organisation is protected, influenced executive decision-making, and prepared the business to respond to emerging cyber risks while ensuring long-term resilience and continuity. The Transformation category goes further, asking for a cybersecurity-led project from the past one year that changed how the organisation is protected, overcame key challenges, delivered quantifiable impact, and contributed to the wider cybersecurity community. Ecosystem Team nominations must show how a project shaped and strengthened the cybersecurity agenda across the organisation, its partners and even the broader country context, with clear challenges, outcomes and quantifiable value. If you lead a cybersecurity team that has delivered measurable impact, or if you know a peer whose leadership deserves broader recognition, nominate them. If you are a CISO or CSO whose work has materially improved your organisation’s resilience, nominate yourself. The region needs to see the leaders and teams setting the standard for security maturity, operational continuity and business trust. The deadline for nominations: 31 July 2026. Awards Gala website: https://event.foundryco.com/cio-100-asean-and-hk/ Due to the sensitive nature of cybersecurity work, project details will not be published, which gives nominees the confidence to submit meaningful work without exposing sensitive information. The CSO30 ASEAN & Hong Kong Awards matter because we recognise a kind of leadership the region increasingly depends on – decisive, collaborative, strategic and resilient. We give visibility to the people and teams making cybersecurity a stronger part of business performance and long-term continuity. Media Contact: Estelle Quek Editorial Director, CIO ASEAN & CSO ASEAN View the full article

Researchers have uncovered a previously undocumented Russian group that makes extensive use of large language models (LLMs) in its attacks against private, government, and military organizations in Ukraine. It uses a variety of attack vectors along with custom malware, with the goal of intelligence gathering for the ongoing war. Dubbed Greyvibe by researchers from WithSecure, the group has shown systematic use of generative AI across all stages of its operations, from crafting spear phishing lures and malicious scripts to full on malware development and setting up of backend infrastructure. “While the activities align with Russian state interests, several observed indicators suggest the group has ties to the broader cybercrime ecosystem, with the group potentially involving current or former cybercriminal actors,” the WithSecure researchers said in their report. Shifting attack vectors Greyvibe’s first campaign was launched in August 2025, with a series of spear phishing emails that purported to come from Ukrainian officials and government agencies including the Kyiv City, the Main Directorate of the State Emergency, and the State Service of Special Communications and Information Protection. The emails included links to ZIP and RAR archives, hosted on Google Drive and a service called 4sync, that contained malware loaders written in Python and JavaScript. The final payload was a custom malware program developed by the group that the WithSecure researchers dubbed PhantomRelay. In another attack in October, the group experimented with ClickFix-style attacks on fake CloudFlare CAPTCHA pages. These attacks instructed users to open the Windows Run dialog and paste in malicious commands. Greyvibe also set up fake adult club websites in Ukrainian, as well as fake websites for charities claiming to support the Ukrainian military with FPV drones and UAVs. These attacks distributed several malware programs for both Android devices (FallSpy) and Windows (PhantomRelay and LegionRelay). The researchers also tracked a website in Russian that they believe was part of the group’s operations; it referenced hard-coded telephone exchange numbers for secure telecommunications that are typically used by the Russian military. “The intended victimology of this activity remains unclear,” the researchers said. “However, the most plausible hypothesis is that the lure was designed to deceive Ukrainian military personnel by presenting the illusion of access to a Russian military terminal.” Custom malware developed using LLMs The PhantomRelay malware program is a remote access trojan (RAT) written in PowerShell that can execute additional custom scripts received from the command-and-control (C2) server. While variants of this program have been observed in activity that might be unrelated to Greyvibe, the group completely rewrote the tool and created a version that was exclusively used in its own operations. LegionRelay is another PowerShell-based RAT that can similarly execute commands and scripts received from the C2 server; it is used for file enumeration, file exfiltration, screenshot capture, browser data theft, Telegram and WhatsApp data exfiltration, RDP access setup and other actions. FallSpy is an Android spyware program that can steal contacts, call logs, a list of installed applications, SIM-linked phone numbers, device and network information, Wi-Fi SSID, the phone’s last known location, its public IP address, and media files. Finally, a series of custom scripts for obfuscating and loading malware was also observed: LOOKVALPS (PowerShell), LOOKVALJS (JavaScript), DAYLIGHT (PowerShell), and TEASOUP (JavaScript). The WithSecure researchers have determined, with moderate confidence, that several of these custom tools were developed with the help of LLMs. LegionRelay in particular, as well as the background infrastructure serving it, show strong indicators of AI generation. The researchers believe some of the platforms used by the attackers include Ideogram AI, ChatGPT and Google Gemini. “Greyvibe appears to use AI not only for isolated development tasks, but across multiple operational phases,” the researchers said. “This likely enables the group to compensate for capability gaps, accelerate development cycles, and potentially reduce historical backlinks to prior activity. Given this extensive use, we expect the group’s tradecraft to continue evolving and diversifying, likely increasing the complexity of continuous detection, tracking, and attribution.” View the full article

Microsoft and a prominent cybersecurity researcher have gotten into a very public and rather personal exchange of unpleasantries about what responsible cybersecurity disclosures should mean in 2026. A cybersecurity researcher going by the name Nightmare Eclipse, who has disclosed several cybersecurity holes before patches were available, posted that he had tried to contact Microsoft officials and was rebuffed, which led him to publish details about the bugs. “When I actively asked you [Microsoft] to communicate with me, you refused, humiliated me and made sure to insult me in front of people. You defame me in public with your CVE-2026-45585 advisory even though you literally deleted the Microsoft account I used to report bugs to you with and I got zero pennies from doing so and I still happily did like an idiot,” the researcher posted, adding that Microsoft has now deleted his GitHub account. “You are proving to everyone that you [are] actively escalating this conflict but I’m done begging you.” The researcher then made a cryptic threat: “Mark this date July 14th, I will make sure your bones are shattered that day.” In another post, the researcher was even more direct: “I was told personally by [Microsoft] that they will ruin my life and they did” adding that Microsoft will “do everything but support the research community, I won’t disclose details, but they sabotage people a lot.” Microsoft responded with its own post saying that some of the vulnerabilities revealed by the researcher “were not responsibly disclosed” and that there was an “unnecessary risk created by these disclosures,” adding, “uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable, and have real-world consequences.” It was then Microsoft’s turn to get personal, with the veiled implication that the researcher has a bad reputation. “We always have and will continue to welcome vulnerability submissions from anyone through our public researcher portal, regardless of past interactions or reputation,” the post said. However, one senior Microsoft security executive posted a slightly more upbeat message, suggesting that the company may now have to rethink how it handles cybersecurity bug reports. “At this time, we are not changing our bug bar or the criteria we use to decide when a fix is required, though we will continue to evaluate as conditions evolve. Severity continues to be grounded in real-world impact and exploitability, drawing on the full set of signals in the Security Update Guide,” wrote Tom Gallagher, VP of engineering at the Microsoft Security Response Center (MSRC). “We will continue to anchor on a predictable rhythm and a disciplined process, while adapting as needed to the conditions in front of us,” he said. “What we encourage in turn is a thoughtful look at whether the practices that worked well for the patching landscape of a few years ago are still well matched to where the landscape is heading. The fundamentals have not changed. The pace at which they need to be applied is changing.” CSOonline reached out to both Microsoft and Nightmare Eclipse, and neither provided any clarification or additional comments by publication time. Frustration on both sides One of the issues behind the debate over cybersecurity disclosure policies is that many researchers feel that their disclosures are often either ignored or the patch is unreasonably delayed by major vendors, including Microsoft. Adding to researchers’ frustration is the fact that vendors often do not communicate well about where things stand with a reported security problem. But vendors have their own complaint: they can’t address every one of the many holes that are reported to them quickly, given finite resources, and they must prioritize what they patch. A related issue is the belief that major vendors, including Microsoft, will quickly prioritize patches once the hole becomes public; one example was the Microsoft Authenticator flaw, which Microsoft had known about for eight years before fixing it after it was publicized. Both sides may be right Consultants and cybersecurity executives said both sides make good points in this instance. “Microsoft is right that uncoordinated zero‑day drops create real and immediate risk for customers, and researchers are right that vendors sometimes move only when pushed,” said cybersecurity consultant Brian Levine, executive director of FormerGov. “Both truths can exist at the same time.” And, Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, added, “the cry from the security researcher feels like there is something vindictive going on. If the researcher believes that [Microsoft] acted unethically or illegally and has evidence in that respect, they could raise complaints with the appropriate authorities, rather than write a blog post. I am inclined to believe Microsoft more in this case.” Gary Longsine, CEO of Intrinsic Security, also pushed back against Nightmare Eclipse, questioning whether they are functioning as an objective security researcher. “This person might have a legitimate grievance of some sort against Microsoft, however, legitimate security researchers don’t do things this way,” he said. “I don’t do things that cause damage to literally billions of innocent bystanders, as retribution for whatever slight I may perceive. This is an attacker, an adversary, not a security researcher.” Erosion of trust In addition, Ishraq Khan, CEO of coding productivity tool vendor Kodezi, said that he is concerned about the emotional elements of the exchange between the researcher and Microsoft, because it is eroding trust, and that erosion is potentially the biggest danger. “The researcher appears to believe the relationship failed long before the disclosures occurred. Reading the public posts, the recurring theme is not simply vulnerability research, but frustration over communication, trust, and access to the disclosure process,” Khan said. “Whether those claims are accurate or not, the researcher clearly believes private channels stopped working and that escalation was the only remaining option.” And that erosion of trust, Khan said, is a critical issue, because AI, especially autonomous agents, is going to require far more trust between vendors and researchers. “The industry is entering a new era of vulnerability discovery. We are seeing increasingly capable AI systems uncover bugs, identify attack paths, and assist researchers in ways that were not possible a few years ago. The volume of discovered vulnerabilities is increasing while the time between discovery and potential exploitation is shrinking,” Khan said. “That changes the dynamics of disclosure. Historically, researchers and vendors were operating on a timeline measured in months. Today, discoveries can spread globally within hours. A breakdown in trust that might have once affected a handful of people can now affect entire ecosystems.” He added, “the reality is that responsible disclosure only works when both sides believe the system is functioning. Researchers need confidence that findings will be taken seriously. Vendors need confidence that researchers will give them enough time to protect customers. Once either side loses faith in that process, the entire model becomes fragile.” “What concerns me is that these disputes appear to be becoming more public, more adversarial, and more personal. Once security discussions shift from technical facts to questions of intent, reputation, and motivation, customer protection risks becoming secondary to the conflict itself.” View the full article

As AI agents become more numerous and more communicative, keeping track of where to find them is becoming increasingly important. Numerous proprietary agent registries are on the market, but the Linux Foundation suggests we simply extend the distributed, open Domain Name System (DNS) infrastructure we already have. The foundation is now inviting contributions to the DNS-AID project, a standard way for AI agents to discover, verify, and communicate with one another over DNS that requires no new infrastructure. It enables agents and Model Context Protocol (MCP) servers to use DNS as a global, vendor-neutral directory. While many details remain to be worked out, the proposal suggests domain owners create a new well-known address that can provide a starting point for agents looking for one another: _index._agents.{domain}. This approach ensures that agent discovery remains scalable, secure, and compatible with the protocols that underly the internet, the Linux Foundation said. “AI agents are quickly becoming the connective tissue of the modern internet, but without secure, open discovery infrastructure, that connectivity becomes a liability,” said Jim Zemlin, CEO at the Linux Foundation. “DNS-AID helps anchor agent discovery in the DNS infrastructure that the internet already trusts.” DNS-AID was initially developed by staff at Infoblox, and the latest internet draft of the DNS-AID proposal includes contributions from staff at Deutsche Telekom and Amazon. The Linux Foundation said it intends that DNS-AID will remain vendor-neutral. This article first appeared on InfoWorld. View the full article

Researchers in Switzerland claim to have built a perfect random number generator from two quantum superconducting chips, a 30-meter-long pipe, and some software. The resulting device could be used to generate cryptographic keys, or to offer a “public randomness service” for lotteries or blockchain applications, they say. They’re not the first to make the claim. Many sources of randomness are biased. For example, coins or dice tend to favor one side. “Even modern random number generators, which are based on quantum mechanical effects like the reflection of photons from beam splitters, are not entirely immune to such a systematic error or ‘bias’,” said Andreas Wallraff, one of the leaders of the research team at ETH Zurich. Similar biases can be found in purely software-based pseudo-random number generators. This has led to security problems in IoT devices and WhatsApp, among other applications. To get around that, the researchers set up of two supercomputing chips, each representing one qubit, cooled to near absolute zero. The chips are connected by a 30-meter-long microwave guide, similarly cooled, and the microwave photons flying between them create a situation of quantum entanglement. The results produced by this process are then transformed via a special algorithm to generate perfect randomness. “The resulting sequence of zeros and ones is now really perfectly random, and we can even certify that,” said Renato Renner, the other team leader. “The technical improvements allowed us to create random numbers that will remain perfectly random for all eternity.” The team published their results this week in an article entitled “Experimental randomness amplification” in Nature. View the full article

Two arbitrary code execution vulnerabilities in Notepad++ let local attackers run commands of their choice on Windows machines by tampering with the editor’s XML configuration files, with both flaws rated High at CVSS 7.8. The flaws, tracked as CVE-2026-48778 and CVE-2026-48800, affect every version of the editor up to and including 8.9.6, Notepad++ said in a release note. However, the vulnerabilities were patched the same day in version 8.9.6.1, alongside a third lower-severity crash bug, CVE-2026-48770, Notepad ++ author Dun Ho wrote in the release note. The two code execution flaws share a single design weakness. Notepad++ stores user choices, such as the path to the command-line interpreter and the list of user-defined commands, inside XML files in the user’s profile directory. The editor reads those values and passes them to the operating system as commands without checking what they contain, according to a GitHub Security Advisory on Notepad++ published on May 27. Anyone who can write to the XML files can decide what the editor executes, the advisory said. A backdoor that hides in the Run menu The more concerning of the two flaws, CVE-2026-48800, targets the file that holds user-defined Run menu entries. Notepad++ reads its user-defined commands from a file called shortcuts.xml and accepts whatever it finds there without validation, the advisory said. An attacker who can write to that file can add an entry that launches an arbitrary executable when the user clicks it in the Run menu. “The injected commands appear with legitimate-looking names in the Run menu, making them appear as normal user-created shortcuts,” the advisory said. “This creates a viable persistence mechanism, as the injected commands survive reboots.” The proof of concept Ho published shows an injected entry named “System Update Check” that launches Windows Calculator. Italian researcher Michele Piccinni reported the flaw. A second path through the command-line interpreter The second code execution bug, CVE-2026-48778, targets a different file. Notepad++ stores the path to its command-line interpreter in a file called config.xml and accepts whatever value it finds there as the program to launch when the user opens a folder in cmd, a separate advisory said. The interpreter path is stored “without any validation, whitelist, or digital signature check,” the advisory said. An attacker who edits config.xml can substitute any executable for the real Windows command prompt. Piccinni reported this one as well. Neither flaw lets an attacker reach the XML files on their own, the advisories said. Both assume the attacker already has the ability to write to the user’s AppData directory or can trick the user into running Notepad++ against a poisoned settings folder, whether through local malware, a malicious Windows shortcut, cloud-synced settings, or a social-engineered archive extraction. The third patched flaw, CVE-2026-48770, follows the same theme of unchecked input but stops short of code execution. A local process in the same Windows session can send the editor a malformed inter-process message that reliably crashes it, the advisory added. The bug carries a CVSS score of 5.0. A question mark over MSI patch delivery Notepad++ users can download the patched 8.9.6.1 binaries from the project’s download page, which offers both the EXE installer and an MSI installer for enterprise IT deployment that Ho added in November 2025. The MSI followed sustained enterprise demand that intensified after a Chinese state-sponsored group hijacked the editor’s update infrastructure for six months in 2025 and after Ho hardened the update mechanism in February with cryptographic integrity checks. The advisories recommended that users monitor the AppData folder on machines running Notepad++ for unexpected changes to shortcuts.xml and config.xml. The persistence of both flaws leaves no trace at the installation directory and no change to the Notepad++ binary itself, the advisories said, which means endpoint tools that look only at executables will miss it. Ho published no indicators of compromise. View the full article

Ransomware operators have spent years refining the art of locking files. Now, some are working harder to get those lockers to every reachable system first. Microsoft’s recent warning of the Gentlemen ransomware revealed its operators using a self-propagating Go-based encryptor capable of moving laterally through compromised environments and deploying itself across additional systems. “Modern ransomware is no longer just about encrypting files,” said Paul Reid, vice president of Adversary Research at AttackIQ. “The bigger risk is how quickly a single compromised machine can become a broader business disruption.” In a technical breakdown of its operations, Microsoft said the Gentlemen Ransomware was first observed in mid-2025 and remains highly active through 2026, impacting organizations across education, transportation, healthcare, and financial industries in North America, South America, Europe, Africa, and Asia. Gentlemen began as a “closed ransomware,” turned into a ransomware-as-a-service (RaaS) offering in September 2025, and eventually partnered up with BreachForums to pick up affiliates, including pen-testers and initial access brokers, from the popular cybercriminal marketplace. Built to move before it encrypts Microsoft’s analysis specifically focused on the ransomware’s ability to propagate through a network without relying entirely on manual operator intervention. The encryptor, written in Go, includes functionality designed to identify additional systems, authenticate using harvested credentials, and copy itself to remote machines over Server Message Block (SMB). Once deployed, it can execute remotely and continue spreading, creating a chain infection inside compromised environments. According to Microsoft, the malware leverages legitimate administrative tools and Windows functionality to facilitate movement while reducing the need for attackers to remain actively engaged through the operation. “The ransomware operator can control The Gentlemen encryptor through command-line arguments,” Microsoft said. “A password is required for execution, and optional arguments allow the operator to specify encryption scope, speed, lateral movement, and post-encryption behaviors.” One of the command line arguments,“–full,” launches separate processes to encrypt local drives with SYSTEM privileges and network shares visible to the user, to maximize encryption coverage once the machine is compromised. Additionally, a “–spread” command is used for lateral propagation. “Defenders should treat The Gentlemen as an attack-path problem, not just a patching or detection problem,” Reid said. “The priority is to understand where the ransomware could move, which controls would detect, contain, or disrupt it, and where gaps still exist before an incident occurs.” Gentlemen performs a “password check” to validate the use of its RaaS by the affiliates, and blocks its usage from unwanted binary recovery or interception. “Before executing its primary functionality, the malware validates the –password argument against a hardcoded value embedded within the binary,” Microsoft noted. “For the sample analyzed in this blog, the expected password is ‘9VoAvR7G’.” Detection windows are shrinking Microsoft’s analysis highlights the defensive challenges posed by self-propagating ransomware. Once execution begins, the time available to detect, investigate, and contain malicious activity can shrink considerably as the malware spreads to additional systems. “This is not the kind of threat where an organization can wait for a help desk ticket or a locked screen to realize something is wrong,” said John Joyner, Senior Director of Technology at Corsica Technologies. “Malware can move quickly through a network once it gets a foothold, which makes early detection the difference between a contained incident and a business-wide disruption.” Microsoft emphasized the importance of monitoring lateral movement activity, credential abuse, remote execution attempts, and other behaviors associated with Gentlemen’s propagation rather than focusing solely on encryption events. Additionally, it shared a list of indicators of compromise (IOCs) to support detection efforts. For those who don’t catch it on time, the ransomware leaves a note. “Your network is locked by the Gentlemen,” a desktop wallpaper reads on the victim’s machines. View the full article

In 2023, the Securities and Exchange Commission (SEC) required public companies to include a new section in their 10-K annual filings that is devoted to cybersecurity. This section is meant to address “cybersecurity risk management, strategy, governance and incidents.” I got curious as to what senior cybersecurity executives are conveying about their companies in these reports. I turned this into a research project that also gives me a reason to test out some AI techniques as well. The article is broken into two sections: My findings regarding Section 1.C for the top 200 companies in the S&P, and the second being my methods used to include some AI tech. 10-K Section 1.C Some really great analysis of Section 1.C has already been done to include a Harvard Law School study, a PWC study and an International Journal of Accounting Information Systems paper. These were great reads, but both were done over a year ago with the first batch of filings. Also, with the Harvard Law study, they only looked at the top 100 companies. I wanted to see if I could reproduce some of the analysis using this year’s filings, as well as ask some of my own questions, like whether there are any major changes between 2024 and 2025. Companies are required to disclose governance regarding cybersecurity risks. Key requirements include describing board oversight of cyber risks, the committee responsible and management’s role in assessing and managing material cybersecurity threats. Years of experience are often included. Similar to the Harvard study, I’ll look at who holds the senior cybersecurity role and their level of experience, who they report to, what part of the board oversees cybersecurity and standards that they are using. Not every company included all these pieces of information, but the bulk of them did. I’ll also look at overall trends between 2024 and 2025. CISO role top for cybersecurity The chief information security officer (CISO) continues to be the principal position responsible for cybersecurity, with over 70% of companies reporting CISO as the role responsible for cybersecurity. Numbers for CISO slightly increased from 2024 to 2025, going from 137 to 142. A distant second and third are CIO and CSO. The average years of experience for the role is about 23 years (standard deviation 6 years, 140 companies reported). CIO remains top senior in a varied field Chief information officer remains the top person that the cybersecurity official reports to and remained stable between 2024 and 2025 (~49 vs ~48). This is consistent with surveys and other reporting that CIO is the most frequent. I agree with another CSO article that having the position under the CIO is sub-optimal and both inserts conflicts of interest as well as downplays the importance of cybersecurity at the enterprise level. Not saying it can’t work, but there are likely better arrangements. No clear alternative has appeared in either 2024 or 2025 data (see the chart below), and the small relative numbers indicate there is a lot of variety in who the CISO reports to. The CEO, CFO and CTO were other common reporting positions, but none were a clear second. It is also worth noting that for over 50 companies, it wasn’t clear from the 10-K write-ups who the reporting position was. Derek Dye Board oversight Within the Company’s board, the Audit Committee is by far the most common group responsible for cybersecurity, representing 60% of companies. This jumps to about 70% (138 companies), If you include all the variations of Audit to include Audit & Risk, Audit & Finance, etc. Overall, audit numbers remained steady between 2024 and 2025. Distant second and third were the Risk Committee and Board of Directors broadly. NIST CSF for the win National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) is the most referenced cybersecurity standard, increasing between 2024 and 2025(113 vs 118). The most common other standard being ISO 27001, which also grew between 2024 and 2025 (49 vs 55). Interestingly, System and Organization Controls (SOC) was only mentioned by 17 companies. I find this seemingly low, given the importance of SOC reporting in large public sector companies. Overall trends Other interesting observations were what companies listed as their broad efforts as well as disclosures of incidents. Third-party and supply chain risk management. Acknowledging that external partners and suppliers represent a massive attack vector, multiple companies have instituted rigorous third-party risk management (TPRM) programs. These programs mandate pre-engagement security assessments, continuous monitoring and contractual requirements for vendors to maintain security standards and report breaches promptly. Third-party cybersecurity programs are indispensable in an increasingly interconnected economy and increasing reliance on external tools and services for company processes. Proactive testing and incident preparedness. Companies are moving past passive defense into proactive and simulated testing. This includes regular penetration testing, vulnerability scanning and engaging independent external auditors or consultants to assess program maturity and test controls. Furthermore, practically all companies maintain formal Incident Response Plans (IRPs) and conduct regular “tabletop exercises” to simulate cyberattacks, ensuring that management, legal and operational teams are prepared to respond to and recover from real-world crises. The devil is in the details on this one. The 10-K is not meant as a detailed technical rundown of company methods, so while it’s good to see, it’s mostly boilerplate language. Human-centric security defenses. Recognizing that human error is a primary vulnerability, mandatory, enterprise-wide cybersecurity awareness training is a standard requirement. These training programs are frequently supplemented with regular, simulated phishing campaigns to test employee vigilance and provide immediate, targeted feedback or remedial training. This training will need to adapt to the growing sophistication of AI-enabled deep fakes. Consistent disclosure of “No Material Impact” despite ongoing threats. A ubiquitous trend across the filings is the acknowledgment that while the companies face continuous, sophisticated and evolving cyberattacks, they have not experienced any incidents that have had a material adverse effect on their business strategy, results of operations or financial condition to date. I find this interesting, especially with the Critical Infrastructure//telecoms coming under repeated VOLT/SALT TYPHOON compromises as well as other attacks. Many companies also disclose that they rely on cyber liability insurance to mitigate financial exposure, though they frequently note it may not cover all potential losses. I’ll be doing further research here as there are likely more interesting findings between material impacts, news reporting and formal disclosures. Artificial intelligence. AI was cited by over 50 companies and is increasingly referenced as a double-edged sword for cybersecurity. Companies are leveraging AI and machine learning to automate threat detection and sort through vast amounts of security data. However, several acknowledged that AI empowers threat actors to execute more sophisticated, high-velocity attacks (e.g. deepfakes, advanced phishing). A further seven companies mentioned the concern of AI and intellectual property disclosures with Prudential and Capital One having the most explicit language on this risk. Part 2: Data gathering and analysis This was a very iterative process that increased in complexity as I went through the process and also due to the increased need for accuracy. I used several coding methods and AI tools to do this analysis. At first, I tried to use the big models to do all the work for me, but that quickly failed when they didn’t want to do that level of work! It also became apparent that getting the 10-K filings would take more work than just asking an AI agent. Enter some vibe coding. I was raised on C, Java and BASH scripting and have avoided using Python until now. Nothing against Python, I just haven’t needed to, and laziness with going with what you already know has won out before. So, this proved a nice additional challenge. Using the datamule Python module and some vibing, I managed to download all the recent 10-Ks for the top 200 companies onto my local machine. From there, I extracted the 1.C sections into a separate file using another Python script. This caused a bit of an issue as there were some differences (~5%) in filings that used a different format, or the cybersecurity write-up was in a different section of the 10-K. About 15 companies put them in the Risk section or elsewhere. I used a second Python script that leveraged the command-line version of Gemini (gemini-cli) to pull this information out. I then created a database in postgres that would store some of the key findings and allow for some further analysis. To get the data into there, I created a Python script that would run each of the 1.C files through Gemini and Claude using Python API calls. The use of Gemini API and Anthropic API was the new part that I really wanted to test out, and it proved very interesting. LLMs really shine for condensing and summarizing large texts for meaning. The alternative would be very complex and manually written regular expressions. Using Gemini API and Anthropic API, it took the below prompt and produced a string that I could then plug into the SQL command. Very cool seeing this work. (**Note: I was also thinking of how to do prompt injection, data poisoning and the like with this, but the dataset was small and controlled and this isn’t production code!). Derek Dye As a verification step, I then wrote another script that found all database entry differences between Gemini and Claude answers and ran the original 1.C section through Gemini again and told it to pick which answer was better. This changed about 10-30% of the entries, depending on the field. Additional analysis was done in Google Sheets and Google NotebookLM. With this, I created a basic AI-enabled workflow. It wasn’t agentic, but that would be interesting to create an automated version of this. This project showed some of the productivity potential of AI by allowing me to do very detailed research in about 15-20 hours of work, which would have taken at least twice as long by hand. It also highlighted the continued issue with accuracy where accuracy is needed. The bulk of the 15-20 hours was spent doing verification and refinement to make sure the AI answers were correct. The total cost in tokens for development, debugging, and running was around $15, not expensive, but not something I’d likely develop for every project I have. The bulk of that cost came with the refinement and the addition of additional verification checks to ensure the data was correct. Next projects might try to do this on my local computer using a local LLM like llama3 using ollama or maybe an agent that allows queries to the dataset this project created. GEMINI_PROMPT = """ Analyze this SEC 10-K document and extract the following cybersecurity information. Return the response strictly as a JSON object with these exact keys: { "senior_cyber": "Name or title of the senior person responsible for cybersecurity. Provide a one word response either CISO, CTO, CSO, CIO, or position title.", "report_to": "Title or name of who the senior cybersecurity person reports to. one word response either CEO, CTO, CSO, CIO, position title, or unknown. ", "board": "The board committee overseeing cybersecurity Provide a 1-3 word answer. ", "standards": "The cybersecurity standards/frameworks used use provide 5-7 word answer. If unknown, state unknown. use acronyms if available (e.g., NIST, NIST CSF, NIST CSF 2.0, ISO 27001)", "years_of_experience": integer representing years of experience (use 0 if unknown) } """ MODEL_ID = 'gemini-2.5-flash' —---- # 6. Update PostgreSQL upsert_query = """ INSERT INTO company_cyber_filings_v1_4 (ticker, filing_date, senior_cyber, reports_to, board, st andards, years_of_experience) VALUES (%s, %s, %s,%s,%s,%s,%s) ON CONFLICT (ticker, filing_date) DO UPDATE SET senior_cyber = EXCLUDED.senior_cyber, reports_to = EXCLUDED.reports_to, board = EXCLUDED.board, standards = EXCLUDED.standards, years_of_experience = EXCLUDED.years_of_experience; """ # 4. Upload file formatted_date = f"{year}-{month}-{day}" # Formatted for standard SQL DATE cursor.execute(upsert_query, ( prefix, formatted_date, gemini_data.get("senior_cyber"), gemini_data.get("report_to"), gemini_data.get("board"), gemini_data.get("standards"), gemini_data.get("years_of_experience") )) cursor.execute(upsert_query, (prefix,f"{year}{month}{day}")) conn.commit() print(f" -> Saved to database.") This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Big tech firms continue to push back against fines levied for alleged violations of European data protection law, in what could be a harbinger for AI regulations to come. While lawyers and experts quizzed by CSO broadly argue that big tech firms contesting data protection rules isn’t a particular cause for concern, the more widespread introduction of AI technologies is a far greater data protection challenge on the horizon. The EU’s General Data Protection Regulation (GDPR) came into force eight years ago this week. Over those eight years, European regulators announced an estimated €7.1 billion in GDPR fines but nearly 40%, around €2.8 billion, has either already been annulled or is under active legal challenge, according to analysis by insurance brokerage Alliance Risk. Fines that have already been annulled include one against Amazon at €746 million (Luxembourg, March 2026) and another versus OpenAI at €15 million (Italy, March 2026). Those under active appeal include three fines against Meta (€1.2 billion, €265 million, and €91 million) and one against TikTok (€530 million). Alliance Risk used CMS Law GDPR Enforcement Tracker as its primary source for information on GDPR enforcement, cross-referenced against IAPP enforcement data and trackers from Kiteworks and UniConsent. Data on annulments came from reported court decisions. GDPR established a benchmark for breach notification According to Alliance Risk, GDPR successfully laid the foundation for data protection law globally — particularly by first establishing the 72-hour breach notification standard. This three-day notification rule is law in six jurisdictions — EU, UK, Thailand, Kenya, Nigeria, and South Korea — and influential elsewhere. For example, the US CIRCIA rule for critical infrastructure, which is pending final rule publication this month, is due to apply the 72-hour standard. By comparison, HIPAA gives US healthcare organisations 60 days as a breach notification deadline. The SEC gives public companies four business days but only after they’ve internally determined a breach is “material,” which adds its own delay. Although the breach notification regulations established by GDPR have been a success, issues with the enforcement of rules remain. “The framework has structural weaknesses that large companies have learned to exploit in court, and nearly 40% of announced fines reflect that,” according to Alliance Risk. The EU’s AI Act reaches full application in August, and the European Commission is already proposing to reform GDPR through the Digital Omnibus. “The framework is being rewritten while it’s still being tested,” Alliance Risk concludes. “The fact that around 40% of GDPR fines by value are under challenge isn’t necessarily a sign the system is broken,” Nick Phillips, an intellectual property lawyer at Edwin Coe LLP tells CSO. “Eight years in, the bigger fines were always going to end up in court, and the rulings that come out of those appeals are starting to give in-house teams something they’ve never really had before: practical guidance on what regulators can and can’t defend.” Phillips argues that achieving compliance with GDPR has improved enterprise security maturity because of the 72-hour breach notification rule coupled with the obligation to record all breaches and to notify data subjects combined with the need to improve security controls even more than the threat of a fine for non-compliance. “That breach notification regime has arguably been the single biggest factor in forcing organisations to put proper incident response in place, get forensics providers on retainer, and start reporting breaches up to the board,” Phillips says. “A lot of that simply wasn’t happening before 2018, and it’s the part of GDPR that’s done the most work.” Marco Eggerling, LL.M, security and trust officer EMEA and Asia, at robotic process automation vendor UiPath, says it would be a “mistake to read these annulments as courts clearing big tech.” “In the Amazon case, the Luxembourg court upheld the substance of the violations and sent the matter back to the regulator,” Eggerling notes. “The fine fell because the authority skipped required steps, not because the conduct was found lawful.” Eggerling adds: “The lesson for regulators is to build procedurally bulletproof decisions. The lesson for companies is that the underlying obligations have not moved an inch.” Even within the EU there is a disparity in how regulations are understood and applied, making cross-border decisions about data and AI challenging. “A lot of organisations lean towards the ‘lowest common denominator’ and adhere to the strictest governance and more conservative approaches in order to avoid the wrath of regulators,” says Caroline Carruthers, CEO and founder of global data consultancy Carruthers and Jackson. The UK and EU apply stricter regulations than the US or China, so many organisations adhere to the stricter rules wherever they operate. Due to their size and nature, “big tech” organisations tend to have a heightened appetite for risk and a desire to push the boundaries of regulations — and often a different relationship with the general public, whose data is the business model. “They have a vested interest in deregulation and so will naturally be the most likely to contest enforcement,” Carruthers notes. Data regulations need to evolve with the advent of AI For most organisations, the enforcement of GDPR has gotten to a place where it is broadly fit-for-purpose, according to Carruthers. “When GDPR was first introduced, the guidance was unclear and inconsistent,” Carruthers explains. “It felt legally robust, but a lot of the data practitioners struggled to make it work. Even now, some businesses tell us that they are ‘paralysed’ a little by GDPR. They are highly fearful of data and the associated regulation, to the extent that they are unable to maximise — or even touch on — the potential power of data.” However, as AI and data regulation evolves, there’s a need to account for how these tools are now being used. The concern is that history may repeat itself as regulation looks to keep pace with technological change. “There is a risk that organisations get stuck in a mid-maturity plateau in which innovation is halted by complex and inconsistent interpretations of regulations,” Carruthers warns. View the full article

Open source code is everywhere in the enterprise; it’s estimated that upwards of 90% of Fortune 500 companies have it in their software supply chains. But open source code is notoriously rife with vulnerabilities, and identifying and patching those bugs can be an endless battle for security teams. IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process. Announced today, the project will commit $5 billion and 20,000 IBM and Red Hat engineers to build a new ‘enterprise clearinghouse’ to accelerate discovery and remediation of vulnerabilities in open source software. The companies say the clearinghouse will serve as an AI-powered “security coordination layer,” giving enterprises the ability to integrate patches directly into their existing software supply chains. Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription. “The advancement in AI tools has broken the patching map, which is the ability to discover vulnerabilities in software without losing the speed of remediation,” Ashesh Badani, Red Hat SVP and CPO, told CSOonline. “Everyone’s running open source software, and the challenge is not being able to fix vulnerabilities quickly enough.” Closing the remediation gap Open source security issues have been well documented: Almost 50,000 common vulnerabilities and exposures (CVEs) were published in 2025, and Anthropic’s Project Glasswing, powered by its Mythos Preview model, found roughly 3,900 previously undiscovered high or critical severity vulnerabilities in open source software shortly after launch. IBM is considered one of the broadest commercial open source ecosystems, using more than 62,000 packages and operating across Linux, Kubernetes, Kafka, Terraform, Java and other platforms, and providing lifecycle management, validation, and patching for elements within those environments. The company says Project Lightwell will now apply those same engineering principles to broader AI frameworks, independent libraries, language toolchains, and data streaming platforms, to deliver validated fixes to open-source code already in use in enterprise environments. This can support remediation without disruption of stability, certification, or compliance. No upgrades or access to source code are required; Project Lightwell will backport fixes to exact dependency versions that have already been tested and deployed. It operates on fundamental configuration manifests like pom.xml so code remains in controlled enterprise environments when patched artifacts are rolled out. Initial focus will be on Java/Maven, but the project will eventually expand to PyPI, npm, Go, and others. Enterprises will have the ability to share sensitive vulnerabilities under embargo through a “secure intermediary model” and receive validated patches spanning Red Hat platforms and independent community code. They will also be able to deliver fixes across dependency chains; report and address issues across active production environments; and share fixes upstream so the wider open-source community can incorporate them. “We want to make sure that whatever fixes we provide to the enterprises through the clearinghouse also find their way back into the open source community that developed [the code],” Badani explained. For instance, if a piece of Python code was patched, the fix should be quickly delivered back to the Python community. With Project Lightwell, that process can be achieved through a “secure map.” Using advanced AI, and working with leading open source contributors, IBM and Red Hat engineers will focus on connecting upstream and downstream environments so fixes are enterprise-ready. They will also develop patches and perform “high volume” vulnerability review and triage, and dependency hardening. The network of 20,000 engineers will come from IBM’s and Red Hat’s existing pools of talent, and the companies will augment those teams as needed, Badani explained. The companies will take advantage of foundation models coming out of frontier labs, as well as their own internally-built AI tools and frameworks. The $5 billion will be used to equip teams with AI tools and build out internal operational infrastructure. Early Project Lightwell adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. Following the initial design period, IBM and Red Hat will phase more customers onto Project Lightwell via a subscription model. A call to action? This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security. The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it. “If we don’t find a way to invest in open source, which will close a long-standing equity issue, the alternative is everyone building their own bespoke code using AI,” Shipley said. That would be “massively wasteful” from a compute and environmental perspective. “I hope this drives others to act,” he said. Keeping humans in the loop for an ongoing battle Badani emphasized that, while AI is great at discovering security issues in open-source code, the patching process can still be cumbersome. Fixes have to be sent upstream, distributed to the open source community, then flow back to customers and users. “Finding the bug is one thing,” said Badani. “The other is all the steps that it takes to actually go and remediate it. That extra amount of time is the gap that we’re trying to help close.” Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced. “This isn’t going to stop any time soon,” Badani said. “Even if we were to very successfully solve the initial set of challenges that come to us, this will be something that companies are going to need on an ongoing or recurring basis.” And, while the narrative has focused on cutting human engineers in favor of AI, Project Lightwell is focused on the opposite: “We can address [the problem] with a mixture of AI tools and human knowledge and expertise,” Badani said. “Coupling the two gives you a better outcome than just using one or the other.” This article originally appeared on InfoWorld. View the full article

A newly discovered and so far unpatched critical vulnerability in the open source Gogs Git service not only demands immediate action from developers to secure their code, it also puts a spotlight on the potential issues in using self-hosted code platforms from small maintainers. The hole is a critical argument injection vulnerability, discovered by a researcher at Rapid7, that allows any authenticated user to remotely execute code on a Gogs server by creating a pull request with a malicious branch name during a merge operation. Rapid7 published an analysis of the vulnerability today, after the maintainer of Gogs did not respond to a request for status updates or to an offer to defer disclosure after it first reported the hole over two months ago. “This is a serious vulnerability in software that isn’t commonly exposed to the public internet,” Ryan Emmons, staff security researcher at Rapid7, said in an email. “Gogs is typically used in an internal capacity; the most likely threat model is an attacker that has already gained access to an internal network environment exploiting the vulnerability to gain read/write access to source code repositories on the Gogs server. An attacker might leverage this access to silently tamper with source code and exfiltrate sensitive information, such as user password hashes and proprietary software.” Rapid defensive action required David Shipley, head of security awareness provider Beauceron Security, said both the Gogs maintainer and developers must take defensive action fast, because with the publication of a vulnerability “any attackers that didn’t know about this are going to be on it viciously.” The fact that it has been left unpatched for months as of Thursday afternoon is another reason why CSOs and developers prefer GitHub, he added. With any open source project, there are worries about if or when a patch will be issued. “The exploit requires no admin privileges and no interaction with other users,” Rapid7 said in its report. “An attacker operates entirely within their own account. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account and repository on any default-configured instance. Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user.” In addition, any user with write access to a repository where rebase is already enabled can exploit it directly. On instances where repository creation is restricted, an attacker still only needs write access to any repository that has (or can have) rebase merging enabled. If exploited, the vulnerability could not only lead to a Gogs server compromise, but from there it could turn into to a cross-tenant data breach, credential theft, lateral movement across an IT network, and software supply chain attacks through the code that is being developed on the compromised Gogs platform. Until a patch is released, developers and CSOs in organizations with the platform in use should strictly enforce restricted network access to Gogs, Emmons said, and ensure that only those who need access can use the application. Furthermore, if user self-registration is not already disabled, it should be. Only administrators should be able to create new user accounts. Rapid7 describes Gogs as a lightweight, self-hosted Git service written in Go that can run on any platform supported by the Go toolchain, including Linux, macOS, and Windows, as well as on ARM-based systems. It’s one of the more popular self-hosted alternatives to Microsoft-owned GitHub, says Rapid7, and is commonly deployed by companies, universities, and open-source projects. Other self-hosted Git services for developers include GitLab Community Edition, Gitea, Forgejo (a fork of Gitea), and Atlassian’s Bitbucket Data Center. Gogs pros and cons In a blog earlier this month, Open Source Alternatives, which describes itself as a curated directory of self-hosted tools that replace paid software, noted that developers may chose to self-host a git server to avoid GitHub outages, arguing, “your repositories stay online when GitHub goes down, your GitHub Actions minutes bill disappears and your source code never leaves your own server”. Emmons said Gogs is popular because it’s a lightweight and self-contained Git solution. It’s easy to deploy and run, he said, unlike many other Git servers that require heavy operational overhead and IT management. It’s also self-hosted on-prem software, which he said is ideal for teams that don’t, or cannot, for one reason or another, store source code in the cloud. The main pro, Emmons said, is that Gogs is an appealing solution from an operational simplicity perspective. It works well for what it does, and it doesn’t take much management effort to keep it working. But, he added, “a major con is what we saw with this disclosure; Gogs is open-source software maintained by kind people in their free time, and the developers behind it don’t have the support of a major corporate information security team. That means security issues can sometimes present in ways that they typically wouldn’t for a well-funded enterprise product.” This article originally appeared on InfoWorld. View the full article

India’s cybersecurity agency, CERT-In, has urged organizations to patch, mitigate, or isolate known exploited vulnerabilities affecting internet-facing “crown jewel” systems within 12 hours where feasible, warning that AI-assisted attacks are dramatically compressing the time between vulnerability disclosure and exploitation. The recommendation, part of a sweeping new CERT-In blueprint on defending against AI-assisted cyber exploitation, signals a significant escalation in expectations around enterprise vulnerability management, exposure reduction, and operational resilience. The 38-page framework also recommends one-day remediation for critical externally exposed vulnerabilities, three days for critical internal vulnerabilities affecting high-value systems, and five days for high-severity flaws based on risk prioritization. CERT-In said threat actors are increasingly using AI to accelerate reconnaissance, vulnerability discovery, phishing, malware generation, and automated exploitation workflows. “Exploitation timelines are reducing significantly,” the agency warned in the advisory, adding that attacks are expected to become “increasingly autonomous.” An operationally disruptive target Security analysts said the headline 12-hour expectation is likely to force enterprises to rethink traditional weekly or monthly patching cycles, but cautioned that the guidance is more nuanced than a blanket patch mandate. “The 12-hour window is the outlier, realistic only as a containment target on a narrow set of exposed assets, never as a patch-completion target across sprawling estates burdened by fragmented infrastructure, layered approvals, outsourced operations, and legacy dependency,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. Gogia said the blueprint’s tiered approach is more significant than the headline remediation clock itself because it ties response timelines to exposure and operational criticality rather than applying a uniform patching mandate across all systems. “The five-day high-severity window is comfortable for most enterprises. The three-day critical-internal window is where the pressure actually bites,” he said, particularly in sectors such as finance, telecom, healthcare, and operational technology environments where uptime concerns complicate rapid change management. Apeksha Kaushik, senior principal analyst at Gartner, said the biggest challenge for many organizations will not necessarily be deploying patches, but achieving the operational maturity needed for rapid exposure management. “The primary barriers are not just technical, but operational. Most organizations lack real-time asset visibility, automated vulnerability prioritization, and cross-functional incident response playbooks,” Kaushik said. “The most acute struggles will be in asset discovery, risk-based prioritization, and orchestrating rapid response across silos,” she added. From vulnerability management to exposure management The blueprint repeatedly emphasizes that traditional periodic security assessments are becoming insufficient against AI-enabled attacks capable of rapidly weaponizing newly disclosed flaws. Instead, CERT-In is pushing organizations toward continuous exposure management, threat-informed defense, continuous monitoring, and adversarial testing. Notably, the framework leans heavily on temporary mitigations, including isolation, access restrictions, WAF/API protections, enhanced monitoring, and compensating controls when immediate patching is not possible. Analysts said that approach makes the timelines more achievable operationally, but also shifts the burden onto asset visibility and exposure intelligence. “Compensating controls do make the timelines more workable. They also remove every excuse,” Gogia said. “If you cannot isolate, restrict, or monitor quickly, the problem was never patch cadence. The problem is that you do not know your own exposure.” Kaushik similarly said the guidance effectively pushes organizations toward more mature exposure management capabilities. “Organizations must be able to rapidly identify affected assets, assess risk, and deploy effective interim controls,” she said, adding that enterprises lacking mature asset inventories, segmentation, and monitoring capabilities will struggle to operationalize the guidance at scale. The blueprint also calls for continuous vulnerability assessments, AI-assisted security testing, adversarial simulations, penetration testing, and red teaming exercises. A preview of future global standards? Analysts said CERT-In’s remediation expectations are among the most aggressive currently issued by a national cyber agency and may influence broader international vulnerability-management practices as AI compresses attacker timelines globally. “CERT-In has done something the West has largely avoided: it has set standing clocks by asset category rather than deadlines by individual vulnerability,” Gogia said. He contrasted the framework with CISA’s Known Exploited Vulnerabilities (KEV) program, which typically uses vulnerability-specific remediation deadlines rather than persistent enterprise-wide remediation clocks. “The fixed-clock model looks aggressive today because the rest of the world has not caught up, not because it is reading the threat wrongly,” Gogia said. Kaushik said the framework could create operational challenges for multinationals whose global service-level agreements are less stringent than India’s expectations. “For providers, this may create a compliance gap where internal SLAs are less stringent than India’s requirements, necessitating a reassessment of global patching and mitigation processes,” she said. View the full article

Taking down a sprawling malware operation once signaled progress in securing the open-source ecosystem. Now, it barely registers. The GlassWorm campaign disruption comes at a moment when attackers can quickly reconstitute, and defenders are increasingly grappling with a new challenge: distinguishing real threats from automated noise. “I think coordinated actions, like GlassWorm, can sever control, significantly increase attacker costs, buy time for remediation, and signal the possibility of a fightback,” said Agnidipta Sarkar, chief evangelist at ColorTokens. “But most takedowns are temporary actions in a long fight.” The CrowdStrike-led takedown, conducted alongside Google and the Shadowserver Foundation, disrupted infrastructure linked to the campaign that had poisoned hundreds of repositories with malicious packages targeting developers. A day after the takedown, in an independent development, the OSV database withdrew 157 malware reports after maintainers determined the submissions were likely automated false positives. Takedowns help, but analysts question long-term impact The takedown happened on May 26, at 14:00 UTC, with CrowdStrike confirming the operation to have struck down “all four of GlassWorm’s command-and-control (C2) channels simultaneously”. This reportedly helped sever the botnet operators from their infected machines, blocking them from pushing out new malware. CrowdStrike described the GlassWorm operation as targeting infrastructure used to distribute malware through developer-focused repositories, an increasingly popular attack vector as adversaries chase CI/CD access, developer credentials, and downstream enterprise environments. GlassWorm was a cross-platform operation affecting Windows, macOS, and Linux systems, with trojanized VSCode extensions and compromised npm and Python packages for information and credential harvesting. “As part of our disruption efforts, we are working with partners to bring more pain to attackers, especially when we see them abusing our products or targeting our users,” said Google Threat Intelligence Group’s (GTIG) chief analyst, John Hultquist, in an X post. Still, the broader economics of repository abuse remain unchanged. Open-source ecosystems continue to offer attackers low-cost distribution, massive reach, and relatively weak identity verification compared to traditional software distribution channels. That means operators behind campaigns like GlassWorm can often reappear quickly under new accounts, domains, or package names. “It is disruption, not eradication,” Sarkar warned. “To build resilience after a takedown, defenders should prioritize rapid post-takedown scanning to detect the reemergence of malicious artifacts across related repositories and distribution platforms. ” They should then establish granular micro-perimeters, build capabilities to contain propagation across workloads, endpoints, IT/OT/IoT/cloud assets, and limit the blast radius of supply-chain compromises (e.g., a poisoned npm package or a GitHub workflow stealing creds can’t easily pivot). Sarkar advised developers and organizations to establish “granular micro-perimeters,” build capabilities to contain propagation across workloads, and limit the blast radius of supply-chain compromises. AI False positives are becoming part of the supply chain problem If GlassWorm highlights the persistence of real malware campaigns, the OSV withdrawal incident exposed a parallel issue affecting the open-source software (OSS) supply chain. It is the growing reliability surrounding automated security reporting. The withdrawal of 157 malware reports believed to be AI-generated false positives matters, especially when it includes packages like FastAPI v0.136.3. FastAPI is a heavily adopted Python framework powering production APIs, AI services, and cloud-native applications across industries. Even a few days of false flagging can trigger costly deployment delays, CI/CD disruptions, and hours of development time in isolating legitimate software. “I would recommend that enterprises be concerned enough about signal-to-noise problems to consider remedial measures, as automation erodes trust in defensive tools,” Sarkar said. “Unless you have a highly microsegmented enterprise, noise wastes analyst time, slows velocity, and risks missing sophisticated attacks amid fatigue.” In 2026, with AI-assisted malware and reporting both accelerating and rising false positives in SAST/SCA tools, defensive automation is getting asymmetrically compounded by supply-chain volume, he noted. In a blog post, Socket called bad OSV records particularly dangerous as the popular database gets rapidly carried through dependency scanners, CI checks, registry controls, SBOM tools, dashboards, and internal policy systems. All hope is not lost, though, as newer tools promise lower reliance on AI for hunting dependency vulnerabilities. CVE Lite CLI, a light-weight, JavaScript and TypeScript dependency vulnerability scanner, is offering developers a way to know dependency risks while they are still writing code, much earlier than failing automated scanners in CI pipelines. View the full article