CSOonline

Google is expanding the role of its CodeMender security agent from autonomous vulnerability remediation toward a larger agentic development ecosystem, signalling a broader push toward AI-driven AppSec. Months after introducing CodeMender, an AI-powered agent designed to autonomously identify and patch software vulnerabilities, Google is now integrating the technology into its expanding Agent Platform strategy unveiled at Google I/O 2026. The shift suggests that CodeMender may no longer be just a standalone remediation tool. Instead, it appears to be positioned as part of a broader ecosystem of enterprise AI agents capable of navigating software development, security, validation, and operational workflows with limited human intervention. “Embedding CodeMender into Agent Platform with identity, gateway, and observability components all included leads me to believe that Google thinks the enterprise doesn’t or will not trust autonomous remediation as a point solution, but rather as part of their governed infrastructure,” said Chris Steffen, vice president of research at Enterprise Management Associates. “So this isn’t just a product update; it is very likely a strategy pivot.” Launched as a standalone vulnerability remediation agent When Google DeepMind unveiled CodeMender in October 2025, the company presented it as an autonomous security remediation system capable of debugging and fixing vulnerabilities in massive open-source codebases. According to Google, the agent had already generated and submitted dozens of security patches across projects. “Over the past six months that we’ve been building CodeMender, we have already upstreamed 72 security fixes to open-source projects, including some as large as 4.5 million lines of code,” the company had said at launch. The agent was said to be using Gemini reasoning models to analyze vulnerabilities, generate fixes, validate patches, and test whether proposed remediation introduced regressions before surfacing them to developers. At the time, Google framed the technology primarily as a response to the growing burden of software vulnerability management. “Software vulnerabilities are notoriously difficult and time-consuming for developers to find and fix,” it had said. However, Google hasn’t revealed anything about how CodeMender has been doing since launch. “It’s early yet, and I am sure they will release performance data at some point,” Steffen reflected. “As it stands right now, there is no published data on false positive rates, regression rates, or fix accuracy on proprietary codebases.” But Steffen believes that data will come soon because enterprises will ask for these metrics before seriously considering adoption. Now integrated into broader Agent Platform strategy Before flashing a report card, Google started sketching the bigger blueprint. Its latest Agent Platform announcements at I/O 2026 indicate the company may now be thinking about CodeMender in much broader operational terms. Google said it is integrating CodeMender into Agent Platform, adding that the integrated capabilities will be “available soon” to its enterprise customers. “Leveraging Agent Platform capabilities and advanced Gemini models, CodeMender autonomously identifies vulnerabilities within your code,” the company added. The Agent Platform, also called the Gemini Enterprise Agent Platform, is essentially Google’s infrastructure stack for building, deploying, orchestrating, governing, and managing autonomous AI agents across enterprise workflows. Responding to whether the integration signals a shift toward AI-native software security pipelines, Steffen said, “Absolutely — and it’s structural, not cosmetic. There is absolutely no question that AI can now discover vulnerabilities faster than humans can remediate them, and it makes an AI-native pipeline a necessity, not a ‘nice to have’.” Still, substantial trust and governance questions remain. Autonomous remediation tools could introduce faulty fixes or regressions if validation misses edge cases, while enterprises may remain wary of giving AI agents unsupervised access to sensitive codebases. CodeMender’s launch emphasis on validation, testing, and workflow orchestration suggests that Google recognizes those concerns, and may now be attempting to position CodeMender not as a fully independent actor, but as a tightly governed participant inside larger enterprise development pipelines. While breaking the integration news at I/O, Google reiterated that everything will happen “with your approval.” “This entire process automates secure deployment while ensuring your developers retain control,” the company reassured. View the full article

A critical vulnerability in the on-premises version of the Cisco Secure Workload security platform could allow a threat actor to obtain the privileges of a site admin, enabling them to compromise endpoints and read or modify configuration data. “CSOs need to drop what they are doing and patch this immediately,” warned consultant Robert Enderle, who heads the Enderle Group. “Cisco Secure Workload manages zero trust, micro-segmentation, and enterprise-wide network visibility. If an attacker controls the platform that dictates your security policies, they effectively own the map and the keys to your entire network kingdom.” “This is the absolute worst-case scenario,” he added. “Because of how vital this platform is to large enterprises, threat actors will be aggressively scanning for unpatched API endpoints to exploit.” The urgency of addressing this immediately was echoed by Fred Chagnon, principal research director at Info-Tech Research Group. An attacker could modify or dismantle an enterprise’s security policies, he pointed out, effectively opening doors within the environment that were deliberately closed. ‘Blast radius could be significant’ “Because this access operates at the site admin level and crosses tenant boundaries,” he added, “the blast radius in a multi-tenant deployment could be significant, potentially exposing or compromising workloads and data belonging to multiple business units or customers.” Cisco assigned this flaw (CVE-2026-20223) a maximum CVSS score of 10.0 because it allows an unauthenticated, remote attacker to bypass authentication entirely. By sending a crafted HTTP request to an internal REST API endpoint, the threat actor instantly gains site admin privileges. In its advisory, Cisco says this hole is due to insufficient validation and authentication when accessing REST API endpoints. There are no workarounds; the only solution is to install software updates to address this vulnerability, which Cisco “strongly recommends.” Systems running version 4.0 should upgrade to 4.0.3.17. Those with version 3.10 should upgrade to version 3.10.8.3, while those still on version 3.9 and earlier should migrate to a newer, fixed release. The vulnerability affects Secure Workload Cluster Software in both SaaS and on-prem deployments, regardless of device configuration, but only affects internal REST APIs, and doesn’t impact the web-based management interface. However, only those using the on-prem version need to act; Cisco has already patched the SaaS product. As of Wednesday, Cisco wasn’t aware of malicious use of the vulnerability. ‘Treat it as an active threat’ The good news, Chagnon said, is that Cisco’s own security team discovered and disclosed this vulnerability, publishing a patch at the same time as the advisory. And, he added, there are no known signs of exploitation in the wild, and no public disclosure preceded Cisco’s own announcement. While the SaaS version of the platform has already been patched by Cisco, he said, admins running Cisco Secure Workload on-premises shouldn’t treat this as something to be fixed during routine patch cycle. “Given the nature of this vulnerability, a perfect CVSS score, no authentication required, and no available workarounds, organizations should treat this as they would an active threat,” he said. This is not the only critical bug that Cisco admins have faced recently, but it’s the highest rated in severity. In April, admins had to replace an identity provider certificate in Webex Control Hub as part of a fix to address a vulnerability rated 9.8 in severity. In January, patches were released to close a critical remote code execution vulnerability in Unified Communications Manager, Unity Connection, and Webex Calling Dedicated Instance. And in December, Cisco warned that a China-linked hacking group was actively exploiting a zero day vulnerability in its Secure Email appliances. View the full article

Microsoft released emergency fixes for two zero-day vulnerabilities in the malware protection components of Microsoft Defender. The flaws allow local attackers to gain system-level privileges or cause the anti-malware service to stop working correctly. Both conditions are valuable in a malware attack, first to prevent detection if the system relies only on Microsoft endpoint protection and second to gain full control over the system. On Wednesday, the United States Cybersecurity and Infrastructure Security Agency (CISA), added the two vulnerabilities, tracked as CVE-2026-41091 and CVE-2026-45498, to its Known Exploited Vulnerabilities (KEV) catalog, signaling that exploitation was detected in the wild. Security experts report that the two flaws are behind the RedSun and UnDefend exploits published last month on GitHub by a disgruntled researcher who calls themselves Nightmare Eclipse. While plausible, Microsoft has not mentioned those exploit names in its advisories for these two vulnerabilities. The privilege escalation flaw, CVE-2026-41091, is located in mpengine.dll, the Microsoft Malware Protection Engine (MPE) component that handles file scanning, malware detection, and cleaning in several Microsoft anti-malware products: Microsoft Defender, Microsoft System Center Endpoint Protection, Microsoft System Center 2012 R2 Endpoint Protection, Microsoft System Center 2012 Endpoint Protection, and Microsoft Security Essentials. The vulnerability is described as an improper link resolution before file access issue. In other words, it’s related to a link- or shortcut-following routine that has unintended consequences. The flaw is rated with a CVSS score of 7.8, meaning high severity. The other vulnerability, CVE-2026-45498, is in the Microsoft Defender Antimalware Platform (MsMpEng.exe), which along with a series of kernel-mode drivers, is responsible for real-time monitoring and protection. As with MPE, this component is used by Microsoft’s other endpoint protection products. Although Microsoft issues updates for malware definitions three times per day, platform components such as mpengine.dll and MsMpEng.exe are updated only once per month or as needed. Customers are advised to manually trigger a check for updates in their respective product and check that they are running version 1.1.26040.8 or newer of the Malware Protection Engine and version 4.18.26040.7 or newer of the Microsoft Defender Antimalware Platform. The Malware Protection Engine update also fixes a remote code execution vulnerability tracked as CVE-2026-45584, but this flaw has not been publicly disclosed or exploited. View the full article

Researchers have published details about a critical vulnerability in ChromaDB that could allow unauthenticated attackers to execute arbitrary code and access sensitive data on machines running the open-source vector database. The issue, tracked as CVE-2026-45829, is located in ChromaDB’s API server and was published by researchers at HiddenLayer after reportedly failing to get in contact with the developers of ChromaDB, one of the most popular vector databases used for AI applications. The vulnerability stems from a race condition between the code ChromaDB uses to parse embedding model references and the code it uses to perform an authentication check. Attackers can exploit the flaw by sending requests to load malicious model configurations hosted on Hugging Face. “The authentication is not missing, it’s just in the wrong place,” researchers from security firm HiddenLayer said in their report. “By the time it fires, the model has already been fetched and executed. The server rejects the request, returns a 500, and the attacker’s payload has already run.” According to HiddenLayer, the flaw exists in ChromaDB from version 1.0.0 up to 1.5.8, and multiple attempts to report it to the developers since February using different communication channels have gone unanswered, prompting public disclosure. Over 73% of ChromaDB instances that are publicly accessible on the internet and are findable via the Shodan search engine are running a vulnerable version. Until a patch becomes available, the researchers advise deploying ChromaDB servers using the Rust implementation, which is not affected, instead of the Python FastAPI server. Network access to the ChromaDB port should also be restricted to trusted IP addresses only. Two separate issues combine into unauthenticated RCE Vector databases like ChromaDB are often used to enhance the knowledge of LLMs with third-party or company-specific data as part of retrieval-augmented generation (RAG) workflows. That data, typically unstructured in origin, is stored in a vector database as mathematical representations called vector embeddings. To convert unstructured data such as text, images, or audio into vector embeddings, specialized machine learning algorithms known as embeddings models must be used. These models can be specialized for specific use cases. As a result, ChromaDB and other vector databases give users the ability to choose between various embeddings models for these conversions. ChromaDB orders documents into collections, and each collection can be assigned a specific embeddings function that dictates how documents are embedded, with what model, and with what parameters. One of those parameters can be trust_remote_code: true, which tells the model loader to download and execute any additional Python module files shipped with the model. As a result, unauthenticated attackers can send a request to the ChromaDB API server to set up a new collection with a custom embeddings function that points to a malicious model they published on Hugging Face, HiddenLayer’s researchers found. “This is the same class of risk we have written about before in the context of malicious models on Hugging Face and unsafe deserialization in ML artifacts,” the HiddenLayer researchers said. “A model is not passive data. It is code, and loading one from an untrusted source is equivalent to running untrusted code.” But shouldn’t ChromaDB’s API endpoint authentication prevent this from happening? This is where the second issue comes into play. It turns out that ChromaDB’s server code processes such requests before checking for authentication. And while processing the request, it fetches the model reference from Hugging Face to set up the embeddings configuration. So even if the collection is ultimately not created because the eventual authentication check fails, the malicious Python code accompanying the model is still downloaded and executed. “From the outside, it appears to be a failed API call,” the researchers said. “[But] on the attacker’s end, there is a shell on the server.” Because the attacker’s code inherits the permissions of the user running the ChromaDB API server, it has access to everything on the machine the server process also has access to. This means environment variables, API keys, mounted secrets, and the data stored on disk. This is the latest in a string of attacks that are made possible through maliciously crafted AI models and their corresponding configuration files. Earlier this month, HiddenLayer’s researchers showed how remote code execution can be achieved by making minor changes to a model’s tokenizer.json file, which is used to map token IDs to words or characters creating an alphabet the model uses to generate its outputs. Last year, researchers showed how attackers can hide malicious code inside Python Pickle files, a format that is commonly used to distribute AI models. View the full article

Microsoft has open-sourced two new tools aimed at bringing AI safety checks much earlier into the agent development lifecycle. The tools, called Rampart and Clarity, were announced this week as part of Microsoft’s broader push to operationalize safety engineering for agentic AI. “We built these tools because we believe that AI safety has to become a continuous engineering discipline rather than a periodic checkpoint, and we think the best way to make that happen is to put practical, open tools in the hands of the people doing the building,” Microsoft’s AI red team founder Ram Shankar Siva Kumar said in a security blog post. The announcement comes as AI agents evolve from chatbot-style assistants into systems with real operational privileges. According to Microsoft, these newer agents introduce risks that traditional application security workflows were not designed to handle, including prompt injection, unsafe tool use, privilege escalation, and unintended autonomous actions. Both Rampart and Clarity are now available as open-source projects from Microsoft. Rampart for repeated AI red teaming Microsoft has positioned Rampart as the more operational of the two tools. The framework is designed to help developers transform red-team findings into repeatable tests that can run continuously during development and deployment pipelines. Built on top of PyRIT, Microsoft’s open automation framework for red teaming generative AI systems, Rampart aims to allow teams to execute both adversarial and benign test scenarios against AI agents in a structured and automated way. The idea is to move beyond one-off safety reviews and instead include continuous checks directly into CI/CD workflows. “Where PyRIT is optimized for black-box discovery by security researchers after the system is built, Rampart is built for engineers as the system is being built,” Kumar explained. The framework promises the ability to surface issues relating to cross-prompt injection, unsafe data handling, insecure tool execution, and other agent-specific attack paths before applications reach production. Additionally, Rampart is programmed to let organizations convert AI red-team findings into repeatable automated tests, helping engineers continuously check for regressions as agents evolve. Clarity to focus on assumptions in AI agents While Rampart focuses on testing systems being built, Clarity is aimed earlier in the workflow before code starts getting written. Microsoft describes Clarity as a tool that is meant to examine and validate the assumptions behind AI agent design decisions. That would presumably include evaluating how agents are expected to behave, what permissions they should have, how they interact with tools and external systems, and where trust boundaries exist. “Clarity runs as a desktop app, a web UI, or embedded directly in a coding agent,” Kumar said. “It guides engineers through structured conversations covering problem clarification, solution exploration, failure analysis, and decision tracking.” These conversations are written to the “.clarity-protocol/” directory in the repository as markdown files, which can be committed, reviewed in pull requests, and diffed like source code, he added. Microsoft has been building an open-source “agent governance” and safety stack over the past few months, making Rampart and Clarity part of a broader strategy rather than a standalone release. Last month, the company introduced the Agent Governance Toolkit, focused on routine controls, policy enforcement, and OWASP-aligned protections for AI agents. The article originally appeared on InfoWorld. View the full article

