Glasswing, Anthropic's Mythos, and others. All part of the product category lifecycle of "AI" services.

• Intro (2022–2024): Second ELIZA moment. Markets read it as omnipotence. Economics are pre Product Market Fit.
• Growth (2024–2029): Playbooks split. OpenAI bets on volume (B2C cash flow). Anthropic bets on enterprise stickiness.
• Maturity (2030s): Peak around 2030. Not much else to say.
• Decline (2035+): Already one named risk: LeCun's world models. They displace token prediction.

But right now, in 2026, the world wants tokens. Needless to say, so do I.

I took some time to get a little deeper into the Agentic architecture that is responsible for the "high-quality chaos" of security bugs being everywhere in Q1 / Q2. Not the hijacked package manager repositories. That's a different line of problems. The insecure code. The bugs.

In the following, this is a technical article. By the end of 2025, AI pentesting / red teaming was getting hot. With the new generation of Gemini models, especially.

AI pentesting 2025 / 2026 with open source tools

I am sure you also received a cold sales call or two. AI pentesting as a Service. Is this real or hype? In the following, I test 5 different open source AI pentest tools and how they perform against a purposely vulnerable Java Web App. While 2025 has been a

Because SecurityMarius Ciepluch

In Q1 / Q2 2026 we see more source code bughunting. Not yet what I would like to see (SAGE on LLMs). But I am sure this will be coming soon.

The following concept also applies to closed-source software. Decompilers like Ghidra work well in this scenario because the LLMs don't need pretty code to find bugs.

How to get bugs out of an LLM: seek bugs with DeepSeek V4 Flash

I forked Erik Hartford's clearwing codebase and added a proxy to use the cheap DeepSeek platform endpoint with the new v4 models.

These are open-weight models, that everyone can host and use. They are super cheap ($0.0028 1M tokens).

Then I came up with some catchy slogans:

1. From the DeepSeek: Security apocalypse from China.
2. DeepSeek beats Mythos in the greatest bug hunt of all time.
3. Million-dollar security bugs found with Chinese AI models.
4. Companies are not ready for what's coming from China. DeepSeek is finding exploits at scale. You will be next.

The reality is that no one is seriously looking for security bugs. Horizontally across (software) developers, we are not incentivized to fix them. Because it doesn't generate additional cash flow for the company. AI changes very little here, as long as the liability isn't clear.

12 bugs in 2 hours: hacked for 19 cents

And that's before the inflation of 2026.

We have 8 phases. For the most part, this is very pragmatic: seek deep, rate intelligently, verify.

Setup

The setup uses an LLM endpoint. I tried out

• CLIProxyAPI with Opus 4.7 (too expensive)
• OpenRouter with Chinese models (Tencent's new Hy3, InclusionAI's Ling 1T) and American models (Nvidia Nemotron 3).
  • in the future Hy3 or Qwen could be interesting
  • Ling produced too many false positives on C / C++, but I didn't test web projects where it could excel.
• DeepSeek V4 Flash (on their platform) is cost-effective and finds bugs.
  • But it needs 2-3s to answer. I built a proxy and disabled the reasoning in transit because clearwing uses pyo3 which hasn't got direct DeepSeek support.

Results

• Damn Vulnerable C++ program: 100% solved, roughly 45m due to DeepSeek's response time and because I tested clearwing with a campaign fit for an 8 GB Linux VM
  • the scaled-down version can be horizontally scaled across different smaller projects.
  • look for bugs with a small budget; just pick the right targets

  (clearwing) mc@infoseclab:~/.clearwing/campaigns$ more damn-vuln-cpp.yaml 
name: damn-vuln-cpp
budget: 30.0
depth: standard
prompt_mode: unconstrained
max_concurrent_containers: 8

checkpoint_interval_seconds: 60
output_dir: /home/mc/.clearwing/campaigns/damn-vuln-cpp-out

targets:
  - repo: /home/mc/Source/Damn_Vulnerable_CPP_Program
    depth: standard
    branch: master
    max_parallel: 2
    redundancy: 1

output_formats:
  - sarif
  - markdown
  - json

Report example (below)

• The costs in the reports are not correctly attributed by USD. It actually cost about 19 cents to run this campaign.

Summary

• Bug hunting with LLMs works.
  • the security concept of Glaswing, Mythos can be applied in open source / with open-weight models. The model is exchangeable. The logic isn't.
• Chinese models are much more affordable at scale
• This can be adapted by development teams in CI / CD, but they are not incentivized. Technology progresses faster than we do.

For now I don't publish my fork, because it's honestly not much. Just Erik Hartford's work with a little bit of an integration change to use DeepSeek.

Attachment: Clearwing report example

