Malicious Claude Code Extension Planted SSH Backdoors via Cursor Marketplace

A tampered build of Anthropic’s Claude Code extension spent about 11 hours on the Cursor VS Code extension Marketplace. Below is what the payload did, what it left on developer machines, and how to clean it up.

What You Need to Know

A malicious version of the Claude Code extension, Anthropic.claude-code 2.1.313, reached up to 5,000 users through the Cursor marketplace on October 29, 2026. It tried to install a persistent SSH backdoor on developer workstations. Anthropic did not build the malicious version, and the official distribution channels were not shown to be compromised. Uninstalling the extension does not undo what the payload already did, so any host that installed it during that window needs cleanup.

What Happened

Cursor said the affected package was live from about 2:27 a.m. to 1:35 p.m. Pacific Time. After it found the package, Cursor removed it and temporarily shut down the marketplace. It then audited access, rotated keys, and rebuilt the service before bringing it back. Cursor also worked with the attacker’s hosting provider to take the command infrastructure offline.The malicious payload first collected information about the host. It gathered the hostname, username, operating system, architecture, working directories, configured Git email, public IP address, and environment variable names. Next, it added an attacker-controlled SSH key labeled svc-telemetry, tried to enable the local SSH service, and opened a reverse SSH tunnel to 134[.]209[.]82[.]225. For persistence, it used a macOS LaunchAgent, or on Windows, a scheduled task with a Startup-script fallback. Background scripts retried the tunnel about every 60 seconds. Host details and backdoor status went to the attacker in HTTP POST requests on port 8099.

Why This Matters

Developer workstations hold source code, cloud credentials, and access to build systems, which makes them high-value targets. The impact is limited. Cursor found no evidence that other extension versions were affected. Collecting environment-variable names shows which cloud platforms and credential types are set up, but it does not prove the secret values were stolen. On most macOS and Windows systems, the payload lacked the privileges to turn on the SSH service, which closed off the remote-login path. Even so, you still need to remove the unauthorized key, persistence artifacts, and reconnaissance from every affected host. Taking the attacker’s server offline cut the connection, but it did not remove anything already planted on endpoints.

What to Do

Find every install of version 2.1.313 from the Cursor marketplace during the affected window. Match those install records against endpoint and network telemetry, and isolate any host that shows the payload ran or the backdoor was installed. Hunt for:

• the svc-telemetry entry in authorized_keys
• the macOS LaunchAgent com. apple.sysmond
• the Windows scheduled task SysMon
• connections to the attacker’s address on TCP ports 22 and 8099

Run Cursor’s cleanup scripts for each platform to remove the extension, the unauthorized key, the persistence mechanisms, and the tunnel processes. Decide whether affected hosts should be rebuilt. From a trusted system, rotate the credentials and sessions those hosts could reach. Developer tooling is part of the supply chain, so extension installs deserve the same scrutiny as any other software coming into the environment.

PHP2Shell Chain Gave Suspected Chinese Actors Root on 25 PAN-OS Devices

A suspected Chinese state-linked actor chained three vulnerabilities to get root on Palo Alto Networks firewalls and management servers in four countries. Below is how the chain works, what happened at a US government-affiliated target, and what PAN-OS operators should check.

What You Need to Know

Attackers combined PHP2Shell (CVE-2026-109618 and CVE-2026-109619) with the Linux kernel flaw CVE-2026-46300. This gave them root access to 25 Palo Alto Networks firewall and management servers in the United States, Japan, Taiwan, and South Korea. One of the compromised servers centrally managed a US government-affiliated organization’s firewalls and was connected to its Active Directory domain. Organizations with internet-facing PAN-OS management interfaces should patch now and look for signs of compromise, not only close the hole.

What Happened

Researchers at Dream reported the campaign, which ran October 23-24. Palo Alto Networks’ Unit 42 verified the findings on October 29. Unit 42 said the campaign affected about 0.02% of its global installed base, all devices with internet-facing management interfaces. Dream assessed the actor as Chinese state-linked based on who was targeted, what the attackers focused on, and their use of Chinese services, including DeepSeek, Kimi, and FOFA.

The Details

The attacker tailored PHP2Shell, made up of CVE-2026-109618 and CVE-2026-109619, to the PHP session.upload_progress mechanism on the PAN-OS management web server. They then chained it with Fragnesia (CVE-2026-46300), a Linux kernel flaw in the XFRM ESP-in-TCP subsystem. That let them overwrite authentication rules and get root without a password. Dream reported that the full chain went from an unauthenticated HTTPS connection to a persistent root webshell in under 15 minutes.The preparation was extensive. The attacker pulled PHP libraries out of PAN-OS firmware and built memory profiles for nine software versions. They narrowed about 19,000 internet-facing PAN-OS devices down to 240 targets, focusing on the PAN-OS 12.1 and 12.2 branches running PHP 8.0.30. Automated exploitation initially rooted 24 firewalls. On 22 of them, researchers saw only a webshell. Two government-affiliated devices got more persistence, including an eight-port reverse SSH tunnel. The attacker then compromised a third government server that centrally managed the organization’s firewalls, bringing the total to 25.

