Backdoored ARTEX Console Gave Root to Anyone Who Knew the Trigger

A backdoored ARTEX console image, pulled about 9,000 times from Docker Hub, left 62 internet-facing AI pentest consoles serving a pre-authentication root shell in early November 2026. The same family of public AI attack tools sits at the center of CERT-In's warning about Crafty Falcon, a campaign stealing funds from Indian banks and crypto firms.

What breaks when the pentest console is the asset?

A compromised pentest console hands the attacker the target’s entire intrusion, pre-assembled. Badbyte, the researcher who tracked the trojanised ARTEX build, lists what such a console holds: unpatched findings for every system in scope, live credentials harvested during runs, captured sessions and a network position inside or beside the environment under test.

The backdoor grants root before authentication. A hidden routine in the login handler runs attacker-supplied commands as root before any username or password check, then returns the output. We are not describing the trigger; the image names below are enough to hunt.

The second-order risk is worse. Whoever controls the backdoor can quietly change what the agents do on later runs, Badbyte notes. An autonomous pentest agent already has permission to scan, exploit and pivot inside a client network.

It runs under a signed scope letter, and the blue team expects its traffic. Tamper with its instructions and the engagement itself becomes the intrusion.

How did one docker-compose line backdoor ARTEX?

The attacker never touched the application code; they changed which image the compose file pulls. ARTEX, an open-source AI penetration-testing console, was removed from GitHub by its developer after it turned up in real intrusions. The reporting does not name the developer or call the upstream project malicious. Copies filled the gap.

Known replacements include a fork under the trhhubsd account (2,449 stars and more than 600 forks, according to Badbyte), mhtsec/ARTEX, also published on Docker Hub as mianhuatang11/artex, and RuoJi6/ARTEX. The first two can no longer be downloaded.

In one copy, a single line of docker-compose.yml was edited to point at the Docker Hub image tomicdd/artex. The repository read like ARTEX; the container that ran was something else. As Badbyte put it, the result is “an unauthenticated root shell on every install, and it never shows up in a code review.”

The 2024 xz-utils backdoor (CVE-2024-3094) hid in the same place: build and packaging plumbing, not the source people audit. Docker Hub adds no gate. Community images get no mandatory review, most are unsigned, and Docker Content Trust is off by default.

• tomicdd/artex: backdoored, about 9,000 pulls.
• congdonglinux/artex: described as backdoored and identical to tomicdd/artex.
• mianhuatang11/artex, autumn26/artex, andy1099zz/artex, dgddw/artex, trhhubsd/ARTEX, ylh440104/artex: other “artex” namespaces. None is stated to be backdoored; none is vetted.

What do the 62 backdoored ARTEX consoles prove, and what don't they?

Sixty-two consoles were confirmed serving the backdoored build; the larger figure of 1,645 measures exposure, not compromise. Badbyte observed the 62 between 2 and 4 November 2026: 26 in the United States, 17 in Hong Kong and 7 in China. The remaining 12 are not broken down.

The earliest backdoored console was online by 20 October 2026, reportedly twelve days after the image was pushed. The push date is not stated; roughly 8 October is our inference.

On 4 November, 1,645 hosts were serving the ARTEX console. Every one is an attack tool listening on an open port, which is a finding before anyone checks the image.

Badbyte is blunt about ARTEX operators: “The people they were after had already chosen to run an unvetted attack tool as root on an open port.” But plenty of curious, legitimate users installed it too: “They did not sign up for a root shell on their own server.”

What is the Crafty Falcon campaign CERT-In described?

Crafty Falcon is CERT-In’s tracking label for an active campaign against Indian banking, financial services and insurance (BFSI) organizations, cryptocurrency exchanges and digital-asset firms, with theft of keys and funds reported. It follows an October 2026 CERT-In alert covering NBFCs, digital lending platforms, fintechs, payment service providers and crypto wallet operators.

CERT-In names four tools: ARTEX, PentAGI, Cairn and CyberStrikeAI, all public AI-driven offensive tools rather than bespoke malware. In CERT-In’s words, they “execute complete attack chains autonomously at machine speed, generate and refine large numbers of tailored attack scripts in rapid succession, and adapt their payloads based on target responses.”

Infrastructure rotates IP addresses within hours to days, which makes blocklists close to useless. The rest is familiar:

