Skip to content

Responsible Disclosure

Crucible is designed to find real vulnerabilities in production software. Responsible disclosure protects users while giving maintainers time to fix issues.

Disclosure Timeline

gantt
    title Responsible Disclosure Timeline
    dateFormat  YYYY-MM-DD
    section Discovery
    Crash triage & validation    :a1, 2025-01-01, 7d
    Write reproducer             :a2, after a1, 3d
    section Reporting
    Report to maintainers        :b1, after a2, 1d
    Confirm receipt              :b2, after b1, 7d
    section Remediation
    Maintainer develops fix      :c1, after b2, 60d
    Fix released                 :c2, after c1, 1d
    section Publication
    CVE assigned                 :d1, after b1, 30d
    Public disclosure (90 days)  :d2, after b1, 90d

Step-by-Step Workflow

1. Validate the Crash

Before reporting, confirm the crash is:

  • Reproducible — the reproducer file triggers the crash consistently
  • On the latest version — test against the current release
  • A real security issue — not just a handled error or assertion in debug mode
  • Minimized — reduced to the smallest file that triggers the crash

2. Assess Severity

Crucible's triage reports include CVSS estimates:

Crash Type CVSS Range Typical Impact
Heap Buffer Overflow 8.8–9.8 Remote Code Execution
Use-After-Free 8.1–9.8 Remote Code Execution
Integer Overflow 7.5–8.8 Memory Corruption
Stack Overflow 7.0–7.5 Denial of Service
Null Dereference 5.3–6.5 Denial of Service
Assertion Failure 5.3 Denial of Service

3. Report to Maintainers

For projects that support GHSA (llama.cpp, Ollama, whisper.cpp, MLX, etc.):

  • Navigate to the project's Security → Advisories → New page
  • Title: Concise description (e.g., "Heap buffer overflow in gguf_init_from_file via malformed tensor info")
  • Description: Include the Crucible triage report
  • Severity: Use the CVSS score from the report
  • Attach: The minimized reproducer GGUF file

Example links:

VulDB is a CNA (CVE Numbering Authority) that accepts third-party vulnerability submissions and assigns CVE IDs directly.

Required fields:

  • Vendor / Product / Version: e.g., ggml-org / llama.cpp / b8635
  • Vulnerability class: CWE identifier (e.g., CWE-369, CWE-787)
  • Impact: Confidentiality, Integrity, Availability ratings
  • Description: Technical summary with affected function and code path
  • PoC: Reproducer file or steps to reproduce

VulDB typically processes submissions within 2–12 hours (initial acknowledgment) and assigns CVE IDs within 2–7 business days after moderation.

Check the project's SECURITY.md for their preferred reporting channel. If none exists, email the maintainers directly.

huntr runs an OSV (Open Source Vulnerability) program that accepts vulnerability reports for open-source projects including PyTorch, TensorFlow, and other ML frameworks. Reports earn CVE assignment and bounty payouts.

  • Eligible projects: PyTorch, TensorFlow, and 100+ other OSS projects
  • Bounty range: \(500–\)3,000+ per finding depending on severity
  • CVE timeline: Typically 2–4 weeks after acceptance
  • Requirements: Clear PoC, affected version, impact assessment

Use huntr for PyTorch/TorchScript and TensorFlow Lite findings where no GitHub Security Advisory path exists.

4. CVE Assignment

After reporting, request a CVE ID through one of these channels:

Channel When to use Timeline
GitHub GHSA Maintainer accepts the advisory and assigns CVE via GitHub's CNA 1–4 weeks
VulDB Third-party submission; VulDB is a CNA and assigns CVEs directly 2–7 business days
huntr Bug bounty programs for PyTorch, TensorFlow, and other ML frameworks 2–4 weeks
MITRE CNA Fallback when no other CNA applies 2–6 weeks

Crucible's report template includes pre-filled fields for any of these submission paths.

5. Public Disclosure

90-Day Rule

The industry standard is 90 days from initial report to public disclosure. This gives maintainers adequate time to develop and release a fix.

If the maintainer is unresponsive after 90 days, you may disclose publicly with a note that the vendor was notified.

After the fix is released:

  • Publish the CVE details
  • Credit Crucible and Halo Forge Labs
  • Submit conference talk proposals (DEF CON, Black Hat, etc.)

Report Template

Crucible generates reports in this format:

# Vulnerability Report

**Type:** Heap Buffer Overflow
**CVSS Score:** 9.8 (Critical)
**Affected:** llama.cpp (gguf_init_from_file)
**Location:** gguf.c:342

## Description
A heap buffer overflow exists in the GGUF metadata parsing code...

## Steps to Reproduce
1. Build llama.cpp with ASAN
2. Run: `./main -m reproducer.gguf`
3. Observe ASAN report

## Impact
An attacker can craft a malicious GGUF file that, when loaded
by any application using llama.cpp, triggers a heap buffer overflow...

## Remediation
Add bounds checking on metadata key length before allocation.

Ethics

Do Not

  • Exploit vulnerabilities against systems you don't own
  • Share reproducer files publicly before the disclosure period ends
  • Demand payment or bounties as a condition of reporting
  • Test against production systems without authorization