This Week in Threat Intelligence: When Trust Becomes the Attack Surface

This week's roundup covers five stories with a common thread: attackers are increasingly exploiting the systems and workflows we're conditioned to trust, rather than breaking through obvious defenses. A Linux kernel bug turns a routine bridge teardown into a memory-safety hole. Three flaws in HashiCorp's Terraform MCP server show how credential handling in automation tooling can quietly leak across tenants. JADEPUFFER demonstrates an AI agent running most of a ransomware attack chain on its own once it gets a foothold. XCSSET rides trusted developer workflows, spreading through Xcode projects developers pull and build without a second thought. And Kali365 shows that even Microsoft's own legitimate login page can become a token theft vector when device code flow is abused. Read on for what happened in each case and what defenders should do about it.

A Linux Bridge Timer Bug That Outlives the Bridge Itself

This post covers a use-after-free vulnerability in the Linux kernel's bridge Spanning Tree Protocol implementation, disclosed by SSD Secure Disclosure, along with the conditions that trigger it and the fix now available upstream.

What You Need to Know

SSD Secure Disclosure has published details on a use-after-free vulnerability in the Linux kernel's software bridge (net/bridge) STP implementation. A bridge left administratively down with kernel STP enabled, combined with a port pushed into the LEARNING state, can arm periodic STP timers that a normal teardown path won't cancel. When the bridge is deleted, the underlying memory can be freed while a timer is still queued against it, producing a slab use-after-free in the kmalloc-cg-8k cache. Two researchers, n132 and sven sze, submitted the finding during TyphoonPWN 2026 and took second place in the Linux PE category. A patch is already in the upstream kernel.

What's Vulnerable

The bug lives in how the bridge driver manages its STP timers, including the hello timer, tcn timer, topology change timer, and per-port timers. These timers are embedded directly inside struct net_bridge, which itself sits in the private data region of the bridge's net_device. That means the timers' lifetime is tied directly to the net_device allocation, so any code path that frees the device while a timer is still queued creates a use-after-free condition.

The timers get armed through br_stp_enable_bridge() and br_port_state_selection(), and the arming path for a port entering the LEARNING state has no IFF_UP guard, so it will happily arm timers even on a bridge that's administratively down. The only place that synchronously deletes these timers is br_stp_disable_bridge(), which only runs when br_dev_stop() fires on an UP to DOWN transition, meaning it goes through the ndo_stop path.

That's where the asymmetry comes in. Bringing a bridge down through ndo_stop calls br_dev_stop(), which calls br_stp_disable_bridge() and cancels every STP timer with del_timer_sync(). But deleting the bridge link directly runs br_dev_delete() instead, which never calls br_stp_disable_bridge() at all. Worse, unregister_netdevice_many() skips ndo_stop entirely for a device that's already down. So a bridge left down with STP enabled and a port in LEARNING state can have its timers still queued when the link gets deleted. The net_device backing it gets freed while a timer remains linked into a per-CPU timer base, and the next time that base runs in __run_timers(), it fires against memory that's already been freed.

SSD's analysis notes that because the timer keeps firing automatically a few seconds later, an attacker who can reclaim the freed slab with a buffer carrying a controlled function pointer gets a control-flow hijacking primitive out of it, not just a crash.

Why This Matters

This isn't a networking edge case, it's a memory safety bug reachable through ordinary interface management operations. Bridge creation, STP toggling, and link deletion are all things automation, container runtimes, and network configuration tools do routinely, often without anyone thinking about kernel-level timer state. Any system running Linux bridges with STP enabled, including container hosts and virtualization platforms that build bridges programmatically, is potentially exposed to this class of issue until patched.

What to Do

Update to a kernel that includes the upstream fix, available at the commit SSD has linked in their advisory (2a00517db8de4be7df3d483b215c5544fb30a191). If immediate patching isn't possible, avoid leaving bridges administratively down with kernel STP enabled, and audit any automation that creates or tears down bridge interfaces to make sure it isn't inadvertently leaving bridges in that state. Monitor for unexpected bridge deletion activity or unusual state transitions, particularly in environments where bridge configuration is automated or exposed to less trusted processes.

This kind of bug is a reminder that network configuration surfaces and memory safety aren't separate concerns, they're the same attack surface viewed from different angles.

HashiCorp Patches Three Critical Terraform MCP Server Flaws

This post covers three critical vulnerabilities in HashiCorp's terraform-mcp-server, all tied to its streamable-HTTP transport, and the version 1.1.0 release that fixes them.

What You Need to Know

HashiCorp's terraform-mcp-server carried three critical vulnerabilities in its streamable-HTTP transport, all patched in version 1.1.0. The risk isn't a single broken control but a cluster of flaws that together could let an attacker redirect credentials, bypass authorization, or reuse another tenant's Terraform token across requests. Anyone running terraform-mcp-server, particularly in shared or multi-user deployments, should treat this as an immediate upgrade priority.