The cybersecurity profession is on the verge of a sea change, and security pros must begin to master AI tools to combat emerging threats by building more autonomous, real-time protections. Expert panelists at a recent DTX conference session in Manchester, titled “Bot vs Bot: Surviving the Era of Autonomous Cyber Warfare,” highlighted how bringing AI into the security stack without weakening security fundamentals as become a security operations centre (SOC) essential. They also stressed the importance of maintaining human oversight over such systems. While powerful, AI technologies are no panacea for immature enterprise security architectures, and they can only be applied successfully after the fundamentals of cyber defence are well covered, multiple security practitioner panellists argued. This ground layer, they said, includes system hardening, patching, access control, monitoring, and the like. Darren Kimuli, information security lead at reinsurance firm Canopius Group, told delegates that AI deployments need to match the expectations of the business — including how an organisation meets its regulatory obligations. “I’m more concerned about what AI fits rather than what it replaces,” Kimuli said. Changing roles Divine Uzodinma, cybersecurity analyst at managed services and telecom vendor Radius, said AI systems help security analysts correlate and triage security logs, a traditionally labour-intensive task. “AI can analyse and correlate logs and triage alerts while analysts continue with their investigation,” Uzodinma said. Muhammad Khan, head of cybersecurity at Bridgewater Finance Group, added that AI-based security tools minimise alert fatigue — a perennial problem in the industry and a leading cause of staff burnout. The more widespread use of AI systems has meant that the role of security analysts has evolved beyond monitoring and response to “validating inputs” and assessing the risk of AI model hallucination. Enterprises need to test the resilience of AI-based security systems against modern attack paths, such as those found waged against applications and the cloud, as well as supplier access and phishing, according to cybersecurity consultancy Secarma. George Rees, senior cybersecurity consultant at Secarma, noted that AI is already redefining cyber rules in areas such as risk management and resilience. Cyber battle ground redrawn The DTX conference panel also discussed how autonomous attacker tooling is changing the threat landscape. The enterprise threat environment is evolving into a machine-versus-machine battle ground, meaning that CISOs and other security professionals need to drive change across their organizations or risk becoming hopelessly outflanked by adversaries who are making greater use of AI technologies to mount attacks. Moreover, there needs to be clarity on cyber team roles and oversight when automation is used to make decisions. Cyber job roles must be redefined to ensure humans can interpret and oversee autonomous security decisions, according to the panellists. These changing roles mean that skills such as prompt engineering and risk analysis are becoming more important for security professionals and hiring managers, according to Rees. “AI is creating opportunities for more GRC [governance, risk, and compliance] hires” because the skillset is well-suited to the new threat environment, Rees added. Rees compared the scope and pace of change heralded by AI to the period in the 1970s and 1980s when enterprises moved from reliance on typewriters to running a business using computers. The discussion was timely because enterprises are increasingly dealing with AI-accelerated reconnaissance, phishing, and malware development rather than purely human-led attacks. The debate has moved from whether to use AI in security to how to use it safely without losing oversight and control. Many of the responses by the DTX conference panellists showed an evolution in thinking since CSO polled security practitioners they are applying AI for security functions last September. Lessons from Microsoft’s war against scammers Kelly Bissell, a former corporate VP of product abuse and risk at Microsoft, who gave a keynote on cyber resilience and AI at the start of the DTX conference, told CSO after the show that an arms race is under way between cybersecurity professionals and attackers. “Early adopters — in general — have the advantage,” Bissell said. Here, according to Bissell, cybersecurity attackers gain an upper hand because they can ignore rules and regulations such as privacy laws, but defenders can claw back an edge on other fronts. “Because of the scale of data we handled at Microsoft we could use machine learning techniques to see behavioural trends,” Bissell explained. For example, Microsoft developed a neural network that was capable of identifying typosquatted domains being set up prior to impersonation attacks with very low false positive rates. “Our mission was to apply pressure to bot gangs” and frustrate their activity, Bissell said. According to Bissell, CISOs fall into one of three camps: compliance-orientated, package-focused, or elite practitioners. “Elite practitioners will love to use AI to improve their operations,” said Bissell, adding that AI technologies should be introduced through a process akin to a software development life cycle with extensive pen testing and guardrails prior to being left anywhere near production systems. View the full article

Microsoft says it is considering a patch for a zero-day vulnerability, dubbed YellowKey, that allows attackers with access to a Windows device to bypass Bitlocker encryption protection and read and write files. The flaw was disclosed last week, and there is already a public proof of concept available. The company issued an advisory Tuesday saying that companies should act to mitigate the issue, tracked as CVE-2026-45585, while it examines the possibility of a patch. In its advisory, it provided the immediate steps that companies should take. A key defense against possible attack is to limit access to vulnerable devices, as physical access is required for exploit. “Organizations should start by auditing their environment for the conditions that exist that leave them vulnerable to YellowKey,” said Eric Grenier, senior director analyst at Gartner. “They should also have a clear understanding of their risk acceptance in the case of a lost/stolen device and, based on that acceptance (or non-acceptance), follow the steps such as customizing Secure Boot and ensuring firmware and Boot integrity.” . Karl Fosaaen, VP of research at cybersecurity company NetSPI, agreed. “Since this vulnerability requires physical access to exploit, organizations should be focusing on the physical security controls around their Windows devices,” he said. “Having strong policies and controls around physical access to devices is a good first step in helping protect the potentially vulnerable devices. If there are additional concerns about attackers being able to gain access to files on the system, organizations can look at limiting the data that they allow users to store locally.” One of the issues facing companies is the proliferation of employees using mobile devices, which makes it harder for organizations to restrict access to them. “You’re increasingly seeing companies with corporate data on their laptops, and YellowKey can leave that data unlocked,” said Nathan Davies-Webb, principal consultant at UK-based security company Acumen. This is where tight device security policies come into play, such as prohibiting users from leaving devices unattended. However, said Fosaaen, what makes detection of an attack particularly difficult for the individual user is that it is not immediately apparent that a device has been targeted. “If an attacker used the exploit to read files from the encrypted volume, there likely wouldn’t be any indicators to a user. If the attacker implanted malicious software, you might see increased system utilization, or other performance issues,” he noted. To make things worse, it is also possible that Microsoft’s mitigation guidance may not be effective. In a post on a security site, researcher Will Dormann pointed out that there could be a way to override the company’s proposed solution. That being the case, IT managers will certainly be watching for a patch from Microsoft. While Microsoft has announced that it is looking into such a patch, Davies-Webb doesn’t think a solution will be straightforward. “I would heavily speculate that this is something that is there by design,” he said. “Microsoft would be thinking ‘If I stop this happening, what would I be taking away?’ I strongly suspect that there is some functionality in Windows, maybe something in manufacturing, that could be affected by any patch.” “Besides,” he added, “It could take some time for a patch to be released. The RedSun vulnerability [in Windows Defender] was identified last month and still hasn’t been patched.” This article originally appeared on Computerworld. View the full article

Administrators of the Drupal open source content management platform are rushing to install an emergency patch issued today to fix a “highly critical” SQL injection vulnerability in the application’s core. While the vulnerability only affects websites that use the PostgreSQL database, there may be upstream issues with Symfony, a set of PHP packages and web application frameworks used by Drupal, and Twig, an open-source template engine for the PHP programming language. Consequently, Twig was updated to version 3.26.0, and Symfony issued a series of security advisories. As a result, Drupal urges admins using these applications to update them as well, whether or not the SQL injection vulnerability affects their systems. Helpfully, the Drupal fix issued today includes updates for both Symfony and Twig. The vulnerability in Drupal’s core, CVE-2026-9082, is in a database abstraction API that ensures queries against the database are sanitized to prevent SQL injection attacks. In its warning, Drupal said a vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL injection for sites using PostgreSQL databases. This can lead to information disclosure, and, in some cases, privilege escalation, remote code execution (RCE), or other attacks. The vulnerability can be exploited by anonymous users. Drupal admins have known since Monday that the core security release for all supported branches was coming. Drupal Security Team had urged admins to reserve time for the updates on May 20 “because exploits might be developed within hours or days.” The Drupal patches cover supported branches 11.3, 11.2, 10.6, and 10.5. After installing the patch, admins should update to a newer version of the software. Versions below 11.1.x, 11.0.x and 10.4.x are end of life, and are ineligible for the official fixes. However, because of the flaw’s severity, Drupal will shortly issue unsupported patches which are provided as best effort. Users of any version of Drupal 9 can try manually applying the Drupal 9.5 patch. Users of Drupal 8.9 can try manually applying the Drupal 8.9 patch. But those unsupported versions will still contain other previously disclosed security vulnerabilities. Drupal 7 isn’t affected. Sites that use the Drupal Steward web application firewall are already protected from known attack vectors, but should upgrade in the near future in case additional attack vectors are discovered, the company said. “That’s a nasty vulnerability,” commented Robert Enderle, a consultant who heads the Enderle Group. “It’s about as bad as it sounds.” Drupal admins must patch right now, he said. Update Drupal Core immediately, based on the currently supported branch. Those who are “still dragging their feet” on unsupported, end-of-life Drupal versions 8 or 9 need to apply the manual best-effort patches provided. Better yet, he added, they should prioritize migrating to a modern version of Drupal as soon as possible. “Don’t ignore it if you aren’t on PostgreSQL,” Enderle stressed. “Even if IT is running MySQL or SQLite and thinks they are safe from the main [Drupal] bug, they still must apply the update. This release includes critical upstream security fixes for Symfony and Twig dependencies that affect all environments.” In addition, he said, admins need to lock down access permissions. Because of the Twig vulnerabilities, IT needs to audit who actually has the ability to update Twig templates via Views or other modules and restrict that access to trusted admins only. Enderle also urged admins to examine their PostgreSQL and web application firewall logs for “any weird anonymous user activity or suspicious SQL queries leading up to this patch.” Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, agreed that Drupal admins need to act immediately, because the vulnerability can be exploited by anyone with the technical knowledge to send a specially crafted query to a Postgres database, since Drupal databases can contain sensitive personal information that can be exploited by a threat actor. It’s also frustrating, he said, that SQL injection vulnerabilities are still being found. “As an industry, we’re running out of excuses” for why they continue to pop up in applications, he said. This and similar SQL injection vulnerabilities speak to weaknesses in the application development lifecycles of some organizations. View the full article

Microsoft’s GitHub has suffered what appears to be its biggest ever security breach after confirming that attackers exfiltrated code from around 3,800 of the company’s internal repositories. News of the incident first emerged on May 19, when GitHub said it was investigating “unauthorized access.” Hours later, the company’s X account confirmed the worst: “Yesterday we detected and contained a compromise of an employee device involving a poisoned VS [Visual Studio] Code extension. We removed the malicious extension version, isolated the endpoint, and began incident response immediately,” GitHub said. “Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker’s current claims of ~3,800 repositories are directionally consistent with our investigation so far.” GitHub added: “We continue to analyze logs, validate secret rotation, and monitor for any follow-on activity. We will take additional action as the investigation warrants.” The company promised to publish a full incident report once it had completed its investigations. That figure tallied with an earlier claim by the TeamPCP threat group that it had breached 4,000 repos, complete with a threat to leak the stolen code if no buyer willing to pay at least “50k” was found. The group backed up its claim by posting a list of the breached repositories on the LimeWire content sharing platform. “As always this is not a ransom, we do not care about extorting Github, 1 buyer and we shred the data on our end, it looks like our retirement is soon so if no buyer is found we will leak it free,” the group said. GitHub hasn’t named the poisoned VS Code extension that led to the compromise, but security company Akido Security speculated that there might be a connection to a separate TeamPCP attack, also on May 19, that led to the backdooring of the popular Nx Console VS Code extension. “The malicious version collected credentials silently from the moment a developer opened any workspace. The community, including Aikido Intel, caught it quickly, with the version pulled within 11 minutes,” wrote Akido’s technical product marketer Shaun Brown. Nx Console’s advisory put the exposure window for the compromised version 18.95.0 at 18 minutes, advising developers to update to version 18.100.0. According to the maintainers’ internal analytics, thousands of developers were caught out by the infected version. File paths targeted by attackers to steal credentials included Kubernetes, npm, AWS, 1Password, private keys, and GitHub. The same May 19 campaign led to a major supply chain compromise of the node package manager (npm) open-source registry which resulted in attackers publishing 637 malicious versions across the namespace of the AntV enterprise data visualization tool in a 22-minute burst. That came after a May 11 attack targeting the TanStack Router package ecosystem was able to spew 170 malware-infected versions before it was halted. “These are not sketchy packages and extensions from unknown publishers. They are tools developers use without thinking twice, precisely because it has the install count, the verified publisher badge, and the marketplace legitimacy that signal safety,” said Brown. “High install count means high-value compromise. A verified publisher means developers don’t hesitate. Official marketplace means no one thinks to check.” The TeamPCP modus operandi is simple: exploit platform updating weaknesses or stolen credentials to execute short, sharp worm attacks that burrow as far as possible into enterprises using open-source software before defenders can react. As the number of incidents starts to grow — including a March TeamPCP attack on the Trivy vulnerability scanner, and a separate attack on the Axios npm JavaScript HTTP client library — the evidence is that the strategy of targeting open source developer tools is rapidly turning into the next big security headache. This article first appeared on InfoWorld. View the full article

