The Convenience Problem: How Attackers Are Weaponizing What You Already Trust

msaRAT: The Malware That Never Talks to the Internet Directly

Cisco Talos has uncovered a new Rust-based remote access trojan tied to the Chaos ransomware group, and it takes an unusual approach to command-and-control that keeps the malware itself completely off the network.

What You Need to Know

Talos calls the malware msaRAT, and its defining trait is that the RAT process never makes a direct network connection. Instead, it hijacks the victim's own Chrome or Edge browser and uses it as a communication relay, so all C2 traffic appears to come from a legitimate browser process rather than the malware. That shift makes traditional network-based detection far less useful and pushes the burden onto endpoint monitoring instead.

How the Infection Unfolds

The attack starts after an attacker already has access to a victim machine but before ransomware deployment. A disguised MSI file, named to look like a Windows update, gets downloaded and installed. Once executed, a custom action loads the RAT payload directly into memory. From there, msaRAT locates the installed Chrome or Edge browser and launches it in headless mode with remote debugging enabled, giving the malware a way to control the browser through the Chrome DevTools Protocol.

Using that protocol, msaRAT injects JavaScript into the browser and sets up event bindings that let the browser and the RAT pass messages back and forth. The injected code then handles the actual networking. It sends a request to a Cloudflare Workers endpoint to retrieve STUN and TURN server details, and uses that information to establish a WebRTC DataChannel with the attacker's C2 server, relayed through Twilio's TURN infrastructure. Once that channel is up, Cloudflare Workers drops out of the picture entirely, and all further commands flow over the WebRTC connection. The malware also layers its own ChaCha-Poly1305 encryption on top of WebRTC's built-in DTLS protection, so even if the transport encryption were stripped, the underlying data would still be unreadable.

Why This Matters

Because the RAT process itself only ever talks to 127.0.0.1, defenders watching network traffic see nothing unusual coming from the malicious binary. The traffic that actually reaches the outside world comes from the browser, using infrastructure like Cloudflare Workers and Twilio that organizations already trust and rarely block. Talos notes this isn't a browser exploit; it's an abuse of legitimate browser debugging features. That distinction matters because it means patching browsers won't stop this technique. The exposure comes from how developer tooling can be repurposed, not from a flaw that gets fixed in an update.

What to Do

Since this is a detection and monitoring problem rather than a patchable vulnerability, defenders should watch endpoint telemetry for the specific behaviors this technique depends on. That includes browsers launched with remote debugging flags, headless Chrome or Edge processes that don't match normal user activity, unusual installer behavior from files posing as system updates, and process chains where a browser gets spawned by something other than a user action. Cisco has published ClamAV signatures and Snort rules to detect this specific threat, along with indicators of compromise on Talos's GitHub repository, so security teams should incorporate those into existing detection stacks.

Living-off-the-browser techniques like this one are a reminder that trusted, everyday tools can become part of an attacker's infrastructure without anyone touching a zero-day.

Cl0p's Latest Target: Internet-Facing PTC Windchill Servers

Cl0p is back with a new target, and this time it's PTC Windchill and FlexPLM, the product lifecycle management platforms widely used across manufacturing, automotive, aerospace, and retail.

What You Need to Know

Cl0p affiliates are actively exploiting internet-exposed Windchill and FlexPLM deployments in a data-theft campaign aimed at engineering environments. The exploitation centers on CVE-2026-12569, a critical deserialization flaw in Windchill PDMLink and FlexPLM with a CVSS score of 9.8, chained with a separate FlexPLM WSDL disclosure vulnerability rated 7.5. Evidence suggests Cl0p weaponized this as a zero-day before it was even publicly disclosed, and organizations running internet-facing Windchill instances should treat this as an active, ongoing threat.

How the Campaign Works

This fits Cl0p's established playbook: find widely deployed, internet-facing enterprise software, exploit it at scale, then pair intrusion with data theft and extortion rather than traditional ransomware deployment. The group has run this pattern before against managed file transfer platforms and Oracle E-Business Suite, where a single vulnerability exposed many victims at once.

