2026-06-10 AI创业新闻

Microsoft Defender RoguePlanet Zero-Day Grants SYSTEM Access on Updated Windows

The anonymous security researcher going by the name Chaotic Eclipse (aka Nightmare-Eclipse) has released a proof-of-concept (PoC) exploit for yet another Microsoft Defender zero-day named RoguePlanet . “The exploit is a race condition, so it’s a hit or miss,” the researcher, who published the exploit under a new GitHub account, “MSNightmare” said . “I have managed to get a 100% success rate on some machines while it struggled to work on others.” Should the exploit succeed, the result is a shell with SYSTEM-level privileges, granting the attacker the ability to run arbitrary code or perform unauthorized actions. The researcher said the exploit has been tested on Windows 11 and 10 machines with the June 2026 Patch Tuesday updates installed, meaning the exploit works on the up-to-date versions of the desktop operating system.

That said, the exploit does not work on Windows Server instances in its current form since “standard users cannot mount an ISO image.” Chaotic Eclipse emphasized that Windows Server installations are also vulnerable to the flaw and that the exploit needs to be redesigned for it to work. “Getting this PoC to work genuinely drained my soul, it severely degraded my mental and physical health but in the end of May [sic], a full PoC was developed,” the researcher said. “Microsoft’s efforts to protect Defender from path redirection attacks are useless, I have a batch of memory corruption vulnerabilities in defender as well and not to mention the other batch of vulnerabilities I have in several other components.” Security researcher Will Dormann, in a post shared on Mastodon, said “it’s reportedly not 100% reliable, but it worked on the first attempt for me.” RoguePlanet is the latest in a series of flaws uncovered by Chaotic Eclipse in recent months - BlueHammer (CVE-2026-33825) UnDefend (CVE-2026-45498) RedSun (CVE-2026-41091) These uncoordinated disclosures are part of what’s assessed to be a retaliatory effort following an alleged breakdown in communication between the researcher, who has not publicly identified themselves, and Microsoft. In cryptographically signed posts on their Blogger page, Chaotic Eclipse expressed dissatisfaction with the way Microsoft handled the disclosure process and called out the company for revoking access to their Microsoft Security Response Center (MSRC) account, where researchers can report vulnerabilities.

The researcher has also accused Redmond of humiliating them, dismissing their reports, failing to compensate them for the identified vulnerabilities, and defaming them. Late last month, Microsoft condemned the public vulnerability disclosures, stating they are “never justifiable” and put customers at “unnecessary risk.” It’s worth noting that all three aforementioned Defender vulnerabilities have since been exploited in the wild. The public feud has also resulted in the takedown of their GitHub and GitLab accounts. “Microsoft is attempting to misuse its ownership of GitHub to protect only its own products, and misuse its extensive links to law enforcement by branding publishing information about vulnerabilities in its own products as criminal behaviour,” security researcher Kevin Beaumont said .

“To be clear about our approach to legal matters, we have no intention to pursue action against individuals conducting or publishing their security research,” Microsoft said in an X post. “When an individual breaks the law and engages in malicious activity causing real harm to our customers, we will work with law enforcement as appropriate.” “We are committed to approaching every interaction with transparency, clear communication, and professionalism. We continue to believe strongly in Coordinated Vulnerability Disclosure as the foundation for protecting customers and improving our products.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Six Proto6 Vulnerabilities in protobuf.js Expose Node.js Apps to RCE and DoS

Cybersecurity researchers have flagged half a dozen vulnerabilities in protobuf.js, a JavaScript and TypeScript implementation of Protocol Buffers ( Protobuf ), that, if successfully exploited, could result in remote code execution (RCE) and denial-of-service (DoS) attacks. “In affected environments, a single malicious protobuf schema, descriptor, or crafted payload could be enough to trigger crashes, runtime corruption, or even code execution,” Cyera security researcher Assaf Morag said . The vulnerabilities have been codenamed Proto6 . Protobuf is a free and open-source, language-agnostic mechanism for serializing structured data.

It was originally developed and used internally by Google before it was made publicly available in 2008. The identified vulnerabilities affect Node.js applications that use protobuf.js, Google Cloud client libraries, messaging frameworks like Baileys , and CI/CD pipelines. Per Cyera, any Node.js service that deserializes Protobuf data or generates code from schemas with protobuf.js is likely impacted as well. A brief description of each of the flaws is below - CVE-2026-44289 (CVSS score: 7.5): DoS through unbounded protobuf recursion CVE-2026-44290 (CVSS score: 7.5): Process-wide DoS when loading schemas with unsafe option paths CVE-2026-44291 (CVSS score: 8.1): Code generation gadget after prototype pollution CVE-2026-44292 (CVSS score: 5.3): Prototype injection in generated message constructors CVE-2026-44294 (CVSS score: 5.3): DoS from crafted field names in generated code CVE-2026-44295 (CVSS score: 8.7): Code injection in pbjs static output from crafted schema names Cyera said all the vulnerabilities stem from the library’s handling of schema and metadata as trusted by default.

This validation oversight could influence application behavior and lead to code execution. “While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations,” Morag noted. In a potential attack scenario, a bad actor could introduce a malicious protobuf schema to poison CI/CD workflows, leaking build secrets in the process (CVE-2026-44295), or crash Node.js services such as WhatsApp bots built using Baileys, a WhatsApp Web API automation TypeScript library, by means of a specially crafted message (CVE-2026-44292). The most severe of the lot is CVE-2026-44291, which results in code execution when a Node.js application accepts attacker-controlled input.

