Build2 distinct publishers3 min readUpdated
Wiz says attackers are using the WebDriver API's documented remote-command features to plant a modified XMRig on internet-facing Selenium Grid nodes. Authentication is off by default.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
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 [5]. For infrastructure, the actor reuses other compromised Selenium nodes as command-and-control for payload hosting and as a mining pool proxy [6], 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 [7], and says that as far as it can tell this is the first report of this misconfiguration being exploited in the wild [8].
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 [9], 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 [11]. 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 [12]. 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 [13]. 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 [14]. 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 [15].
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 [16].
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 [13]. 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.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Wiz Research detected an ongoing threat campaign, dubbed SeleniumGreed, that exploits exposed Selenium Grid services to deploy cryptominers.
By default, authentication is not enabled for Selenium Grid, meaning many publicly accessible instances are misconfigured and can be accessed by anyone.
The Selenium WebDriver API enables full interaction with the machine itself, including reading and downloading files and running remote commands.
Wiz identified a threat actor targeting publicly exposed Selenium Grid instances and using Selenium WebDriver API features to run Python with a reverse shell to deploy scripts that download an XMRig miner.
The threat actor was still active as of the publication date of the Wiz blog post.
The Selenium project says crypto miners are abusing unsecured Selenium Grids by injecting code in the session create to download and start up crypto miners, that the issue can be abused on most versions of Selenium, and that there appears to be a lot of effort going into abusing Selenium Grid 3.14, asking users to upgrade as security items have been added since then.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Strong first-party technical detail, corroborated on the core mechanism but not independently replicated
The mechanism claims are the strongest part of the record: two independent publishers, one of them the upstream maintainer, agree that Grid has no default authentication and that session creation can be abused across most versions, and Wiz adds payload characterization and version-range confirmation. Weaknesses are real but bounded: the exposure counts and the 30%-of-cloud figure rest on unshared vendor telemetry and third-party scan queries, the first-in-the-wild novelty claim is self-hedged and unverifiable, and no supplied source publishes indicators of compromise or a victim count that another party could check.
Large deployed base with a substantial, quantified internet-exposed subset and live exploitation
Adoption evidence is unusually concrete for a security story. The technology footprint is documented by public pull counts (over 100 million, more than 150,000 weekly), the exposed subset is quantified at more than 30,000 internet-reachable instances mostly on default port 4444, and exploitation is not hypothetical: an active campaign is described and the upstream project independently reports abuse pressure concentrated on Grid 3.14. The score is held below the top band because the number of actually compromised organizations is never stated, so exposure scale is measured while impact scale is not.
Mildly overstated: real active abuse, but framed closer to a vulnerability than a misconfiguration
The substance largely supports the alarm: exploitation is live, the exposed population is large, and the maintainer confirms the problem. The overstatement is in framing rather than facts. This is documented API behavior on services their own vendor says should never be internet-facing, so it requires operator misconfiguration to matter, yet the packaging emphasizes an RCE surface and a first-in-the-wild novelty claim that no source verifies. The vendor's headline popularity statistic that broadens perceived blast radius is proprietary and unmethodized, while the number of actual victims — the figure that would justify the framing — is absent.
Both publishers are interested parties, though disclosure-of-interest is partial
Neither source is a disinterested observer. Wiz is a cloud security vendor publishing named threat research that maps directly onto the exposure-detection and cloud-misconfiguration problems its products address, and it supplies the campaign brand, the market-size statistic, and the novelty claim without addressing that commercial alignment. The Selenium project has a reputational interest in framing the issue as user misconfiguration rather than an insecure default, and its remediation advice routes readers to the cloud vendors that sponsor the project. Incentives are moderate rather than severe because the technical claims are specific, falsifiable in the mechanism, and mutually corroborated on the central point.
Solid on mechanism and exposure scale, weaker on impact and independence
Confidence rests on two-party corroboration of the default-no-auth mechanism and version spread, plus a publicly verifiable distribution metric. It is limited by a two-source cluster in which both publishers are interested parties, no third-party incident confirmation or IOC set, unmethodized telemetry behind the prevalence figure, and no victim or impact quantification. There is also a dating ambiguity: the upstream advisory's own URL places it in 2024 while the cluster timestamps are recent, so the assessment reflects the supplied material rather than a settled timeline.
build
An exposed Java debug port on a CI server was exploited within hours1 distinct publisher
build
A file-copy Allure adapter for Katalon, and the history IDs that make retries useful1 distinct publisher
build
Amazon Q executed code from any repo you opened, and it is not the only one1 distinct publisher
build
A cleanup commit deleted the sanitizer. Five days later a scanner cashed it in.1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 16, 2026
1 article · August 16, 2026