CVE-2026-12569 was disclosed on June 17, 2026, and added to CISA's Known Exploited Vulnerabilities catalog on June 25. Chaining it with the FlexPLM WSDL flaw gives attackers unauthenticated remote code execution, which they've used to drop hex-named JSP webshells inside the Windchill login path. Once inside, observed post-exploitation activity includes filesystem enumeration and staging of sensitive engineering and product design data for exfiltration. Since July 20, Cl0p has also run a parallel extortion campaign, sending mass emails from compromised accounts claiming a Windchill breach and directing recipients to new Cl0p contact channels, a tactic that mirrors its prior Oracle E-Business Suite extortion push. As of July 22, no victims have been publicly listed on Cl0p's leak site, consistent with the group's habit of negotiating quietly before going public.

Why This Matters

Windchill deployments that are internet-reachable are an easy, high-value target, especially where patching lags, access controls are weak, or the application sits without strong network segmentation. Cl0p doesn't need sophisticated malware to succeed here. It just needs software that's exposed to the internet, and it turns that exposure directly into leverage over the organizations that depend on it.

What to Do

PTC has released patches addressing both the RCE and WSDL disclosure issues, so applying them is the immediate priority. Beyond patching, inventory every Windchill and FlexPLM instance in your environment and confirm whether each one is internet-accessible. Restrict access through VPN or IP allowlists where exposure isn't strictly necessary, and review authentication logs for unusual activity. Watch specifically for the indicators tied to this campaign: webshells matching the pattern /Windchill/login/[0-9a-f]{16}.jsp, the malicious HTTP header X-windchill-req, and reconnaissance traffic hitting /Windchill/rfa/jsp/login/*.jsp?wsdl. Given that Cl0p may have exploited this as a zero-day before public disclosure, conduct retrospective threat hunting back to early June 2026, not just from the patch date forward. If a Windchill instance has been internet-exposed at any point during that window, treat it as a high-value, monitored asset rather than a routine internal application.

The bigger lesson holds regardless of the specific software: Cl0p succeeds by finding what's already sitting on the internet, then turning that convenience into its way in.

AgentForger: How One ChatGPT Link Could Plant a Rogue Agent in Your Company

AgentForger is a clear signal that AI workflow features are becoming their own attack surface, not just a productivity layer bolted onto existing tools.

What You Need to Know

Security firm Zenity Labs disclosed a critical vulnerability in OpenAI's ChatGPT Workspace Agents, called AgentForger, that let a single crafted link silently create and deploy an attacker-controlled AI agent inside a victim's workspace. The agent inherited the victim's existing access to connected enterprise tools and could keep receiving instructions from the attacker well after the initial click. OpenAI fixed the issue within days of disclosure, but the underlying pattern, a trusted automation feature turned into a foothold, is worth understanding regardless of vendor.

How the Attack Worked

AgentForger exploited an overly permissive URL parameter in ChatGPT's Agent Builder flow. A victim who was already signed into ChatGPT and connected to enterprise apps like Outlook, Gmail, Slack, or SharePoint only had to click a normal-looking link. That link carried two key parameters: one specifying an agent template, defaulting to the most powerful option available, and another embedding a numbered task list that the Builder treated as instructions rather than something requiring user confirmation. The result was an agent created, configured with all connector permissions set to skip approval, and published, all without the victim reviewing or confirming a single step.

What made this especially dangerous was persistence. Once live, the forged agent could run on a recurring schedule, checking for new instructions from the attacker and reporting results back automatically. It could pull data from connected tools, send messages under the employee's identity, and move through business systems without any further interaction from the victim. Researchers described it less as a stolen session and more as a fully agentic insider planted inside the organization. Zenity reported the flaw to OpenAI through its Bugcrowd program on June 4, 2026, OpenAI confirmed it within a day, and the vulnerable parameter was removed by June 8. No evidence has surfaced of exploitation before the fix.

Why This Matters

Traditional CSRF attacks trick a browser into firing off a single unwanted action. AgentForger went further, using that same trust relationship to stand up a persistent, autonomous system with its own tools, approvals, and schedule. As agentic AI features spread across enterprise platforms, this kind of attack shows that the risk isn't limited to prompt injection or data leakage. It extends to the agent creation process itself, which can be hijacked to build something that operates as a standing insider threat.

What to Do

Organizations using AI workspace agents, on any platform, should limit who has permission to create agents in the first place and restrict which connectors those agents are allowed to use. Review default approval settings so that sensitive actions require confirmation rather than defaulting to automatic execution, and monitor for unusual agent creation events or unexpected changes to permission defaults. Because the initial click is what makes this class of attack possible, training users to treat unexpected links, even ones that look like ordinary ChatGPT links, with the same caution as any phishing attempt is a meaningful part of the defense.

