Threat Intelligence Feed

BearSSL — Applying the wolfSSL Methodology to an Unfuzzed Target

After validating our LLM-augmented fuzzing pipeline on wolfSSL (a heavily audited, OSS-Fuzz target), we applied the exact same approach to BearSSL — a compact TLS library that has never been through OSS-Fuzz and appears unmaintained since 2022. The hypothesis: less-audited code yields more findings.

Why BearSSL?

BearSSL is written by a cryptographer known for constant-time implementations and security-first design. But it lacks the continuous fuzzing and enterprise-grade defensive patterns that wolfSSL has built up over years of OSS-Fuzz and FIPS certification. The question: does craftsmanship alone prevent the bugs that automated tooling finds?

Fuzzing: 419M executions

Same CMPLOG + LAF + ASAN pipeline as wolfSSL. Two harnesses targeting the X.509 certificate parser and private key decoder — the highest-risk attack surfaces.

Coverage plateaued early and never increased during extended runs — the harnesses couldn’t break through BearSSL’s input validation. Same limitation as wolfSSL: real TLS fuzzing needs grammar-aware seed generation and multi-message handshake sequences, not just random mutation.

Multi-model code review: 3 models, same approach

We ran the identical multi-model pipeline from the wolfSSL research: function-level chunking, target-specific system prompts, force local GPU only, Claude FP filtering on each model’s top candidates.

What the models found

Each model produced 1 Claude-confirmed true positive. We are currently in manual review to verify exploitability and assess impact.

• 1 finding cross-confirmed by 2 models (qwen + deepseek independently flagged the same function) — this is the strongest signal we’ve seen across all our research. In wolfSSL, no finding was cross-confirmed.
• 1 finding unique to dolphin-mistral — the uncensored model caught a different class of issue that the censored models didn’t flag. This validates the multi-model approach: each model has different blind spots.

We are not disclosing specific details until manual verification is complete. BearSSL is unmaintained, which means any confirmed findings cannot be patched upstream. We will publish full technical details after completing our assessment and determining the appropriate disclosure path.

wolfSSL vs BearSSL: what the comparison tells us

The pattern is clear: less-audited code yields more findings. wolfSSL’s one confirmed finding was in debug-only code behind #ifdef. BearSSL’s findings are in production code paths. The absence of continuous fuzzing (OSS-Fuzz) and the lack of systematic defensive macros make a measurable difference — even in code written by one of the world’s best cryptographers.

Multi-model validation: confirmed

The wolfSSL research suggested that running multiple models adds noise without adding bugs on mature codebases. BearSSL tells a different story:

• Cross-model confirmation works. Two models independently flagging the same function is a much stronger signal than a single model’s verdict. In wolfSSL we never saw this. In BearSSL we did.
• Dolphin finds what censored models miss. The uncensored model caught a different class of issue entirely. For less-audited targets, the multi-model approach is justified.
• BearSSL scans are fast. 8.3 minutes for qwen on 59K lines. The entire 3-model pipeline (code review + Claude filter) completed in under an hour. For small libraries, multi-model scanning has negligible cost.

Status