A newly disclosed macOS infostealer campaign is exploiting user trust in some of the biggest names in tech to slip past defenses. Researchers at SentinelOne have detailed a new variant of the SHub malware family, dubbed “Reaper,” that impersonates Apple, Google, and Microsoft at different stages of a single attack chain targeting Mac users. The SHub stealer family, identified two years back, previously used variants relying on fake installers and ClickFix-style social engineering, often prompting victims to paste commands into Terminal. Reaper changes tactics by moving execution into Apple’s Script Editor, sidestepping the protections Apple recently introduced to curb Terminal-based attacks. The end goal, however, remains credential theft, wallet compromise, and persistent access. “The SHub Reaper variant represents a noteworthy evolution in macOS infostealers by shifting away from standard social engineering tactics that require victims to manually paste commands into the Terminal,” said Jason Soroko, senior fellow at Sectigo. “This approach lowers the technical barrier for infection and demonstrates a strategic pivot toward abusing native application handlers rather than relying purely on user error.” Fake Apple updates run hidden AppleScript The attack starts with users pulled onto malicious websites displaying fake Apple security alerts. The pages then initiate a ClickFix workflow by instructing users to launch a supposed fix through the Script Editor, instead of the Terminal. Rather than getting the user to copy and paste shell commands like earlier, Reaper now abuses the applescript:// URI handler to pre-populate malicious AppleScript inside Script Editor. The victim is then socially engineered, through the ClickFix, into running the script themselves. So the victims are still executing the malware themselves, but just can’t see it anymore. SentinelOne researchers noted the malware also performs several environment and anti-analysis checks before continuing execution. Once active, the malware deploys additional payloads and establishes persistence through LaunchAgents posing as legitimate vendor files. “Defenders should shift macOS detection from file signatures to behavior, because Reaper executes through legitimate Apple tools and drops no obvious malicious app for a scanner to catch,” said Collin Hogue-Spears, senior director of solution management at Black Duck. “Script Editor, osascript, and a LaunchAgent are all legitimate software.” The multi-brand deception Researchers observed the malware using branding associated with multiple technology companies throughout the attack chain. Apple-themed security warnings lure victims into initiating execution, Google-related interfaces help maintain legitimacy during later stages, while Microsoft-themed domains and infrastructure are used elsewhere in the operation. “Reaper uses fake WeChat and Miro installers as lures, but what stands out is the way the infection chain shifts its disguise at each stage,” the researchers said in a blog post. “The payload may be hosted on a typo-squatted Microsoft domain, executed under the guise of an Apple security update, and persist from a fake Google Software Update directory.” Once execution succeeds, Reaper starts harvesting sensitive user data. SentinelOne said the malware targets browser credentials, password managers, Keychain data, cryptocurrency wallets such as MetaMask and Phantom, messaging applications, and user documents. Protection beyond blocking Terminal-pastes SHub Reaper campaign’s complete abandonment of the traditional Terminal-centric infection flow appears to be tied to Apple’s recent efforts to crack down on Terminal paste abuse. In macOS Tahoe 26.4, Apple introduced protections that display warnings when users attempt to paste potentially dangerous commands into Terminal, directly targeting the social engineering methods widely abused in ClickFix-style attacks. “This is not an Apple security failure,” Hogue-spears said. “It is Apple’s fix working exactly as intended. The fix raised the cost of one technique; so the crew switched to another.” Apple did not immediately respond to CSO’s request for comments. SentinelOne researchers recommended that defenders monitor for unusual Script Editor activity and investigate where “osascript” or AppleScript-related processes spawn unexpected processes or initiate outbound network connections. They also advised organizations to watch for suspicious LaunchAgent persistence mechanisms posing as legitimate Apple, Google or Microsoft components. Additionally, Soroko suggested network-based protections. “Security teams should implement strict web filtering to intercept typo-squatted domains and monitor for anomalous invocations of the macOS Script Editor triggered directly by web browsers,” he said. View the full article

On April 22, for roughly 90 minutes, a malicious version of Bitwarden CLI appeared on npm. Version 2026.4.0 contained a credential-stealing payload that executed an obfuscated loader and harvested AWS, Azure, GCP, GitHub, and npm tokens from any developer machine that ran npm install. The attackers reached Bitwarden’s npm publishing path through a compromised GitHub Action related to the Checkmarx supply chain incident that affected several other downstream consumers that week. About nine days later, CVE-2026-42994 was issued by Bitwarden for the trojanized version. Defenders running a software composition analysis tool began seeing it on their dashboard. Detection engineers started writing rules. The incident got a writeup, an entry in someone’s threat intelligence feed, and a row in next quarter’s metrics deck. Notice what CVE actually does, though. It doesn’t tell anyone to patch a flaw. The flaw was a 90-minute window in which a publishing pipeline was compromised, and the window has closed. The CVE is a retroactive notification. Meaning, if you ran npm install during that window, treat your developer credentials as exposed. That’s incident response, not vulnerability tracking. This is the system functioning by 2026 standards. That’s a long way from what CVE was built to do. The drift CVE launched in 1999 as a vulnerability identifier. The original definition was tight: a flaw in a system that violates a security policy, with a fix that defenders can apply against a known version range. Heartbleed in OpenSSL 1.0.1f. The deserialization flaws in Apache Struts. Patch the version, scan to verify, dashboard turns green. MITRE and CNAs began stretching the framework almost immediately. The SolarWinds incident of 2020 got CVE-2020-10148, but the “vulnerability” was a backdoor inserted into a signed update, not a code flaw the maintainer wrote. node-ipc/peacenotwar in 2022 got CVE-2022-23812 for protestware that wiped files based on geolocation. The fix in both cases was “remove the bad version,” not a patch to a defective component. The identifier still worked, but it was no longer doing the job it was designed for. CVE was now tracking incidents rather than defects in code. Attacks like s1ngularity and Shai-Hulud broke the stretch. The self-propagating npm worm that emerged in September 2025 and returned in escalating variants through 2026 infected hundreds of packages across the ecosystem. Some affected versions got CVEs, but most didn’t. Red Hat’s advisory on the campaign acknowledged the obvious: “due to the unprecedented number of impacted organizations and individuals, it is unlikely that all package infections will be assigned CVE identifiers.” Interestingly, the Bitwarden compromise from late April is itself a Shai-Hulud variant, with the string “Shai-Hulud: The Third Coming” embedded in the malicious payload. It got a CVE because it’s one identifiable package with one identifiable bad version. The 700-plus packages from earlier waves of the same campaign mostly didn’t. Vendors also quietly fix things without disclosure. A researcher’s report gets closed as informative, the issue ships in the next release as a “hardening improvement” or better yet “security enhancement” (not a fix). No CVE is requested. Sometimes that’s reasonable — not always. Either way, no defender’s tooling sees it, and AI is making it worse. What agents do to all of this The category that breaks the framework most clearly is the one with no existing identifier scheme to begin with. Skills, MCP servers, and the wider scaffolding around AI agents have several properties the CVE framework was never designed to handle. They mutate at runtime. The operative payload is often a natural language instruction that an agent reads and executes, meaning agentic assets don’t always have stable identities. They get pulled from public registries but also shared via Slack or forked from a repo that looked official three months ago. The harm doesn’t map to any existing weakness category. For example, a skill called derp on the skills.sh registry illustrates the problem. It contains zero traditional malware indicators. No network calls, base64 blobs, or credential paths. The SKILL.md instructs Claude to deliberately produce broken code, then offer broken fixes in a loop, while hiding the fact that it’s doing so. A CVE has nothing to point at. No memory corruption, authentication bypass, or a CVSS vector. The harm, however, is real — wasted hours, eroded trust in the agent, an inflated bill for compute/tokens — but it’s behavioral. A scanner looking for malicious patterns will not catch it. derp is small, but structurally identical attacks aren’t. In my research at Manifold Security this April, we identified the ClawSwarm campaign which catalogs 30 skills published by a single ClawHub author. Some of these include utilities like Cron Helper (903 downloads) and Agent Security (685 downloads) that quietly enroll the user’s AI agent into a third-party network. Install one, and the agent registers itself with an external server, reports its capabilities, generates a Hedera crypto wallet, stores credentials on disk, and polls for tasks every four hours. The skills work. They also recruit the agent into someone else’s economy without the operator’s knowledge. What’s the CVE for that? These skills aren’t malware in any traditional sense. The HTTPS calls are documented. The wallet generation uses a legitimate SDK. There’s no shellcode to flag or a known C2 to block. Even if a registry pulls the campaign, the same pattern can reappear under a different author with a different filename in a week. The artifact-centric model has nothing to grip. Frontier model vendors face a variation of the problem. They do version their releases (Sonnet 4.6, Opus 4.7, GPT-5.1, and so on) but security fixes aren’t always pronounced within release notes. The vulnerability that worked on yesterday’s model and fails on today’s gets bundled into a capability update or new “safeguards” with no security delta called out, no advisory, and often no version bump at all when the change is to a system prompt or classifier rather than the model itself. A recent academic survey of 295 GitHub Security Advisories that referenced LLM-related components found that existing CWE metadata captures code-level defects but systematically underrepresents model-mediated exposure, the cases where the vulnerability is triggered or amplified through model reasoning rather than a flaw in the surrounding code. As the authors put it: “Current GHSA metadata lacks structured indicators of LLM involvement, requiring manual classification to identify model-mediated exposure patterns.” CVE-2025-68664 in LangChain Core, a deserialization flaw triggerable through prompt-influenced metadata, is a rare case that did make it into the system, but most don’t. A prompt injection technique that lets an attacker exfiltrate tool-call outputs from an agent could get fixed in the next model checkpoint, surface in a research paper six months later, and never appear on any dashboard. Both are exploitable, but only one is being tracked. What a workable signal layer looks like CVE still does its job for what it was designed for. But the assumptions underneath the framework — stable identity, fixed content, coordinated disclosure, vendor advisories — don’t hold for a meaningful and growing share of the agent attack surface. A workable signal layer for this category probably needs three things the current system lacks. Behavioral identifiers rather than artifact identifiers: If a skill that instructs an agent to exfiltrate environment variables gets removed and the same instruction shows up tomorrow under a different author with a different filename, the relevant identifier is the behavior, not the SHA. Fingerprinting what an agent actually does — what data flows where, what external services it enrolls itself with, what tool calls it makes on a user’s behalf — gives you something durable to track even when the upstream artifact is ephemeral. Registry transparency for takedowns: When npm removes a package, there’s a paper trail. When a Skills registry removes a publisher, there often isn’t. The ecosystem will mature on this front, but enterprise consumers should be pushing for it now rather than waiting. Responsible disclosure, but for vendors: We need an honest accounting from vendors about what they fix and ship silently, including model vendors. I’m not optimistic about this one in the short term. Commercial incentives point the wrong way, and customer pressure (and then some from bug bounty hunters) is what tends to move vendors here. The dashboard you have was built for the threats you had The vulnerability tracking system was built around an artifact-centric model. It still pulls its weight for the threats it was designed for. The Bitwarden CVE landed on dashboards across the industry. So will the next one. What won’t land is a skill pulled from a registry with no advisory. Or a model checkpoint that quietly resists a prompt injection it used to fall for. Or your agent, already enrolled in someone else’s network because a SKILL.md told it to. If you run a security program in 2026, your dashboard is increasingly an incomplete picture. The things that will get you are not always the things on it. Knowing what your tools actually watch, and what they’ve stopped watching, is where the work starts. View the full article

Microsoft has disrupted the infrastructure powering the largest malware code-signing service used to help ransomware groups and other cybercriminals make malicious programs harder to detect on Windows. The threat actors behind the service used stolen identities and impersonated legitimate organizations to obtain more than 1,000 code-signing certificates. Microsoft seized the group’s website, signspace[.]cloud, revoked the abused certificates, which were obtained through its Artifact Signing service, and took offline hundreds of virtual machines set up by the attackers on Azure. Cybercriminals paid between $5,000 and $9,000 to use the malware signing as a service (MSaaS), highlighting its effectiveness. Microsoft’s researchers have established clear links between the group running this operation, which it calls Fox Tempest, and ransomware affiliates who worked with gangs such as INC, Qilin, Akira, and Rhysida. One ransomware group tracked as Vanilla Tempest used the code-signing service to create malcious installers for common enterprise software, such as AnyDesk, Microsoft Teams, Putty, and Webex. These fake but digitally signed installers were distributed via SEO poisoning and malvertising and were used to deploy a variety of backdoors, infostealers, and ransomware programs. “This case points to how cybercrime is changing,” Steven Masada, assistant general counsel with Microsoft’s Digital Crimes Unit, said in a blog post. “What once required a single group to carry out an attack from start to finish is now broken into a modular ecosystem where services are bought and sold and work interchangeably with one another. Some services are inexpensive and widely used. Others, like Fox Tempest, are highly specialized and expensive because they remove friction or bypass obstacles that make attacks fail, making them both more reliable and harder to detect.” Code signing at scale The value of digitally signing executable files is that Microsoft Defender SmartScreen will display weaker warnings for downloaded files, or no warning at all if the file has built up a clean reputation over time. For attacks that rely on users executing rogue installers that masquerade as popular applications, having no scary warnings is a big advantage. For a digital signature to be valid, it needs to be created by a code-signing certificate that was issued by one of the trusted Certificate Authorities in the Windows Trust Store. Microsoft offers such a service under Azure called Artifact Signing through which developers can obtain short-lived certificates for their applications, but this process requires identity verification. Fox Tempest likely used stolen identities to pass the verification process and created hundreds of Azure accounts and tenants for use in its operation. The group then built its service on top of these subscriptions and provided code-signing services to the cybercrime ecosystem since at least May 2025. More recently the group started providing preconfigured VMs hosted on a VPS provider that enabled threat actors to upload malicious files directly and receive signed binaries in return. “Illicit code-signing certificates have been sold and trafficked for more than a decade,” Masada said. “That includes its use by nation-state actors to target critical infrastructure organizations in Europe. What’s changed is how this activity is marketed, packaged, and sold as a service, along with the scale at which it is now used across ransomware campaigns. Instead of buying certificates one-by-one, criminals upload their malware to a service that signs it for them.” View the full article