• Newly disclosed file-upload and deserialization chains leading to web shells in PHP and Node.js apps. No CVEs were given.
• Cloud infrastructure for command execution and payload deployment.
• Exposed non-production environments mined for shared credentials, tokens and network paths before a pivot to production.
• Reverse-engineered victim code for tailored exploits, and modified app packages making unauthorized API calls.
• Log deletion and endpoint-security tampering to slow incident response.

How do stolen API keys move money from inside the allow-list?

The attacker calls the fund-transfer API as the victim’s own infrastructure, so application-level checks never run. CERT-In says initial access comes largely from exposed applications, APIs and privileged endpoints, where operators steal credentials for payment aggregators, payment gateways and partner banks.

Those credentials are used from inside the victim’s allow-listed infrastructure. Loan creation, KYC, sanction, beneficiary verification, balance sufficiency and per-transaction limits all live in the application. The API trusts the caller, and the caller is now the attacker.

CERT-In lists four more entry paths:

• Stolen long-lived static or hard-coded API tokens.
• Source-code repository compromise through forged commits.
• Plaintext credentials in configuration files, source code or databases.
• Applications and remote services without MFA.

Before moving large sums, operators send test transfers of about Rs. 1, then route funds to mule accounts across multiple banks and abuse payment aggregators’ merchant settlement APIs. The same Rs. 1 check shows up in account-takeover and BEC fraud.

None of this needs AI. It is a confused-deputy failure plus broken function-level authorization, both staples of the OWASP API Security Top 10. AI changes the speed, not the flaw. Modified app packages also break the assumption that only the legitimate client calls these APIs, which is exactly what API penetration testing should challenge.

What should teams check if they ran ARTEX or a replacement fork?

Assume compromise if any host ran tomicdd/artex or congdonglinux/artex, and treat every other ARTEX fork as hostile until proven otherwise:

• Search registries, CI logs and container runtimes for both namespaces. Rebuild affected hosts; do not clean them.
• Rotate every credential, token and session the console stored or captured, including client credentials from past engagements.
• Re-validate findings produced after the pull. A controlled agent can suppress results as easily as it can add actions.
• Diff docker-compose.yml, Dockerfiles and CI configs against the last known-good commit, and pin images by digest, not tag.
• Put consoles behind a VPN or an identity-aware proxy, off the public internet.

Practitioner’s note

In our engagements, offensive tooling is the least-governed software in the building. Red team boxes skip the asset inventory, run as root “because the tool needs it” and hold more credentials than most admin workstations.

When we review containerized apps, we grep auth paths first for anything that shells out. Input that reaches a command before the credential check is critical, however it got there. If your tooling comes from public forks, an AI supply chain security audit belongs in scope.

What do CERT-In's AI security auditing guidelines require?

The new Artificial Intelligence Security Auditing Guidelines, published alongside the advisory, require human approval for consequential AI-agent actions. Auditors must test agent identities, authorized objectives, approved tool use, permission boundaries and least privilege. High-risk systems need emergency interruption, credential revocation and controls that prevent automatic restarts.

An agent with a payout API key and no approval gate is the Crafty Falcon problem with you as the owner. A kill switch the agent can restart around is not a kill switch. AI agent penetration testing should verify those properties by trying to break them.

What is still unknown?

CERT-In has not linked Crafty Falcon to the backdoored image; the two share a toolkit, not evidence. No CVEs were named for the web-shell chains. The ARTEX developer is unnamed, the push date is unconfirmed, and nobody has said whether the backdoor was used against the 62 consoles’ owners or their targets. Refer to CERT-In’s advisory for indicators.

FAQ

Was ARTEX backdoored on Docker Hub?

Yes, in specific images. tomicdd/artex and the identical congdonglinux/artex give a root shell before authentication; other "artex" namespaces are unvetted.

Is the original ARTEX GitHub project malware?

Nothing reported says so. The developer removed it after it was abused in real intrusions, and trojanised copies appeared afterward.

How many ARTEX consoles were exposed in November 2026?

1,645 hosts served the console on 4 November 2026; 62 were confirmed serving the backdoored build between 2 and 4 November.

What is the Crafty Falcon cyber campaign?

CERT-In's label for an ongoing campaign that uses public AI offensive tools and stolen API credentials to steal keys and funds from Indian BFSI, crypto and digital-asset firms.

If your team runs AI agents with real tools, or AI pentest consoles with real credentials, agent::offense tests both the way an attacker would. See our AI and LLM agent security testing.