Artex goes closed source: what an author can do when a security tool is abused

A tool built to find vulnerabilities was found being used in real attacks, and its author chose to shut the door. That happened in early October.

What happened

Artex is an AI-driven security tool. Its original goal was plain: help organisations find the vulnerabilities in their own systems.

Korean authorities say it was very likely used in breaches at more than seven financial institutions. Korea’s Financial Services Commission put the number of affected people above 68,000, with around 25,000 customers at Shinhan Bank alone. Similar attacks were reported in Japan at the same time.

The developer, using the alias Autumn-27, posted a statement on GitHub: the project will not be updated, will move to closed source, will publish no new public releases, and will offer no maintenance support. Using Artex for attacks, he said, “completely goes against” what it was built for.

This is not new

Exploit tooling being abused is nearly as old as the tooling. Metasploit, Cobalt Strike, every scanner in between — they all run the same loop:

1. A tool is built so defenders can verify their systems.
2. Attackers find it more convenient.
3. People start asking who is responsible.
4. The author tightens distribution (closed source, vetting, commercial licensing) or stops maintaining it.

What differs is speed. Artex is AI-driven: it pushes down the cost of the “find the vulnerability” step, so an attacker does not have to become an expert first. The more automated the tool, the shorter the gap between intent and abuse.

Does closing the source fix it

My answer is no, but it does fix part of it.

Closed source cannot stop anyone who already has a copy — once code is public, it does not come back. What it does is raise the cost of the next acquisition: new versions are no longer a download away, so abusers have to maintain their own fork.

The costs are concrete:

Gain	Cost
Less casual abuse	Defenders can no longer use it
The author stops endorsing downstream behaviour	No one can audit whether it is safe
Distribution is controllable	Community fixes and forks disappear

Once a security tool goes closed, it becomes something that cannot be audited. Defenders lose their ability to verify with it, while attackers lose nothing — they keep the old version.

My take

What this really exposes is not whether one tool is good or bad, but where the “open security tool” shape sits in an automated era.

When attack cost is mostly a function of human skill, publishing the tool is net positive: there are more defenders than attackers, so the benefit is larger. When attack cost is mostly a function of how automated the tool is, the net benefit turns negative, because the attacker can copy as fast as the defender.

I do not think the answer is closed source. The likelier answer is friction at distribution: signed applications, declared purpose, traceable usage records. None of them is perfect, but each turns “who is using this” from invisible into partly visible.

Until then, every incident like this asks the same question again, and each answer lands closer to “don’t publish”.