The Details

The first issue, CVE-2026-14869, is a server-side request forgery flaw in the streamable-HTTP transport. An unauthenticated client could supply a TFE_ADDRESS parameter that causes the server to send its Terraform bearer token to an attacker-controlled endpoint.

The second issue, CVE-2026-16496, affects stateful streamable-HTTP mode. An attacker who obtains another user's MCP session ID can use it to execute tool calls with that user's Terraform credentials.

The third issue, CVE-2026-16498, affects stateless HTTP mode. It allows one user's Terraform token to be reused for subsequent users' requests, because the underlying MCP library doesn't assign unique session identifiers in that mode.

Why This Matters

Taken together, these flaws create serious exposure for centralized Terraform automation. A successful attack could leak tokens, cross tenant boundaries, and trigger unauthorized infrastructure changes in Terraform Cloud or Enterprise environments. The practical impact is highest wherever MCP is exposed over HTTP in shared or multi-user deployments, especially where session handling and outbound request controls are already weak.

What to Do

Upgrade terraform-mcp-server to version 1.1.0 or later, then rotate credentials and invalidate active sessions. If you can't upgrade right away, disable exposed streamable-HTTP access, restrict the listener to trusted networks, and avoid configurations that mix shared transport endpoints with sensitive Terraform credentials.

JADEPUFFER Shows an AI Agent Can Run Most of a Ransomware Attack on Its Own

This post covers JADEPUFFER, a ransomware operation documented by Sysdig where a large language model agent handled the technical execution of an intrusion end to end, and what it signals for organizations running internet-facing AI tooling.

What You Need to Know

Sysdig has documented JADEPUFFER, what its researchers describe as the first known case of agentic ransomware, where an AI agent carried out the technical attack chain from initial access through credential theft, lateral movement, and destructive encryption largely on its own. A human operator still set up the infrastructure and picked the target, but the agent adapted in real time, corrected its own failed steps, and chained together exploitation, reconnaissance, and extortion without step-by-step human direction. It's a useful signal for defenders because it shows that ordinary weaknesses, an exposed service, weak secrets hygiene, permissive credentials, are now enough for an AI-driven attack to move from foothold to destructive impact quickly.

What Happened

JADEPUFFER gained initial access by exploiting CVE-2025-3248, a missing-authentication remote code execution flaw in Langflow, an open-source framework for building LLM-driven applications. The vulnerability let an unauthenticated attacker run arbitrary Python on the host. It had been patched since April 2025 and added to CISA's Known Exploited Vulnerabilities catalog the following month, but the affected instance was never updated, a common state for Langflow deployments, which are often stood up quickly with minimal hardening and frequently hold cloud credentials and API keys.

From the compromised Langflow host, the agent established persistence with a cron job beaconing to attacker infrastructure every 30 minutes, then pivoted to a separate production server running MySQL and Alibaba Nacos, the organization's real target. It probed the Nacos configuration service, adapting its approach when responses came back in unexpected formats, and ultimately used an authentication bypass to create rogue administrator accounts. From there it enumerated and exfiltrated data before encrypting 1,342 Nacos configuration items and deleting the originals. Sysdig found the encryption key had been generated randomly and never stored or transmitted anywhere, meaning the encrypted data cannot be recovered even if a ransom is paid.

Why This Matters

JADEPUFFER doesn't rely on novel techniques. Every individual step, exploiting a known and patched vulnerability, harvesting credentials, moving laterally, encrypting data, is familiar. What's changed is the speed and adaptability with which those steps get chained together. An agent that can test, fail, correct itself, and move forward within seconds shifts the economics of an attack, letting less skilled operators achieve outcomes that previously required a hands-on-keyboard specialist. Organizations exposing AI tooling like Langflow to the internet, or running adjacent services like configuration stores and databases with weak segmentation, are the ones most exposed to this class of attack.

What to Do

Patch internet-facing AI tooling and remove exposed code-execution endpoints, especially anything running Langflow or similar agent frameworks that hasn't been updated against known vulnerabilities. Keep provider API keys and cloud credentials out of reachable application environments, and harden adjacent services such as databases and configuration stores rather than assuming they're insulated by the AI tool in front of them. Just as important, assume agentic attackers will look for the easiest path between systems, so segmentation, least privilege, and strong runtime authorization for non-human identities matter more now than they did a year ago.

XCSSET Returns Through Compromised Xcode Projects

This post covers a new XCSSET malware campaign, documented by Palo Alto Networks' Unit 42, that spreads through compromised Xcode projects and GitHub repositories to infect macOS developers.

What You Need to Know

