Censys, which surveys publicly exposed assets on the internet, announced on November 5, 2026 that it had identified 1,465 hosts with exposed admin panels for ARTEX, an AI-powered penetration testing tool, as of early November. ARTEX builds a work plan from goals given in natural language and carries out tasks by combining external AI models with existing security tools. It can be used for legitimate security assessments, but it can also be abused for unauthorized intrusion. Excluding two large groups that appear to share identical configurations leaves about 815 hosts, but that does not mean each one is run by a different attacker. Separately, research by Check Point Research found records of ARTEX continuing attacks without additional instructions, as well as a case in which a breach succeeded even though no financial gain was made. Distinguishing the number of exposed hosts from actual attack activity reveals what AI-driven autonomous attacks really look like.
1,465 exposed ARTEX hosts, about 815 after removing duplicate configurations
According to the findings published by Censys, the figure of 1,465 is the number of hosts detected using the page title used by ARTEX's admin panel and the static files of Next.js, a framework used to build web applications. Of these, 493 and 157 hosts belonged to groups that appear to have identical configurations. Excluding those 650 hosts leaves 815, which Censys considers deployments with differing configurations. However, differing configurations do not necessarily mean differing operators, so the 815 figure cannot be interpreted as the number of attackers or attacking organizations.
Censys itself states clearly that not every ARTEX instance it found is being operated with malicious intent. In addition, being able to reach an admin panel from the internet is a separate matter from being able to operate its management functions without authentication. This research confirmed that admin panels were exposed, but it does not show that all 1,465 hosts could be operated while bypassing authentication. The number of exposed hosts, the variety of configurations, actual attack activity, and the occurrence of damage must each be treated as distinct metrics.
The difference becomes clear when compared with Check Point Research's investigation of ARTEX's internal records. The company analyzed 10 externally exposed databases to examine the actual instructions and agent behavior. While Censys's research captured what was publicly visible on the internet, Check Point Research's analyzed specific attack activity from execution logs left inside. The table below summarizes what each study observed and what can be concluded from it.
| Observed item | Count / scale | Researcher | What can be concluded |
|---|---|---|---|
| Hosts with exposed ARTEX admin panels | 1,465 hosts (early November 2026) | Censys | Number of exposed hosts matching the detection criteria. Does not indicate the number of attackers or victims |
| Deployments after excluding 650 hosts with identical configurations | About 815 | Censys | Number of hosts that appear to have different configurations. Not necessarily the number of unique operators |
| Exposed databases whose internal records could be analyzed | 10 | Check Point Research | Recorded operation behavior and results. Not a representative sample of all ARTEX use |
| Successful breaches and cryptocurrency obtained | Determined from individual operation records | Check Point Research | Allows breaches such as data exfiltration to be distinguished from financial gain by attackers |
Thus, the figure of about 815 shows only that a certain number of exposed ARTEX hosts with apparently different configurations exist. Whether they are actually being used in attacks, and how much damage has occurred, must be confirmed with other evidence. Because the two companies' studies differ in what they observed and how they counted, their numbers also cannot be compared directly to judge whether attack activity is rising or falling.
Exposed directories revealed command histories and SSH-related files
Censys also found open directories on 32 of the hosts running ARTEX, where file listings and contents could be viewed from outside. These directories held tools used for post-intrusion activity and command histories, and also included SSH-related files. What matters is that not only were the admin panels visible externally, but files tied to actual operating environments were also exposed. Such information can help analysts understand the configuration and operations of the tools used in attacks, but it is also a security risk for the operators who exposed it.
The exposure is not static, however. Censys observed that many directories were closed within hours to days; 10 were closed between November 3 and 5, while 15 new ones were exposed on other hosts. In other words, a list of open directories found at one moment does not represent the continuing state of exposure. Because exposure and closure repeat over short periods, continuous observation is needed to understand the real situation.
Censys also examined other services running on the ARTEX hosts. Of the 1,465 hosts, 155 (10.6%) were found running services that fall under other threat categories, and 43 had software that relays or resells access to large language models (LLMs). However, the fact that another service runs on the same host does not by itself show that ARTEX is being used maliciously. Nor is it evidence that multiple hosts or services are operated by the same attacker.
ARTEX is distinctive in that it does not embed its own AI model but instead works by combining external models with existing security tools. When given a goal in natural language, the AI builds a work plan, multiple agents run tools, and the next step proceeds based on the results. According to CERT-EU's explanation, derivative versions have been confirmed even after the original repository was made private. In this design, the AI links everything from interpreting the goal to evaluating results and choosing the next action, so work can be repeated without humans directing each individual operation.
AI continued attacking without further instructions; breach succeeded despite zero revenue
Check Point Research analyzed 10 externally exposed ARTEX-related databases to examine actual attack instructions and agent execution results. The company's report also cites figures of 2,557 systems in total, including those observed in the past, and 1,608 that were active and exposed at the time of the investigation. However, because these differ from Censys's research in observation timing and in how duplicates are excluded, they cannot be read as an increase from 1,465 to 1,608. The two companies' findings should be treated as independent observations.
The internal records also confirmed cases in which ARTEX advanced attacks without continuous human instruction. In one operation aimed at obtaining cryptocurrency, the agent reportedly continued working without additional instructions after being given its initial goal. This operation set 292 targets and recorded 230 findings and 400,791 messages. However, the figure of 230 is the number of findings output by the tool, and does not indicate the number of vulnerabilities confirmed as exploitable or the number of compromised organizations.
Interestingly, despite executing such a large volume of processing, the attacker gained no financial profit. According to Check Point Research, there was a case in which an ARTEX agent mistook a success response returned by an API for evidence that a cryptocurrency transfer had been completed. But the attacker's wallet balance was $0, and no actual transaction record was found. The agent had failed to distinguish a system-level success response from an actual transfer of funds on the blockchain.
That said, the lack of financial gain does not mean the attacks caused no harm. The company also reported cases in which actual breaches succeeded, including information exfiltration from databases and overwriting of data on Amazon S3. This shows that an AI agent's ability to keep working autonomously, the success of system intrusion or data tampering, and the attacker's ultimate profit are separate outcomes. Even in operations where the attacker earned no money, victims still face the risk of information leaks and compromised data integrity.
However, these records of autonomous execution relate to the specific operations analyzed here. They do not show that every operation using ARTEX has the same degree of autonomy or succeeds in intrusion without additional instructions. To assess the real capabilities of AI agents, it is necessary to check whether individual operations succeeded, not just the number of executions or messages generated.
Defensive focus: exposed admin panels and managing authentication and privileges
In its November 5, 2026 explanation, CERT-EU pointed out that ARTEX's adherence to its authorized scope of work and its avoidance of destructive operations depend on configured rules and the judgment of the AI model in use. According to the agency, there is no mechanism that technically enforces these constraints. The convenience of specifying goals in natural language is a separate matter from being able to reliably restrict an AI agent's actions to the permitted scope. For this reason, it is important to limit access and operation privileges on the actual systems rather than relying only on instructions to the AI model.
CERT-EU recommends reducing internet-accessible assets, isolating admin panels, applying patches, deploying multi-factor authentication, and monitoring access privileges. It also urges organizations not to exclude seemingly minor misconfigurations from remediation, because in an environment where AI agents operate multiple tools in succession, individual configuration flaws can lead to the next step. When an admin panel is exposed, it is necessary to check not only whether authentication exists but also which functions and what range of data are accessible after authentication.
This research revealed that command histories and related files were left in exposed directories, and that internal records show AI agents autonomously repeating large volumes of processing. However, not every exposed host was being used in attacks, and the number of observed hosts cannot be taken as the scale of the threat. What matters for defenders is not whether attackers ultimately profited, but understanding how far they could proceed using an exposed admin panel or a misconfiguration as a foothold. Restricting external access and properly managing authentication and privileges is needed to cut off the path by which continuous operations by AI agents escalate into a breach.