Why This Matters

Taking over the central management server turned a perimeter breach into an identity problem. That server holds the configurations, credentials, and network settings for every firewall it manages. Its Active Directory connection gave the attacker a path deeper into the network. Researchers could not tell whether the attempted password spraying, backdoor account creation, or SAML key extraction succeeded, so the full scope remains unknown. The Chinese state-linked attribution is an assessment and has not been confirmed.

What to Do

Apply Palo Alto Networks’ patches and mitigations for CVE-2026-109618 and CVE-2026-109619, and remove public access to management interfaces. Patching does not prove a device is clean, so investigate any exposed device. Look for unauthorized webshells, reverse SSH tunnels, configuration changes, and suspicious logins tied to connected identity services. If you find a compromise, review the credentials and trust relationships reachable through central management, and don’t limit containment to the firewall that was first exploited. Management planes need the same protection as the networks they control. When one falls, it can expose everything it manages.

Ivanti Connect Secure 0-Day Chain Steals Domain Credentials Without Leaving a Backdoor

An exploit chain against Ivanti Connect Secure gave attackers root on VPN appliances, including one that was fully patched at the time, and then reached into Active Directory. Below is how the chain worked, why integrity checks missed it, and which releases fix it.

What You Need to Know

Attackers chained Ivanti Connect Secure 0-days (CVE-2026-104935 and CVE-2026-111357) to get unauthenticated root access on VPN appliances. They used that access to steal domain credentials and query sensitive Active Directory data. The actor left no persistent backdoor, which helped the activity get past Ivanti’s Integrity Checker. Fixed releases are available, but patching does not revoke credentials already stolen.

What Happened

Volexity tracks the activity as UTA0576. Exploitation began October 3, 2026, and one targeted appliance was running version 22.8R2.4, which was fully patched at the time. Ivanti confirmed a limited number of customers were affected. The chain combines an authentication bypass and code execution, tracked as CVE-2026-104935, with a privilege escalation tracked as CVE-2026-111357. Later reporting also links CVE-2026-118527, a predictable-filename weakness, to the same attack surface. Ivanti released initial fixes on October 13 and more updates on October 29. Versions 25.1.1.3 and 22.8R2.6 are reported to fix all disclosed vulnerabilities on their branches.

The Details

The intrusion started in welcome.cgi. That component handled the requested URL and the X-DSCGI-PATH header inconsistently, which allowed unauthenticated access to a protected upload handler, wu.cgi. That handler wrote uploaded content to a predictable temporary location before checking it. The attacker uploaded a Perl script and executed it as the cgi-server user before the appliance’s cleanup process could delete it. The attacker then manipulated library code in memory and the DSCache configuration store, causing the privileged dsinvoked service to run attacker-controlled commands as root.After each run, UTA0576 restored the modified settings and memory and deleted selected log entries. It did not install a persistent backdoor or webshell. Instead, it re-ran the exploit chain for each command and received the results in HTTPS responses.

Why This Matters

The impact goes well beyond the VPN appliance. The attacker pulled stored domain credentials and used the appliance’s Active Directory service account to query internal systems. It went after Windows LAPS administrator passwords, BitLocker recovery keys, and attributes containing passwords. Researchers also saw password spraying, username collection, and packet analysis aimed at recovering credentials from network traffic. Because the actor left so few artifacts behind, a clean integrity check does not prove an appliance was never compromised. Being fully patched at the time was not enough either.

What to Do

Move to the current fixed release for your branch, such as 25.1.1.3 or 22.8R2.6. Don’t assume the first October update fixed every disclosed issue. Along with patching, run network and memory forensics. Review unusual welcome.cgi requests, mismatched paths and headers, temporary files, and unexpected connections from VPN appliances to internal systems. For confirmed compromises, CISA recommends resetting or rebuilding affected appliances, upgrading to the latest release, and replacing exposed authentication material, including passwords, certificates, and API keys. Closing the exploit path is necessary, but you must handle stolen credentials and access gained elsewhere in the network separately.

Binance Loses $6.3 Billion in 20-Minute Crypto Heist

Hackers drained about $6.3 billion from Binance wallets on at least ten blockchains, most of it in about 20 minutes. Below is how the operation unfolded, what has been frozen, and what crypto custodians can learn from it.

What You Need to Know

On October 29, hackers stole about $6.3 billion in cryptocurrency from Binance, draining most of it in roughly 20 minutes. The theft hit exchange wallets on at least ten blockchains, including Ethereum, Bitcoin, Tron, and Solana. Blockchain investigators provisionally link it to North Korea’s TraderTraitor. The attack shows how quickly a compromised endpoint can lead to control of hot-wallet transactions.

What Happened