Until a few days ago, a publicly-accessible GitHub repository exposed credentials for both US government AWS accounts and internal Cybersecurity and Infrastructure Security Agency (CISA) systems. That’s according to cybersecurity reporter Brian Krebs, who first broke the news over the weekend, acting on a tip from researcher Guillaume Valadon at GitGuardian. Valadon confirmed the information in an email interview with CSO. Based on the repository’s commit history and the account creator’s own troubleshooting notes, committed back into the repo, Valadon believes the repository was run by a CISA contractor who created it on his personal GitHub account. “This is a serious breach of security controls, because secrets are stored in plain text and committed to Git instead of being fetched from a secret manager at runtime,” he wrote, “and because internal documents meant to remain private were pushed to a public repository inside a personal developer account.” GitGuardian is a French-based service whose products scan internal and external sources, including GitHub, for exposed secrets. On May 14, it found a public GitHub repository named “Private-CISA.” The repository, which had been live since November 13, 2025, contained 844 MB of data, including Kubernetes files, GitHub Actions workflows, internal documentation backups, personal documents and operational scripts, plain-text passwords, AWS tokens, and GitHub access tokens. The good news: GitHub events data indicates the repository was never forked, Valadon said, “which limited the blast radius.” The bad news: The owner of the account didn’t reply immediately to Valadon’s warning message, which is why he went to Krebs. Valadon also reported the leak to the US-based Computer Emergency Response Team Coordination Center (CERT/CC) on May 14, and the next day reached out to CISA. The repository was offline that night. “I must credit them [CISA] for deleting this repository quickly,” Valadon said. “Most of our responsible disclosures take much longer, and many are never fixed. Managing to take the repository offline in a day is impressive work.” “I worked nine years at ANSSI [France’s equivalent to CISA],” Valadon added, “and now, dealing with leaks daily at GitGuardian, this is definitely one of the worst I have ever seen.” Based on the account’s data, Krebs believes it was run by a Washington, DC area cybersecurity firm contracted by CISA. The company wouldn’t confirm that when CSO asked for comment, instead referring questions to CISA. Asked for comment, a CISA spokesperson said in an email that the agency is aware of the reported exposure and is continuing to investigate the situation. “Currently, there is no indication that any sensitive data was compromised as a result of this incident,” they wrote. “While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.” There are many serious security problems with GitHub repositories, ranging from fake repositories created by threat actors to legitimate accounts that are wrongly created with public access. And last month, researchers at Wiz uncovered an injection vulnerability in the internal git infrastructure that could have enabled hackers to execute arbitrary commands on GitHub’s backend servers. In the current case, the problem is human; GitHub repositories can contain a range of secrets, such as tokens and credentials included by account creators, which is why users need to implement GitHub’s extensive protections and security best practices, including limiting access to the repository. Related content: GitHub accounts targeted with fake security alerts What CSOs and CIOs should do Exposing secrets on GitHub “is a serious and sadly common problem,” commented Johannes Ullrich, dean of research at the SANS Institute. But, he added, there are several steps IT can take to prevent this. First, secrets such as passwords and API keys must be centrally managed. An enterprise-wide secret management process isn’t easy to implement, he acknowledged, “but it is also your best bet to avoid secrets from being handled inappropriately.” Second, use tools that proactively scan user systems and public services such as GitHub for exposed keys. “These products are essential to enforce any policy governing the secure handling of secrets,” Ullrich said. “In this particular case, the fault appears to have been with a contractor, not CISA itself,” he noted. “Managing vendor relationships is important and must include agreements on how to handle secrets used to access internal systems and data.” Veteran consultant Robert Enderle of the Enderle Group noted that this kind of exposure happens with alarming frequency. “Developers are often under immense pressure to deliver code quickly,” he said, “and the lines between personal and professional repositories can easily blur. However, for a contractor tied to CISA — the very agency tasked with defending our national infrastructure — the potential fallout is catastrophic. Leaving credentials exposed in a public GitHub repository is akin to leaving the master keys to the nation’s cyber defenses on a public park bench. Had those credentials been leveraged by a nation-state actor, it could have facilitated a massive supply chain attack or deep infiltration into critical government systems.” To mitigate that potential, CSOs and CIOs must stop relying on policy alone and implement robust, automated governance, Enderle said. “You cannot expect humans not to make mistakes; you have to build systems that catch them,” he said. This means mandating automated secret scanning tools that actively block commits containing credentials or API keys before they ever hit a repository. Enterprises also need to enforce strict separation between personal and professional developer environments, mandate multi-factor authentication (MFA) across the board, and embrace a zero trust architecture that assumes credentials will eventually be compromised, he said. Valadon added that CSOs and CIOs should perform full secret scanning on all internal repositories, not just public GitHub accounts, block secrets before they reach the repository, use short-lived credentials wherever possible, deploy honeytokens, such as fake passwords that would trick curious attackers, in sensitive repositories, and inventory where their organization’s code actually lives, including checking whether it’s in employees’ and contractors’ personal GitHub accounts. View the full article

The world’s largest open-source registry, node package manager (npm), has been hit by another fast-moving malware attack, this time targeting the widely-used AntV enterprise data visualization tool. Unlike last week’s high-profile npm attack on TanStack, which exploited a complex GitHub Actions cache poisoning weakness, the latest incident early on May 19 took the more conventional route of compromising the credentials of a high-value npm maintainer account. According to analysis by SafeDep, the account in question, atool ([email protected]), which publishes the timeago.js JavaScript library, had rights to a large catalog of packages, including popular tools such as size-sensor (4.2 million downloads per month), echarts-for-react (3.8 million), @antv/scale (2.2 million), and timeago.js (1.15 million). This privilege level allowed the attacker to publish at least 637 malicious versions across 317 different npm packages in a single 22-minute burst. This resulted in the compromise of a big chunk of Alibaba’s AntV namespace, a growing platform across Asia, the US, and Europe used to build dashboards, user interfaces, and interactive applications. Attacks on the npm supply chain this year plot a challenging trend, said Aikido Security in its analysis. “This is the third major wave we have tracked. It went from a handful of SAP packages in April, to 169 packages in the TanStack wave, to a much larger set of packages now. Each wave has been faster and broader than the last.” “Here We Go Again” Anyone unlucky enough to be infected by one of the malicious packages will find themselves on the receiving end of the potent Mini-Shai-Hulud worm, the source code for which was recently briefly released to other criminals on GitHub. Its purpose is to steal npm and GitHub tokens, as well as credentials from 130 file paths, including multiple cloud platforms, Kubernetes, Docker, Hashicorp, password vaults, SSH keys, and Bitcoin wallets. For unknown reasons, the attackers then use stolen CI/CD tokens to store exfiltrated data in public GitHub repositories themed on the science fiction novel Dune, which, within hours of this attack, grew to 2,500 in number. Each repository description contains the string “niagA oG eW ereH :duluH-iahS” (“Shai-Hulud: Here We Go Again” backwards). In theory, the malware is also capable of persistence via a Python-based backdoor installed at ~/.local/share/kitty/cat.py, although according to security company Wiz, this function doesn’t yet seem to be active. The group behind the campaign, TeamPCP, doesn’t lack for ambition: the malware even tries to modify Claude Code’s settings.json, which allows the malware to be stealthily reinstated with full LLM privileges in case the infected npm packages have been removed. Next steps After the attack was detected, AntV’s maintainers issued the following warning on GitHub: “Due to the impact of an external worm attack, AntV-related npm packages have been compromised. The infected packages have been deleted, while the remaining ones have been marked as deprecated,” it read. “Users are advised to carefully identify and download the latest versions. AntV is actively contacting the npm registry to have the deprecated packages removed.” In other words, while malicious versions have been deleted, remaining packages should be treated with extreme caution, providing an incentive for developers to audit and move to known safe versions. Because the attack infected multiple versions of the same library, establishing a known safe version will be perilous. Developers can consult a list of compromised packages (published by SafeDep as a .csv), although it’s safe to assume that if any version of the AntV library is in use, infection is a possibility. Beyond that, recommended actions are to look for signs of compromise in CI/CD environments and repositories, and to rotate all credentials. But the most important advice from experts is much simpler: strengthen defenses against future attacks targeting npm by improving monitoring and package verification. This article originally appeared on InfoWorld. View the full article

Faced with the growing volume of submission to its bug bounty program, GitHub is replacing cash bounties with swag rewards for reports with low security impact — and asking researchers to stop submitting reports that are low quality or about things that aren’t its fault. The cloud-based code repository platform has seen a sharp increase in submissions that don’t demonstrate real security impact over the past year due to newer tools such as generative AI. “Not every valid submission represents a meaningful security risk. Some reports identify hardening opportunities or documentation gaps,” Jarom Brown, a senior security researcher at GitHub, wrote in a blog post. On top of that, he said, many of the reports GitHub receives describe out-of-scope scenarios in which someone experiences an “undesirable” outcome after interacting with malicious content in GitHub. “These reports are often well-written and technically accurate in their observations, but they misunderstand where the security boundary lies. When an ‘attack’ requires the victim to actively seek out and engage with attacker-controlled content (cloning a malicious repo, asking an AI tool to analyze untrusted code, opening a crafted file), the security boundary is the user’s decision to trust that content. These scenarios generally don’t represent a bypass of GitHub’s security controls,” he wrote. Brown’s explanation also serves as a reminder to GitHub users of what the company expects them to do to protect themselves. Although artificial intelligence has swollen the flood of bug reports, GitHub doesn’t want security researchers to stop using it. “We have no problem with researchers using AI tools. AI is a force multiplier, and we expect it to play an increasing role in security research. We use AI across our own internal security programs, and we’re seeing the best external researchers do the same. We welcome it,” Brown wrote. But all AI-generated submissions must be reviewed and validated by a human first —a rule that has applied to the use of any tool to help with bug hunting. In this way, GitHub hopes to screen out reports without a proof of concept, theoretical attack scenarios that don’t hold up under scrutiny, and others covered by its published list of those ineligible for rewards. AI-generated noise is an industry problem GitHub isn’t the only bug bounty provider struggling with the volume of submissions — although not all are as welcoming of AI. Security vendors, open-source maintainers, and bug bounty platforms across the industry, analysts warned, have increasingly complained about a flood of low-quality, AI-assisted vulnerability reports that consume analyst time, slow incident response, and make it harder to identify legitimate threats amid growing volumes of automated noise. Open-source project Curl has eliminated its bug bounty due to AI slop, and HackerOne paused payouts form its Internet Bug Bounty program because it couldn’t keep up with AI submissions. The Google Open-Source Software Vulnerability Reward Program is also restricting payouts. And Linux creator Linus Torvalds recently warned that a “continued flood” of AI-generated vulnerability reports had made the Linux kernel security mailing list “almost entirely unmanageable” because of massive duplication from researchers using the same AI tools to find identical bugs. Cutting off the security talent pipeline Pareekh Jain, principal analyst at Pareekh Consulting, said GitHub’s switch from cash payouts to swag could reduce participation from new and independent researchers, many of whom rely on rewards from smaller findings to build credibility, sharpen their skills, and sustain their work financially. That decline in participation at the lower end of the ecosystem could have longer-term consequences for the cybersecurity talent pipeline if fewer newcomers see bug bounty hunting as a viable path to learn, contribute, and grow within the security community, said Akshat Tyagi, associate practice leader at HFS Research. On the flip side though, Tyagi pointed out that the move could be positive for experienced researchers: “Less queue noise means faster triage, faster payouts, and more program credibility.” An open door, but not for everyone Greyhound Research chief analyst Sanchit Vir Gogia expects platforms such as GitHub to respond to the AI deluge by introducing more explicit trust controls to contribution workflows. “Some will be visible: permissions, rate limits, templates, identity verification, reputation scoring. Others will be less visible: ranking systems, automated pre-triage, AI-origin signals, behavioral scoring, and quiet prioritization of known-good contributors,” he said. And Jain suggested GitHub could apply its recently introduced Stacked PRs code review tool to its bug bounty program. “Just like stacked PRs help developers review AI-generated code in smaller and more structured chunks, bug bounty platforms may introduce more structured vulnerability submissions with automated validation, reproducible exploit steps, deduplication, and AI-assisted triage,” he said. “Security reporting could start looking more like a CI/CD workflow instead of long text-based reports.” View the full article

Microsoft’s aging “mshta.exe” utility, a leftover component from Internet Explorer, is still being actively abused in modern malware campaigns years after the browser itself was retired. According to new research from Bitdefender, attackers continue to abuse Microsoft HTML Application Host (MSHTA), a built-in Windows utility capable of executing VBScript and JavaScript from local or remote files. Despite Internet Explorer reaching the end of life in 2022, MSHTA is packaged by default on Windows systems and is used as a living-off-the-land (LOLBIN) binary to launch malware. “Even when companies retire legacy products, parts of their ecosystem can persist in Windows for years to support older workflows and enterprise compatibility requirements,” the researchers explained in a blog post. “Threat actors frequently abuse trusted, preinstalled Windows binaries to execute malicious content while relying on software already present on the system.” Microsoft did not immediately comment on the issue. Bitdefender researchers observed MSHTA appearing across infection chains associated with commodity stealers such as LummaStealer and Amatera, multi-stage loaders like CountLoader and Emmenhtal Loader, banking trojans including ClipBanker, and even the long-running PurpleFox malware family. Infections through fake CAPTCHAs, updates One of the most active clusters analyzed by Bitdefender involved CountLoader, an HTA-based loader that used MSHTA to deliver infections with LummaStealer and Amatera. Attackers relied on fake software downloads, cracked applications, SEO-poisoned websites, and social engineering to lure victims into executing malicious payloads. Victims downloaded password-protected archives containing legitimate-looking installers. But clicking through them executed a legitimate Python interpreter bundled with malicious scripts that ultimately launched a renamed copy of mshta.exe. The binary then contacted a C2 infrastructure hosting HTA payloads for next-stage malware retrieval. “Starting in late February 2026, we observed a new CountLoader domain-hosting pattern,” the researchers noted. “The naming convention remained similar, using domains that imitate legitimate service names, but the infrastructure shifted to .vg and .gl TLDs. Examples include explorer[.]vg, ccleaner[.]gl, and microservice[.]gl.” Threat actors also ran Emmenhtal Loader campaigns that abused fake CAPTCHA verification pages distributed through Discord phishing messages. Victims were tricked into copying malicious commands into the Windows Run dialog under the pretext of “prove you are human”. MSHTA executed obfuscated HTA payloads in memory before launching PowerShell to fetch additional malware, ultimately delivering LummaStealer in one analyzed case. A legacy Windows tool that refuses to die Bitdefender’s findings suggest MSHTA remains attractive because it checks several boxes attackers like. These include it being Microsoft-signed, preinstalled on Windows, capable of in-memory execution, and still implicitly trusted in many environments. Other sophisticated campaigns picked it up too. Bitdefender detailed PurpleFox using MSHTA to launch ‘msiexec’ commands that downloaded MSI payloads posing as PNG images from remote IP addresses. PurpleFox, once installed, operates as a rootkit-enabled backdoor capable of persistence, surveillance, information theft, and distributed denial-of-service (DOS) activity. Elsewhere, ClipBanker campaigns used HTA loaders to execute Base64-encoded PowerShell commands that established persistence through scheduled tasks posing as legitimate Windows services. The malware ultimately hijacked cryptocurrency wallet addresses copied to victims’ clipboards. Bitdefender cautioned that not every MSHTA execution is inherently malicious. “ A significant portion of detections came from the update mechanism of DriverPack, an older software package that downloads driver files from third-party sources rather than through official Microsoft update channels,” the researchers pointed out. Still, they argued the balance has clearly shifted toward abuse. View the full article

