A Safe Way to Run ARTEX: Our Audited, Source-Built Fork

Sources checked: 11 November 2026. FailSafe Research.

ARTEX is worth studying, and the prebuilt Docker image is the wrong way to do it. In November 2026 the widely used tomicdd/artex image was found to contain an unauthenticated command-execution backdoor. Researchers who wanted to examine agentic attack behavior were installing a remotely controllable implant to do it. We have published a source-built distribution of ARTEX with that implant absent, and this article explains what it changes, what it does not, and how to run it responsibly.

The repository is at github.com/failsafe-security/artex, released under ARTEX's own AGPL-3.0 license. It compiles from the audited v0.3.15 source tag, keeps the upstream runtime capabilities, and ships a documented audit of that specific build.

What was wrong with the prebuilt image

Offensive-security tooling distributed as prebuilt binaries asks you to trust an opaque artifact with a privileged runtime. The backdoor in the prebuilt image allowed command execution without authentication. An operator console that can run shell commands and send network traffic is dangerous by design; a remotely reachable backdoor into that console removes the choice entirely. Our earlier ARTEX threat report covers how the framework is being used in real intrusions, and exposed consoles were part of that picture.

The fix is not a patch on the image. It is building from source you can read, from a tag you can pin, with an audit you can reproduce.

What the fork changes

The distribution compiles the upstream v0.3.15 source with minimal deployment changes. The framework's API, UI, skills, browser MCP and browser-driven recon are unchanged. What differs:

Upstream prebuilt image versus the FailSafe build

Area	Prebuilt image	FailSafe build
Provenance	Opaque binary containing an implant	Compiled from the audited v0.3.15 source tag
Console binding	Published on 0.0.0.0:8787	Loopback only, 127.0.0.1:8787
Recording proxy	Published on port 8788	Not published
Container capabilities	Default set	Default set plus no-new-privileges
Base images	Floating tags	Pinned by digest
Self-update	Points at upstream	Disabled; one-click update removed from the attack surface

The console being loopback-only is the change that matters most in practice: the operator interface is not reachable from other hosts unless you deliberately publish it. The audit's residual-risk section is explicit that the container still runs as root for upstream capability parity, so host isolation remains the operator's responsibility.

What the audit checked

The full report ships in the repository as audit/artex-v0.3.15-audit.md. Its verdict: the known implant is absent, the build is reproducible from the source tree, and the runtime keeps upstream capability. The checks include:

• Static indicator checks for the backdoor's markers in the binary, which came back absent.
• A login request carrying the old backdoor's field, which returned 401 against this build.
• Capability verification: the browser MCP discovered its tools, Puppeteer drove the bundled Chromium, and the recon stack (Node 22, Playwright, Chromium, nmap) works as upstream intends.
• Reproducibility: binary and image hashes recorded for the arm64 build, with make verify checking the implant indicators and printing the artifact hashes.

The audit is honest about its limits: it proves this tree builds this binary and that the known implant is absent, not that every dependency is free of every defect. The browser stack is the largest third-party surface, Go modules are checked against go.sum but not audited line by line, and the image is not yet signed or SBOM-annotated. Those caveats are in the repository, and we would rather publish a bounded claim than a comforting one.

How to use it

The repository's README carries the full quick start. The essentials: Docker with Compose v2, about 5 GB of disk, and a copied .env.safe with a database password and optionally an LLM key. The compose file builds from source and binds the console to localhost.

Authorization is the first configuration decision, not an afterthought. ARTEX runs an autonomous agent that can execute shell commands and send network traffic. Run it only against systems you own or have explicit written permission to test. Keep the console loopback-only. Do not put real credentials near the environment. Treat the data volumes, which can contain scan evidence with credentials and tokens, as sensitive.

If self-hosting the operational controls is more than your team wants to carry, FailSafe also runs managed ARTEX engagements with GlassBreak, our cyber-grade model, under agreed scope, isolation and evidence handling. Contact the team to scope one.

Why we published it

Agentic attack frameworks are now part of the threat landscape, and defending against them requires understanding what they expect from their environment. A research community forced to choose between opaque prebuilt images and abandoning the subject entirely will make the wrong choice sometimes. A readable, reproducible, audited distribution is the minimum bar for studying offensive agents without installing someone else's backdoor.

The repository will track upstream releases: review the diff, rebuild, rerun the verification, update the audit, then deploy. If you use ARTEX in authorized research, use a build you can verify.