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 purpose-built for ML model file formats and inference infrastructure. Crucible targets the C/C++ parsing code that runs every time someone loads a model through llama.cpp, Ollama, whisper.cpp, stable-diffusion.cpp, or any tool built on the ggml ecosystem.

Current target surface:

  • GGUF file format — header, metadata, tensor info, alignment, and data region parsing
  • ggml-rpc protocol — the unauthenticated wire protocol for distributed inference
  • GBNF grammars — constrained decoding grammar parsing and evaluation
  • Jinja templates — chat template rendering from model metadata
  • JSON Schema — structured output constraint parsing
  • Server API — llama-server HTTP endpoint request handling
  • Downstream projects — whisper.cpp, stable-diffusion.cpp, Apple MLX, and other ggml consumers
  • External ML frameworks — PyTorch/TorchScript deserialization, TensorFlow Lite model loading, ONNX Runtime

Crucible combines format-aware mutation (60 strategies across 12 categories) with crash triage, automatic CVSS scoring, and CVE-ready report generation.

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