“That input reaches a prototype pollution gadget,” security researcher Vladimir Tokarev explained . “Later, the same process uses protobuf.js to encode or decode a message. Because protobuf.js resolves type names through plain property lookups, a polluted Object.prototype can make an attacker-controlled string look like a valid protobuf primitive.” “Protobuf.js then inserts that string into a generated encoder or decoder function and compiles it with Function(). The attacker gets arbitrary JavaScript execution inside the Node.js process.” The following versions of the tool are vulnerable - protobuf.js: versions <= 7.5.5 and >= 8.0.0 <= 8.0.1 protobufjs-cli: versions <= 1.2.0 and >= 2.0.0 <= 2.0.1 Patches for the flaws are available in protobufjs 7.5.6 and 8.0.2, and protobufjs-cli 1.2.1 and 2.0.2.

Users are advised to apply the latest fixes to safeguard against potential threats. “Because protobuf.js is heavily used inside databases, vector stores, inference pipelines, orchestration systems, CI/CD tooling, and cloud SDKs, successful exploitation could impact sensitive enterprise and AI workloads at scale,” Cyera said. “Modern software increasingly treats schemas, metadata, and configuration files as trusted inputs that drive automation, orchestration, and code generation. When those trust assumptions break, data can become behavior.

That shift creates new attack surfaces that security teams must learn to identify and manage.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Meta to Use Off-Site Business Data for Feed and AI Personalization

Meta on Tuesday announced that it will use information shared by other businesses to personalize users’ feed and responses from its artificial intelligence (AI) chatbot, expanding its scope beyond targeted ads. “Businesses often share information about people’s activity on their sites with us to make ads more relevant,” Meta said in a statement. “We already use this data - like games you play or purchases you make on other websites - to make the ads you see more relevant. In the future, we’ll use this information to personalize other parts of your experience, including the content you see in your Feed and AI responses.” The social media giant emphasized that it’s not collecting any new data as part of the update, adding users are in the driver’s seat and that they get to decide how this information is used for personalization.

To that end, Meta is streaming its controls by expanding the “Activity from other businesses” setting (formerly “Activity information from ad partners”) to better manage how data from other businesses are used for this purpose. The setting “Your activity off Meta technologies” will be discontinued. “If you allow us to use this data to show you personalized content, the ads and other content you see will be more relevant,” the company said. “For example, if you’ve recently purchased a tent online, you might see more Reels about camping.” However, if users don’t allow it, the content shown will be based on other activity on its platforms, such as liking a reel or post.

It’s worth pointing out that businesses can also share customer lists with Meta

e.g., those that have signed up to receive emails - who are then served relevant ads. Meta said the new option allows users to manage how the data is used to serve both ads and non-ad content. The change is expected to go into effect in the U.S. and a number of other countries, including the U.K., Brazil, Thailand, South Africa, Turkey, South Korea, Ecuador, Nigeria, and Kenya, starting next month.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

State of AI in the Cloud 2026: How AI is Reshaping Cloud Attack Surface

Veeam Backup & Replication RCE Flaw Lets Domain Users Run Remote Code

Veeam has released security patches to address a critical flaw in its Backup & Replication software that could result in remote code execution. Tracked as CVE-2026-44963 , the vulnerability carries a CVSS score of 9.4 out of a maximum of 10.0. “A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user,” Veeam said in a Tuesday advisory. It credited watchTowr researcher Sina Kheirkhah for responsibly discovering and reporting the issue.

It impacts Veeam Backup & Replication 12.3.2.4465 and all earlier versions of 12 builds. Veeam has noted that the vulnerability does not affect any version 13.x build of the backup software due to architectural changes introduced in version 13. The shortcoming has been addressed in Veeam Backup & Replication version 12.3.2.4854. In March 2026, Veeam resolved multiple critical vulnerabilities in Backup & Replication software that, if successfully exploited, could result in remote code execution.

It’s essential that users update to the latest version for optimal version, particularly given that prior vulnerabilities in the program have been exploited by bad actors, including ransomware groups. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Restores Some GitHub Repos, Keeps Others Offline as Miasma Probe Continues

Microsoft on Monday confirmed that it temporarily removed some GitHub repositories in response to a recent security incident that led to 73 of its open-source projects being compromised to inject an information stealer into the code. “Our priority is to protect customers and the broader ecosystem,” a Microsoft spokesperson told The Hacker News via email. “We temporarily removed some repositories as we investigated potential malicious content. Some of these repos have been restored after review, while others may remain offline while work continues.” “As part of our investigation, we notified a small number of customers who may have pulled down content from the affected repositories.

We will continue to investigate, and if anything further is identified that requires customer action, we will reach out directly through our established support channels.” The development comes days after the Windows maker cut off access to dozens of its open-source projects hosted on GitHub following reports that they were compromised as part of an ongoing software supply chain campaign codenamed Miasma. Among the projects that were infected included “durabletask,” a Python package that was first compromised last month by a cybercrime group known as TeamPCP to deliver an information stealer designed for Linux systems. Further analysis of the Miasma payload embedded into the projects has uncovered capabilities to trigger automatic code execution when an unsuspecting developer opens the repository in an artificial intelligence (AI)-powered coding tool or integrated development environment (IDE). The findings are the latest in a sustained software supply chain campaign that has breached widely used open-source packages to plant malware capable of propagating to downstream users and beyond.

