ARTEX Preserves Its Final Version as a Pure-Source Backup

The maintainers of ARTEX, an autonomous penetration-testing system described as the champion entry in Baidu's "agent+" attack-and-defense competition, have preserved the project's final version as a pure-source backup after the former autumn27/artex Docker image became unavailable, directing users to the maintained mianhuatang11/artex image or a local source build. The system pairs a Go monolithic backend with an embedded Next.js frontend and PostgreSQL storage, using a dual-graph design that separates a shared asset graph from a task-specific exploration graph, and an event-driven planner/worker loop with human-in-the-loop approval gates. The repository documents that the in-application updater replaces the program but not the Docker image, so bundled tools such as Playwright and nmap require pulling and recreating the container to update.

ARTEX’s maintainers are preserving the autonomous penetration-testing system’s final version as a pure-source backup. The former autumn27/artex Docker image is unavailable, so the repository now directs users to the maintained mianhuatang11/artex image or a local source build. Developers evaluating or operating ARTEX should note that these deployment paths have different update behavior, as documented in the project repository https://github.com/mhtsec/ARTEX . The project describes ARTEX as the champion entry in Baidu’s “agent+” attack-and-defense competition. That designation is the maintainers’ description and should not be read as independent verification of either the contest result or the system’s effectiveness against real targets. The repository page https://github.com/mhtsec/ARTEX is the source of the claim. ARTEX combines a Go monolithic backend, a statically exported Next.js frontend embedded in the Go binary, and PostgreSQL storage. Exploration requires an LLM configuration through Anthropic or OpenAI credentials or the application’s interface. Its documented agent roles include goal decomposition, a planner, multiple workers and a human-in-the-loop main agent. The architecture documentation https://github.com/mhtsec/ARTEX describes these components. The system separates its data into two linked structures. A shared asset graph stores domains, subdomains, IP addresses, services, applications and endpoints. A task-specific exploration graph stores goals, intents, facts, findings and hints, while anchors associate those records with individual assets. This separation supports both an investigation’s lineage and asset-level coverage views, according to the dual-graph design https://github.com/mhtsec/ARTEX . The planner reads the exploration state and dispatches uncovered directions as intents. Workers claim one intent at a time, run tools and write resulting assets, facts or findings back to the graphs; those changes can wake the planner for another cycle. Workers can also search traces from other work items in the same task, excluding their own current trace. The engine documentation https://github.com/mhtsec/ARTEX specifies this event-driven loop and cross-worker search. ARTEX documents a recording MITM proxy for tool traffic and guard and intercept components that provide approval gates. Its interface exposes activity streams, approval records, traffic recordings, asset coverage and human-in-the-loop conversations. The repository’s subsystem and interface documentation https://github.com/mhtsec/ARTEX lists those controls and views. Vulnerability retesting runs in a separate agent session rather than restarting the original scan. A retest can conclude that an issue remains reproducible, has been fixed or cannot be confirmed. A successfully completed retest marked as fixed can update the vulnerability’s status automatically, while the original evidence and report remain available. The retesting documentation https://github.com/mhtsec/ARTEX defines that workflow. The installation script supports either an all-Docker deployment or a locally compiled application, while Docker Compose and a manual source build are also documented. The backup repository does not host precompiled binaries; it instead refers users to releases from the original repository when available. The installation instructions https://github.com/mhtsec/ARTEX describe these options. ARTEX’s in-application updater replaces the program but not the Docker image. The documentation warns that tools bundled in the image, including Playwright and nmap, are not updated through that path, and recreating the container restores the application version included in the image. Updating the full environment instead requires pulling and recreating the ARTEX container. The update documentation https://github.com/mhtsec/ARTEX distinguishes these procedures. Analysis — ARTEX effectively treats the application binary and its containerized security toolchain as separate release units. The unresolved operational issue is release coordination: an application-only update leaves bundled tools unchanged, while container recreation can replace the application with the image’s bundled version. Teams adopting ARTEX should therefore decide which combination constitutes a tested deployment and track both layers rather than treating the two update paths as interchangeable. This interpretation follows from the project’s documented Docker update behavior https://github.com/mhtsec/ARTEX .