Multi-Patch Vulnerability Fixes Create Blind Spots in Open Source Security
Researchers reveal that many open source vulnerability fixes are applied in multiple commits, with the first often leaving the flaw accessible, bypassing standard vulnerability management.
A common shorthand in vulnerability management—a CVE is linked to a patch, the patch is applied, and the ticket is closed—is proving insufficient for many open source projects. A new study by researchers at the University of Texas at Dallas highlights a significant blind spot: a substantial number of open source vulnerability fixes are not delivered in a single, definitive patch. Instead, they arrive as a series of commits, with the initial commit often failing to fully address the vulnerability, leaving the software exposed for a period.
The research team analyzed 1,646 open source CVEs from the National Vulnerability Database, spanning records from 1999 to 2025, that exhibited this multi-patch behavior. While these cases represent a relatively small fraction of all open source CVEs with linked patches (approximately one in fifteen), the operational implications are considerable. The interval between the first and last commit in these multi-patch sequences creates a window of opportunity for attackers.
On average, the study found 2.55 patches were required per CVE. This distribution is not uniform across projects; for instance, ImageMagick, which maintains multiple release lines, needed more than one commit for nearly a third of its fixes, largely due to the necessity of porting the same repair across all supported versions.
The researchers categorized these multi-patch scenarios into three main groups. The largest, comprising 830 records, involves vulnerabilities residing in multiple locations within the codebase, such as separate branches, methods, or even distinct projects. Due to the nature of version control systems like Git, a single commit cannot be applied universally, necessitating individual ports of the fix to each affected location.
A second category includes security changes bundled with other development tasks, like temporary workarounds, changelog updates, or documentation modifications committed separately. The third and most concerning group consists of defective fixes, where the initial patch either incompletely addresses the vulnerability or introduces new bugs. Incomplete fixes alone accounted for 641 records, making them the second-largest subcategory.
Automated detection tools, including prominent open-source systems like CodeBERT and UniXcoder, struggle to differentiate between partial and complete fixes. When tested on the incomplete-fix dataset, these models exhibited accuracy and F1 scores below 50%, performing worse than random guessing. The researchers attribute this limitation to the fact that security patches often alter only a small portion of code, leading the models to label pre-fix, intermediate, and post-fix versions similarly.
Similarly, tools designed to detect duplicate vulnerable code across a codebase faltered when analyzing multi-location fixes. Open-source clone detectors like ReDebug and FIRE showed a significant drop in their ability to identify recurring vulnerable code, with FIRE's true positive rate falling from 90% to approximately 52%. This is because the vulnerable code sites often differ enough from one another that a signature derived from the initial location fails to match the others.
The time lag between the first and last patch commit is a critical factor, turning these gaps into exploitable windows. The study found that 31.7% of multi-patch fixes take more than a day to complete, with cross-branch and cross-project ports taking the longest. This delay creates a race condition: once a fix is publicly committed to one branch, attackers can analyze the repository, identify the equivalent weakness in unpatched branches, and exploit it before the repair arrives. While direct evidence of exploitation during these intervals was not found, the researchers emphasize that the structural risk is real, drawing parallels to the community's existing concerns about code reuse across projects.