SlowMist discovered a malicious TRAE IDE extension named juannegro.solidity that impersonates a legitimate Solidity plugin drops cross platform backdoors on Windows macOS and Linux and uses a live Ethereum smart contract as a dynamically updatable command and control server that removing the extension cannot stop.

Imagine you installing what looks like a perfectly legitimate Solidity language support plugin for your IDE and then sitting back while it silently installs a persistent backdoor across your entire development machine. The payload connects to a command and control server whose address never sits inside the extension file itself.

Instead it lives on the Ethereum blockchain permanently modifiable by the attacker without ever touching the extension again. Removing the plugin does nothing. The daemon keeps running. The shell stays open. SlowMist published this discovery on July 20 2026 and it represents one of the most technically sophisticated IDE extension supply chain attacks documented so far this year.

TRAE IDE Malicious Extension Explained

The malicious extension carries the package name juannegro.solidity and was first flagged publicly by researcher Will42W on July 17 2026 who warned TRAE IDE users about extension supply chain risks and tagged the SlowMist security team in the post.

TRAE automatically synchronizes newly published extensions from Open VSX but critically does not synchronize subsequent removals or blacklistings. The legitimate registry removed this extension within hours of its May 1 2026 publication date.

Yet as of July 18 2026 TRAE marketplace API still served version 0.0.189 for download making the malicious VSIX file available for more than two and a half months after Open VSX had already removed it.

The impersonation technique sits carefully constructed. The publisher name juannegro differs from the legitimate Solidity extension developer juanblanco by only a few characters.

The malicious extension directly copied the legitimate plugins description icon and repository information making a casual visual scan produce no obvious red flags. Only a character by character comparison of the publisher name reveals the typosquatting attack hiding beneath an otherwise convincing facade.

The extension’s package.json file declares two activation events. The first activates when a user opens any Solidity file through onLanguage:solidity.

The second and far more dangerous one activates through onStartupFinished which fires automatically every time the IDE finishes its startup sequence without requiring the user to open any file or execute any command. This means the malicious activate function runs every single time the IDE launches regardless of what the developer does next.

The code inside out/extension.js avoids directly calling child underscore process exec which would be an obvious indicator to any static scanner. Instead it calculates SHA-256 hashes of Node.js built-in module names and function names then uses two fixed hash values to reverse lookup and obtain the strings child process and exec through indirection.

A function object gets compared against a fixed string which can never be equal making the comparison result always true and bypassing whatever check was written to look legitimate while the actual exec function gets passed to the attempt update function to execute system commands.

When attempt update fires it identifies the operating system through os.platform and then drops platform appropriate payloads with matching persistence mechanisms. On macOS the payload lands under home .solidity and a LaunchAgent gets created at the path Library LaunchAgents com.solidity.langsupport.runner.plist to restart it on every login.

On Linux the payload drops to the same hidden directory and a systemd user service gets registered with automatic restart on failure configured. On Windows the updater writes to C:\Users\Public\solidity and modifies the HKCU Run registry key while also attempting to add the payload path to Windows Defender exclusions to prevent detection during subsequent executions.

The element that separates this attack from every conventional extension backdoor involves where the command and control address actually lives.

Neither the macOS and Linux Go binary nor the Windows JavaScript payload contains a hardcoded server address. Instead both poll public Ethereum RPC endpoints and query a specific smart contract deployed at address 0xf8a900db50b3331be6b768ba460bb59f3e40c344 deployed on Ethereum mainnet on March 14 2026 two months before the extension itself appeared in any marketplace.

The contract exposes two functions param1 and param2. The macOS and Linux payload reads param1 to obtain the remote shell address and connects to it. The Windows payload reads param2 to obtain the URL of a second stage JavaScript file and downloads and executes it.

The attackers controlling wallet address 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7 holds owner permissions over the contract and can update both parameters through signed transactions at any time without touching the extension file at all.

SlowMist verified the full parameter update history through Blockscout transaction records. The contract deployed on March 14.

Twenty minutes after deployment the controlling wallet set param1 to localhost:4912 confirming the attacker was testing the on-chain control mechanism before any extension existed. On May 3 two days after the extension published the wallet updated param1 to 107.189.27.46:4912.

On May 16 the wallet updated param2 to the Windows second stage payload URL on the same server. At the time of SlowMist review both parameters pointed to 107.189.27.46 at ports 4912 and 3000 respectively.

Malware Detection Removal & Mitigation Guide

The most important characteristic of this attack that every developer needs to understand clearly involves what removing the extension actually accomplishes. Uninstalling juannegro.solidity from the TRAE extension list stops no existing infection.

The extension already wrote persistence mechanisms to disk during its first activation and may have already downloaded additional second stage payloads. Those files and startup entries remain completely independent of the extension marketplace and survive both extension uninstallation and TRAE itself being removed or reinstalled.

Any developer who installed this extension should treat the affected machine as fully compromised rather than recoverable through simple file deletion.

The payload carries the capability to execute arbitrary commands and establish persistent remote shell connections meaning any credentials stored on the machine including code signing keys SSH private keys cloud provider access keys cryptocurrency wallet seed phrases and production environment tokens should be considered already exposed and must get rotated from a separate clean device before that rotation carries any security value.

For developers who want to check for infection before treating the machine as compromised the investigation should cover specific paths and registry locations across all three platforms. On macOS check the home .solidity directory and the LaunchAgents plist file at the com.solidity.langsupport.runner path.

On Linux check the same home .solidity directory and the systemd user service file for solidity-langsupport-runner. On Windows check C:\Users\Public\solidity and examine the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key for entries pointing at solidity-compiler.js along with the EVJ subkey under the same CurrentVersion path.

Network log review provides the most definitive confirmation of whether the payload actually executed on a given machine. Any outbound connection to 107.189.27.46 on ports 4912 or 3000 confirms active C2 contact.

Any outbound eth call requests to public Ethereum RPC endpoints originating from IDE or shell processes rather than from explicitly blockchain related applications represents a strong behavioral indicator since legitimate developer machines do not typically query Ethereum contract state from system level processes during IDE startup sequences.

The on-chain C2 mechanism means that the specific IP addresses in the current contract parameters may change at any time through a new transaction from the controlling wallet. Detection should therefore cover the contract address and function selectors alongside any current IP values since the attacker can redirect all infected hosts to entirely new infrastructure by updating two contract storage slots rather than by rebuilding or republishing any payload.

TRAE’s synchronization gap created the conditions this attack depended on and the broader lesson applies to every marketplace that aggregates content from upstream registries. Synchronizing publication events without synchronizing removal and risk assessment events creates a window where content that legitimate registries already identified as malicious continues to reach end users through downstream platforms that appear trustworthy.

Extension marketplaces have an obligation not just to index available content but to propagate security signals from upstream registries with the same priority as publication signals and to provide installed user notification when any extension they installed gets subsequently flagged as malicious.

This attack demonstrates what becomes possible when a blockchain becomes the configuration layer for malware infrastructure. Traditional takedowns disable C2 servers and the malware stops working. An Ethereum contract costs a few cents to update and cannot be seized or taken offline by any single authority making the C2 infrastructure effectively permanent for the lifetime of the blockchain itself.