According to blockchain investigators cited by WIRED, Binance suspended deposits and withdrawals, said it would cover all losses, and began working with law enforcement and cryptocurrency companies to trace and freeze the stolen assets. TRM Labs and Chainalysis provisionally linked the operation to TraderTraitor, a North Korean threat actor known for targeting cryptocurrency businesses. Elliptic also assessed North Korean involvement as likely but did not attribute the attack specifically to TraderTraitor.

The Backstory

TRM Labs said the attack followed at least 36 hours of preparation. The attacker made small test withdrawals, deployed and tested attack code against two wallets, and rehearsed a later version against a third. About four hours later, the code reached a Binance hot wallet. Hot wallets stay connected to the internet to process customer transactions, so control of one means control of the funds in it. Binance first pointed to a compromised engineer’s laptop as a possible entry point, then said its investigation had found additional breach points. Chainalysis reported that the stolen funds were mixed with funds from the previous month’s Bitget exploit, which researchers also attributed to North Korean actors. Investigators saw thousands of rapidly processed transactions and unfamiliar laundering patterns, which points to automation designed to make tracing harder.

Why This Matters

Neither Binance nor law enforcement has publicly confirmed who did it, and the full intrusion path is still unknown. The laundering evidence supports the attribution, but it does not explain how the attacker got in. Tracing cryptocurrency is also different from getting it back. Binance and other firms said they froze about half the stolen assets, while Elliptic estimated the frozen amount at about $2.8 billion, mostly stablecoins. Frozen funds can’t be moved, but that doesn’t mean they’ve been returned. Elliptic warned that much of the rest, including Bitcoin, Ether, and XRP, can’t be frozen directly and would have to be intercepted when it reaches a cooperative exchange or service.

What to Do

For cryptocurrency custodians, the priority is to limit how far a compromised employee endpoint can reach into transaction authorization. Keep workstation access separate from signing authority, cap hot-wallet balances, and require independent approval for sensitive changes. Monitor for unusual withdrawals across blockchains, and rehearse escalation procedures so the team can suspend transactions and coordinate with issuers and exchanges within minutes. An attack that takes 20 minutes needs a response measured in minutes too.

DarkSword Turns iPhone Web Browsing Into a Data-Theft Path

DarkSword is an iOS exploit framework that compromises vulnerable iPhones when they load a malicious web page. Below is the vulnerability chain it uses, what researchers confirmed it can steal, and how to manage the exposure across your iPhones.

What You Need to Know

DarkSword chains six vulnerabilities, three of them exploited as 0-days, to go from a malicious web page to privileged access on iPhones running iOS 18.4 through 18.7. The victim doesn’t have to install anything or approve a profile; loading attacker-controlled web content is enough. Multiple surveillance vendors and suspected state-sponsored actors use the framework. All mapped vulnerabilities are now patched, so the remaining risk lies with iPhones that haven’t been updated.

What Happened

Google Threat Intelligence Group traced DarkSword activity back to at least November 2025, with campaigns targeting users in Saudi Arabia, Turkey, Malaysia, and Ukraine. Delivery includes watering-hole attacks, in which attackers compromise websites their targets are likely to visit. Because several operators use DarkSword, it isn’t limited to one campaign or one intelligence service. On October 29, Zimperium published research on infrastructure that delivers both Coruna and DarkSword-derived chains, choosing the payload based on the visiting device’s iOS version.

The Details

The chain picks its browser exploit based on the iOS version. Releases before iOS 18.6 get CVE-2025-31277, a JavaScriptCore optimization flaw. iOS 18.6 through 18.7 get CVE-2025-43529, a JavaScriptCore garbage-collection vulnerability. Later stages use CVE-2026-20700 in Apple’s dynamic linker, CVE-2025-14174 in the ANGLE graphics component, and the kernel vulnerabilities CVE-2025-43510 and CVE-2025-43520. Together, these let the chain break out of browser isolation and get elevated access. In a controlled test on an iPhone running iOS 18.6.2, Zimperium confirmed theft of the Apple Notes database and an inventory of 214 installed apps. Researchers also found the ability to access process memory, communicate with command-and-control over encrypted channels, and delete crash logs and Safari website-data records.

Why This Matters

A compromise that starts with a web visit and ends with data theft and deleted evidence is more than a browser crash or a single bad session. Every stage relies on a known, already-fixed vulnerability, so DarkSword doesn’t need a fresh undisclosed bug to work. iPhones on older releases are exposed. Updating closes the known paths but doesn't recover data already stolen.

What to Do

Inventory the iPhones that access corporate resources, enforce supported iOS versions through mobile device management, and check that updates actually installed instead of trusting deployment status. Cut off access to sensitive enterprise services for devices that can’t get current security updates. In investigations, correlate suspicious browsing with mobile security alerts, unexpected outbound traffic, and signs of data access or exfiltration. If you suspect a compromise, preserve whatever evidence you can and assess the accounts, sessions, and corporate data that were exposed. For DarkSword, keeping iPhones updated is the most effective defense, so the work is in confirming every device actually installed the update.