Despite strong and redundant defenses, enterprises remain vulnerable to a wide range of cyberattacks. And because attacks — and cyber incidents — are inevitable, developing an incident response and recovery process that’s quick, comprehensive, and coordinated is essential. Expediting incident recovery time is critical because the longer an outage persists, the more costs, risk, and business disruption issues will compound, says Sharon Chand, US cyber defense and resilience leader at professional services firm Deloitte. “AI-driven attacks accelerate adversary actions and adaptation, so a slow recovery increases the window for re-compromise,” she adds, warning that extended outages can create cascading failures across interdependent internal and third-party systems. Additionally, manual work-arounds deployed during and after an attack can threaten data integrity and increase compliance risk. “Internally, a prolonged ‘war room’ recovery strains the entire cyber workforce, raising burnout issues, error rates, and attrition, ultimately making future incidents even harder to handle,” she explains. Are you doing all you can to minimize incident recovery time? Here are seven tips for accelerating incident recovery and keeping your enterprise secure. Sharpen your incident response team’s skills and coordination A well-defined and well-prepped incident response team is essential to ensuring quick recovery from a cyber incident, says Chris Hill, CISO at unified communications services provider Avaya. “In resilient organizations, this team is already prepared, tested, and ready to move without delay,” he says. Response teams should be trained and honed to quickly define the situation, understanding precisely what’s happening, containing the issue, and preventing any further adverse impact, Hill says. In parallel, response teams must be adept at investigating root causes, assessing business impact, and coordinating with legal and communications teams. Coordination within the security organization and IT at large is essential, Hill adds, as IT and cybersecurity will need to collaborate on “recovery actions to restore services and strengthen safeguards” even as response is ongoing. According to Hill, the final goal should be to restore full service with minimal disruption while simultaneously reinforcing security platform resilience so that the enterprise emerges from the incident stronger and better protected. Tabletop exercises are vital to ensuring response teams are prepared. Emphasize scoping and containment from the outset Because you can’t recover from what you can’t stop, scoping and containment should be the absolute first priority during incident recovery, says Amit Basu, CIO and CISO at freight shipping firm International Seaway. “Before anything else, you must stop the bleeding,” he says. This means understanding the true scope of the breach, identifying and isolating affected systems, and revoking compromised credentials. “Rushing to remediation before fully understanding what was compromised could lead to incomplete recovery and re-infection,” Basu warns. Basu believes that the post-containment process should flow through five phases: eradication (removing malware, closing attack vectors, patching vulnerabilities), evidence preservation (forensic imaging before wiping systems, which is essential for legal and regulatory purposes), system restoration (rebuilding from known clean backups or golden images, not just patching compromised systems), validation and testing (confirming that restored systems are clean and functional before reconnecting them), and monitoring (heightened post-recovery surveillance to detect re-entry attempts). Establish situational awareness Creating situational awareness that includes a bad actor assessment, the threat vector, affected assets, and the potential impact to critical services or products should all be considered and addressed, says Dugan Krwawicz, director of technology consulting at Global Consulting Firm Protiviti. Once situational awareness has been firmly deployed, attention should be turned to relevant incident response and crisis management governance, Krwawicz states. “This includes assigning necessary roles aligned to known severity levels and initiating war room or call bridges to enable timely and open collaboration.” He notes that subsequent efforts should focus on three core areas: eradication, recovery, and coordinated communications. Krwawicz says that the goal of any incident response effort should include the safe resumption of critical business activities at acceptable service levels and within a pre-determined timespan. He warns, however, that additional challenges may arise when a CISO prioritizes restoration speed over system and data integrity. “It’s also a mistake for technology and cyber teams to operate in silos without business alignment or executive coordination,” Krwawicz adds. Seek external support When facing a cyber incident, CISOs should immediately enlist an experienced incident recovery provider that can help rapidly stand up or augment incident commands, coordinate stakeholders, and accelerate safe restoration of critical services, Chand advises. A multi-disciplinary partner will typically provide digital forensics and incident response (DFIR), as well as containment/eradication support, cloud recovery specialists, and a structured secure restore approach, she says. “A provider can also help orchestrate parallel workstreams with outside breach counsel, the cyber insurer/breach coach, key technology vendors, and, when needed, crisis communications and regulatory readiness,” Chand says. “This outcome will lead to faster, better-governed recovery with clearer decisions, cleaner evidence, and fewer operational surprises.” Prioritize restoration by business criticality When a cyber incident impacts business systems, every hour of downtime leads to greater financial loss, customer trust erosion, and regulatory exposure, says Aparna Himmatramka, a security engineering manager at Amazon. “A slower recovery gives malicious actors more dwell time and increases the risk and quantity of data exfiltration/exposure,” she adds. Yet declaring victory too early, while tempting, can lead to future failures, Himmatramka warns. Organizational pressure to say “we’re back up” can lead to skipping root cause analysis, missed complex persistence mechanisms, and unvalidated backup integrity. “The breach isn’t over when systems are back online; it’s over when you understand exactly what happened and have successfully closed the gap,” she says. Himmatramka recommends prioritizing restoration by business criticality, not technical convenience. “Restore revenue-generating and safety-critical systems first, using validated clean backups, then verify integrity at each stage and run communications as a parallel workstream while keeping leadership, legal teams, and regulators informed with timelines.” Be disciplined and avoid improvisation It’s important to address recovery calmly and logically, says Jay Martin, CISO at systems integrator and cloud services firm Blue Mantis. He suggests executing your playbook in a disciplined manner and relying on practiced procedures rather than improvisation. “Ensure that the incident response team follows the NIST 800-61 framework and the Responsible, Accountable, Consulted, Informed (RACI) matrix in order to clarify who handles technical analysis, communications, legal issues, and interactions with cyber insurers” Martin says. “This type of structured approach ensures that all necessary actions are covered and that your response is both coordinated and efficient.” Martin notes that a CISO should build strong support from an array of sources, including the incident response team, crisis communication experts, legal counsel, cyber insurance providers, and third-party vendors, such as managed security service providers (MSSPs) or managed service providers (MSPs). “When incidents drag on, trust can erode, tempers can flare, and internal friction can start to undermine the process,” he warns. “Strong leadership is essential to hold the team together and keep response functions moving in the right direction.” Implement lessons learned for the future Once the dust has settled, it’s important to ensure that you have achieved full containment, eradication, and remediation, says Josh Ray, CEO at cybersecurity firm Blackwire Labs. “Nothing else should happen until you can confirm verification with confidence,” he states. Despite the temptation, Ray warns not to immediately launch a penetration test. “The adversary just ran one for you — and you failed it,” he says. “Instead, spend your money shoring up your defenses, then validate with testing once your lessons-learned have been implemented and your new controls have had a chance to prove themselves.” View the full article

PeopleImages.com – Yuri A | shutterstock.com Protokoll-Daten zu auditieren, zu überprüfen und zu managen, ist alles andere als eine glamouröse Aufgabe – aber ein entscheidender Aspekt, um ein sicheres Unternehmensnetzwerk aufzubauen. Schließlich schaffen Event Logs oft eine sekundäre Angriffsfläche für Cyberkriminelle, die damit ihre Aktivitäten verschleiern wollen. Vorgängen wie diesen treten Netzwerksicherheitsexperten mit Tools aus dem Bereich Security Information and Event Management (SIEM) entgegen: Diese Werkzeuge bieten im Regelfall einen zusätzlichen Schutzschirm für Logs, indem sie sie auf einen Server oder Service auslagern und so verhindern, dass sie manipuliert oder gelöscht werden. In diesem Ratgeber lesen Sie: welche Kriterien bei SIEM-Tools wichtig sind, was bei diesen Lösungen mit Blick auf die Kosten zu beachten ist, und welche SIEM-Anbieter und -Lösungen führend sind. Das richtige SIEM-Tool auswählen Eine passende SIEM-Lösung auszuwählen, ist essenziell, um geschäftskritische Systeme und Dienste zu überwachen. Aber auch, um: Daten für Authentifizierungszwecke bereitzustellen, die Threat Detection zu unterstützen, und SOAR-Plattformen Kontext zu liefern. Die folgenden Bereiche, beziehungsweise Kriterien, sollten Sie mit Blick auf SIEM-Angebote unbedingt vor einem Kauf durchdenken. Betriebsmodell Um Funktionen schneller zu iterieren und hinzuzufügen, steht das Gros moderner SIEM-Lösungen inzwischen in einem Software-as-a-Service (SaaS)-Modell zur Verfügung. Die unendliche Kapazität der Cloud erleichtert es den Anbietern dabei auch, Machine-Learning (ML)-Funktionen zu integrieren, die Referenzdaten in rauen Mengen benötigen, um Anomalien erkennen zu können. Es besteht grundsätzlich Einigkeit darüber, dass der SaaS-Ansatz dazu beigetragen hat, SIEM-Lösungen voranzubringen. Dennoch sind einige Unternehmen darauf angewiesen, SIEM-Tools On-Premises zu betreiben. In der Regel, weil sie Compliance-Vorschriften einhalten und in diesem Zuge Protokolle (und die damit zusammenhängenden Daten) in ihrer lokalen Infrastruktur vorhalten müssen. Deshalb gibt es immer noch einige SIEM-Optionen für den Einsatz vor Ort – darunter auch solide Open-Source-Lösungen. Analytics Eine SIEM-Lösung ist nur so gut wie die Informationen, die sie liefert: Log- und Event-Daten aus der Infrastruktur zu sammeln, ist nutzlos, wenn es nicht dazu beiträgt, Probleme zu erkennen und informierte(re) Entscheidungen zu treffen. Deswegen setzen moderne SIEM-Systeme auf Machine Learning, um Anomalien in Echtzeit zu erkennen und ein präzises Frühwarnsystem für potenzielle Angriffe sowie Anwendungs- und Netzwerkfehler zu etablieren. Wie Ihre spezifischen Anforderungen an die Analysefähigkeiten einer SIEM-Lösung aussehen, hängt von mehreren Faktoren ab: Welche Systeme sollen überwacht werden? Welche Skills stehen in der Organisation mit Blick auf Dashboards, Reportings und Untersuchungen zur Verfügung? Haben Sie bereits in eine Analytics-Plattform investiert und möchten diese integrieren? Die Antworten auf diese Fragen können Sie dabei unterstützen, SIEM-Optionen einzugrenzen. Sollten Sie weder auf entsprechende Skills, noch Lösungen zurückgreifen können, empfiehlt sich möglicherweise eine SIEM-Lösung mit einer umfangreichen Dashboard-Bibliothek – beziehungsweise ein Managed Service. Protokolle Wie ein SIEM-System Daten verarbeitet, ist ein weiterer, wichtiger Aspekt mit Praxisbezug. Häufig extrahieren Software-Agenten Protokoll- und Ereignisdaten von Servern und Workstations, während Netzwerkhardware und Cloud-Anwendungen sie über eine Integration oder eine API direkt an das SIEM „übergeben“ können. Eine grundlegende Frage ist in diesem Zusammenhang, ob das SIEM auch wichtige, externe Event-Informationen akkurat identifizieren kann. Im Idealfall sollte das SIEM ausgereift genug sein, um Event-Daten aus den gängigsten Systemen zu parsen und dabei so genau sein, dass keine Anpassungen erforderlich sind und wichtige Details wie Event-Levels oder betroffene Systeme herausgefiltert werden. Um zu vermeiden, dass Log-Einträge nicht korrekt geparst werden, empfiehlt sich zudem eine Lösung, die flexible Möglichkeiten bietet, Event-Daten zu verarbeiten, nachdem sie erfasst wurden. Warnmeldungen Ein wesentlicher Vorteil moderner SIEM-Lösungen ist die Möglichkeit, Systeme in Echtzeit zu überwachen. Allerdings ist das Feature überflüssig, wenn das SIEM selbst, beziehungsweise seine Alerts, nicht von einem menschlichen Experten ausgewertet werden. Mit Blick auf die Warnmeldungen und Benachrichtigungen besteht die Herausforderung vor allem darin, beim Volumen der Alerts Maß zu halten: Zu viele Warnmeldungen werden von den Benutzern entweder deaktiviert oder ignoriert. Zu wenige Alerts bergen die Gefahr, dass kritische Bedrohungen unter den Tisch fallen. Auch mit Blick auf dieses Kriterium empfehlen sich flexible SIEM-Lösungen, die es ermöglichen, Alerts zu konfigurieren – zum Beispiel über Regeln, Schwellenwerte oder verschiedene Warnmethoden (SMS, E-Mail, Push-Nachrichten und Webhooks). Rollenbasierter Zugriff Rollenbasierte Zugriffskontrollen sind für große, weltweit tätige Unternehmen mit unterschiedlichen Business-Segmenten und Applikationsteams unerlässlich. Dabei ist es nicht bloß ein Komfort-Feature, Admins, Entwickler und Datenanalysten nur Zugriff auf die Event-Logs zu gewähren, die sie benötigen. Vielmehr entspricht das dem Least-Privilege-Prinzip, das in einigen Branchen auch regulatorisch durchgesetzt wird. Den Zugriff der Benutzer auf SIEM-Event-Daten beschränken zu können, begrenzt zudem den Impact kompromittierter Konten und trägt letztlich zum Schutz des gesamten Netzwerks bei. Schließlich bieten Event-Daten oft tiefe und detailreiche Einblicke in Applikations- und Service-Funktionalitäten – oder gar die Netzwerkkonfigurationen von Devices. Diese Informationen könnten Cyberkriminelle nutzen, um Systeme auszuspähen und zu infiltrieren. Compliance Diverse, regulatorische Rahmenwerke – beispielsweise die DSGVO oder HIPAA – setzen nicht nur voraus, dass SIEM- oder ähnliche Systeme eingesetzt werden, sondern schreiben teilweise auch vor, wie die Lösung konfiguriert sein sollte. Sie sollten sich deshalb mit den für Ihre Organisation relevanten Anforderungen im Detail vertraut machen. Dabei können unter anderem relevant sein: Aufbewahrungsfristen, Verschlüsselungsanforderungen, digitale Signaturen und Berichtspflichten. Dabei sollten auch mögliche Audit-Elemente nicht unberücksichtigt bleiben: Die SIEM-Lösung Ihrer Wahl sollte die erforderlichen Dokumentationen und Reportings ausgeben können, die die Auditoren zufriedenstellen. Event-Korrelation Die Möglichkeit, Protokolle aus unterschiedlichen (und/oder integrierten) Systemen in einer einzigen Ansicht zu korrelieren, ist ebenfalls ein guter Grund dafür, ein SIEM-System zu implementieren. Dieses sollte in der Lage sein, Log-Events von jeder Anwendungskomponente (Datenbank, Applikationsserver) zu verarbeiten (selbst wenn sie auf mehrere Hosts verteilt sind), und diese in einem Data Stream zu korrelieren. Das macht nachvollziehbar, wie die Events der Komponenten miteinander zusammenhängen. In vielen Fällen können korrelierte Ereignisprotokolle eingesetzt werden, um (Privilege-Escalation-)Angriffe zu erkennen und ihren Impact über die verschiedenen Netzwerksegmente hinweg zu tracken. Das wird auch deswegen immer wichtiger, weil Unternehmen zunehmend auf die Cloud oder Container-basierte Infrastrukturen setzen. Ökosysteme Ein SIEM mit einem robusten, ausgereiften Ökosystem ermöglicht es, verschiedene Funktionen zu verbessern, beziehungsweise zu erweitern. Wenn das SIEM direkt (oder über Plugins) in andere Systeme integriert werden kann, erleichtert das die Arbeit erheblich. Neben den Systemverbesserungen, die durch ein SIEM-Ökosystem erzielt werden können, gibt es noch weitere Business Benefits. So kann eine moderne, ausgereifte SIEM-Lösung: die Nachfrage nach Schulungen steigern, Support auf Community-Basis fördern, und den Einstellungsprozess vereinheitlichen. API-Interaktion Ein Ökosystem wird nicht allen Anforderungen gerecht: Falls Ihr Unternehmen Software entwickelt oder in DevOps-Initiativen investiert hat, kann die Möglichkeit, programmgesteuert mit einer SIEM-Lösung zu interagieren, einen wesentlichen Unterschied machen. Statt wertvolle Entwicklungszeit in Logging-Funktion zu stecken, kann das SIEM-System Ereignisdaten aus benutzerdefiniertem Code aufnehmen, korrelieren und analysieren. Künstliche Intelligenz (KI) SIEM scheint ein maßgeschneiderter Anwendungsfall für KI-gestützte Analysen – entsprechend scheuen sich die Anbieter nicht, entsprechende Funktionen in ihre Lösungen zu implementieren. Die fokussieren sich im Allgemeinen auf die Bereiche Analytics und Alerts. KI-fähige SIEM-Systeme können mit Cloud-Daten-Feeds einer Vielzahl von Anbietern und Quellen integriert werden. Das ermöglicht, Event-Daten automatisiert mit Kontext auszustatten und dafür zu nutzen, um: Ereignisse zu bewerten, Angriffsketten zu identifizieren und Incident-Response-Pläne zu erstellen. Mit Blick auf KI-fähige SIEM-Lösungen kann auch das Thema Betriebsmodell eine Rolle spielen: Einige On-Premises-Angebote erfordern unter Umständen, KI-Workloads an Cloud-Services auszulagern. SIEM-Kosten Wenn es um Security Information and Event Management geht, sollten Sie den Gürtel nicht unbedingt enger schnallen – schließlich möchte wohl niemand im Angriffsfall am falschen Ende gespart haben. Natürlich sind die Kosten auch im Fall von SIEM-Lösungen ein Faktor – bei der Berechnung gilt es allerdings auf Feinheiten zu achten. SIEM-Lösungen, die in Form eines Cloud-Service angeboten werden, stehen fast immer in einem Abo-Modell zur Verfügung. Dabei können jedoch auch Nutzungsgebühren anfallen – beispielsweise für: das Volumen der Event-Daten oder die Anzahl der überwachten Endpunkte. Achten Sie bei Plattformen, die mit einer Open-Source-Lizenz angeboten werden, zudem auf versteckte Kosten (beispielsweise für Support) und stellen Sie sicher, dass die gewählte Lösung sämtliche relevanten, geschäftlichen Anforderungen erfüllt. Wenn Sie Ihr persönliches SIEM-Kandidatenfeld auf diejenigen eingegrenzt haben, die die benötigten Funktionen bieten, vergleichen Sie die voraussichtlich anfallenden Abonnement- und Nutzungsgebühren im Detail. SIEM-Anbieter & -Lösungen Der Markt für SIEM-Lösungen ist reich an Optionen. Um Ihnen den Einstieg in die Tool-Recherche zu erleichtern, haben wir einige, wichtige SIEM-Anbieter, respektive -Produkte, für Sie zusammengestellt: Datadog Cloud-SIEM ist eine ausgereifte SIEM-Suite, die sämtliche wichtigen Bereiche umfasst und mehr als 800 Integrationen sowie über 350 vorgefertigte Detection-Regeln bietet. Elastic Logstash ist keine echte SIEM-Plattform – das Open-Source-Tool (in erster Linie für die DevOps-Welt konzipiert) ermöglicht es aber, Log-Events aus einer Vielzahl von Quellen zu analysieren und zu verarbeiten. Exabeam LogRhythm SIEM ist einem Zusammenschluss der Sicherheitsanbieter Exabeam und LogRythm entsprungen und zeichnet sich in erster Linie durch ein umfassendes Ökosystem und vorgefertigte Compliance-Frameworks aus. Fortinet FortiSIEM ermöglicht Asset-Erkennung und rollenbasierten Zugriff, sowie User and Entity Behavior Analytics (UEBA) – und kann sowohl integriert werden, um Events zu erfassen, als auch, um automatisiert auf diese zu reagieren. Huntress Managed SIEM ist ein solides, modernes Managed SIEM von einem aufstrebenden Anbieter, dessen Analysten und Security Engineers interne Teams entlasten können. IBM QRadar SIEM ist in der Lage, Datenmengen und Funktionen im Enterprise-Format zu bewältigen, verfügt über eine integrierte Analytics-Engine, KI-Funktionen und bietet Support für mehr als 500 Integrationen. Guardsix SecOps (ehemals LogPoint) setzt UEBA für Threat Modeling und Machine Learning ein, unterstützt automatisierte Übersetzungen sowie wichtige Compliance-Standards und korreliert Ereignisse auch mit dem MITRE ATT&CK-Framework. Microsoft Sentinel ist in der Lage, Ereignisse sowohl von lokalen, als auch von Cloud- Ressourcen einzuspeisen, zu korrelieren und zu analysieren – dabei hilft inzwischen auch die KI in Form von Microsofts Security Copilot. OpenText Enterprise Security Manager kann alle Anforderungen an ein Enterprise-SIEM erfüllen, bietet zahlreiche Integrationen mit Drittanbieter-Systemen und umfassenden Support für Automatisierung. NetWitness bietet ebenfalls diverse Enterprise-SIEM-Funktionen, zeichnet sich aber vor allem durch seine integrierten Encryption-Tools aus, die Support für verschlüsselte Event-Daten (oder Netz-Traffic) bieten. SentinelOne Singularity AI SIEM setzt auf State-of-the-Art-Techniken, um Daten zu erfassen und zu filtern, liefert robuste Analysen und verspricht intuitive Automatisierungen. SolarWinds Security Event Manager bietet zwar weder ML-basierte Datenanalysen, noch kann es in Sachen Integrationen mit den anderen hier aufgeführten Optionen mithalten – dafür bietet es USB Device Monitoring und beeindruckende Compliance-Reporting-Fähigkeiten. Splunk bietet seine SIEM-Plattform, die sich insbesondere durch ihr Ökosystem (beziehungsweise ihren App Store) auszeichnet, in zwei Versionen an: Splunk Enterprise für den On-Premises-Einsatz und Splunk Cloud als SaaS-Modell. Trellix Enterprise Security Manager stellt Benutzern umsetzbare Warnmeldungen zur Verfügung und legt den Fokus auf Flexibilität, wenn es um Architektur und Integrationen geht. Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen. View the full article

