Learn

In this blog post, we explore how VulHunt integrates with large language models to scale vulnerability research and reduce manual analysis effort. We walk through two practical use cases — vulnerability triaging and vulnerability hunting — demonstrating how Claude, equipped with VulHunt's MCP tools and Claude Skills, can autonomously fetch CVE details, decompile binaries, perform dataflow analysis, and generate annotated vulnerability reports. Along the way, we show how this LLM-guided workflow successfully replicates manual reverse engineering results, and how integration with the Binarly Transparency Platform enables end-to-end AI-assisted analysis.

VulHunt is a binary vulnerability analysis framework designed to bring semantic, code-level analysis to binaries. This post explains how it works, from dataflow analysis and pattern matching to IR and byte-level detection within the Binarly Transparency Platform.

In this blog post, we adopt the mindset of a vulnerability researcher and use VulHunt to hunt for vulnerabilities in the Netgear RAX30 router firmware. We walk through the full workflow, from initial reconnaissance of CGI binaries and identifying sources and sinks, to rapid prototyping of taint-tracking scopes in the VulHunt interactive shell, and finally transitioning to a robust VulHunt rule capable of scanning at scale. Along the way, we successfully rediscover known CVEs, including CVE-2023-48725, and demonstrate how VulHunt's scalability can uncover additional affected binaries beyond what was originally reported.

In our very first blogpost about VulHunt, we’ve explained what is the problem our framework solves, how it differs from common approaches to detect vulnerabilities in binaries, and introduced you to our framework’s core capabilities. As we previously discussed, VulHunt has two usage modes: standalone and agentic. In this blogpost, we’ll focus on the standalone mode, which works with VulHunt rules – Lua language scripts that interact with the core engine to detect vulnerabilities.We’ll guide you through the process of writing a VulHunt rule for a known vulnerability in Rsync, a popular tool to transfer files over the network present in many systems. We start by understanding the vulnerability before proceeding to how we can use VulHunt to detect the exact point in the code where the vulnerability occurs.

This is the third (and, we hope, final) part of a series of blog posts related to vulnerabilities identified in the Supermicro BMC firmware image authentication design. To gain more context, we highly recommend checking out the other posts in this series:

Software and its supply chain are becoming increasingly complex, with developers relying more and more on third-party frameworks and libraries to ship fast and fulfill business objectives. While the prevalence of such libraries and frameworks is a boon, allowing developers to focus on specific business logic as opposed to “reinventing the wheel,” these dependencies often introduce vulnerabilities into otherwise secure codebases.

The latest release of the Binarly Transparency Platform (version 3.5) introduces several new features designed to help organizations strengthen and secure software supply chains. One key enhancement is the integration and full support of YARA, the de facto standard widely used for malware detection, threat hunting, and digital forensics.

Cryptographic algorithms protect critical properties of modern software. With the potential danger posed by the advent of quantum computers, it has become more important for companies to identify which algorithms are present in the systems they use or ship to customers.While mature algorithm usage detection solutions for languages which target the JVM are readily found when working at the source code level (e.g. CodeQL, Semgrep), solutions working at the bytecode level are less prevalent, outdated, or do not provide comprehensive coverage.

Software mitigations play a critical role in the quest to secure the digital world. Shortly after the discovery and the rise of buffer overflows in the 90s, mitigations were introduced in the software ecosystem and eventually made their way into virtually any piece of software we run on our devices: from browsers to web servers, from OS kernels to userspace applications. Mitigations are typically designed to address one or more classes of vulnerabilities, making their exploitation more difficult. For example, while exploiting a stack overflow without any deployed mitigation is straightforward, the presence of properly implemented stack canaries requires chaining additional vulnerabilities or leveraging more complex techniques to bypass this protection. 

In a previous blog post, we detailed three Supermicro BMC firmware vulnerabilities that were originally found by the NVIDIA Offensive Security Research Team and disclosed earlier this year. All these issues were related to the BMC firmware update process and could be exploited by an attacker with administrative access to the BMC operating system who uploaded a specially crafted image. 

The Binarly REsearch team conducted an analysis of signed UEFI modules and the findings show the true scale of the attack surface hidden inside Secure Boot’s trust model. Across thousands of firmware images, we found that modern platforms typically trust approximately 1,500 signed modules, with some builds peaking above 4,000.

In this blog, we share a new finding in the XZ Utils saga: several Docker images built around the time of the compromise contain the backdoor. At first glance, this might not seem alarming: if the distribution packages were backdoored, then any Docker images based on them would be infected as well. However, what we discovered is that some of these compromised images are still publicly available on Docker Hub.

The accidental leakage of sensitive information like API keys and passwords, commonly from container images, poses significant risks, requiring thorough scanning to prevent exposure. Challenges in secret detection include managing diverse secret formats, minimizing false positives, and ensuring high performance to avoid CI/CD delays.

Binarly REsearch has investigated alarming vulnerabilities in Supermicro BMC firmware, including a critical signature verification bypass (CVE-2024-10237). These issues provide attackers persistent control beneath the OS level.

Learn how Binarly enhances decompiled code by recovering meaningful type info—boosting binary analysis, triage, and reverse engineering accuracy.

Binarly uncovers CVE-2025-3052: a Secure Boot bypass affecting most UEFI devices, enabling attackers to run unsigned code before OS load.

Binarly’s reachability analysis cuts through alert fatigue by identifying which vulnerabilities are actually exploitable. By focusing on real execution paths and environment context, it helps teams prioritize what truly matters and ignore the noise.

This REsearch report follows our recent talk at RSAC 2025, where we presented new research and revisited past research sitting at the intersection of UEFI firmware and cryptography. In this research we highlight multiple failures in key management, for instance, we cover the data breaches that affected UEFI-related vendors that led to the exposure of private keys, discussing their past and ongoing consequences on the ecosystem. Using the latest available data on the UEFI ecosystem we’ll also be able to provide new up-to-date insights on these old but current issues affecting the ecosystem.

Introducing Exploitation Maturity Score (EMS), designed to measure the present by using real-world signals like public PoCs, exploit reliability, ransomware activity, public and private threat intelligence telemetry.

The latest release of the Binarly Transparency Platform introduces powerful new capabilities that bring clarity to the chaos of vulnerability management and software supply chain security. This update is purpose-built to help enterprise defenders to prioritize what truly matters and to surface the vulnerabilities that pose real, immediate security risk.