Lighting the Way in the Dark: Unveiling Zorya-Volos at BSides Joburg 2026

The energy at BSides Joburg is always incredible, and this year’s event was no exception. It is a space where researchers, engineers, and hackers gather to share the specialized tools they’ve been pouring their late nights into. I had the privilege of taking the stage to present our latest research: Lighting the Way in the Dark: Binary-Only Race Detection in Go with Zorya-Volos. For those who couldn’t make the live talk, here is a summary of what we covered and why it matters for modern security engineering.

The Hard Problems: Binary Analysis and Concurrency

To understand the value of Zorya-Volos, we first need to look at why binary analysis is inherently so challenging. Analyzing binaries is crucial because compiler-derived vulnerabilities and hardware-derived bugs often do not manifest at the source code level, yet they can easily cause code execution vulnerabilities and affect widely used cloud software. Furthermore, binaries are rarely distributed with input samples, lack semantic or typing information, and must run across multiple ISAs and complex hardware architectures. When organizations employ IP-protective obfuscation and stripping, the safety analysis of the final product becomes significantly harder.

Detecting race conditions specifically introduces another heavy layer of complexity. It requires grappling with:

• Thread Interleaving Analysis: Threads spawn in different schedulings, reorder, die, and respawn unpredictably, creating a massive matrix of potential states.
• Shared Resource Analysis: Navigating complex channels, sockets, files, and shared memory without explicit mapping or source-level synchronization primitives.
• Memory Interaction Sampling: Deciding whether to sample ahead of time, during execution, or analyze after execution, all while dealing with non-deterministic runtime behaviors.

Traditional symbolic execution struggles to scale here due to the massive path explosion; as the engine attempts to map conditional branches, the number of active symbolic states grows exponentially over subsequent execution steps, eventually overwhelming the solver.

Introducing Zorya: Bridging Literal and Concolic Execution

To tackle these scaling issues, we developed Zorya, an engine that mathematically models the unique idiosyncrasies of Go’s runtime into its core analysis.

The Zorya pipeline begins by taking the target ELF binary and pulling CPU register and memory section dumps at a chosen execution address. It then lifts the binary to Ghidra P-Code, utilizing an internally developed translation layer that interfaces directly with the Z3 SMT solver.

Zorya stands out in the landscape of race detection because it:

• Blends both literal and concolic execution: This overlay execution model effectively mitigates the state explosion that historically plagues traditional symbolic engines.
• Is developed entirely in Rust: This guarantees high-performance memory safety and helps weed out compiler or common bugs on the analysis side.
• Features a flexible plugin architecture: Allowing for tailored analysis and the rapid deployment of custom rulesets for specific vulnerability classes.
• Performs analysis without requiring source code: It acts in a completely binary-format friendly manner while successfully automating test case generation and reproducing input samples.

Volos: The Concurrency Judge

While Zorya handles the core symbolic execution, the Volos plugin acts as the memory concurrency judge.

Volos solves the thread interleaving problem by applying “Happens-Before” lock-set analysis directly at the instruction level. By intercepting routine forks and release/acquire events, Volos tracks vector clocks across threads. This allows the engine to definitively pinpoint where threads read or write to shared memory without the protection of a shared lock, effectively mapping Go’s runtime scheduler behavior to state-changing operations within the binary.

Real-World Impact: Hunting CVEs in the Dark

Zorya is not just an academic exercise—it finds real, reproducible bugs in widely used software critical to SecOps.

During our May-June 2026 runs using the Zorya MCP Server, we analyzed 148 targets (averaging a cost of just €3 per target identification) and uncovered 28 distinct findings. These included integer overflows, out-of-bounds slice errors, and nil-pointer dereferences across various off-the-shelf (COTS) projects.

Most notably, Zorya picked up multiple critical CVEs:

• CVE-2026-54908: A remote denial of service via a panic while parsing a crafted ECDHE_PSK ServerKeyExchange message in [github.com/pion/dtls/v3](https://github.com/pion/dtls/v3). Zorya-Volos successfully flagged a fatal out-of-bounds read (CWE-125) occurring because the code failed to apply defensive checks against the length of read-in data before indexing the array. This flaw disrupts the availability of the affected service for versions prior to 3.1.4.
• CVE-2026-54909: A XOR-MAPPED-ADDR panic in stun.

We will be posting more about the framework as time allows, if you’d like to check out the slides they’re available here: Lighting the Way in the Dark (BSides JHB 2026)

Partner with KMSEC

Building Zorya-Volos aligns perfectly with our core mission at KMSEC: delivering practical, in-depth security assessments and bespoke research. Automated, surface-level scanners can only get you so far. Tackling deeply embedded concurrency bugs requires bespoke engineering and a willingness to dive straight into the binary.

Whether you require deep-dive vulnerability analysis, custom tool development, or advanced technical training for your engineers, explore our consultancy and training services to see how we can partner together.