Replication Package for "Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities"

Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities Zirui Chen The State Key Laboratory of Blockchain and Data Security, Zhejiang University Hangzhou, China [email protected] Zhipeng Xue The State Key Laboratory of Blockchain and Data Security, Zhejiang University Hangzhou, China zhipeng[email protected] Jiayuan Zhou Queen’s University Kingston, Canada [email protected] Xing Hu∗ The State Key Laboratory of Blockchain and Data Security, Zhejiang University Hangzhou, China [email protected] Xin Xia∗ The State Key Laboratory of Blockchain and Data Security, Zhejiang University Hangzhou, China [email protected] Xiaohu Yang The State Key Laboratory of Blockchain and Data Security, Zhejiang University Hangzhou, China [email protected]du.cn Abstract Exploits are commonly used to demonstrate the presence of library vulnerabilities and validate their impact across different versions. However, their direct application to alternative versions often fails due to breaking changes introduced during evolution. These failures stem from both changes in triggering conditions (e.g., API refactorings) and broken dynamic environments (e.g., build or runtime errors), which are challenging to interpret and adapt manually. Existing techniques primarily focus on code-level trace alignment through fuzzing, which is both time-consuming and insufficient for handling environment-level failures. Moreover, they often fall short when dealing with complicated triggering condition changes across versions. To overcome this, we propose Diffploit, an iterative, diff-driven exploit migration method structured around two key modules: the Context Module and the Migration Module. The Context Module constructs contexts derived from analyzing behavioral discrepancies between the target and reference versions, which capture the failure symptom and its related diff hunks. Leveraging these contexts, the Migration Module guides an LLM-based adaptation through an iterative feedback loop, balancing exploration of diff candidates and gradual refinement to resolve reproduction failures effectively. We evaluate Diffploit on a large-scale dataset containing 102 Java CVEs and 689 version-migration tasks across 79 libraries. Diffploit successfully migrates 84.2% exploits, outperforming the change-aware test repair tool TaRGET by 52.0% and the rule-based tool in IDEA by 61.6%. Beyond technical effectiveness, Diffploit identifies 5 CVE reports with incorrect affected version ranges, three of which have been confirmed. We also discover 111 unreported versions in GitHub Advisory Database. ∗Corresponding authors This work is licensed under a Creative Commons Attribution 4.0 International License. ICSE ’26, Rio de Janeiro, Brazil ©2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2025-3/26/04 https://doi.org/10.1145/3744916.3773205 CCS Concepts •Security and privacy →Software security engineering. Keywords Library Vulnerabilities, Exploit Migration, Affected Version ACM Reference Format: Zirui Chen, Zhipeng Xue, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang. 2026. Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities. In 2026 IEEE/ACM 48th International Conference on Software Engineering (ICSE ’26), April 12–18, 2026, Rio de Janeiro, Brazil. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3744916.3773205 1 Introduction Open-source libraries serve as critical infrastructure in modern software development, allowing developers to avoid redundant reimplementation and accelerate the development process [ 32 , 51 , 57 , 65 , 71 ]. However, the widespread adoption of open-source libraries raises concerns about the risk posed by vulnerabilities in these libraries [ 10 , 23 , 37 , 42 , 43 , 45 , 64 , 68 – 70 ], as they can propagate from upstream libraries to downstream projects [ 5 , 33 , 35 ]. Given that libraries often evolve rapidly and downstream projects may depend on a wide range of versions, it becomes essential to assess the impact of vulnerabilities across versions [ 4 , 49 ]. To this end, developers often employ publicly disclosed exploits to evaluate whether and how vulnerable behavior manifests in different versions [ 66 ], such as identifying affected library versions [ 13 , 29 ] and assessing exploitability in downstream projects with various affected versions [10, 17, 20, 31, 70]. However, simply reusing the original exploit on other affected versions frequently fails to reproduce without adaptation [ 13 , 66 ], since disclosed exploits are typically crafted for the version in which the vulnerability was originally reported and do not generalize across other affected versions. These failures often result from (1) broken dynamic environments [ 26 , 61 , 66 ] and (2) changes in the underlying triggering condition [ 67 ]. Manually understanding and resolving these issues is often time-consuming and requires substantial expertise, highlighting the need for automated exploit ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Zirui Chen, Zhipeng Xue, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang migration. Existing studies have demonstrated the feasibility of migrating exploits across versions [ 13 , 29 ], typically by aligning execution traces via API matching. Despite their success in handling minor API changes, these approaches often rely on fuzzing, which can be time-consuming, especially when multiple versions require migration. More importantly, they overlook two critical challenges that frequently arise in practice: ❶ Broken Dynamic Environment: Previous methods primarily address code-level variations, neglecting the incompatibilities introduced by environmental changes such as dependency upgrades or runtime configurations. For instance, the exploit for CVE-2020-5245 [ 55 ] fails with a runtime error in version 1.3.8 due to an updated library (javassist), despite identical exploit code. Such environmentinduced failures may surface across multiple phases, including the build process and runtime [ 63 ], and exhibit considerable variability across libraries, posing significant challenges to mitigation. ❷ Complicated Triggering Condition Evolution: When API interfaces undergo substantial changes, refactoring [ 56 ], or removal between versions, existing trace alignment methods, such as identifying function renaming or function merging/splitting [ 13 ], struggle to identify suitable replacements. A representative example is CVE-2024-22257 [ 16 ] illustrated in Figure 1, where critical methods (createList and createAuthorityList) are absent in 2.0.8.RELEASE, requiring alternative APIs with significantly different signatures and semantics, which cannot be effectively addressed through existing API matching strategies. Incorrect or inadequate matching in these scenarios leads directly to ineffective migration efforts. Addressing these challenges requires a comprehensive approach that considers both environmental adjustments and intelligent API adaptation mechanisms, beyond simple trace or naming alignment. To effectively address the challenge of exploit migration across versions, we introduces an iterative, diff-driven LLM (Large Language Model) framework, Diffploit. The key idea is to iteratively adapt failed exploits using version-aware context and feedback. When a migration attempt fails, Diffploit compares the behavior of target version against a successful reference version to identify failure indicators. These indicators trigger the construction of a structured migration context by the Context Module:Causing Diffs that likely led to the failure, and Supporting Diffs that may help resolve it. This context guides the Migration Module to adapt the exploit. A simulated annealing strategy is designed to explore and refine adaptations across multiple iterations. After each attempt, the updated exploit is re-executed, and new feedback is collected to guide the next cycle. Through this closed-loop process, Diffploit incrementally reduces discrepancies and achieves effective migration, even in the face of significant API or environment changes. We evaluate Diffploit on a large-scale open source dataset of Java library vulnerability exploits [ 57 ], comprising 102 CVEs and their explicitly affected versions across 79 libraries. Among them, we identify 30 exploits that require migration across 689 versions, which is comparable to prior studies in the C/C++ domain [ 13 ], involving 30 CVEs and 470 versions. Specifically, Diffploit successfully migrates 580 out of the 689 exploits to target versions in 23 CVEs, achieving a success rate of 84.2%. Compared to the recent change-aware test repair research [ 48 ], Diffploit outperforms TaRGET by 52.0% and surpasses the rule-based approach in IDEA by 61.6%, highlighting the effectiveness of Diffploit in harnessing the capabilities of LLMs for exploit migration. We demonstrate the rationality of Diffploit’s design through ablation studies, where it achieves a 46.1% improvement over the base model. To validate the practicality and correctness of exploits migrated by Diffploit, we identify previously undisclosed vulnerable versions based on the migrated exploits on five CVE vulnerabilities and contact the CNAs (CVE Numbering Authority) [ 11 ] for confirmation. Among them, three cases are confirmed, with our submitted exploit links incorporated into the reference links. Meanwhile, we submit six pull requests to the GitHub Advisory Database to include a total of 111 missing versions detected by Diffploit, of which 82 versions are accepted. We further demonstrate that Diffploit effectively overcomes the previously mentioned challenges with a low cost. This paper makes the following main contributions: • We propose Diffploit, a novel discrepancy-driven approach that automatically migrates exploits from target versions to reference versions. Both the source code and dataset of Diffploit are available on our website [9] • We conduct an evaluation on 689 versions and demonstrate that Diffploit successfully migrates exploits for 580 of them, outperforming our baselines. • Our migrated exploits reveal five CVEs with inaccurate affected version ranges (three confirmed by CNAs) and uncover 111 affected versions missing from the GitHub Advisory Database. 2 Motivation In this section, we introduce the usage scenario and a motivating example to illustrate the challenges addressed by Diffploit. 2.1 Usage Scenario In real-world vulnerability management, our method is designed to support two practical usage scenarios: (1) Adapting ineffective exploits to confirmed affected versions. Disclosed exploits are crucial for validating whether a specific project is affected by a known upstream vulnerability. However, these exploits are typically crafted for a particular version of a vulnerable library and often fail to function on other affected versions due to code or environment changes. For example, suppose a security advisory confirms that version 4.0.56 of the library nettycodec-http is affected by CVE-2021-43797, but the public exploit only works on versions above 4.1.0.CR7 [ 55 ]. Developers using version 4.0.56 are left without a working exploit to verify the vulnerability in their context. Diffploit addresses this gap by automatically adapting existing exploits to these confirmed yet incompatible versions, enabling practical verification in real-world environments. (2) Discovering previously unreported affected versions. Manually curated vulnerability reports often contain inaccuracies and omissions [ 7 , 12 , 18 , 30 , 41 ]. When a migrated exploit successfully triggers the vulnerability in a version not listed in public advisories, it suggests that the affected range may be broader than disclosed. Thus, Diffploit can assist in identifying missing affected versions and improving the completeness of vulnerability databases. It is worth noting, however, that if Diffploit fails to migrate an exploit to a particular version, this does not necessarily mean the version is unaffected, and additional analysis is required [ 25 ], such as introducing commit analysis [2, 8, 60]. Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Reference Exploit (3.0.0.RELEASE) Migrated Exploit (2.0.8.RELEASE) [Failure Indicator] -Package does not exist [Related Diff] -{Classname}.java 3.0.0.RELEASE 2.0.8.RELEASE Supporting Diff {Classname}.java: - package org.springframework.security.vote; … - package org.springframework.security; … - package org.springframework.security.util; … UnanimousBasedTests.java: - ConfigAttributeDefinition config = new ConfigAttributeDefinition(new String[]{"ROLE_1", "DENY_FOR_SURE"}); + List<ConfigAttribute> config = SecurityConfig.createList(new String[]{"ROLE_1", "DENY_FOR_SURE"}); AuthorityUtils.java: - public static GrantedAuthority[] commaSeparatedStringToAuthorityArray (String authorityString) { … - return authorities; - } [Failure Indicator] -Cannot find symbol [Related Diff] -UnanimousBasedTests.java -AuthorityUtils.java CVE-2024-22257 Library: spring-security-core Require Migration: 2.0.0 - 2.0.8.RELEASE NVD: 5.7.0 to 5.7.12 5.8.0 to 5.8.11 6.0.0 to 6.0.9 6.1.0 to 6.1.8 6.2.0 to 6.2.3 Reference Reported Omitted! Target Causing Diff Supporting Diff Figure 1: Migrating the exploit of CVE-2024-22257 from version 3.0.0.RELEASE to 2.0.8.RELEASE by Diffploit. 2.2 Motivating Example Figure 1 presents a motivating example from spring-security-core, demonstrating how Diffploit facilitates exploit migration across versions. Through this process, we identify that versions prior to 5.7.0.RELEASE are affected by CVE-2024-22257, although they are not included in the CVE report. For versions above 3.0.0.RELEASE, a publicly disclosed exploit for CVE-2024-22257 is available to reproduce the vulnerability, which serves as the reference exploit. The reference exploit fails to execute directly on earlier versions, such as 2.0.8.RELEASE, because it depends on APIs introduced in later versions (e.g., line 16, line 23) and is affected by breaking changes introduced during updates (refactoring existing APIs to various packages) [52], which requires exploit migration. Recent advances in artificial intelligence, especially LLMs, demonstrate strong capabilities in various tasks [ 21 , 34 , 44 , 48 , 54 , 62 , 72 ], like understanding complex documentation [ 72 ] and resolving errors [ 21 , 54 ]. However, without sufficient contextual information, LLMs often struggle to update exploits using the appropriate APIs of the target versions. Furthermore, in earlier versions, LLMs frequently fail to generate valid API calls due to the lack of corresponding usage patterns in their training data [ 50 ]. These limitations hinder the effectiveness of LLMs in generating reliable exploits tailored to target versions. We observe that providing diffs between the target version and the reference versions to LLMs enables them to infer the root causes of the failures and identify adaptation strategies, such as locating alternative APIs. Based on this insight, we identify two types of diffs that facilitate exploit migration: Causing Diff and Supporting Diff. Failures in exploit reproduction, either due to modifications in triggering conditions or environmental breaks, are caused by changes introduced in the evolution of the library (causing diff). Meanwhile, libraries themselves often contain internal adaptations to these changes, which can provide LLMs with guidance for migration (supporting diff). Take CVE-2024-22257 as an example: • Causing Diff : The cause of the Package does not exist error from line 5 to line 11 is the result of refactoring or modifications to the class file. Specifically, the corresponding hunks are those involving target package name changes, such as the removal of the package declaration line package org.springframework.security in the ConfigAttribute class. These changes provide LLMs with accurate package structure information of the target version, thereby reducing hallucinations such as generating outdated or non-existent import paths. • Supporting Diff : For the modification in line 16, a change in UnanimousBasedTests reflects a response to the refactoring of ConfigAttributeDefinition and guides the modification in resolving the Cannot find symbol error for the createList method. In addition, the diff in AuthorityUtils provides explicit guidance for replacing the unavailable createAuthorityList method at line 23 with an alternative API introduced in the target version. These diffs facilitate LLMs in addressing the evolution of triggering conditions by identifying a suitable replacement for deleted APIs. Building on the identified diffs, we propose Diffploit, which iteratively leverages the diffs to facilitate exploit migration through a feedback loop. Diffploit takes nine steps to migrate the exploit for CVE-2024-22257, despite the significant challenge of identifying relevant information from the 2,555 diffs between the two versions. 3 Proposed Approach In this section, we present our approach, Diffploit, detailing the overall workflow as well as the design of its two core components: the Context Module and the Migration Module. 3.1 Overview Given a target version requiring exploit migration, our method iteratively repairs its behavioral discrepancies with reference exploits through a self-adaption process. The reference version is chosen from the set of reproduced versions to provide contextual guidance. The overall process follows a discrepancy-driven loop. At each iteration, we compare the execution outputs of the target version and the reference version to identify reproduction failures. Each ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Zirui Chen, Zhipeng Xue, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang Location Prompt … Your task is: 1. Analyze why this issue occurs in {from_version} but not with {to_version}. 2. Consider how to resolve this without updating this library. 3. Determine migration location in the exploit …'pom' or 'test ' … Detail:{Indicator} Migration Prompt … Your task is: 1. Locate the code related to the unexpected behavior. 2. Analyze the diffs from {from_version} to {to_version}. 3. Fix it only when diff is helpful… Error Detail:{Indicator}… Related Diff:{Diff}…Exploit:{Exploit Content} ① Identifier Extraction Prompt You are given an error log when executing 'mvn test'… the exploit executes as expected in the {from_version}. Extract key entities from the error … reflect code-level identifiers appear in diffs … Error Detail:{Indicator} Failure Identifier Failure Identifier1; Failure Identifier2 e.g., SecurityConfig;createList Target Version Reference Version Nearest Actual Behavior Reference Behavior Diff-Based Migration (Migration) Compare Failure Indicator 1… Overview Valid Exploit Target Versions Update Pom.xml Execution Not Reproduced Versions Executor Context ① ②MigrationValidator Migration Iteration Target Exploit Migration Location e.g., pom; e.g.,test For each Diff-Based Migration (Diff Annealing) Failure Identifier Relevant Diffs Cause Rules Identifier Position Plus Blocks Identifier Del Blocks Related Diff Similarity Supporting Diffs … ID Diff Contents Score ID Diff Contents Score Relevant Diffs Combination Causing Diffs Migrated Exploit Next loop Valid Back to annealing Else Search Space Update Diff Score &Temperature End loop Selected Diff ② ②Relevant Context Extraction Failure Indicator N Explore Depth 2. Explore Depth Temperature Annealing 1. Solved Figure 2: The overall framework and prompt details of Diffploit. detected failure indicator in the target version triggers the construction of a dedicated migration context via the Context Module. This context encapsulates the failure symptom, its corresponding diagnostic key, and the associated code-level differences that may either underlie or assist in resolving the failure. For each detected failure, the corresponding migration context is passed to the Migration Module, which attempts to adapt the exploit with the context. The migration process is guided by a simulated annealing strategy that explores diffs within the context to identify those effective in resolving the failure. The search process continues until the failure is resolved or a termination criterion (e.g., iteration limit or temperature threshold) is met. Upon resolving each failure indicator, the adapted exploit is reexecuted on the target version to collect fresh output. These outputs are then compared again to extract updated failure indicators. The process iterates through these indicators until all discrepancies are either successfully addressed or deemed irrecoverable under the current search configuration. 3.2 Context Module The Context Module extracts a set of migration contexts from the target version 𝑣𝑡 by analyzing behavioral discrepancies with a reference version 𝑣𝑟 . Each migration context corresponds to a specific failure unit, representing a reason for reproduction failure (triggering condition change or dynamic environment broken), and includes the related diffs that potentially cause or resolve the failure. These migration contexts provide structured and targeted information to guide the subsequent migration process. Definition 3.1 (Migration Context). An migration context is a structured representation that links a reproduction failure indicator 𝑓𝑖 observed in 𝑣𝑡 to its corresponding failure identifier 𝑘𝑖 , along with related diff hunks. Formally, it is defined as: C𝑖=(𝑓𝑖,𝑘𝑖, 𝐷 (𝑖) cause, 𝐷 (𝑖) support) where: •𝐷(𝑖) cause are diff blocks related to the potential root cause of 𝑓𝑖; •𝐷(𝑖) support are diff blocks that provide additional assistance for migration, such as modified test cases or alternative functions. All diff blocks refer to Git-style diff hunks produced by git diff. 3.2.1 Failure Indicator Extraction. For each 𝑣𝑡 requiring exploit migration, we determine a corresponding 𝑣𝑟 to serve as contextual guidance. The reference version is selected from a list of successfully reproduced versions 𝑅={𝑣1, 𝑣2, ..., 𝑣𝑛} such that 𝑣𝑟= arg min𝑣∈𝑅dist(𝑣, 𝑣𝑡) , where dist(·) denotes a version distance metric. The list 𝑅 is constructed by executing the disclosed exploit across all historical versions from the Maven Central repository. After identifying 𝑣𝑟 , we execute the reference exploit against both 𝑣𝑟 and 𝑣𝑡 , and collect respective outputs. We then compare the two outputs to detect behavioral discrepancies. Each discrepancy is abstracted into a failure indicator 𝑓𝑖 , representing a concrete symptom of the failure in 𝑣𝑡 . Failure indicators encompass a variety of failure types, including build-time errors, runtime exceptions, and assertion failures. The set of extracted indicators {𝑓1, 𝑓2, ..., 𝑓𝑛} serves as the entry point for constructing migration contexts. 3.2.2 Failure Identifier Extraction. Given a failure indicator 𝑓𝑖 , the goal of this module is to derive a corresponding set of failure identifiers 𝑘𝑖 that concisely capture the semantic essence of the failure to support downstream diff retrieval. While certain indicators, such as build-time errors, follow structured formats that can be parsed with simple rules, others such as runtime exceptions or unexpected execution outcomes are more variable in syntax and semantics, making them difficult to handle with pattern-based heuristics. To address this, for each 𝑓𝑖 , we prompt the LLM to generate a corresponding set 𝑘𝑖 of identifiers, where each element in 𝑘𝑖 is a salient token selected to reflect the core failure content in a way that facilitates matching against diff content. These identifiers 𝑘𝑖 typically includes method names, exception types, or symbolic tokens that are likely to appear in the associated diffs, and will later be used to retrieve causing and supporting diffs. 3.2.3 Causing Diff Extraction. The goal of this module is to identify diff blocks that potentially the root cause of a given failure 𝑓𝑖 . We leverage a set of handcrafted heuristic rules tailored to common Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil failure types to extract relevant diffs. These rules allow us to efficiently associate symbolic error traces with corresponding code modifications without relying on complex program analysis. Given a failure indicator 𝑓𝑖 and its corresponding identifier set 𝑘𝑖, we define a mapping function: 𝐷(𝑖) cause =Rule(type(𝑓𝑖),𝑘𝑖) where type(𝑓𝑖) denotes the high-level category of the error (e.g., ‘AssertionMismatch’, ‘MissingMethod’, ‘RuntimeError’). We implement the following rules, which are designed to handle not only triggering condition changes and environment-level breakages but also other unexpected scenarios encountered during migration: • AssertionMismatch: Collect diff blocks that affect method in 𝑘𝑖 calls directly invoked in the exploit, especially those on the call stack leading to assertion failure. • RuntimeError: Identify diff blocks that modify methods, classes, or environment associated with the exception type or message tokens found in 𝑘𝑖 . These symbols typically reflect failed API usage or behavior changes in dynamic execution. • MissingClass / MissingPackage: Identify diffs under the file corresponding to the missing class or package in 𝑘𝑖. • MissingMethod: Locate diff blocks that modify or remove the method signature referenced in 𝑘𝑖. • IncompatibleType / WrongReturn: Retrieve diff blocks that affect method return types, parameter types, or generic usage near the method identified by 𝑘𝑖. • Other: For all other failure types, we retrieve diff blocks that modify elements (e.g., classes, methods, or fields) whose names match any identifier in 𝑘𝑖 . This fallback rule ensures general applicability when more specific heuristics are not available. We apply a set of rules to determine whether a diff hunk satisfies these conditions (e.g., pattern \b\w[\w\s<>,]*\s+{cause}\s*\( is used to detect MissingMethod cases). Each diff hunk matched by these heuristics is then assigned a relevance score (10 points for the first five categories and 2 points for each 𝑘𝑖 in Other) to guide the subsequent migration process. 3.2.4 Supporting Diff Extraction. This module aims to identify diff blocks introduced by the library in response to breaking changes leading to 𝑓𝑖 , which can assist the exploit migration process. We observe that breaking changes, such as API deletions or refactorings that cause exploit failures, also affect internal API usages within the library. To maintain functionality and compatibility, the library often introduces corresponding code updates, including modifications to internal method calls, additions of wrapper functions, or adjustments to test cases. These responsive changes serve as valuable supporting for guiding migration. Such responses frequently appear as newly added diff blocks that are structurally similar to deleted or modified code within the same hunk. To detect such patterns, we first locate occurrences of tokens from the failure identifier set 𝑘𝑖 within the diff. Then, around each occurrence, we extract contiguous diff blocks composed of lines sharing the same diff prefix. Specifically, we collect: • B+ : blocks of contiguous added lines (prefixed with ‘ + ’) near the positions where tokens in 𝑘𝑖appear; • B− : blocks of contiguous deleted lines (prefixed with ‘ − ’) near the positions where tokens in 𝑘𝑖appear; We compute token-level similarity between each added block 𝑏+∈ B+ and corresponding deleted block 𝑏−∈ B− using the normalized length of their longest common subsequence (LCS): sim(𝑏+,𝑏−)= 2× |LCS(𝑏+,𝑏−)| |𝑏+|+|𝑏−| where |LCS(·)| denotes the number of matched tokens in LCS, and | · | denotes the token count of a block. If the similarity exceeds a threshold 𝜏 , the diff hunk containing the block pair is considered a candidate hunk and is selected as part of the support diff set 𝐷(𝑖) support . We assign each selected hunk a score based on this similarity (ranging from 0-10), which is then used to guide the subsequent diff annealing process. Finally, the migration context C𝑖 for failure 𝑓𝑖 is generated by associating the failure indicator and its identifier 𝑘𝑖 with the extracted causing diffs 𝐷(𝑖) cause and supporting diffs 𝐷(𝑖) support , forming a structured representation to guide the migration process. 3.3 Migration Module To support effective migration, the Context Module provides candidate diff hunks derived from the migration context C𝑖 . These candidates form the search space for the Migration Module and play a central role in navigating towards a successful exploit migration. Building on this set, the Migration Module guides the migration process by selecting diffs with our annealing strategy and presenting them along with 𝑓𝑖 to the LLM, which implicitly determines the appropriate migration locations within the exploit. 3.3.1 Diff Annealing. To expand the diversity and complexity of candidate diffs for migration, we design an annealing-based mechanism to explore a broader diff space with controlled randomness. Here, complexity refers not only to the number of diffs applied simultaneously to a given failure indicator 𝑓𝑖 , but also to the number of repair rounds permitted when new failure indicators emerge during the migration process of 𝑓𝑖 . This setting allows the system to consider both wider combinations of patches and deeper chains of repair actions, thereby enriching the potential solution space. This mechanism operates over three categories of diffs: highscoring causing diffs 𝐷cause , supporting diffs 𝐷support , and a newly synthesized set of composite diffs 𝐷combo . We begin by constructing 𝐷combo through pairwise combinations of top-ranked diffs from 𝐷cause ∪𝐷support . For each combination, the new diff inherits a composite score, computed as the average of its constituent diffs’ scores. Together, 𝐷cause ∪𝐷support ∪𝐷combo define the search space Dfor this annealing process. To initiate the annealing, we define a temperature parameter 𝑇 , which governs both the selection probability of diffs and the exploration depth for resolving the current failure indicator 𝑓𝑖 . The selection probability of a diff 𝑑∈ D is proportional to its normalized score and temperature: 𝑃(𝑑) ∝ exp 𝑠(𝑑) 𝑇, where 𝑠(𝑑) denotes the score of diff 𝑑 . Higher temperatures bias the selection toward higher-scoring diffs. ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Zirui Chen, Zhipeng Xue, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang In addition, the exploration depth—i.e., the number of retry attempts made when new failure indicators emerge during migration— is inversely correlated with the temperature. At higher temperatures, the system prefers quick evaluations of promising diffs, while deeper exploration is deferred to later stages when the temperature cools down. This design ensures that the system prioritizes efficient evaluation of high-scoring diffs in early stages. During each iteration: • A diff 𝑑∈ D is sampled and applied to perform a migration targeting 𝑓𝑖via LLM. • If the migration fails, the score of 𝑑 is penalized, the global temperature 𝑇 is decreased, and the diff combination list 𝐷combo is refreshed based on the updated scores. •A new diff is then selected, and the process repeats. This annealing-based strategy enables a controlled exploration of the diff space, balancing exploitation of high-scoring diffs and exploration of more diverse or complex diff combinations. 3.3.2 Exploit Migration. Given a failure indicator 𝑓𝑖 extracted from the execution outputs of the target version, the Exploit Migration module aims to adapt the original exploit such that the expected vulnerability behavior is restored. This process takes as input a selected related diff 𝑑𝑖 , which is expected to resolve the failure based on prior analysis. We first utilize the LLM to localize the relevant modification site within the exploit, conditioned on the failure indicator 𝑓𝑖 , its associated diagnostic key 𝑘𝑖 , and the selected diff 𝑑𝑖 . These elements are encoded into a structured prompt, as illustrated in our Figure 2, which guides the LLM in pinpointing the modification location. Based on this localization, Diffploit then instructs the LLM to generate an adapted exploit ˆ 𝑒𝑖 by modifying the original exploit according to the changes reflected in 𝑑𝑖 at the identified position. ˆ 𝑒𝑖 is then executed on the target version. Its runtime output is analyzed to determine whether 𝑓𝑖has been resolved. 3.3.3 Migration Validation. Following the adaptation of the exploit targeting the specific failure indicator 𝑓𝑖 in the preceding module, Diffploit re-run the exploit to collect the updated failure indicators in order to determine whether 𝑓𝑖has been resolved. • If 𝑓𝑖 still appears in the failure list, the migration attempt is considered unsuccessful. The process then returns to the annealing process to select the next diff candidate. This iterative search continues until 𝑓𝑖 is resolved or the search terminates due to reaching the temperature limit or timeout. • If 𝑓𝑖 no longer appears in the failure list, indicating successful resolution, we analyze the updated failure indicators further: – If no failure indicators remain, the migration process proceeds to perform the final reproduction verification by checking whether the assertions in the exploit behave as expected and whether the observed behavior matches the expected reproduction behavior. If both conditions are satisfied, the migration process terminates successfully. – If the remaining failure indicators are all previously known (i.e., identified prior to addressing 𝑓𝑖 ), we consider 𝑓𝑖 to have been successfully resolved and proceed to handle the remaining failures accordingly. – If new failure indicators emerge after attempting to resolve 𝑓𝑖 , we initiate a limited number of additional repair attempts to address these emergent failures. The number of such attempts, denoted as the exploration depth, is determined based on the current temperature 𝑇 , with higher annealing temperatures yielding shallower exploration. If the number of repair attempts exceeds the exploration budget derived from 𝑇 , the current migration path is terminated, and a new diff candidate is selected to resolve 𝑓𝑖. 4 Experimental Setup Research Questions. Our experimental evaluation aims to answer the following research questions: • RQ1 (Effectiveness): To what extent can Diffploit effectively migrate exploits to target versions? • RQ2 (Ablation Study): How does each component within Diffploit contribute to the overall migration process? • RQ3 (Practical Feasibility): Dose Diffploit acceptable in realworld scenarios, considering the cost and quality of exploits? We address RQ1 to evaluate the effectiveness of our diff-based exploit migration method and its superiority over existing approaches. We address RQ2 to assess the rationality of key components in our method, including the causing diff extraction module, the supporting diff extraction module, and our proposed diff annealing algorithm. We address RQ3 to verify whether the exploits generated by Diffploit and the under-reported vulnerable versions it identifies are recognized and accepted. 4.1 Dataset To minimize bias in the exploit collection process, we evaluate the performance of Diffploit using the largest publicly available Java exploit dataset [ 57 ]. This dataset comprises 102 CVE vulnerabilities, each with a corresponding exploit targeting a specific version and a set of manually verified affected versions, making it well-suited for assessing the effectiveness of exploit migration approaches. To identify versions requiring exploit migration, we execute exploits on versions labeled as affected and examine execution results. The dataset includes assertions designed to verify reproduction, which means versions failing to satisfy assertions are marked as requiring migration. We identify 988 versions meeting this criterion. Further analysis is performed to confirm the presence of vulnerabilities in these versions, resulting in a final set of 689 truly affected versions for 30 vulnerabilities. This reduction is mainly attributed to 176 versions in CVE-2023-51080 and 72 versions in CVE-2021-43795 that are incorrectly labeled as vulnerable before the introduction of the vulnerability [38, 53]. 4.2 Baselines To the best of our knowledge, no prior work has explored exploit migration across Java library versions, though third-party libraries play a crucial role in the Java ecosystem [ 22 ]. Existing studies [ 13 , 29 ] rely on fuzzing frameworks such as AFLGo [ 6 ], which are difficult to adapt to Java. We include the following four baselines: ❶ TaRGET [ 48 ] is a pre-trained language model-based approach for automated function-level test repair, which treats test repair as a language translation task and leverages context Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil information extracted from the test breakage. Although it is not specifically designed for exploit migration, we include TaRGET as a baseline due to its strong performance in repairing broken JUnit test cases, which are structurally similar to the exploits in our dataset. ❷ IDEA [ 27 ] is the combination of Quick Fix and Auto-import features provided by IntelliJ IDEA. These features assist developers in resolving compilation issues caused by API refactoring, missing imports, or outdated method signatures, which can partially mitigate exploit failures caused by changes in triggering conditions. ❸ GPT-4o and ❹ DeepSeek-v3 are two of the most advanced proprietary LLMs, demonstrating strong capabilities in both code understanding and generation. In this study, we examine whether existing SOTA LLMs can generalize to the task without any task-specific fine-tuning. 4.3 Migration Success Criteria To ensure an exploit triggers the same vulnerability after migration, we perform validation along two dimensions: assertion consistency and behavioral verification. Assertion consistency refers to whether the migrated exploit exhibits the same assertion failure behavior as the original, indicating consistency at the assertion level. Behavioral verification involves checking fine-grained behavioral indicators in the output logs to determine whether the expected vulnerability behavior is preserved after migration. An exploit is considered successfully migrated to the target version if and only if it triggers the expected assertion, and the location and manifestation of the assertion are consistent with those in the reference version. 4.4 Implementation In our experimental setup, we deploy a Docker environment based on Ubuntu 20.04. Following the configuration by Wu et al. [ 57 ] for exploit collection, we select Java 11 as the runtime environment, specifically version 18.9 (version: build 11+28). We execute exploits using the mvn test command. For the selection of LLMs, we employ a high-performance closed-source model, GPT-4o (snapshot as of 2024-11-20), alongside an open-source model with strong performance on code tasks, DeepSeek-v3 (snapshot 0324), to conduct our experiments. To improve reproducibility, the base model of Diffploit is DeepSeek-v3. A time constraint of 5 minutes is applied to Diffploit and baselines for each version during experiments. Since all libraries in our dataset are hosted on GitHub/GitLab, we use git diff to generate the diff files. Regarding the baseline setup, we reproduce TaRGET using the fine-tuned weight provided in the replication package. Despite our best efforts, we were unable to reproduce TaRGET on CVE-202013956 and CVE-2023-51075, as it requires the construction of valid exploits tailored to these vulnerabilities. For experiments involving IntelliJ IDEA, we use version 2025.1.3. We apply IntelliJ IDEA Quick Fix and Auto-import features to modify the exploit and run tests using mvn test after no further modifications are possible. When suggestions are abundant, including cases like multiple renaming suggestions, we evaluate the top five candidates. 5 Experimental Evaluation We evaluate the performance of Diffploit from three perspectives. First, we assess its effectiveness and compare it with baseline methods using the largest dataset of Java library vulnerability exploits, and analyze its strengths and limitations. Second, we conduct an ablation study to demonstrate the contributions of the diff and migration modules to the overall performance. Finally, we analyze the practical feasibility of Diffploit based on cost and responses from CNAs and open-source maintainers. 5.1 Effectiveness 5.1.1 Performance. We evaluate the effectiveness of Diffploit on a dataset containing 689 version pairs that require exploit migration. Diffploit successfully migrates 580 of them, achieving an overall success rate of 84.2%. In the context of 30 representative CVEs, Diffploit successfully performs exploit migration for 23 cases, covering a diverse range of vulnerability types and affected libraries. This demonstrates the generality of Diffploit across both vulnerability classes and dependency ecosystems. Notably, for 20 CVEs, all associated versions requiring migration are successfully repaired, highlighting the potential of Diffploit to serve as a reliable component in automated vulnerability validation pipelines. However, it is important to emphasize that a failed migration does not necessarily imply the absence of a vulnerability. Compared to the baseline method TaRGET,Diffploit achieves a relative improvement of 51.0%, demonstrating its robustness in handling critical challenges in exploit migration, such as adapting to non-function-level edits like import adjustments and build configuration updates. When compared with IDEA that combines IntelliJ IDEA’s Quick Fix and Auto Import features, Diffploit outperforms significantly in 61.6%. This result highlights its ability to address migration scenarios that exceed the capabilities of predefined rules. We also compare Diffploit against direct application of LLMs. GPT-4o and DeepSeek-V3 can migrate 243 (35.2%) and 263 (38.1%) cases respectively, which, while competitive in some straightforward scenarios, underperform due to lack of migration context. In contrast, Diffploit leverages migration-specific contextual information, enabling it to maintain a higher success rate especially in complex migration scenarios. 5.1.2 Strength. Compared to the baseline method TaRGET,Diffploit demonstrates superior adaptability in handling test changes that are not confined to the function level. While TaRGET focuses on identifying faulty functions, it relies on developers to manually apply legitimate edits when changes occur outside function bodies, such as modifications in import statements or resolving runtime environment broken in pom.xml. As a result, it fails to repair test cases in 16 CVEs where such non-functional changes are essential. Diffploit is also capable of addressing scenarios where an exploit test should fail but instead passes silently in the target version. These cases, where the presence of a vulnerability is masked by a superficially successful test, are often overlooked by TaRGET. By leveraging rich migration context and historical diffs, Diffploit can detect and adapt such misleading test cases, ensuring they remain effective indicators of vulnerabilities. Additionally, Diffploit leverages a structured migration context that captures both the causing and supporting diffs of a test case. ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil Zirui Chen, Zhipeng Xue, Jiayuan Zhou, Xing Hu, Xin Xia, and Xiaohu Yang Table 1: Performance of Diffploit and Baseline Methods on Exploit Migration Library CVE Reference Version Affected Versions Diffploit TaRGET IDEA LLM Total Need Mig. GPT-4o DeepSeek-v3 commons-fileupload CVE-2016-1000031 1.1.1 8 3 30 0 3 3 cxf-rt-rs-security-xml CVE-2014-3584 2.6.10 33 14 0 0 0 0 0 dolphinscheduler-api CVE-2022-34662 2.0.0 20 12 0 0 0 0 0 dolphinscheduler-common CVE-2023-49250 2.0.0-alpha 44 12 0 0 0 0 0 dropwizard-validation CVE-2020-5245 2.0.1 40 16 16 0 0 0 0 hibernate-validator CVE-2019-10219 6.0.5.Final 31 12 12 0 0 1 12 httpclient CVE-2020-13956 4.5.3 40 6 0 – 0 0 0 hutool-core CVE-2023-51075 5.7.18 38 1 0 – 0 0 0 jackson-databind CVE-2022-42004 2.0.0-RC1 24 5 2 0 0 0 0 jackson-dataformat-xml CVE-2016-7051 2.7.7 75 69 69 0 0 0 0 junrar CVE-2022-23596 6.0.0 15 8 80 0 5 8 kernel CVE-2022-24197 7.2.0 24 5 0 0 0 0 5 netty-codec-http CVE-2021-43797 4.1.49.Final 157 86 86 80 0 80 0 CVE-2019-20444 4.1.43.Final 131 71 71 65 65 1 65 CVE-2019-16869 4.1.0.Beta1 131 71 71 65 65 1 65 netty CVE-2015-2156 3.3.0.Final 65 45 0 0 0 0 0 para-core CVE-2022-1848 1.42.2 102 84 84 0 21 84 23 plexus-utils CVE-2017-1000487 1.4.2 50 2 22 0 2 2 postgresql CVE-2024-1597 9.4.1212 179 49 48 0 0 0 0 protocols-imap CVE-2021-40111 3.5.0 11 9 9* 0 0 0 0 socket.io-client CVE-2022-25867 1.0.0 12 9 90 0 0 0 spring-amqp CVE-2017-8045 2.1.0.RELEASE 49 2 20 0 2 2 spring-actuator-logview CVE-2021-21234 0.2.9 14 10 10 10 5 5 10 spring-context CVE-2022-22968 4.2.9.RELEASE 194 19 19 0 0 19 19 spring-security-core CVE-2019-11272 3.0.0.RELEASE 61 9 90 0 0 0 CVE-2024-22257 5.7.11 210 9 90 0 0 9 spring-webmvc CVE-2014-3625 3.0.4.RELEASE 30 1 10 0 1 1 spring-web CVE-2013-6430 1.1.1 53 4 4 0 0 0 0 CVE-2020-5421 5.2.8.RELEASE 124 39 39 0 0 39 39 wicket-core CVE-2013-2055 1.5.10 33 7 70 0 0 0 SUM 30 CVEs – 1,998 689 580 (84.2%) 222 (32.2%) 156 (22.6%) 243 (35.2%) 263 (38.1%) *The exploit is a flaky test. This design enables it to accommodate a broader range of code modifications related to exploit migration. This advantage becomes more prominent in complex exploit migration tasks, which require understanding subtle semantic changes. In our Discussion section, we further analyze the edit distance before and after migration, highlighting Diffploit’s ability to apply complex adaptations. 5.1.3 Limitations. While Diffploit demonstrates strong performance in migrating exploits across versions, it has several limitations. First, it struggles to handle cases where the vulnerability manifests differently across versions. For instance, in CVE-202013956 and CVE-2023-51075, the exploits trigger exceptions such as NumberFormatException and IndexOutOfBoundsException, rather than the originally expected assertion failures. Although such runtime exceptions still indicate security-relevant behavior, Diffploit currently treats them as failures, as it enforces a fixed assertionbased validation strategy. Similarly, in CVE-2023-49250, the exploit leads to a malicious server connection. Second, Diffploit encounters difficulties when migrating exploits that depend on version-specific APIs, especially when the target version lacks both a structurally similar counterpart and supporting information. As illustrated in Figure 3, in CVE-2022-34662, the original exploit in a higher version invokes ResourcesServiceImpl.verifyFile, while the lower version provides a semantically ResourcesServiceImpl res = new ResourcesServiceImpl(); Method method_verifyFile = res.getClass().getDeclaredMethod(“verifyFile”, … Reference v2.0.0-alpha ResourcesService res = new ResourcesService(); Method method_verifyFile = res.getClass().getDeclaredMethod(“updateResource”, … Valid v1.3.9 Migration Failed Migration Success Diffploit Figure 3: A failure case of Diffploit for CVE-2022-34662. related method updateResource under a different class, ResourcesService.Diffploit failed to migrate the method due to missing contextual alignment. This example shows that while Diffploit can partially adapt such cases, external API knowledge is required. 5.2 Ablation Study Our ablation study aims to achieve two goals: (1) to demonstrate that each component in our design contributes to higher exploit reproduction success, and (2) to show that our design helps reduce the reproduction cost in terms of step count. We construct three ablated variants of Diffploit to evaluate the contribution of each component: (a) Diffploit-Causing, which disables the extraction of causing diffs; (b) Diffploit-Supporting, which disables the extraction of supporting diffs; and (c) Diffploit-Annealing, which removes the diff annealing process. To further evaluate the Diffploit: Facilitating Cross-Version Exploit Migration for Open Source Library Vulnerabilities ICSE ’26, April 12–18, 2026, Rio de Janeiro, Brazil effectiveness of our diff combination strategy, we design an additional variant named (d) Diffploit-Combining, in which only diff scores are used to provide contextual information, without incorporating among diffs. The performance of the base model without any diff information has already been evaluated in Table 1, so we do not include a separate variant for this setting. We evaluate each variant using three metrics reported in Table 2. Average Step measures the average number of adaptation steps required to successfully migrate exploits, where failures are assigned a default value of 30 steps, derived from the estimated time to complete exploit execution and the response latency of the LLM within five minutes. Success Rate reports the version number and percentage of exploits successfully migrated. Overhead quantifies the average step overhead relative to the origin Diffploit, offering a normalized view of the cost efficiency. Table 2: Ablation Study on Diffploit. Method Average Step* Success Rate Overhead Diffploit 8.28 580/689 (84.2%) - Diffploit-Causing 12.71 470/689 (68.2%) 277.15% Diffploit-Supporting 11.15 489/689 (71.0%) 159.09% Diffploit-Annealing 15.02 462/689 (67.1%) 444.69% Diffploit-Combining 13.35 505/689 (73.3%) 400.92% * Failures are assigned a default number of steps. We observe from Table 2 that Diffploit achieves the highest success rate, outperforming the best ablated variant by over 10.9%. This confirms that each component in our design contributes to the overall success. Among the variants, although the success rates degrade when removing any single module, they all remain notably higher than the base model (evaluated separately in Table 1), indicating that the use of context-aware diffs and annealing strategies brings substantial benefits. In terms of cost, Diffploit not only achieves the highest success rate but also requires the fewest steps on average (8.28), demonstrating that each component of Diffploit contributes effectively to the overall performance. Although all three variants yield similar success rates, they incur different levels of reproduction cost, with the variant without Annealing performing the worst (15.02 steps on average, 444.69% overhead relative to the origin Diffploit). This highlights the importance of the annealing process in filtering and prioritizing diffs that are most helpful to migration. Although Diffploit-Combining achieves the highest success rate among all variants, it requires significantly more steps than Diffploit, indicating that our combination strategy substantially improves the efficiency of discovering valid exploits. 5.3 Practical Feasibility 5.3.1 Acceptability. We aim to introduce an objective assessment of Diffploit ’s practical feasibility by assessing whether migrated exploits are accepted by real-world vulnerability management processes. Some adapted exploits target early branches that are no longer maintained, making it impossible to evaluate the acceptance of Diffploit by library maintainers. To overcome this, we evaluate the acceptance of Diffploit by submitting the previously undocumented affected versions supported by our migrated exploits. We identify and report previously undocumented affected versions to CVE, the most authoritative vulnerability repository, and the GitHub Advisory Database, which facilitates communication through pull request-based submissions. Our migrated exploits serve as supporting evidence in these submissions. We assess the real-world acceptance of Diffploit based on the responses from CNAs and open-source reviewers. Diffploit successfully migrates exploits to 580 affected versions. We further investigate whether these versions are explicitly documented in the NVD descriptions and the affected product listings in the GitHub Advisory Database. As illustrated in Table 3, our migrated exploits uncover five NVD entries with missing or unclear specifications of affected version ranges, as well as 111 affected versions omitted from the GitHub Advisory Database. We contact the corresponding CNAs via email, and three of them has incorporated our migrated exploit into the reference links of the CVE report, while the remaining CNAs have not responded by the time of submission. We also submit six pull requests to the GitHub Advisory Database, which result in updates to 57 affected versions. The remaining submissions are not merged due to GitHub’s limited capacity to validate exploits at scale [ 3 ]. The addition of our exploits to the CVE reference links and the update of affected versions identified by migrated exploits demonstrate our practical feasibility. Table 3: Real World Response of Diffploit. CNA CVE CNA Response GitHub Missing Mitre CVE-2019-20444 Confirmed 14 (12 Accepted) Mitre CVE-2019-16869 Confirmed 2 (0 Accepted) GitHub, Inc. CVE-2021-43797 Under Review 13 (Under Review) GitHub, Inc. CVE-2020-5245 - 19 (7 Accepted) VMWare CVE-2024-22257 Under Review - Red Hat, Inc. CVE-2013-6430 - 38 (38 Accepted) Red Hat, Inc. CVE-2019-10219 Confirmed 25 (25 Accepted) SUM 7 CVEs 3 Confirmed 111 (82 Accepted) Diffploit contributed to improving the quality of the CVE reports by identifying additional affected versions and providing a working exploit. As confirmed by Red Hat: “Thank you again for helping us improve the CVE records. The changes for version information were made, and the references you sent added.” 5.3.2 Cost. We estimate the financial cost of using Diffploit to migrate an exploit with base model DeepSeek-V3. On average, each successfully migrated exploit consumes 7,029 input tokens and 831 output tokens. According to the pricing details provided by DeepSeek as of July 2025, this corresponds to an average cost of $0.0014 per successful migration. Similarly, for failed migrations, the average token consumption is 12,977 input tokens and 997 output tokens, resulting in an average cost of $0.0020 per failed attempt. These results indicate that the financial cost of using Diffploit remains low and practical for real-world deployment. 5.3.3 Data Leakage. To evaluate the performance of Diffploit on unseen vulnerabilities, we conduct an experiment using exploits that are disclosed after the model cutoff date. Our base model used for all experiments is Deepseek-V3-0324, thus we select five CVEs that are published after March 2025.