Agentic AI is only going to become more embedded in daily workflows, and attackers will keep looking for ways to turn that trusted automation into a way inside.

SharedRoot: A Sandbox Escape in Claude Cowork's Local VM

A newly disclosed flaw in Anthropic's Claude Cowork shows how even a well-designed isolation boundary can fail when a single kernel bug and an overly broad mount combine.

What You Need to Know

Researchers at Accomplish AI found a sandbox escape vulnerability in Claude Cowork, dubbed SharedRoot, that let an AI agent break out of its Linux virtual machine and read or write files anywhere on the host Mac, including SSH keys and cloud credentials. The issue affected roughly 500,000 macOS users running local Cowork sessions before the current version of Cowork shifted to defaulting to cloud execution, which sidesteps the problem. Users who still choose to run Cowork sessions locally remain exposed.

How the Escape Worked

Claude Cowork's desktop app runs as the logged-in Mac user, while the actual agent work happens inside a disposable Linux VM created through Apple's Virtualization framework. Folders the user connects get shared into that VM by a root daemon called coworkd, but the entire host filesystem, mounted so only guest-root inside the VM could see it, was also shared in with read-write access. That meant any way of reaching guest-root inside the VM effectively meant reaching the whole host.

Researchers found that path by loading the Linux kernel's act_pedit traffic-control subsystem into an unprivileged user namespace, then exploiting CVE-2026-46331, a recently disclosed flaw known as pedit COW, to obtain guest-root. From there, the agent could access the full host filesystem and operate on it with the permissions of the logged-in desktop user, all without a permission prompt. Following responsible disclosure, Anthropic closed the report as informative rather than issuing a direct fix, though Cowork's shift to cloud-first execution addresses the exposure for most users going forward.

Why This Matters

The researchers behind SharedRoot noted that act_pedit is just one instance of a recurring pattern in the Linux kernel's networking subsystem: an autoloadable module, a configuration path an unprivileged user can reach, and a memory bug at the end of it. Patching one instance doesn't close off the category, since a similar chain can re-arm with the next kernel bug while everything above it stays untouched. For any platform that runs AI agents inside a VM or container, this is a reminder that the strength of the isolation boundary matters as much as the capability of the agent itself. A single kernel privilege escalation shouldn't translate directly into full access to the host.

What to Do

If you're running Claude Cowork or a similar AI agent platform locally, prefer cloud execution where it's available, since it removes this class of exposure entirely. For any local agent sandboxing setup, disable unprivileged user namespaces where they aren't needed, avoid overly permissive seccomp filters, and stop unnecessary kernel module autoloading. Scope shared mounts to only the folders an agent actually needs rather than mounting the entire host filesystem, or mount host access read-only where write access isn't required. Running the sharing daemon with stricter system protections, such as its own mount namespace and hardened service settings, ensures that even a full guest-root compromise has nothing further to reach.

The broader lesson holds across AI agent platforms generally: a strong isolation boundary has to assume the kernel inside it will eventually be broken, and design the blast radius accordingly.

Sandworm-Linked Group Hides Malware Inside a Fake Notepad++ Update

Ukraine's CERT has uncovered a campaign that smuggles malware onto Windows systems by bundling it alongside a genuine, working copy of Notepad++.

What You Need to Know

CERT-UA attributes the campaign to UAC-0099, a threat cluster with a history of providing initial access for attacks carried out by Sandworm, also tracked as APT44. The attack relies entirely on social engineering rather than any vulnerability or supply-chain compromise in Notepad++ itself, and it uses a legitimate copy of the editor as cover to install a malicious plugin, create persistence, and load additional malware onto the victim's machine.

How the Attack Works

Victims receive a ZIP archive containing a VBS script disguised as a PDF document. Once launched, the script retrieves a second archive, Evernote.zip, which contains a complete legitimate copy of Notepad++ version 8.8.3, a malicious plugin named NppExport.dll, a password-protected archive called updater.rar, and a legitimate copy of WinRAR. The VBS script installs this package into a randomly named directory, launches Notepad++, and loads NppExport.dll through the application's normal plugin-loading mechanism.