Schwachstellen zu managen, muss keine Schwerstarbeit sein. Wenn Sie die richtigen Tools einsetzen. Das sind die besten in Sachen Vulnerability Management. Foto: eamesBot – shutterstock.com Nicht nur das Vulnerability Management hat sich im Laufe der Jahre erheblich verändert, sondern auch die Systeme, auf denen Schwachstellen identifiziert und gepatcht werden müssen. Systeme für das Schwachstellen-Management fokussieren heutzutage nicht mehr nur auf Netzwerke und private gehostete Applikationen. Sie müssen in der Lage sein, Schwachstellen sowohl On-Premises, als auch auf IoT-Devices sowie in Public- und Private-Cloud-Instanzen zu identifizieren. Zudem sollten sie die Security-Teams der Unternehmen dabei unterstützen, die bestmöglichen Entscheidungen zu treffen, um die Lecks zu beheben. Eine Schwachstelle im System, die nicht ausgenutzt werden kann, stellt keine große Gefahr dar. Umso wichtiger ist es, zu wissen, was wirklich gefährlich ist. Nur so lassen sich Sicherheitslücken evaluieren und kategorisieren. Dabei spielen auch die potenziellen Auswirkungen eine große Rolle: Es ist zwar peinlich, wenn eine Unternehmenswebseite verunstaltet wird, der Diebstahl vertraulicher Informationen kann jedoch geschäftskritisch sein und darüber hinaus zu hohen Geldbußen führen. Gute Vulnerability-Management-Programme zeichnen sich dadurch aus, dass sie ihren Schwachstellen-Scans einen Kontext hinzufügen. Bei potenziell Tausenden von Schwachstellen, die sich in jedem größeren Unternehmensnetzwerk verbergen, ist das die einzige Möglichkeit, zuverlässig zu priorisieren und damit Risiken zu minimieren. Vulnerability Management Tools: Top 6 Die folgenden sechs Produkte setzen in mindestens einem Aspekt des Schwachstellenmanagements neue Maßstäbe. Qualys VMDR Qualys war im Jahr 1999 die erste SaaS-Plattform für Schwachstellen-Management. Qualys Vulnerability Management Detection and Response (VMDR) steht als Cloud-Service zur Verfügung. Mit Voice Agents, virtuellen Scannern und passiven Netzwerk-Scanning-Funktionen unterstützt die Lösung Unternehmen dabei, ihre Assets zu identifizieren – On-Premises, in der Cloud und auf den Endpoints. Die Dashboards sind individuell anpassbar. Die gesammelten Schwachstellen-Daten können die Anwender auf Asset-Basis untersuchen, um tiefere Einblicke in Konfiguration, laufenden Dienste, Netzwerkinformationen und andere Daten zu bekommen. Mit einer “AssetView”-Funktion können Sicherheits- und Compliance-Teams ihre Informationsressourcen auf der Grundlage der für ihr Unternehmen wichtigen Daten kontinuierlich aktualisieren. Nachdem Qualys VMDR Assets und Schwachstellen identifiziert sowie nach Risikolevel priorisiert hat, können die Anwender Patches innerhalb der Plattform bereitstellen. Orca Security Das Cloud Security Posture Management (CSPM)-Tool Orca Security verwaltet Schwachstellen in Cloud-Infrastrukturdiensten wie Amazon Web Services (AWS), Microsoft Azure und Google Cloud. Da Orca für die Cloud entwickelt wurde, lässt es sich problemlos in diesen Umgebungen einsetzen. Die Side-Scanning-Technologie von Orca ermöglicht es Benutzern, ihre Cloud-Umgebung zu inventarisieren und sammelt zum Beispiel Daten über Betriebssystempakete, Anwendungen oder Bibliotheken. Zu jeder aufgedeckten Schwachstelle erstellt das System eine eigene Map, die die Beziehung zu anderen Assets darstellt. Das hilft bei der Priorisierung. Um den Schweregrad der Schwachstellen in den Cloud-Systemen eines Unternehmens grafisch darzustellen, analysiert die Lösung Cloud-Systeme und -Workloads sowie deren Konfigurationen und Sicherheitseinstellungen. Darüber hinaus regelt Orca die Konnektivität und kann erkennen, welche Netzwerke öffentlich zugänglich sind und welche nicht. Mit all diesen Daten erstellt das Vulnerability Management Tool eine Visualisierung, die versucht, das tatsächliche Risiko einer Schwachstelle im Kontext des Cloud-Systems zu bewerten. Die zugehörige Schwachstellen-Datenbank enthält Daten aus mehr als 20 verschiedenen Quellen. Detectify Das Angebot von Detectify fällt in die Kategorie Attack Surface Management (ASM). ASM konzentriert sich auf Schwachstellen aus der Sicht eines Angreifers. Es setzt sich aus der kontinuierlichen Erkennung von Enterprise IT-Assets, internetfähigen Systemen wie Cloud-Infrastruktur, Drittanbietersystemen und Webanwendungen zusammen. Dabei identifiziert es Schwachstellen in diesen Systemen und unterstützt dabei, diese zu priorisieren und zu managen. Da Detectify auf Cloud-Basis operiert, ist keine Installation erforderlich. Sie müssen lediglich die zu überprüfende Domain hinzufügen, schon werden alle zugehörigen Subdomains und Anwendungen kontinuierlich überprüft. Die Lösung unterteilt ihre Scanning-Aktivitäten dabei in zwei Bereiche – Surface und Application Monitoring. Erstere Kategorie prüft die Internet-Assets einer Organisation und evaluiert die gefundenen Hosts auf Schwachstellen, Fehlkonfigurationen und ähnliches. Beim Application Scanning findet hingegen eine kontinuierliche Evaluierung der Web-Applikationen beziehungsweise dort vorhandener Schwachstellen statt. Detectify bewertet Anwendungen in der Produktion, der Entwicklungspipeline und im Application Staging. Ein interessanter Aspekt von Detectify ist die Kombination aus Automatisierung und Crowdsourcing: Das Unternehmen arbeitet mit Ethical Hackern zusammen und lässt deren Erkenntnisse einfließen. Das stellt sicher, dass die Unternehmenssysteme automatisiert auf vorhandene Schwachstellen überprüft werden, während erfahrene Sicherheitsforscher nach bislang unentdeckten Schwachstellen suchen. Kenna Security Vulnerability Management Jeder, der schon einmal mit Vulnerability Management Tools gearbeitet hat, weiß, dass verschiedene Lösungen oft unterschiedliche Schwachstellen erkennen. Einige performen bei spezifischen Aufgaben zudem etwas besser als andere, etwa wenn es um die Bewertung von lokalen Netzwerken oder Cloud-Anwendungen geht. An dieser Stelle kommt Kenna Security Vulnerability Management ins Spiel: Diese Lösung führt selbst keine Scans durch sondern stellt sogenannte Connector-Programme zur Verfügung. Diese nehmen Daten von nahezu allen Schwachstellen-Scannern auf, einschließlich derer von Tripwire, Qualys, McAfee und CheckMarx. Die Plattform selbst wird als Service bereitgestellt, Anwender melden sich bei einem Cloud-Portal an, um ihre Informationen zu überprüfen. Die Idee dahinter: Die Lösung von Kenna sammelt Vulnerability Alerts und gleicht diese dann in Echtzeit mit Bedrohungsdaten ab. Eine entdeckte Schwachstelle kann dabei einer aktiven Bedrohungskampagne zugeordnet und entsprechend priorisiert behoben werden. Alle weltweit ausgenutzten Schwachstellen erhalten automatisch eine höhere Priorität. So können die Verteidiger die gefährlichsten Probleme lösen, bevor Angreifer sie entdecken und ausnutzen. Die Kenna-Plattform war eine der ersten, die Echtzeit-Bedrohungsdaten in das Schwachstellenmanagement einbezog. Seitdem wurde sie um zusätzliche Bedrohungsdaten erweitert. Die Plattform erklärt dabei, warum Schwachstellen in einem geschützten Netzwerk vorhanden sind und gibt Tipps, um diese zu beheben. Sie kann entdeckte Schwachstellen außerdem priorisieren, je nachdem, welche Assets betroffen sind und wie schwerwiegend das Problem ist. Risikobasierte Service Level Agreements (SLAs) gehören ebenfalls zur Plattform und schaffen einen Zeitrahmen um Probleme zu beheben, der auf der Risikotoleranz eines Unternehmens basiert. Je weniger Risiko ein Unternehmen stemmen kann, desto schneller muss es die Schwachstelle beheben. Die risikobasierten SLAs von Kenna basieren dabei auf drei Faktoren: Risikotoleranz, Asset-Priorität und der Risikobewertung der Schwachstelle. Seit 2021 ist Kenna Security Teil von Cisco. Flexera Software Vulnerability Management Viele Vulnerability Management Tools konzentrieren sich auf intern entwickelte Anwendungen und Code. Dagegen nimmt die Software-Vulnerability-Management-Plattform von Flexera Softwareprogramme von Drittanbietern in den Fokus, die fast jedes Unternehmen nutzt. In den meisten Fällen wird eine Schwachstelle in gekaufter oder lizenzierter Software durch ein Patch behoben. Das kann für Unternehmen zu einem Problem werden, wenn Tausende von Systemen oder kritischen Diensten dafür offline genommen werden müssen. Dabei besteht zudem die Möglichkeit, dass durch die Behebung eines Problems weitere, neue entstehen. Die Flexera-Software will dieses Problem bekämpfen, indem sie einen sicheren Patch-Management-Prozess für das gesamte Unternehmen realisiert. Die Lösung kann Schwachstellen in Software von Drittanbietern aufspüren und Administratoren über den Schweregrad der potenziellen Bedrohung informieren. Einen umfassenden Patch für Tausende von Anwendern herauszugeben, um eine geringfügige Schwachstelle zu beheben oder eine Funktion zu patchen, die vom Unternehmen unter Umständen weder installiert noch genutzt wird, macht wenig Sinn. Flexera kann an dieser Stelle unterstützen, indem es den Kontext mitliefert und Patches zu dem Zeitpunkt bereitstellt, wenn sie notwendig werden. Mit der Flexera-Plattform lässt sich auch ein automatisiertes Patch-Management-System etablieren. Darüber hinaus können benutzerdefinierte Reportings erzeugt werden. Das gilt nicht nur für das Schwachstellen- und Patch-Management, sondern auch wenn es um Compliance (Frameworks, Gesetze, Best Practices) geht. Tenable.io Tenable ist bekannt für seine Security Dashboards. Mit Tenable.io bietet das Unternehmen dieselbe Diagnose-Technologie auch in Kombination mit Vulnerability Management an. Die Plattform wird in der Cloud gemanagt und nutzt eine Kombination aus aktiven Scan-Agenten, passiver Überwachung und Cloud-Konnektoren, um nach Schwachstellen zu suchen. Um zu ermitteln, welche Korrekturen nötig sind, damit Angreifer keinen Erfolg haben, nutzt die Tenable-Lösung maschinelles Lernen, Data Science und KI. Eine der größten Stärken von Tenable.io: Schwachstellen werden für jedermann verständlich dargestellt – ganz ohne spezielle Schulungen oder Fach-Knowhow. Um seine Attack-Surface-Management-Fähigkeiten zu stärken, hat Tenable den ASM-Anbieter Bit Discovery übernommen. So erhalten die Kunden einen umfassenden Überblick über ihre internen und externen Angriffsflächen. (fm) Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen. View the full article

