Your test grid is an RCE surface: SeleniumGreed turns exposed Selenium hubs into miners

Wiz Research has documented an ongoing campaign it calls SeleniumGreed, in which a threat actor finds publicly exposed Selenium Grid services and uses them to deploy cryptominers ^[1]. What makes this worth your attention is not the miner but the mechanism: Selenium Grid ships without authentication enabled ^[2], and its WebDriver API is designed to interact with the underlying machine, including reading and downloading files and running remote commands ^[3]. That combination means an internet-reachable test grid is not a QA convenience with a hygiene problem. It is unauthenticated remote code execution with a browser icon on it.

The attack chain is unremarkable, which is the point. According to Wiz, the actor uses WebDriver API features to run Python with a reverse shell, then pulls down scripts that install an XMRig miner ^[4]. The miner is a modified XMRig packed with custom UPX headers ^[8]. For infrastructure, the actor reuses other compromised Selenium nodes as command-and-control for payload hosting and as a mining pool proxy ^[9], so the grid you left open may be serving payloads to the next victim. Wiz reported the actor as still active at the time of publication ^[5], and says that as far as it can tell this is the first report of this misconfiguration being exploited in the wild ^[15].

The exposure surface is large. Wiz's data puts Selenium in over 30% of cloud environments, making it the most common testing framework it sees ^[16], and the official selenium/hub Docker image has been pulled more than 100 million times, averaging over 150,000 pulls per week ^[10]. At that weekly rate, the image is picking up roughly 7.8 million pulls a year ^[14]. Grid's architecture is a hub that distributes tests to registered nodes, where a node is any machine registered to the hub and able to run a browser ^[11]. Every node is therefore a machine you have volunteered to run code on behalf of whoever can reach the hub.

The Selenium project's own response is refreshingly direct. Its blog notes that the abuse works by injecting code into session creation to download and start miners, that it can be abused on most versions of Selenium, and that there appears to be a lot of effort going into Selenium Grid 3.14 specifically, with a request to upgrade because security items have been added since then ^[6]. The project also confirms the design assumption plainly: there is no authentication by default because the expectation has always been that you put the grid behind a secure network ^[7]. Wiz frames it the same way, saying Grid is built for internal networks, lacks security controls by default, and ideally should never be exposed to the internet ^[12].

Practical next steps are in the project's own tooling: running `java -jar selenium-server-<version>.jar info security` prints security guidance, and the project points to its help documentation and to hosted grid vendors as alternatives ^[13].

What to watch: whether the 3.14 concentration holds, since a version-specific campaign suggests the actor is targeting a known population of stale hubs rather than scanning broadly ^[6]. Watch also for the same technique aimed at something other than mining. A reverse shell on a test node that can read and download files ^[3] is worth more to an actor collecting credentials than it is to one selling Monero.