This includes a newer PyPI wave tied to the broader Mini Shai-Hulud, Miasma, and Hades waves, infecting an additional set of 23 packages, including some bioinformatics-related libraries used in graph learning, patient phenotyping, phenopacket tooling, and scientific workflows. Some of the other packages include a collection of AI and Model Context Protocol (MCP)-themed packages and typosquat-style packages such as rsquests, tlask, and rlask that impersonate requests and flask, and a langchain-core-mcp. The complete list of legitimate and bait packages is below - dreamgen 1.8.1 embiggen 0.11.97 ensmallen 0.8.101 gpsea 0.9.14 instructor-mcp 1.15.2, 1.15.3 langchain-core-mcp 1.4.2, 1.4.3 mem8 6.0.1 mflux-streamlit 0.0.3, 0.0.4 openai-mcp 2.41.1, 2.41.2 orchestr8-platform 3.3.2 phenopacket-store-toolkit 0.1.7 ppkt2synergy 0.1.1 pyphetools 0.9.120 ray-mcp-server 0.2.1 rlask 3.1.7 rsquests 2.34.3 tiktoken-mcp 0.13.1, 0.13.2 tlask 3.1.4 The new cluster employs a new payload delivery mechanism, per Socket , indicating that the threat actors are adapting and actively experimenting with different methods as part of what has been described as a “fast-moving supply chain campaign.” While the earlier packages used executable .pth startup hooks to bootstrap Bun and run an obfuscated JavaScript stealer, the latest set incorporates different approaches - Trojanized native .abi3.so extensions that execute the stealer when the package is imported A .pth startup hook loader variant that searches sys.path for the “_index.js” payload instead of bundling the payload in the same wheel “That last variant separates the loader from the JavaScript payload, which could make the package look less obviously malicious during static analysis,” Socket told The Hacker News. Regardless of the method used, the end result is the same.

Once executed, the malware targets developer workstations and CI/CD environments, harvesting high-value secrets and exfiltrating them to a public GitHub repository. Kirill Boychenko, senior threat intelligence analyst at the company, told The Hacker News via email that the latest assortment of Python libraries marks the first time the Mini Shai-Hulud / Miasma / Hades-linked attacks have mixed compromised legitimate packages with threat actor-published typosquats and ecosystem-lure packages. “Earlier publicly documented TeamPCP-linked attacks primarily involved poisoned releases of real projects, compromised publisher accounts, or compromised CI/CD release paths, rather than brand-new lookalike packages,” Boychenko said. As for why the threat actors would embrace the approach at this stage of the operation, the researcher said the likely reason is tactical diversification.

“Compromised legitimate packages give them trust and reach, but those paths depend on stolen credentials or CI/CD access that can be revoked quickly,” Boychenko added. “Typosquats and ecosystem-bait packages are easier to publish, faster to iterate on, and useful for testing new malware loader behavior without burning a high-value compromised project. The MCP and AI-themed names also fit a fast-moving ecosystem where developers may install unfamiliar packages that look plausible.” A key capability of the bioinformatics package is its ability to derail and bypass AI-powered scanners and analyst copilots by means of an adversarial prompt injection embedded within a JavaScript block comment, an aspect previously detailed by StepSecurity. “The Hades branch of the Shai-Hulud and Miasma activity is best understood as a fast-moving supply chain campaign, not a single package incident,” Boychenko said.