Sourcehunt Report — campaign-941fbf7c-Damn_Vulnerable_CPP_Program

• Repo: /home/mc/Source/Damn_Vulnerable_CPP_Program
• Findings: 30 (12 verified)
• Spend by tier: A=$13.5513, B=$37.6752, C=$0.0000
• Total spend: $51.2265

Band Distribution

• Fast: 3 runs, $13.00 (avg $4.33/run)
• Standard: 3 runs, $38.23 (avg $12.74/run)
• Deep: 0 runs, $0.00 (avg $0.00/run)
• Promotions: fast→standard: 3

Dedup Summary

• Total findings: 17
• Unique clusters: 19
• Duplicates removed: 0

Pipeline Health

ranker: succeeded
hunter_pool: succeeded

Severity Histogram

• critical: 7
• high: 18
• medium: 4
• low: 1

Findings

1. [CRITICAL] format_string at unvalid_input_src/unvalid_input_vulnerable_code.cpp:35

• CWE: CWE-134

• Evidence: exploit_demonstrated

• Discovered by: hunter:unconstrained

• Verified: yes

  Format String Vulnerability in printFormattedMessage(). The function vsprintf(buffer, format, args) at line 35 passes a user-controlled format string (from handleFormatStringVulnerability() via getline(cin, user_input)) directly to vsprintf without sanitization. An attacker can:

1. Use %p, %x, %s to leak stack and heap memory (information disclosure)

2. Use %n to write arbitrary values to arbitrary memory addresses (arbitrary write primitive)

3. Use %c to produce arbitrarily large output overflowing the 256-byte stack buffer

   Proof of Concept - Information leak via %p:
   Input: "3\n%p.%p.%p.%p.%p.%p.%p.%p\n4\n"
   Result: Leaks stack pointers, canary values, and code addresses
   Observed output: (nil).0x4182da.0x3ffffffffffffffe.0x740c4c1dcc68.0x4041f0.0x4192d0.0x17.0x1e

   Proof of Concept - Stack buffer overflow via %256c:
   Input: "3\n%256c\n4\n"
   Result: ASan reports "stack-buffer-overflow" on the buffer[256] array, with WRITE of size 257 at offset 352

   Proof of Concept - %n arbitrary write leading to crash:
   Input: "3\nAAAAAAAA%9$n\n4\n"
   Result: Segmentation fault (tries to write to address 0x4141414141414141)

   Attacker trigger: An attacker selects option 3 from the menu, then provides a malicious format string. This gives the attacker full control over process memory - allowing information leakage, memory corruption, and potentially arbitrary code execution.

• Validation axes:

  • REAL: PASS (high)

  • TRIGGERABLE: PASS (high)

    Verifier counter-argument: The provided PoCs may rely on specific compiler/ASan builds; however, the underlying classic format string vulnerability is standard and unconditional in the code. No sanitization is present, so the risk is genuine.

• Mitigations bypassed: ASLR (bypassed via format string leak), Stack canary (can be leaked)

• Chained findings: command_injection

• Exploit cost: $11.78

2. [HIGH] heap_buffer_overflow at src/dvcppp.cpp:199

• CWE: CWE-122

• Evidence: root_cause_explained

• Discovered by: hunter:unconstrained

• Verified: yes

  Heap buffer overflow in ProcessImage() at lines 199, 217, 224. The code allocates heap buffers (buff1, buff2, buff4) with sizes derived from attacker-controlled width/height fields (size1 = width+height, size2 = width-height+100, size3 = width/height). It then unconditionally copies sizeof(img.data) = 10 bytes via memcpy into these buffers using the fixed sizeof(img.data) as the copy length, without checking that the allocated size is >= 10. If the attacker sets width and height such that size1, size2, or size3 are less than 10, the memcpy writes 10 bytes into a smaller heap buffer causing a heap buffer overflow. This can corrupt adjacent heap metadata or other heap objects. Exploitation: an attacker crafts a binary with small width/height values (e.g., width=1, height=0 for size2=101 which is OK, but width=1,height=1 for size3=1 causes overflow at line 224). ASan confirmed: WRITE of size 10 at 0x602000000030 located 0 bytes after 1-byte region.

• Validation axes:

  • REAL: PASS (high)

  • TRIGGERABLE: PASS (high)

    Verifier counter-argument: The finding also claims overflow at lines 199 and 217, but the PoC only demonstrates line 224; however, the same pattern applies to lines 199 and 217 with sizes size1 and size2. For size1 = width + height, if both are small (e.g., 1+1=2), it's also vulnerable. The real risk is consistent.

• Exploit partial: primitive=bounded_write

• Mitigations bypassed: ASLR (partial - non-PIE binary)

• Exploit cost: $7.62