Skip to content

About Crucible

Who

Crucible is built and maintained by Halo Forge Labs. It started as a focused effort to answer a simple question: what happens when you point a structure-aware fuzzer at the binary parsers that every ML inference stack depends on?

What Crucible Is

A structure-aware fuzzer for the code that turns an untrusted model file into a running model. That path runs through two stages, and Crucible targets both:

  • Load time — the hand-written parsers and loaders that read a file's structure: GGUF, ONNX, SafeTensors, and TensorFlow Lite headers, metadata, tensor info, and offsets, across llama.cpp, Ollama, whisper.cpp, stable-diffusion.cpp, ONNX Runtime, and more.
  • Run time — the quantization and compute kernels that execute after the file parses. Quantization metadata (group sizes, block sizes, scale and zero-point shapes, group indices) flows straight into kernel pointer arithmetic, a surface that up-front file verification does not cover.

Other targets across the ecosystem include the ggml-rpc wire protocol, GBNF grammars, Jinja chat templates, JSON Schema constraints, and framework loaders (PyTorch/TorchScript, mistral.rs, tract).

Crucible combines format-aware mutation (60 strategies across two structure-aware mutators) with crash triage, stack-hash deduplication, automatic CVSS scoring, and disclosure-ready report generation. Every finding is replayed on a HEAD build and read at the source before it is named.

What Crucible Is Not

  • Not a model-level attack tool. Crucible does not do adversarial examples, prompt injection, model extraction, or training data poisoning. Those are important research areas — they are not what this project does.
  • Not a generic fuzzer. Tools like AFL++ and libFuzzer are excellent general-purpose fuzzers. Crucible uses them as execution backends but adds structure-aware mutation that generic byte-level fuzzing cannot achieve against binary format parsers.
  • Not an exploit framework. Crucible finds bugs and generates reproducer files. It does not develop exploits, build weaponized payloads, or automate attacks against production systems.

Disclosure Policy

All vulnerabilities discovered by Crucible are reported through responsible disclosure:

  1. Report — Findings are submitted privately to the affected project's security team (via GitHub Security Advisories, VulDB, or the project's preferred channel)
  2. Remediation — Maintainers are given time to develop and release a fix
  3. CVE assignment — A CVE identifier is requested through the appropriate CNA (GitHub, VulDB, or MITRE)
  4. Publication — Details are published after the fix is released, following a 90-day disclosure timeline

Crucible does not publish vulnerability details, proof-of-concept files, or root cause analysis for any finding until the disclosure process is complete. See the Responsible Disclosure guide for the full workflow.

Contact