“The langchain-core-mcp variant goes further by installing a .pth loader that searches sys.path for _index.js, meaning the loader and payload do not need to live in the same wheel.” (The story was updated after publication to include a response from Socket.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

WinRAR Flaw Exploited by Russia-Aligned Groups to Deploy Stealers in Ukraine

Two Russia-aligned cyber attack campaigns have continued to exploit a security flaw in WinRAR to target Ukrainian organisations, almost a year after patches for the vulnerability were released. The activity has been attributed by Trend Micro to Earth Dahu (aka Gamaredon) and SHADOW-EARTH-066 (aka UAC-0226). It involves the exploitation of CVE-2025-8088 , a path traversal flaw that allows an attacker to write files outside the extraction directory via NTFS Alternate Data Streams (ADS). It was patched by WinRAR in July 2025.

The findings show “how unmanaged software keeps an exploited entry point open long after the fix ships,” Trend Micro researchers Hiroyuki Kakara and Feike Hacquebord said in an analysis published Monday. The WinRAR exploit chain exploited by SHADOW-EARTH-066 is a departure from Excel macro droppers previously used by the threat actor to deliver an information stealer called GIFTEDCROOK. The latest iteration makes use of crafted RAR archives featuring a decoy PDF document and three hidden ADS payloads that are outside the extraction directory to initiate the infection. This includes a Windows Shortcut (LNK) file that’s placed in the Startup folder so that it’s automatically executed every time a user logs in.

This, in turn, spawns a PowerShell loader via “cmd.exe,” which then uses in-memory DLL loading to ultimately launch an updated version of GIFTEDCROOK (“result.dll”). The malware targets passwords and cookies from Chromium-based browsers (Google Chrome, Microsoft Edge, and Opera) and Mozilla Firefox, in addition to harvesting documents matching certain extensions from the victim’s machine. Once the data is exfiltrated to an external server, all malicious artifacts are deleted to cover up the forensic trail. A notable change is the shift from Telegram as an exfiltration channel to dedicated command-and-control (C2) servers, a key modification that likely aligns with Russia’s blocking of the messaging platform in the country earlier this February.

The second Russia-affiliated hacking group to weaponize CVE-2025-8088 is Earth Dahu, which has incorporated the flaw into its arsenal since at least September 2025. The adversary is known for its “industrial-scale effort” to maintain long-term access to compromised organizations. “Earth Dahu used the vulnerability with an HTA-to-VBScript infection chain that delivered espionage modules,” Trend Micro noted. “Based on RAR internal file timestamps and file naming conventions, the chain remained active through at least April 10, 2026.” These attacks, as recently also documented by Sekoia last week, lead to the deployment of GammaPhish, an HTML Application (HTA), which is then used to retrieve a VBScript downloader named GammaLoad.

The intermediate downloader subsequently delivers additional modules like GammaSteel. GammaLoad is “a collection of VBScripts designed to ensure continuous access and deploy payloads over time by leveraging Dead Drop Resolvers (DDR),” Sekoia said , adding it’s used to deploy a dropper that’s designed to launch a VBScript loader responsible for executing GammaSteel , a comprehensive information stealer that can monitor changes to files in real-time. “WinRAR is deeply embedded in daily operations across Ukrainian organizations, making it an attractive target for exploitation,” Trend Micro said. “The convergence of both established state-backed groups and independently tracked clusters on a single vulnerability reflects the scale of the cyber threats that Ukraine faces.” Found this article interesting?

Researchers Build Self-Replicating AI Worm That Operates Entirely on Local, Open-Weight Models

University of Toronto researchers have built and tested a proof-of-concept AI-driven computer worm that uses a locally hosted open-weight large language model to reason its way through a network, generate tailored attack strategies for each target it encounters, and replicate itself, all without human intervention and without touching a commercial AI service. The preprint, posted to arXiv on June 2 and currently under peer review, shows why single-CVE patching breaks down when malware can inspect exposed services, read fresh advisories, and generate a new attack path at runtime. In 15 isolated runs on a deliberately vulnerable 33-host network, the worm identified an average of 31.3 vulnerabilities and gained elevated access on 23.1 hosts, roughly three-quarters of the hosts it actively targeted. It then replicated autonomously to 20.4 of those hosts, or 62% of the full network, over seven days, with no prior knowledge of the network topology and no human input.

Traditional worms ship with a fixed exploit payload chosen at build time. Patch those specific bugs, and the worm stops spreading. This worm does something different: it uses an open-weight LLM running on a single GPU to generate attack logic at runtime, tailored to whatever it finds on the next target. No pre-encoded exploit chain.

No dependency on OpenAI, Anthropic, or any other API that a platform could revoke or rate-limit. What the worm actually did Led by associate professor Nicolas Papernot, the CleverHans Lab team spans the University of Toronto, Vector Institute, University of Cambridge, and ServiceNow. They ran 15 independent experiments on an isolated 33-host network (“FakeCorp”) spanning Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019, and 2022, and IoT devices. Each host had at least one real-world vulnerability.

Five of the 33 machines had GPUs. In the main propagation experiments, the worm used a shared GPU inference pool to simulate compute acquired from victim machines. The team separately tested full GPU-tier replication, in which the worm stages a local LLM instance on a compromised GPU host; that succeeded in 68.8% of attempts. In the tiered design, infected GPU-capable hosts serve as distributed reasoning nodes that provide inference for lower-compute devices on the network that cannot run the model themselves.

Across the 15 runs, the worm gained elevated access on 23.1 hosts and successfully launched a replica on 88% of those. It reached up to seven generations of self-replication, with a mean of 5.1. The setup was intentionally vulnerable: the paper says the test measures autonomous reasoning across realistic individual flaws, not spread through a mostly hardened production network under active endpoint defense. Exploits across a single run included a chained SambaCry and writable root cron privilege escalation, Dirty Pipe , PrintNightmare , Drupalgeddon 2 , Exim RCE , blind SQL injection, JWT bypass, Redis escape, and more, not because they were pre-programmed, but because the agent reasoned its way to them from what it found on each host.

The paper’s Figure 2 maps the full radial propagation tree across one run, showing six to seven generations of spread across Linux, Windows, and IoT hosts. Individual exploit attempts succeeded about 44% of the time. Most failures came from malformed payload syntax, not flawed logic. Web app exploits and Windows privilege escalation were harder than Linux local escalation and service exploits, a capability ceiling the paper treats as a current model limitation, not a structural defense.

The patching-window problem The worm bypassed its own training cutoff by ingesting public advisory text at runtime, successfully exploiting test hosts configured with three vulnerabilities disclosed after the model was trained: CVE-2026-39987 , a pre-authentication RCE in the Marimo Python notebook (CVSS 9.3); CVE-2026-31431 (CopyFail) , a Linux kernel privilege-escalation flaw in the algif_aead module that CISA added to its Known Exploited Vulnerabilities catalog in May; and CVE-2026-43284 / CVE-2026-43500 (DirtyFrag) , related Linux kernel local privilege-escalation issues. Against those three hosts, the worm reached root in 41 of 67 attempts. CVE-2026-39987 was disclosed on April 8, 2026. Sysdig observed exploitation in honeypots 9 hours and 41 minutes after that, and separately documented a real-world intrusion where an attacker used an LLM agent for post-exploitation activity after compromising a public Marimo instance.

Same old patch gap, now with an agent reading the advisory and trying it at scale. The relevant parallel to WannaCry is the patch gap, not the blast radius. EternalBlue had been patched for months before WannaCry struck. The paper is making the same point under a different constraint: an adaptive worm can keep testing new paths while defenders are still validating fixes.

Zero marginal cost, no central kill switch Two things make this harder to contain than a traditional worm. First, the cost shifts from rented API access to whatever compute the worm can capture. Once a GPU-capable victim infrastructure exists, the attacker no longer pays per attempt. Second, because everything runs on open-weight models with no vendor dependency, provider-side controls miss the core problem.

Service refusals, rate limiting, account suspension: none of it applies. There is no API key to revoke. Containment has to happen at the network and host layer. The researchers also observed the worm rewrite its own code on several occasions to bypass local security controls in the test environment, behavior they never coded for.

The current version was deliberately built without stealth features: no encryption, no polymorphic code, no persistence mechanisms, no covering of tracks. A malicious variant with persistence, encrypted payloads, process masquerading, and log cleanup would give defenders fewer of the easy signals this prototype leaves behind. Where this fits This is not the first AI-driven worm research. Morris II (Cohen et al., 2025) showed a self-replicating adversarial prompt spreading across AI email assistants through retrieval-augmented generation, propagation within the AI application layer, not across host infrastructure.

In March 2026, ClawWorm demonstrated self-replicating attacks across LLM agent ecosystems, hijacking persistent configurations and propagating to agent peers. The Toronto worm is different in kind: the LLM is not the thing being attacked. It is the attack engine being used to compromise ordinary network infrastructure. Real-world operations are already testing the same boundary.

Anthropic said in November 2025 that it disrupted a large AI-orchestrated espionage campaign attributed with high confidence to GTG-1002, a Chinese state-sponsored group. Claude Code handled 80-90% of the operation, including reconnaissance, exploit development, credential harvesting, lateral movement, and exfiltration, with humans stepping in at a few decision points. Google’s Threat Intelligence Group reported a related shift in May 2026: what it assessed with high confidence to be the first zero-day exploit developed with AI assistance, found in a criminal group’s script ahead of a planned mass exploitation event, alongside malware families that generate their own commands at runtime rather than relying on hardcoded logic. The Toronto work is the lab version of that direction pushed into host-level worm propagation.

The direction is clear enough: less prompting, more delegation, and more of the intrusion handed to the model. What should defenders do now? The behavioral signals this prototype produces give defenders something concrete to hunt for, because the current version does not try to hide. Segment GPU-capable machines aggressively.

The worm’s design routes LLM inference through any compromised GPU host it can reach. In a flat network, one compromised deep-learning server becomes a reasoning hub for every infected device on the same subnet. Segment GPU infrastructure and apply zero-trust controls to prevent lateral reach to and from those hosts. Treat published advisories as near-term weaponization targets.

For internet-facing CVEs, the exploitation window is already measured in hours for some vulnerabilities. Verify exploitability fast, patch internet-facing exposure first, and use compensating controls when deployment cannot happen before the next business cycle. Rotate credentials exposed on any compromised or credibly suspected host. The worm demonstrated systematic credential reuse as a propagation path.

Harvested credentials move laterally faster than most detection cycles. Monitor for agent-specific behavioral signals. Non-standard port activity, automated SSH public key injection, and clusters of LLM inference appearing on unexpected endpoints are the observable artifacts this prototype leaves behind. They are the starting point for detection logic.

In the test runs, that combination produced root on fresh vulnerabilities in 41 of 67 attempts and replication to 62% of the network in seven days with no further human input. Once a GPU foothold exists inside a flat network, the cost of mapping and exploiting additional hosts drops to whatever compute the worm can capture, while public advisories become immediate playbooks. The implementation is not publicly released. The University of Toronto is establishing a vetting process for qualified defensive researchers to request access.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Chrome V8 Zero-Day CVE-2026-11645 Exploited in the Wild - Patch Now

Google has released security updates to address 74 vulnerabilities, including one that has come under active exploitation in the wild. The high-severity vulnerability, tracked as CVE-2026-11645 (CVSS score: 8.8), has been described as an out-of-bounds memory access in V8, Chrome’s JavaScript and WebAssembly engine. “Out-of-bounds read and write in V8 in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page,” reads a description of the flaw in the NIST’s National Vulnerability Database (NVD). A security researcher named “303f06e3” has been credited with discovering and reporting the flaw on April 27, 2026.

The researcher has been awarded a bug bounty of $55,000 for responsible disclosure. As is customary in these cases, Google acknowledged that an “exploit for CVE-2026-11645 exists in the wild,” but stopped short of sharing additional specifics to ensure that a majority of the users are updated with a fix and to prevent further exploitation. With the latest development, Google has addressed a total of five actively exploited Chrome zero-days since the start of the year. This includes CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, and CVE-2026-5281.

For optimal protection, users are advised to update their Chrome browser to versions 149.0.7827.102/.103 for Windows and Apple macOS, and 149.0.7827.102 for Linux. To make sure the latest updates are installed, users can navigate to More > Help > About Google Chrome and select Relaunch. Users of other Chromium-based browsers, such as Microsoft Edge, Brave, Opera, and Vivaldi, are also advised to apply the fixes as and when they become available. Found this article interesting?

The Hidden Security Risk in Modern Networks: The Work Between Tools

Organizations have more visibility than ever. Growing tech stacks provide greater coverage, and network security teams are increasingly adopting AI and automation to help with routine tasks and reduce manual effort. But the same challenges persist. Outages still last hours, causing significant financial losses, operational disruption, and reputational impact.

Threat response and mean time to remediate (MTTR) remain slow. Misconfigurations and human error still create major incidents. And, despite the promises of AI, teams remain overwhelmed and burnt out. Detection isn’t the issue.

Neither is tooling. Today, the real problem is execution - that is, the work that happens between tools. The hidden operational layer most organizations overlook Every time an alert fires, network security teams must: Gather context across systems Validate ownership and severity Route tickets to the appropriate people Request approvals Implement changes manually Log evidence This operational work spans multiple systems and environments, requiring analysts to context-switch between: SIEM Firewalls Identity and access management (IAM) systems ITSM Monitoring platforms Cloud, on-prem, and hybrid environments Messaging and collaboration apps This isn’t just time- and labor-intensive. Manual processes also increase opportunities for human error - including inconsistencies, missed steps, and compliance gaps - introducing risks that can quickly compound.

Recent industry shifts have only made the problem worse. Distributed infrastructure, API sprawl, and increasingly interconnected tooling have expanded the number and complexity of systems teams must coordinate across. Attack velocity is increasing, and threats are becoming more sophisticated. At the same time, AI is accelerating operations and raising expectations of scale and speed, putting teams under increased pressure to deliver with limited capacity.

The key takeaway? Although today’s environments may be more connected technically, the underlying operational workflows remain fragmented - creating bottlenecks, slowing response times, and limiting security’s business impact. 3 places where the work between tools creates risk When teams manually coordinate work between systems, people, and tools, operations can quickly break down. Here are three critical workflows where disconnected processes put your organization at risk.

Alert triage and incident response Detection may be automated, but investigation and coordination usually aren’t. Teams must manually gather context across systems to enrich alerts and dismiss false positives, increasing investigation time and using valuable resources that could be better spent on more complex problems. These slow, manual processes lead to: Delays in identifying, escalating, containing, and remediating issues Missed threats that become real security incidents Alert fatigue that leads to poor analysis quality, missed true positives, and team burnout 2.

Access and change management Security-sensitive processes still rely heavily on humans as the integration layer. Access requests and network changes require manual approvals, which can lead to inconsistent validations and gaps in policy enforcement. Security and IT often work in separate systems, leading to duplicate work, delayed provisioning, and poor visibility into changes. At scale, this can cause: Overprivileged access that violates least-privilege and Zero Trust principles Misconfigurations that create security vulnerabilities and outages Audit and compliance gaps that expose your organization to regulatory risk 3.

Hybrid and multi-environment operations Working across fragmented technology and hybrid environments adds complexity and operational overhead, as analysts must switch between different tooling and ownership models. Inconsistent processes and visibility gaps between teams make it difficult to maintain accountability, enforce standards, and execute reliably across systems. This fragmentation can result in: Configuration drift that creates network instability and compliance risks Delayed responses to threats and incidents Security gaps due to inconsistent policy enforcement across environments What forward-thinking organizations are doing differently The solution isn’t replacing tools. It’s orchestrating how work moves across them.

To do this, organizations are adopting intelligent workflows . Intelligent workflows are the operational layer that connects systems, teams, approvals, automation, and decision-making across all environments. They combine three essential types of workflow: Deterministic automation to handle highly predictable, reliable, and controlled tasks AI to assess context, make decisions, and execute tasks autonomously Humans to handle high-impact, high-stakes tasks that require judgment and creativity Unlike automation alone , which only handles discrete, isolated tasks, intelligent workflows enable network security teams to orchestrate entire processes from beginning to end, while still providing the flexibility, control, and oversight needed to apply the right approach to the right task. What does an intelligent workflow look like in practice?

Consider the alert triage and incident response process above. Using intelligent workflows: A monitoring tool detects unusual activity and creates an alert AI pulls context from multiple systems to triage, enrich, and prioritize the alert based on severity and risk If the alert meets specific predefined conditions, the workflow automatically triggers actions, like containment or remediation processes If human judgment is required, the workflow routes the issue to the appropriate analyst for deeper investigation or approval All actions, decisions, and evidence are automatically logged to support auditing and compliance requirements Before, the work between tools led to delays, missed threats, and alert fatigue. Now, intelligent workflows handle the end-to-end process, enabling teams to move from detection to execution faster, reduce MTTR, and relieve the strain on analysts. How intelligent workflows enhance network security For network security teams in particular, intelligent workflows unlock a number of benefits: Standardization reduces inconsistencies, missed steps, and errors, ensuring responses follow defined protocols and guidance across the entire organization Automatic evidence logging eliminates manual effort and improves auditability Shared workflows provide cross-functional visibility, alignment, and accountability Reduced operational burden relieves analyst fatigue and wins back time for high-impact security work, like complex investigations or strategy Consistent execution strengthens security posture and reduces risk Faster coordination reduces response times and improves operational resilience All of this allows network security teams to operate at scale, extending their capacity without needing to add headcount.

Closing the gap between detection and execution The biggest operational risk in modern networks isn’t tooling or visibility - it’s the gap between detection and execution. The organizations that improve security and operational resilience don’t just add more technology. Instead, they improve how work moves across their environment, using intelligent workflows to orchestrate the work between tools. As network and security environments become more complex, this operational coordination will become just as crucial as visibility itself, enabling teams to operate securely, consistently, and at scale.

Learn more in Tines’ ultimate guide to network operations management . Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New FROST Attack Lets Websites Track What Sites and Apps You Open via SSD Timing

A malicious website can work out which sites you visit and which apps you open, using nothing but JavaScript and the timing of your SSD. The attack, called FROST , needs no native code, no extension, and no permission prompt. You open the page, leave the tab sitting there, and it watches the drive for contention in the background. Researchers at Graz University of Technology built it and described it in a new paper set to appear at DIMVA 2026.

It abuses a storage feature present in every major desktop browser, and the underlying timing channel works on both macOS and Linux. SSD timing attacks are not new. Last year the same group published Secret Spilling Drive , which read user behavior off a drive by watching how reads slow down when something else is using it. The catch was that it needed native code on the machine, through a low-level interface like Linux’s io_uring.

FROST drops that requirement. It runs inside the browser sandbox, which turns a local attack into a remote one. You no longer have to be on the machine to pull it off. The same Graz lab has done this before.

Its SnailLoad attack inferred the sites and videos a victim loaded from network latency alone, no JavaScript at all. How FROST Attack Works The way in is the Origin Private File System , or OPFS, a storage feature browsers added in 2023 so web apps like in-browser editors and IDEs can keep files on disk. OPFS gives each origin its own sandboxed slice of the file system, and because that slice is walled off, it skips the permission prompt a page normally needs to reach your files. No dialog, no click.

A site can just start writing. Normally the operating system hides disk timing behind the page cache, serving repeated reads from memory so they never touch the drive. FROST gets around this by creating a file larger than the machine’s RAM. The cache cannot hold all of it, so reads keep landing on the SSD.

On Chrome and Safari, OPFS can grow to 60% of disk space, far more than enough; Firefox caps each origin lower, though an attacker can spread the load across multiple origins to get past that. The attacker’s code then reads random 4 kB chunks of that file in a loop, and times each read with performance.now(). Browsers blunt their timers by default to make this kind of measurement harder, but the attacker sharpens the resolution back up by switching on cross-origin isolation, which it can do freely on its own page. When you open a site or launch an app on the same drive, that activity competes with the attacker’s reads, and the timing shifts measurably.

A neural network trained on those traces identifies the site or app. The accuracy is the uncomfortable part. On a Mac, against the top 50 websites, FROST identified the site being visited with an F1 score of 88.95% in a closed-world test, and held at 86.95% in an open-world test that added 300 sites it had never seen. For ten native, pre-installed macOS apps, it reached 95.83%.

The team also built a covert channel on the same signal, moving data from a cooperating native app to the malicious page at 661.63 bit/s on Linux and 719.27 bit/s on macOS through OPFS. The native attack was faster at its best, but that is a lot of data for code stuck inside a browser sandbox. While the timing channel also works on Linux, the team ran the full classifier only on macOS, so those fingerprinting numbers are a macOS result. FROST also only picks up activity on the same disk as its OPFS file.

A single-drive laptop puts everything on that disk; a multi-drive workstation hides whatever runs on a separate drive, though app startups that touch the home directory tend to leak anyway. What You Can Do Not much, for now. Google, Mozilla, and Apple were all told before publication. Google’s Chromium team does not treat fingerprinting as a security vulnerability.

Apple called it out of scope but left room for a mitigation later. Mozilla acknowledged it and has shipped nothing. There is no CVE, and no public evidence that the technique has been used in the wild. That leaves the defenses thin.

The measurement only runs while the attacker’s page is open, so closing the tab ends that run. Watching your browser’s storage for an unexplained multi-gigabyte file is another tell, though browsers do not make OPFS usage easy to see. On Linux, systems running profile-sync-daemon, a utility that keeps the browser profile in RAM, are incidentally protected against the zero-click version, because OPFS writes never reach the SSD. The weaker variant, where a page uses a file-picker dialog to get you to select a large file yourself, still works.

The fixes that would actually close it sit with the browser makers: capping OPFS size so the file fits in memory and generates no contention, throttling high-resolution timers while OPFS is in use, or putting a permission prompt in front of it. Each costs something in speed or usability, which is part of why none of them has happened. The real disagreement is whether a website quietly learning what you do on your own machine is a bug or a feature working as designed. The researchers’ real concern is structural: browsers keep handing web apps near-native access to the hardware, and near-native access brings near-native leakage with it.

FROST is one API. The pattern is the thing to watch. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Hades PyPI Attack: 19 Packages Poisoned to Auto-Run Bun Credential Stealer

The Miasma supply chain campaign has sparked a fresh attack wave called Hades , this time involving 37 malicious wheel artifacts across 19 packages in the Python Package Index (PyPI) registry, as the Mini Shai-Hulud-style attacks continue to be refined and splintered to target specific ecosystems. “The compromised releases shipped a *-setup.pth file that attempts to execute automatically during Python startup, download the Bun JavaScript runtime, and run an obfuscated JavaScript payload named _index.js,” Socket said in a new analysis. The list of identified packages is below - bramin 0.0.2, 0.0.3, 0.0.4 cmd2func 0.2.2, 0.2.3 coolbox 0.4.1, 0.4.2 dynamo-release 1.5.4 executor-engine 0.3.4, 0.3.5 executor-http 0.1.3, 0.1.4 funcdesc 0.2.2, 0.2.3 magique 0.6.8, 0.6.9 magique-ai 0.4.4, 0.4.5 mrbios 0.1.1, 0.1.2 napari-ufish 0.0.2, 0.0.3 nucbox 0.1.2, 0.1.3 okite 0.0.7, 0.0.8 pantheon-agents 0.6.1, 0.6.2 pantheon-toolsets 0.5.5, 0.5.6 spateo-release 1.1.2 synago 0.1.1, 0.1.2 ufish 0.1.2, 0.1.3 uprobe 0.1.3, 0.1.4 Like in the previous Shai-Hulud and Miasma campaigns, the malicious payload downloads and installs the Bun JavaScript runtime, which is then used to launch a heavily obfuscated JavaScript stealer that can harvest a wide range of data from developer systems. This includes secrets associated with GitHub, npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic, AWS, GCP, Azure, and Kubernetes, along with Docker configurations, Vault tokens, SSH keys, shell histories, .env files, .npmrc files, .pypirc files, Claude/MCP configurations, and other local or runner-accessible credentials.

What’s changed this time around is the campaign marker. While previous iterations exported the harvested data to a public GitHub repository with the description “Miasma: The Spreading Blight,” “Miasma: The Spreading Blight,” and “Miasma - The Spreading Blight,” the latest wave includes the repository descriptions - Hades - The End for the Damned Hades * The End for the Damned “That makes Hades best understood as a PyPI branch of the same Mini Shai-Hulud / Miasma lineage, not a standalone Python malware incident,” the application security company said. “The core playbook remains the same: abuse trusted package channels, execute before normal package use, stage a Bun-powered JavaScript payload, steal developer and CI/CD credentials, and use GitHub-centric exfiltration and propagation logic.” What has changed this time around is the use of a *-setup.pth file that’s processed by Python’s “site” module during interpreter startup, resulting in the execution of the malicious payload after installation without requiring the victim to import the poisoned package. The payload, in turn, downloads and runs Bun from GitHub and runs the stealer, but not before checking if the system corresponds to the Russian locale.

“This is the Python equivalent of the npm install-hook problem that Shai-Hulud and Miasma repeatedly exploit,” Socket explained. “The syntax is different, but the security consequence is the same: dependency installation creates an execution edge before application code is reviewed or invoked.” Hades Cluster Attempts to Mislead AI Security Scanners Also compromised as part of the Hades campaign are a number of packages related to the computational biology, bioinformatics, and genotype-phenotype analysis ecosystem - embiggen 0.11.97 ensmallen 0.8.101 gpsea 0.9.14 mflux-streamlit 0.0.3, 0.0.4 nhmpy 2.4.7 ppkt2synergy 0.1.1 pyphetools 0.9.120 Interestingly, this cluster employs a different approach in that the entry point is embedded inside the package’s “init.py” file as an obfuscated single-line import hook. However, the outcome is the same: Downloading and running the Bun runtime, followed by the execution of the JavaScript payload. “The use of the Bun runtime remains a consistent theme,” StepSecurity said .

“Downloading Bun as a standalone ZIP file allows the malware to run complex JavaScript tasks in environments that lack a Node.js installation, bypassing traditional package manager controls and network proxy logs.” In what has been characterized as a novel artificial intelligence (AI) defense evasion technique, the malware also incorporates a plain-text prompt injection that attempts to deceive Large Language Model (LLM)-based package analysis tools to instruct the model to classify the package as safe. On top of that, the malware queries GitHub commits for the keyword “TheBeautifulSnadsOfTime” to extract a Base64-encoded string containing a JavaScript payload. It also polls GitHub for commits matching the keyword “firedalazer” so as to fetch a Python-based dropper and execute it. Some of the important features built into the Hades malware are listed below - Replicate and spread laterally across developer networks via SSH or SCP, push trojanized versions of PyPI packages from compromised systems by exploiting the developers’ OpenID Connect (OIDC) trust configurations.

Target GitHub repositories to extract organization secrets using GitHub Actions runners if the harvested GitHub token has appropriate write permissions. Backdoor local workspace folders to trigger code execution when analyzed by AI assistants or opened in IDEs. Targets include Anthropic Claude, OpenAI Codex, Google Gemini, Microsoft Copilot, Cline, Aider, Tabby, Amazon Q, Cody, Bolt, and Continue. Install a background service named “gh-token-monitor” that acts as a wiper by removing all data (“rm -rf ~/; rm -rf ~/Documents”) if the stolen GitHub token is revoked by the developer.

“A key capability of the Miasma actor is reading the process memory of the GitHub Actions runner (the Runner.Worker process) to extract secrets,” security researcher Rohan Prabhu said. “In earlier campaigns, this was limited to Linux systems using /proc/{pid}/mem. The Hades Campaign introduces tailored macOS and Windows memory scrapers.” The development comes as StepSecurity revealed that an unknown attacker compromised the GitHub account (“LeonOstrez”) linked to “Pythagora-io/gpt-pilot,” a popular open-source AI developer tool, and force-pushed a variant of the Shai-Hulud credential-stealing worm to the main branch. The malware is designed to activate silently when an unsuspecting developer runs the project, while avoiding systems with a Russian locale.

“The malware, a variant of the Shai-Hulud worm, was stopped by an unlikely defender: ruff, a Python code formatter,” Ashish Kurmi, co-founder and CTO of StepSecurity, said . “The attacker tried twice to get the malicious code past CI and failed both times because their injected Python file did not match the project’s formatting and linting rules.” Software supply chain security company Snyk has described these attacks as part of the Shai-Hulud / Miasma lineage, with each wave leveraging a Bun-runtime obfuscated stealer and combining it with “new persistence, new exfiltration routes, and new ways to fire code automatically at install or build time.” “The Miasma campaign proves that having signed keys and authenticated maintainer accounts are no longer an absolute guarantee of safety,” Cloudsmith said . “When upstream registries and repos are compromised, public code becomes one of the easiest, and most direct, ways of getting pwned.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added a high-severity flaw impacting BerriAI LiteLLM to its Known Exploited Vulnerabilities ( KEV ) catalog, citing evidence of active exploitation. The vulnerability, tracked as CVE-2026-42271 (CVSS score: 8.7), is a command injection vulnerability that could allow any authenticated user to run arbitrary commands on the host. It affects the following version of the LiteLLM Python package -

= 1.74.2 < 1.83.7 “Two endpoints used to preview an MCP server before saving it - POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list - accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport,” according to a description of the flaw shared by BerriAI.

“When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process.” The maintainers of the open-source AI gateway and Python SDK said the endpoints were secured only by means of a valid proxy API key, as a result of which any authenticated user, including privileged internal-user keys, could execute arbitrary commands on a susceptible system. As part of the patches released in version 1.83.7, both the test endpoints now require the PROXY_ADMIN role, making it consistent with the save endpoint. LiteLLM Unauthenticated Remote Code Execution via Starlette Host Header Validation Bypass Last week, Horizon3.ai said it chained CVE-2026-42271 with CVE-2026-48710 (CVSS score: 6.5), a “ BadHost “ host header validation bypass vulnerability affecting Starlette , a lightweight Asynchronous Server Gateway Interface (ASGI) framework, to completely sidestep authentication and achieve remote code execution against vulnerable LiteLLM deployments. “CVE-2026-48710 can be used to bypass the authentication mechanism entirely in LiteLLM deployments whose dependency tree includes Starlette versions ≤ 1.0.0,” Horizon3.ai said .

“This transforms the vulnerability into unauthenticated remote code execution with no credentials required.” Successful weaponization of the exploit chain could allow attackers to run arbitrary commands on the LiteLLM host, access model provider credentials, siphon API keys and secrets stored by the proxy, move laterally into connected AI infrastructure, and even compromise downstream systems integrated with the gateway. Per Horizon3.ai, the chained vulnerability has a combined CVSS score of 10.0, making it critical in nature. There is currently no information on how CVE-2026-42271 is being exploited, the identity of the threat actor(s) behind the efforts, who are targeted, how widespread these attacks are, or if the activity has successfully compromised any instances. It’s also unclear if the attacks observed in the wild are leveraging the exploit chain.

Users are advised to update LiteLLM to version 1.83.7 or later and Starlette to version 1.0.1 or later. If immediate patching is not an option, the following mitigations are recommended - Block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway. Restrict network access to trusted segments. Rotate credentials stored by the proxy.

Review logs for unusual Host header activity and subprocess execution events. The development comes a little over a month after a critical SQL injection flaw in LiteLLM ( CVE-2026-42208 , CVSS score: 9.3) came under active exploitation within 36 hours of the bug becoming public knowledge. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.