Copy Fail detector, or why uncensored AI coding tools matter

Also known as: sometimes security research looks malicious because reality is malicious enough

TL;DR

Check if your system is vulnerable:

curl -fsSL https://raw.githubusercontent.com/codref/copy-fail-detector/master/detect.py | python3

Full source and documentation at github.com/codref/copy-fail-detector .

Copy Fail is one of those bugs which is both elegant and terrifying.

The exploit is tiny, almost rude in its simplicity: open /usr/bin/su read-only, abuse AF_ALG plus splice(), overwrite the cached beginning of the binary with a minimal ELF payload, then execute it.

No fancy framework, no gigantic exploit chain, no suspicious 30MB binary blob downloaded from somewhere with a skull in the domain name. Just a few lines of Python touching a weird but very real Linux kernel path.

And this is exactly where many AI tools become useless.

The problem with “security safety” filters

Try to ask common AI coding assistants, including tools like Copilot, to analyze an exploit like this.

Very often the result is not analysis, but panic:

Sorry, this code appears malicious.

Well, yes. It is an exploit. That is the point.

Security research often starts from malicious-looking code, because vulnerability research is the study of how systems fail under hostile conditions. If a tool refuses to even explain what the payload does, or why a syscall sequence is dangerous, it is not protecting the user. It is removing one of the most useful workflows from defensive research.

This is especially frustrating when the objective is not to weaponize the exploit, but to build a safe detector.

In this case the useful question was simple:

Can we reproduce the vulnerable kernel primitive on a harmless temporary file, without touching /usr/bin/su and without executing the payload?

That is not malware development. That is exactly what administrators need.

Enter opencode and Kimi

This project was developed by simply asking Kimi to analyze the public Copy Fail exploit.

No magic prompt. No “jailbreak”. No ridiculous roleplay.

Just: understand this exploit, explain the payload, and build a safe detector.

Kimi understood the important pieces:

• the payload is a tiny ELF which calls setuid(0) and then execve("/bin/sh", NULL, NULL)
• the actual vulnerability is not the shellcode, but the AF_ALG plus splice() page-cache write primitive
• a detector should not execute su
• a detector should create a temporary file, open it read-only, replay the primitive, and compare the bytes before and after
• kernel version checks are only hints, because vendors backport patches and custom kernels exist

The result is this repository:

curl -fsSL https://raw.githubusercontent.com/codref/copy-fail-detector/master/detect.py | python3

It is short, practical, and it gives a behavioral answer instead of only guessing from /proc/version.

Why this matters

AI coding tools are not all the same.

Some products, Copilot included in many practical workflows, are tuned to refuse at the first sight of an exploit. That may look good in a compliance screenshot, but it is not very useful if your job is to understand whether your fleet is vulnerable before someone else does.

Tools like opencode are extremely valuable for the security research field because they can stay with the technical problem instead of running away from it.

An opencode Go account can give hours of pure analysis at a very low cost. Using models like Kimi 2.6, you can keep a real engineering loop open:

• read the exploit
• decode the payload
• identify the primitive
• build a detector
• test it
• improve the documentation

This is the good part of AI-assisted security work. Not “press button, get hacker tool”, but “press less buttons, think more clearly”.

Verification matters

After Kimi built the detector, the result was reviewed with GPT-5.5.

That second pass confirmed that Kimi did a good job: the detector exercises the same kernel primitive on a harmless file, treats version checks as a heuristic, and reports a real byte-level modification when the kernel is vulnerable.

No AI vendor gets an ID card here.

The lesson is not “model X is always better than model Y”. The lesson is that we finally have cheap, competent tools which can help with real security research, provided they are allowed to actually look at the problem.

The final result

The detector is intentionally boring:

• it checks prerequisites
• it creates a temporary file safely
• it opens it read-only
• it replays the exploit primitive
• it reports whether the page-cache bytes changed

Exit codes are also boring, as they should be:

0 = not vulnerable by behavioral test
1 = vulnerable
2 = inconclusive

This is the kind of small defensive tool that should be easy to build, easy to audit, and easy to run.

And honestly, it is a good example of where AI tools can be more than autocomplete.

They can be research companions, provided they are not trained to faint every time the word “exploit” appears on screen.

The tool

The Copy Fail detector is available at github.com/codref/copy-fail-detector .

Run it, review it, and use it to check whether your systems are vulnerable before anyone else does.