Sie fühlen sich leer ohne Security-Dashboard? Diese Dokumentationen überbrücken den Schmerz bis zum nächsten Arbeitstag. Foto: Gorodenkoff – shutterstock.com Wenn Sie in Ihrer Profession als Sicherheitsentscheider voll aufgehen, brauchen Sie möglicherweise auch zwischen den Arbeitstagen ihre tägliche Dosis Cybersecurity. Falls Ihnen die zahlreichen Annäherungen Hollywoods an das Thema viel zu weit von der Realität entfernt sind, können Sie auf ein Füllhorn hochwertiger Dokumentationen zurückgreifen. Die sind nicht nur informativ, (meist) sehr nah an der Realität und unterhaltsam, sondern teilweise auch historisch wertvoll und in einigen Fällen kostenlos in voller Länge verfügbar. Doku-Highlights für Sicherheitsentscheider Nachfolgend haben wir diverse sehenswerte Dokumentationen in Zusammenhang mit Cybersecurity und Hacker-Kultur für Sie zusammengestellt. Viel Spaß! Hackers – Wizards of the Electronic Age (1985) Kurz und knapp: frühe Doku über die Hacker Community unter anderem mit Steve Wozniak kostenlos in voller Länge verfügbar Hackers in Wonderland (2000) Kurz und knapp: porträtiert UK- und US-Hacker beleuchtet Hacktivismus kostenlos in voller Länge verfügbar Secret History of Hacking (2001) Kurz und knapp: fokussiert frühe Hacking-Techniken mit John Draper, Steve Wozniak und Kevin Mitnick kostenlos in voller Länge verfügbar Hackers Are People Too (2008) Kurz und knapp: von Hackern kreiert will mit Stereotypen aufräumen beleuchtet auch die Rolle der Frauen in der Community We Are Legion: The Story of the Hacktivists (2012) Kurz und knapp: beleuchtet das Hacker-Kollektiv Anonymous zahlreiche O-Töne von Mitgliedern und Experten auf diversen Filmfestivals ausgezeichnet DEFCON: The Documentary (2013) Kurz und knapp: stellt das 20-jährige Jubiläum der Hacking-Konferenz DEFCON in den Fokus bis zu dieser Doku herrschte auf der Konferenz striktes Kameraverbot O-Töne von Teilnehmern und Verantwortlichen Citizenfour (2014) Kurz und knapp: thematisiert Edward Snowden und den NSA-Skandal enthält Interviews mit Snowden aus dem Jahr 2013 entstand unter Beteiligung von Glenn Greenwald Digital Amnesia (2014) Kurz und knapp: wirft ein Schlaglicht auf digitale Daten und den Umgang mit diesen mit Beteiligung von Experten des Internet Archive kostenlos in voller Länge verfügbar Deep Web (2015) Kurz und knapp: thematisiert den Darknet-Marktplatz Silk Road beleuchtet dabei auch die Verhaftung und den Prozess von Gründer Ross Ulbricht O-Töne von zahlreichen Beteiligten A Good American (2015) Kurz und knapp: erzählt die Geschichte des Ex-NSA-Direktors Bill Binney klärt auf, wie ein Computerprogramm 9/11 hätte verhindern können Regie führte der Österreicher Friedrich Moser War for the Web (2015) Kurz und knapp: wirft einen Blick auf die physische Infrastruktur hinter dem Internet zeigt, wie Unternehmen und Regierungen hinter den Kulissen um die Vorherrschaft kämpfen beleuchtet dabei auch Fragen wie Data Ownership, Datenschutz und Security Cyber War (2016) Kurz und knapp: zeigt, wie Regierungen im Kampf gegen kriminelle Hacker aufrüsten dabei kommen auch unlautere Mittel wie Spionage zur Sprache viele prominente O-Töne Down the Deep Dark Web (2016) Kurz und knapp: bietet Insider-Einblicke in das Darknet beleuchtet dabei auch legitime Einsatzzwecke will mit Vorurteilen und Stereotypen aufräumen Zero Days (2016) Kurz und knapp: erzählt die Geschichte des Stuxnet-Virus analysiert ausgiebig die Folgen des Angriffs bietet zahlreiche Insider-Einblicke und O-Töne Facebook: Cracking the Code (2017) Kurz und knapp: beleuchtet die Security-Kultur und -Probleme bei Facebook geht dabei auch auf die Nutzung von User-Daten, Ad-Gebahren und Fake News ein zahlreiche O-Töne von Experten Kim Dotcom: Caught in the Web (2017) Kurz und knapp: erzählt die Geschichte von Megaupload-Gründer Kim Schmitz beleuchtet dabei seinen Kampf gegen die US-Regierung und die Entertainment-Branche zahlreiche O-Töne von Beteiligten – auch Kim selbst The Defenders (2018) Kurz und knapp: analysiert vier schlagzeilenträchtige Cyberattacken nimmt dabei die Perspektive der Verteidiger ein produziert vom Sicherheitsanbieter Cybereason The Great Hack (2019) Kurz und knapp: thematisiert den Skandal um Facebook und Cambridge Analytica nimmt dabei die Perspektive verschiedener Beteiligter auf aufwändig produziert HAK_MTL (2019) Kurz und knapp: kanadische Hacker stellen die Datenschutz-Versprechen von Unternehmen auf die Probe dabei liegt ein Fokus auf Überwachungstechnologien interessante Insider-Einblicke und O-Töne WannaCry: The Marcus Hutchins Story (2019) Kurz und knapp: erzählt die Geschichte des IT-Experten, der WannaCry durch Zufall stoppte und anschließend in Zusammenhang mit einem Banking-Trojaner verhaftet wurde dabei kommt auch Hutchins selbst zu Wort KnowBe4: The Making of a Unicorn (2020) Kurz und knapp: erzählt die Gründungsgeschichte des Security-Unternehmens KnowBe4 mit Beteiligung von Chief Hacking Officer Kevin Mitnick produziert vom Cybercrime Magazine MY.DOOM: Earth’s Deadliest Computer Viruses (2021) Kurz und knapp: thematisiert den Computervirus MyDoom aus dem Jahr 2004 analysiert dabei auch seine Auswirkungen kostenlos in voller Länge verfügbar Biggest Heist Ever – Der große Bitcoin-Raub (2024) Kurz und knapp: thematisiert den Hackerangriff auf die Hong Konger Kryptobörse Bitfinex aus dem Jahr 2016 beleuchtet den Werdegang von Ilya Lichtenstein und Heather Morgan, die für den Angriff verurteilt wurden diverse O-Töne von Ermittlern, Freunden, Betroffenen – und auch von Ilya Lichtenstein selbst Most Wanted: Teen Hacker (2025) Kurz und knapp: beleuchtet die Cybercrime-Karriere des finnischen Hackers Julius Kivimäki enthält Interviews mit Strafverfolgungsbehörden und Opfern des Cyberkriminellen auch Kivimäki selbst kommt zu Wort Joybubbles (2026) Kurz und knapp: erzählt die Geschichte des blinden Telefonhackers Joe Engressia aus dessen eigener Perspektive ursprünglich als Kickstarter-Projekt gestartet erfolgreiche Premiere auf dem Sundance Film Festival 2026 View the full article

“Something didn’t go as planned. Undoing changes.” That’s all the clue some Windows 11 users will get when Microsoft’s May Security Update fails to install because of insufficient free space on the EFI System Partition (ESP), leaving their systems unprotected by the dozens of patches it contained. This issue affects devices with limited free space available — typically 10MB or less — on the ESP. “On affected devices, the installation might proceed through the initial phases but fail during the reboot phase at approximately 35-36% completion,” Microsoft said in an advisory. It recommended changing a Windows registry setting to force the update, or to roll back changes and wait for a future update to fix the problem. Consultants said it was a potentially serious issue given the unexpected exposure and the time the destined-to-fail patch takes to fail to install. This is the kind of failure that keeps IT leaders up at night, said cybersecurity consultant Brian Levine, who serves as executive director of FormerGov. “When a security update cannot install because the operating system misjudges the state of its own boot partition, the problem isn’t only storage. The real problem is trust in the update process,” he said. “This is a basic hygiene failure dressed up as a technical issue. An update that cannot reliably detect available space on the EFI System Partition is not a small miss. It is a reminder that even mature platforms still struggle with dependency awareness and pre-flight validation.” Eric Grenier, senior director analyst at Gartner, recommended increasing the size of the disk partition to 1.5GB so that the update can go ahead. “This should not hamper business needs in terms of the size of usable space for an end user”, he said, adding that it will also enable updating of the Windows Recovery Environment. He warned that Microsoft’s own recommendation could lead to trouble. “I would recommend that if an organization wanted to use the modified registry fix that they not only backup the registry beforehand but also test it on some pilot devices before rolling out to the rest of the environment and even then, I would do a slow phased rollout to be sure nothing breaks,” he said. “This type of fix in a production environment should be done with extreme caution because if done incorrectly, fixes will require hands on the keyboard.” Ishraq Khan, CEO of coding productivity tool vendor Kodezi, says there is a blame on both IT teams and Microsoft. “Most IT teams reasonably assume that if Windows Update passes its prechecks and starts installation, Microsoft has already validated the system state well enough to avoid a reboot-stage failure. If ESP space is critical to the update succeeding, the updater should have detected and blocked that condition earlier with a clear remediation message,” Khan said. “So while IT environments may contribute to partition pressure over time, Microsoft still owns the orchestration and validation logic that allowed the update to proceed.” Khan added that this can become a very expensive enterprise IT headache. “That is a design problem for enterprise IT because failure during reboot is much more disruptive than blocking the update before installation begins. From a software maintenance perspective, this is exactly the kind of edge case that becomes expensive at enterprise scale. A small partition constraint on a subset of machines can turn into help desk tickets, rollback cycles, delayed patching, and security exposure.” David Neuman, COO of consulting firm Acceligence, agreed that this is a substantial IT headache. “The update appears to pass the early phases but then fails during the reboot phase, which means IT may not find out until the endpoint has already burned through the maintenance window time and rolled back. In an enterprise, it becomes a fleet hygiene problem rather than a one-off help desk problem,” he said. “Affected endpoints may remain unpatched while IT burns time diagnosing a failure that should have been explained earlier. The bigger lesson is that boot, recovery, and firmware-adjacent partitions are now part of patch-management hygiene. Mature IT teams should add ESP size and free-space checks to endpoint health reporting, update gold images so new deployments have adequate ESP capacity and treat boot-partition cleanup or resizing as lifecycle engineering rather than break-fix scripting.” Microsoft said that it had resolved the issue automatically for consumer devices and non-managed business devices, but that leaves enterprises managing their own devices to sort things out for themselves. “We recommend IT administrators follow guidance within the known issues documentation, to mitigate this issue and re-deploy the latest May Security Updates to be protected,” a Microsoft representative said via email. The company plans to update documentation when it has resolved the problem. View the full article

