A widely shared copy of ARTEX, the AI penetration-testing console, has been found to contain a backdoor that gives anyone who can reach it a root shell. Anyone who pulled the image to try out agentic offensive tooling should assume the console, and every secret and client finding inside it, has been exposed.
What happened
On 4 November 2026 the independent researcher BadByte published an analysis of a Docker Hub image called tomicdd/artex, a repackaged build of the ARTEX AI penetration-testing framework. The image carries a small but deliberate change to the console’s login code: a hidden routine that executes operating system commands as root and returns the output, triggered before any username or password is checked. A second image, congdonglinux/artex, has identical digests and is equally affected.
The background matters. ARTEX is a multi-agent console that uses large language models to plan and run penetration tests. It has featured in reporting on real intrusions, including attacks on South Korean banks and a campaign against more than 200 organisations in 14 countries. On 8 October its author announced the project was going closed source and pulled the GitHub repository. Within hours a new Docker Hub account had appeared and pushed an ARTEX image, and a GitHub copy of the source was published with just one line of its compose file altered to point at that image. That copy attracted roughly 2,400 stars and more than 600 forks, according to BadByte.
Docker Hub showed just over 9,000 pulls of the tomicdd image on 5 November. Internet scanning found 62 consoles serving the backdoored build between 2 and 4 November, with the first one online by 20 October. The United States accounted for 26, Hong Kong 17 and China seven. A wider count found 1,645 hosts exposing an ARTEX console of some build. A GitHub user flagged a suspected backdoor in an issue on 23 October; the repository owner closed it the following day.
The technical picture
What makes this case instructive is where the malicious code lives. The GitHub copy of the source matches the original project, so anyone reviewing the code would find nothing wrong. The tampering exists only in the prebuilt binary inside the container image. Ostorlab, summarising BadByte’s work, reports that the binary was compiled from an upstream commit plus uncommitted local changes, and that a function-by-function comparison against the official v0.3.15 release showed three differences: one new function, an enlarged login handler and an extra field in the login request. BadByte put it neatly, saying the backdoor “never shows up in a code review”.
From the network, a trigger request looks much like an ordinary failed login, which means status codes and simple failed-authentication alerting will not reveal it. No account, session or callback is required, and nothing needs to be installed.
The impact is worse than a typical root shell because of what the console holds. According to the analysis, the container stores the PostgreSQL superuser password, unencrypted Anthropic and OpenAI API keys, search and notification credentials, engagement targets and scope, credentials harvested from targets, findings with evidence, intercepted traffic, the interception proxy’s CA private key and the key used to sign admin session tokens. An intruder can also alter the agents’ prompts, tools and skills, so future test runs cannot be trusted even after the container is swapped out.
There is no patch, CVE or vendor advisory, because there is no maintained upstream. The tool’s built-in update route does not help either: it simply pulls the same image again.
Why it matters for UK organisations
The published country breakdown of the 62 exposed consoles names the US, Hong Kong and China and does not mention the UK, but that total is a floor. It covers only consoles reachable from the internet; anything behind NAT, a VPN or a firewall is invisible to scanners yet still exposed to anyone on the same network segment.
The more important point is who installs tools like this. UK consultancies, in-house red teams, university labs and curious practitioners are among those experimenting with agentic offensive frameworks, and ARTEX attracted plenty of attention. If a tester ran this image on a client engagement, the client’s vulnerability findings, captured credentials and network position may now sit with an unknown third party. That is a data protection problem as well as a security one. Where engagement data includes personal data, a UK firm may need to assess whether it has a reportable breach under UK GDPR, with the 72-hour clock to the ICO, and to tell the affected clients.
For buyers of testing, it is a reminder that the security of the tester’s own toolchain is part of your attack surface.
Expert view
Offensive tooling has always had a supply chain problem. The industry has long seen trojanised proof-of-concept repositories and backdoored “cracked” commercial frameworks. What is new here is the combination of hype, an abrupt takedown by the original author and a container image that most people would never think to inspect. When a popular tool disappears, demand does not, and whoever fills the gap first wins the installs.
In my experience, testers are more disciplined about client systems than about their own lab kit. A console run as root, published on all interfaces, holding plaintext LLM keys and a database of other people’s weaknesses, is exactly the kind of target we would flag in a client report. AI attack platforms make this worse because they centralise so much: scope, credentials, traffic captures and agent instructions all live in one place.
I would also be wary of treating the “official” source as automatically safe. Nobody maintains it, and I would not run it near client data without a thorough review and strong isolation.
What to do now
- Find it. Search compose files, repositories, CI pipelines and container hosts for tomicdd/artex and congdonglinux/artex, and check running containers and image digests. Treat any run of either image, however brief, as a likely compromise.
- Contain and preserve. Stop the container but keep its volumes and logs for investigation. Look for signs of persistence on the underlying host.
- Rotate everything. Revoke LLM provider keys first, then database, search, messaging, SMTP and proxy credentials, and replace the session signing key and interception CA.
- Look for use. Review web and reverse proxy logs for login requests whose responses carried unexpected content, rather than relying on status codes.
- Notify. Identify which client engagements the console held, inform those clients, and assess UK GDPR reporting obligations.
- Fix the process. Pin images by digest, build security tools from reviewed source, run consoles as non-root, bind them to localhost or a management VPN, and keep offensive tooling on segregated hosts. These map directly to the Cyber Essentials controls on secure configuration, user access control, firewalls and security update management.
Bottom line
The trojanised ARTEX image shows that attackers will go after the attackers’ tools, and that a clean source tree proves nothing about the container you actually run. Any UK team trialling agentic red team platforms should treat them like any other high-risk software: verify the provenance, isolate them and keep secrets out of them. If you pulled this image, assume you were breached and act accordingly.
Sources
- Ostorlab: Malicious ARTEX Docker Image Hands Out Root Shells
- BadByte: ARTEX Backdoor: 7,946 Pulls of a Trojanized Docker Image Handing Out Root Shells
- The Hacker News: CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access
- FirstHackersNews: Backdoored ARTEX Docker Image Exposes Servers to Unauthenticated Root Access
