REsearch

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.

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.

In this blog post, the Binarly REsearch team introduces a novel methodology for detecting UEFI bootkits by analyzing their unique code behaviors. By starting from an in-depth analysis of known bootkits, we identify features that can be used for generically detecting bootkits and build rules that we used for hunting new unknown bootkits. Then, we show how these rules can be even further improved, by leveraging advanced static analysis techniques, semantic detection and ML-based clustering.