“Something didn’t go as planned. Undoing changes.” That’s all the clue some Windows 11 users will get when Microsoft’s May Security Update fails to install because of insufficient free space on the EFI System Partition (ESP), leaving their systems unprotected by the dozens of patches it contained. This issue affects devices with limited free space available — typically 10MB or less — on the ESP. “On affected devices, the installation might proceed through the initial phases but fail during the reboot phase at approximately 35-36% completion,” Microsoft said in an advisory. It recommended changing a Windows registry setting to force the update, or to roll back changes and wait for a future update to fix the problem. Consultants said it was a potentially serious issue given the unexpected exposure and the time the destined-to-fail patch takes to fail to install. This is the kind of failure that keeps IT leaders up at night, said cybersecurity consultant Brian Levine, who serves as executive director of FormerGov. “When a security update cannot install because the operating system misjudges the state of its own boot partition, the problem isn’t only storage. The real problem is trust in the update process,” he said. “This is a basic hygiene failure dressed up as a technical issue. An update that cannot reliably detect available space on the EFI System Partition is not a small miss. It is a reminder that even mature platforms still struggle with dependency awareness and pre-flight validation.” Eric Grenier, senior director analyst at Gartner, recommended increasing the size of the disk partition to 1.5GB so that the update can go ahead. “This should not hamper business needs in terms of the size of usable space for an end user”, he said, adding that it will also enable updating of the Windows Recovery Environment. He warned that Microsoft’s own recommendation could lead to trouble. “I would recommend that if an organization wanted to use the modified registry fix that they not only backup the registry beforehand but also test it on some pilot devices before rolling out to the rest of the environment and even then, I would do a slow phased rollout to be sure nothing breaks,” he said. “This type of fix in a production environment should be done with extreme caution because if done incorrectly, fixes will require hands on the keyboard.” Ishraq Khan, CEO of coding productivity tool vendor Kodezi, says there is a blame on both IT teams and Microsoft. “Most IT teams reasonably assume that if Windows Update passes its prechecks and starts installation, Microsoft has already validated the system state well enough to avoid a reboot-stage failure. If ESP space is critical to the update succeeding, the updater should have detected and blocked that condition earlier with a clear remediation message,” Khan said. “So while IT environments may contribute to partition pressure over time, Microsoft still owns the orchestration and validation logic that allowed the update to proceed.” Khan added that this can become a very expensive enterprise IT headache. “That is a design problem for enterprise IT because failure during reboot is much more disruptive than blocking the update before installation begins. From a software maintenance perspective, this is exactly the kind of edge case that becomes expensive at enterprise scale. A small partition constraint on a subset of machines can turn into help desk tickets, rollback cycles, delayed patching, and security exposure.” David Neuman, COO of consulting firm Acceligence, agreed that this is a substantial IT headache. “The update appears to pass the early phases but then fails during the reboot phase, which means IT may not find out until the endpoint has already burned through the maintenance window time and rolled back. In an enterprise, it becomes a fleet hygiene problem rather than a one-off help desk problem,” he said. “Affected endpoints may remain unpatched while IT burns time diagnosing a failure that should have been explained earlier. The bigger lesson is that boot, recovery, and firmware-adjacent partitions are now part of patch-management hygiene. Mature IT teams should add ESP size and free-space checks to endpoint health reporting, update gold images so new deployments have adequate ESP capacity and treat boot-partition cleanup or resizing as lifecycle engineering rather than break-fix scripting.” Microsoft did not respond to a request for comment. View the full article

The ability of AI models to perform end-to-end, multi-stage penetration tests that match the capabilities of humans undertaking the same tasks has improved dramatically in recent months, according to new benchmarks published by the UK government’s AI Security Institute (AISI). In November 2025, the difficulty of cyber tasks the best models could complete was doubling every eight months, according to AISI, a research organization within the Department for Science, Innovation and Technology (DSIT). By February this year, the performance improvements had accelerated, with the difficulty of the tasks AI models could complete doubling every 4.7 months, and since then the latest Claude Mythos Preview and GPT-5.5 models are showing even greater capability, AISI said. The time horizon benchmarks used by AISI first measure or estimate the time it would take a human expert to solve a variety of challenges as a proxy for their difficulty and then estimate the longest task (in human work hours) that AI models can complete with a success rate of 80%. This makes it a measure of autonomous capability rather than speed: If a human can successfully complete a set of pen testing tasks in 4 hours, time horizon testing measures how successfully an AI model can match this capability at a given reliability. To achieve this, the AI must sustain performance over multiple steps while maintaining context and recovering from failures. The more steps, the more difficult pen testing becomes, and the more meaningful the results. As with all benchmarks, there are caveats. The first is that to compare performance between models over time, the testing capped the AI systems at a low 2.5 million tokens. This has a number of effects including, in these benchmarks, limiting the ability of the AI models to keep track of what they were working on at an earlier stage. As AISI said in its analysis, “They are inexact predictors of performance; AI struggles with some tasks humans do quickly, and easily completes others that humans find hard. However, we use this type of benchmark because it offers a measure of AI autonomy from which we can draw trends.” Growing risk The research is cause for concern for the UK government. “Our independent testing shows that cyber capabilities in leading AI systems are advancing much faster than we expected. That matters because this isn’t theoretical — those advances are already starting to translate into real risks for organisations, especially those with weak cyber defences,” UK AI Minister Kanishka Narayan said via email. “These tools can also help cyber security teams spot and fix weaknesses faster. The UK is leading the way in testing and understanding frontier AI, and that capability is only going to become more important as the technology continues to move at pace,” he added. In April, DSIT Secretary of State Liz Kendall and Security Minister Dan Jarvis posted an open letter warning businesses of the growing cyber security risks posed by AI models. What’s clear is that the capabilities of AI models under real-world scenarios are rapidly improving and, on the evidence of the recent AISI evaluation of Claude Mythos Preview, are probably accelerating. Not all recent benchmarking of AI’s abilities to solve difficult problems has delivered such impressive results. In a recent test of 19 AI models against a range of tasks including coding, crystallography, genealogy and music sheet notation, researchers at Microsoft found the models could be error-prone and unreliable, especially for longer tasks. Kat Traxler, principal security researcher at Vectra AI, sees the benchmarks as a useful signal that enterprises should pay attention to. “The AISI benchmarks don’t measure if models can spot a flaw. Rather, they measure whether various models can chain together a series of exploits into working attacks to achieve an end goal, like a real-world attackers do. As a signal of offensive capability, AISI’s results carry real weight,” she said. However, she pointed to a recent Xbow evaluation of Claude Mythos that found mixed performance at some tasks. “How these known model limitations will actually limit real-world autonomous offensive campaigns is still being determined, but it does point to the need for a sophisticated validation harness to truly see the ceiling of model capabilities.” According to Chris Lentricchia, director cloud and AI security strategy at Sweet Security, enterprises should also look at the upside — AI models aid attackers, but also defenders. “This is not purely an offensive story. The same acceleration improving attacker capability can also improve defensive capability in areas like proactive threat detection and response automation. Benchmarks are best viewed as indicators for understanding whether enterprise defenses are evolving fast enough to keep pace with accelerating AI capability,” said Lentricchia. View the full article

The ability of AI models to perform end-to-end, multi-stage penetration tests that match the capabilities of humans undertaking the same tasks has improved dramatically in recent months, according to new benchmarks published by the UK government’s AI Security Institute (AISI). In November 2025, the difficulty of cyber tasks the best models could complete was doubling every eight months, according to AISI, a research organization within the Department for Science, Innovation and Technology (DSIT). By February this year, the performance improvements had accelerated, with the difficulty of the tasks AI models could complete doubling every 4.7 months, and since then the latest Claude Mythos Preview and GPT-5.5 models are showing even greater capability, AISI said. The time horizon benchmarks used by AISI first measure or estimate the time it would take a human expert to solve a variety of challenges as a proxy for their difficulty and then estimate the longest task (in human work hours) that AI models can complete with a success rate of 80%. This makes it a measure of autonomous capability rather than speed: If a human can successfully complete a set of pen testing tasks in 4 hours, time horizon testing measures how successfully an AI model can match this capability at a given reliability. To achieve this, the AI must sustain performance over multiple steps while maintaining context and recovering from failures. The more steps, the more difficult pen testing becomes, and the more meaningful the results. As with all benchmarks, there are caveats. The first is that to compare performance between models over time, the testing capped the AI systems at a low 2.5 million tokens. This has a number of effects including, in these benchmarks, limiting the ability of the AI models to keep track of what they were working on at an earlier stage. As AISI said in its analysis, “They are inexact predictors of performance; AI struggles with some tasks humans do quickly, and easily completes others that humans find hard. However, we use this type of benchmark because it offers a measure of AI autonomy from which we can draw trends.” Growing risk The research is cause for concern for the UK government. “Our independent testing shows that cyber capabilities in leading AI systems are advancing much faster than we expected. That matters because this isn’t theoretical — those advances are already starting to translate into real risks for organisations, especially those with weak cyber defences,” UK AI Minister Kanishka Narayan said via email. “These tools can also help cyber security teams spot and fix weaknesses faster. The UK is leading the way in testing and understanding frontier AI, and that capability is only going to become more important as the technology continues to move at pace,” he added. In April, DSIT Secretary of State Liz Kendall and Security Minister Dan Jarvis posted an open letter warning businesses of the growing cyber security risks posed by AI models. What’s clear is that the capabilities of AI models under real-world scenarios are rapidly improving and, on the evidence of the recent AISI evaluation of Claude Mythos Preview, are probably accelerating. Not all recent benchmarking of AI’s abilities to solve difficult problems has delivered such impressive results. In a recent test of 19 AI models against a range of tasks including coding, crystallography, genealogy and music sheet notation, researchers at Microsoft found the models could be error-prone and unreliable, especially for longer tasks. Kat Traxler, principal security researcher at Vectra AI, sees the benchmarks as a useful signal that enterprises should pay attention to. “The AISI benchmarks don’t measure if models can spot a flaw. Rather, they measure whether various models can chain together a series of exploits into working attacks to achieve an end goal, like a real-world attackers do. As a signal of offensive capability, AISI’s results carry real weight,” she said. However, she pointed to a recent Xbow evaluation of Claude Mythos that found mixed performance at some tasks. “How these known model limitations will actually limit real-world autonomous offensive campaigns is still being determined, but it does point to the need for a sophisticated validation harness to truly see the ceiling of model capabilities.” According to Chris Lentricchia, director cloud and AI security strategy at Sweet Security, enterprises should also look at the upside — AI models aid attackers, but also defenders. “This is not purely an offensive story. The same acceleration improving attacker capability can also improve defensive capability in areas like proactive threat detection and response automation. Benchmarks are best viewed as indicators for understanding whether enterprise defenses are evolving fast enough to keep pace with accelerating AI capability,” said Lentricchia. View the full article

Security researchers have developed a new image-based prompt injection attack that can manipulate how multimodal AI systems interpret user instructions without modifying the original text prompt, potentially expanding security risks for AI agents and vision-language systems. In a research paper published this week, researchers from Xidian University described a technique called “CrossMPI,” which uses nearly imperceptible image perturbations to alter how large vision-language models (LVLMs) process both visual and textual inputs. “CrossMPI can steer the model’s interpretation of both textual and visual inputs via image-only prompt injection,” the researchers wrote in the paper. Unlike traditional prompt injection attacks, which typically rely on malicious text instructions embedded in prompts or webpages, the new technique attempts to change how the model interprets a benign user request by manipulating images alone. “The perturbed image can manipulate the model’s understanding of the user’s instruction,” the paper said. In one example described in the paper, researchers subtly modified an image of an airplane using nearly imperceptible pixel-level perturbations invisible to human users. When a multimodal AI system was then asked whether the airplane belonged to Air Canada, the manipulated image caused the model to incorrectly identify the object as “a mobile phone,” illustrating how the attack could distort both visual understanding and interpretation of the user’s task. The findings add to growing concerns around multimodal AI security as enterprises increasingly deploy AI copilots, autonomous agents, document-processing assistants, and vision-enabled workflows that combine image and text reasoning. Apeksha Kaushik, senior principal analyst at Gartner, said the risks could grow rapidly as enterprises adopt more multimodal AI systems. “By 2030, 80% of enterprise software and applications will be multimodal, up from 1% in 2024,” Kaushik said. Attack targets multimodal reasoning layers Prompt injection has emerged as one of the most closely watched risks in generative AI systems, particularly as organizations adopt AI agents capable of interacting with enterprise applications, websites, documents, and external tools. Most existing prompt injection attacks rely on malicious text embedded in prompts, webpages, or hidden instructions. Some multimodal attacks have also attempted to manipulate AI behavior using images containing visible or hidden text instructions. The researchers argued their approach differs because it attempts to alter how the model interprets the original task itself through image perturbations alone. By contrast with earlier methods, the researchers noted that CrossMPI uses image modifications to “change the model’s interpretation of both the visual and textual prompts.” The paper said the attack specifically targets the “hidden state space of LVLMs” — the stage where models combine textual instructions and visual evidence into internal representations before generating outputs. According to the paper, the most effective attack layers were not the final output layers traditionally targeted in adversarial AI attacks, but intermediate layers where visual and textual information are fused together. Researchers claim strong black-box transferability The researchers evaluated the technique against multiple open-source LVLMs, including MiniGPT4, BLIP-2, InstructBLIP, BLIVA, and Qwen2.5-VL, the paper added. According to the paper, the attack achieved an average success rate of 66.36% across tested models, outperforming prior baseline attacks by roughly 41 percentage points. The researchers also said the technique demonstrated “strong transferability in black-box settings,” meaning the attacks remained effective even without direct access to a target model’s parameters or architecture. The paper further claimed the perturbations remained visually stealthy while maintaining effectiveness across multiple LVLM architectures. No effective defense The researchers evaluated several defense mechanisms designed to neutralize hidden image manipulations, including random resizing, image rotation, JPEG compression, and inference-level safeguards such as SmoothVLM, a specialized defense framework designed to protect Vision-Language Models (VLMs) from patched visual prompt injections, and DPS, which guides models using partial image views. According to the paper, SmoothVLM proved the most effective, reducing attack success rates to below 5% in several scenarios, while JPEG compression also weakened the attacks by suppressing high-frequency image artifacts. However, the researchers said none of the tested defenses completely eliminated the attacks, suggesting stronger multimodal AI security protections may still be needed. Enterprise AI deployments may widen exposure The research arrives as enterprises rapidly expand deployments of multimodal AI systems capable of processing screenshots, PDFs, dashboards, forms, video streams, and enterprise documents alongside natural language prompts. The researchers noted that adversarial examples generated using the technique could potentially “mislead VLM-based web agents” and “disrupt real-world object detectors.” “Even if textual inputs are sanitized, manipulated images can still subvert the model’s outputs or actions,” Kaushik said. She said organizations that use multimodal AI for document processing, customer interactions, content moderation, and autonomous systems may face increasing exposure to adversarial image manipulation and prompt injection attacks. “Security controls designed for unimodal systems are insufficient,” Kaushik said. The researchers acknowledged that the work was conducted in controlled research settings using open-source models and did not describe observed exploitation in real-world enterprise environments. View the full article