XCSSET, a macOS malware family that's been active since at least 2021, has resurfaced after months of inactivity in a new version tracked as v40. Researchers at Unit 42 found the threat actor compromising vulnerable Git repositories and injecting downloader scripts into benign files inside Xcode projects. Developers who pull down an infected project and build it locally get infected, and the malware then spreads to every other Xcode project on that system, propagating further through shared source code. The new version adds stronger evasion and two new modules targeting Chrome and Telegram.

What's New in v40

Unit 42 observed XCSSET v40 used in two separate attack waves, in mid-April and early May. Once it infects a system, it runs through a four-stage infection chain before deploying 17 separate modules covering credential theft, keystroke logging, clipboard manipulation, browser hijacking, and data exfiltration.

The two modules new to this version are a Chrome hijacker and a Telegram trojanizer. The Chrome hijacker wraps the browser in a malicious launcher and enables the Chrome DevTools Protocol on a local port to pull JavaScript from the attacker's command-and-control infrastructure, letting them intercept web traffic, credentials, cookies, and MetaMask transactions, which can be altered on the fly to redirect payments. The hijacker also opens a fileless reverse shell for system command execution, a technique Google already blocks in Chrome for Windows and is working to extend to macOS. The Telegram trojanizer deletes the legitimate Telegram Desktop app and replaces it with a malicious version; Unit 42 couldn't recover its encrypted configuration, so its exact function is still unknown.

The new version also raises the bar on evasion. It periodically recompiles its loader on the C2 server, uses separate encryption keys for inbound and outbound traffic, and obfuscates function names, variables, and strings with ciphers unique to each build. It also actively works to disable macOS's own defenses, going after XProtect, MRT, TCC, and Rapid Security Response, terminating Apple's CloudTelemetryService, and blocking XProtect signature updates.

Why This Matters

XCSSET spreads through shared source code, so a single compromised project can seed infections across an entire development ecosystem before anyone notices. Developer endpoints and build pipelines are part of the attack surface here, not just shipped applications, and security controls focused solely on finished software will miss this entirely, since the compromise happens before the code is ever built or released.

What to Do

Review Xcode projects before building them, and verify third-party dependencies rather than pulling and building blindly. Scan repositories for injected downloader scripts before they enter your pipeline. Monitor for suspicious AppleScript activity, ad hoc-signed binaries that bypass Gatekeeper, unusual Chrome remote-debugging flags, and unauthorized browser modifications. Given how aggressively this version goes after built-in macOS defenses, don't rely on XProtect or MRT alone to catch it.

Kali365 Turns Microsoft Device Code Login Into a Token Theft Pipeline

This post covers Kali365, a device code phishing kit that abuses Microsoft's legitimate authentication flow to steal Microsoft 365 access and refresh tokens from targeted organizations.

What You Need to Know

Kali365 is a phishing service that weaponizes Microsoft's legitimate device code authentication flow to steal Microsoft 365 access and refresh tokens. Victims are lured through pages impersonating trusted services like SharePoint, OneDrive, or DocuSign, then redirected to Microsoft's real login page, where they're asked to enter an attacker-generated code and unknowingly authorize the attacker's device. ANY.RUN telemetry has tracked more than 80 public sandbox sessions tied to this campaign each week, with the United States as the primary target and activity showing up across manufacturing, technology, healthcare, government, consulting, and MSSP organizations.

How the Attack Works

The attack unfolds in three stages. First, a lure page impersonates a trusted business service to draw the victim in. Second, the victim is redirected to Microsoft's legitimate device login portal and prompted to enter a code the attacker generated. Third, once the victim completes that authentication step, the attacker can retrieve OAuth access and refresh tokens tied to the victim's account.

Those tokens can provide persistent access to Outlook, Teams, OneDrive, SharePoint, and other Microsoft 365 resources without the attacker ever needing the victim's password again. A single approved device code request can turn into email compromise, document exposure, internal phishing, and downstream financial or operational abuse.

This technique is effective because it uses a genuinely trusted Microsoft page and a normal-looking login action, making it harder to spot than an obvious credential-harvesting site. It also sidesteps MFA in practice: the attacker isn't trying to defeat the second factor, they're capturing the token issued after the victim has already completed legitimate authentication.

Why This Matters

Kali365 shifts the security conversation from password hygiene alone to control over authentication flows, token lifetime, and device code usage specifically. Because the victim-facing part of the attack happens on Microsoft's own infrastructure, it can look like routine activity right up until the tokens are already in the attacker's hands, giving defenders less lead time than a conventional phishing page would.

What to Do

Block device code flow wherever possible, and limit any exceptions to specific hardware or emergency use cases rather than leaving it broadly available. Monitor for unusual Microsoft 365 sign-in patterns tied to device code authentication. User training should emphasize one simple rule: never enter a device code unless you initiated that sign-in yourself, on that same device.