That DLL, tracked by researchers as LunchPoke, creates a scheduled task and extracts the contents of the password-protected RAR file, which include RemoteLibUpdater.exe and InitTest.dll. The executable, known as BurnyBear, acts as a loader for the DLL, which is the MatchBoid V2 malware loader. If BurnyBear fails to launch RemoteLibUpdater.exe, it falls back to a resource-exhaustion attack targeting the host's RAM and CPU. CERT-UA also notes that Notepad++ 8.8.3, the exact version bundled in this campaign, has a DLL hijacking flaw tracked as CVE-2025-56383, though the Notepad++ team disputes this classification and maintains that plugin loading is standard functionality.

Why This Matters

This campaign works precisely because it doesn't need to exploit anything. A victim who checks that Notepad++ actually launches and functions normally has no reason to suspect anything is wrong, since the malicious behavior rides alongside a fully working application. For organizations, that makes the initial delivery vector, a ZIP archive disguised as a PDF, the most important point of defense, since everything downstream depends on that first click succeeding.

What to Do

CERT-UA advises updating Notepad++ to version 8.9.7, 7-Zip to version 26.02, and WinRAR to version 7.23 to close off the known flaws this campaign targets. Beyond patching, treat ZIP or RAR archives delivered through email or messaging platforms with heightened scrutiny, particularly ones disguised as PDFs. Monitor for scheduled task creation originating from application directories, and watch for unexpected DLL loads through Notepad++'s plugin mechanism, since that's the exact technique this campaign relies on to establish its foothold.

Bundling malware alongside a working copy of legitimate software remains an effective way to bypass the instinct to double-check that something "looks right."

CVE-2026-50522: A 9.8 SharePoint Flaw Now on CISA's Must-Patch List

A critical SharePoint deserialization vulnerability is under active exploitation, and CISA has given federal agencies a hard deadline to patch it.

What You Need to Know

CVE-2026-50522, a critical deserialization vulnerability in Microsoft SharePoint with a CVSS score of 9.8, is being actively exploited following the public release of proof-of-concept code. CISA added it to its Known Exploited Vulnerabilities catalog within hours of that PoC appearing and has ordered federal agencies to patch by July 25, 2026. Any organization running on-premises SharePoint, not just federal agencies, should treat this as an immediate priority.

What's Vulnerable

CVE-2026-50522 pairs with a related flaw, CVE-2026-58644, both stemming from SharePoint's handling of untrusted serialized data. SharePoint accepts serialized data from users and deserializes it to process requests, but fails to verify the contents are safe before acting on them, letting an attacker embed malicious instructions inside a crafted request. Microsoft's own advisory lists the flaw as requiring authenticated Site Owner privileges, but researchers describe the pair as triggerable without authentication or user interaction in practice, and observed real-world exploitation has borne that out.

The flaw was demonstrated live at Pwn2Own Berlin before Microsoft shipped a patch, meaning a working exploit chain existed before remediation was available. It was patched in the July 2026 Patch Tuesday release. Security firm watchTowr identified public PoC exploit code on July 20, and within hours its honeypot network captured active exploitation attempts successfully compromising target systems. Attackers are using the flaw to extract SharePoint's machine keys in a single request, and those keys let them forge authentication tokens to impersonate any user on the system. A separate cybersecurity firm, Defused Cyber, observed attackers using the flaw to deliver a .NET deserialization payload through a SharePoint sign-in endpoint, consistent with an unauthenticated remote code execution profile.

Why This Matters

Because a patch only closes the vulnerability itself, it doesn't invalidate machine keys that were already stolen before remediation. Any SharePoint server that was internet-accessible before the patch went out should be treated as having had its machine keys compromised, whether or not any intrusion alert actually fired. That makes this a case where patching is necessary but not sufficient on its own.

What to Do

Apply the July 2026 Patch Tuesday update immediately across SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. After patching, rotate machine keys and any other potentially exposed credentials on every SharePoint instance that was internet-reachable before remediation. Treat any internet-facing SharePoint server from before July 20 as a priority target for credential rotation, since machine key theft leaves no reliable trace and the patch alone won't undo it. While CISA's July 25 deadline formally applies to federal agencies, the same urgency applies to any organization running exposed SharePoint infrastructure.

A patch closes the door, but it doesn't take back keys that already walked out through it. Credential rotation is what actually closes that gap.