Pith. sign in

REVIEW 2 major objections 7 minor 72 references

There are More Fish in the Sea: Automated Vulnerability Repair via Binary Templates

T0 review · 2 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Template-based repair applied directly to Java bytecode correctly fixes 11 real vulnerabilities and securely fixes 15 on the Vul4J benchmark.

desk verdict Solid new capability—binary-level template repair for Java—but the security-fixing headline rests on a definition the paper itself violates. read the letter →

arxiv 2411.18088 v1 pith:TFQDV3D3 submitted 2024-11-27 cs.SE

Bo Lin , Shangwen Wang , Liqian Chen , Xiaoguang Mao This is my paper · ORCID
classification cs.SE
keywords automatedvulnerabilityrepairJavabytecodetemplatesbinary-levelVul4JManyVuls4Jfaultlocalizationpatchvalidation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

TemVUR repairs security vulnerabilities directly in Java bytecode, without needing source code. It applies 33 hand-assembled repair templates, drawn from both general automated program repair and vulnerability-specific analyses, to suspicious instructions, then uses the project's test suite to filter candidate patches. On the Vul4J benchmark it correctly fixes 11 of 79 vulnerabilities and securely fixes 15, compared with 7 correct and 9 security-fixing by the strongest previous techniques, a 57.1% improvement in correct fixes. The authors argue this shows binary-level repair is viable when source code is unavailable, avoids costly recompilation, and generalizes to their new 103-vulnerability dataset, ManyVuls4J.

What carries the argument

The load-bearing mechanism is a catalogue of 33 fix templates in 14 categories, implemented as bytecode rewrites in a Java binary. Each template is triggered by an instruction or instruction sequence detected in the suspicious region: a checkcast instruction triggers insertion of an instanceof guard, a tableswitch triggers mutation of a default branch, a method invocation can be swapped for a compatible one, and so on. A Java-agent instrumentation pass gathers instruction coverage, line-number tables map that coverage to Ochiai suspicion scores, bytecode traversal matches instructions to templates, and the resulting candidate binaries are validated against the test suite and proof-of-vulnerability. The contribution is the bytecode-level realization of known templates, including adjustments to the operand stack and constant pool indexes.

What would settle it

Run each of TemVUR's 15 security-fixing patches against an independent exploit proof-of-vulnerability for its CVE, re-launching the original attack on the patched jar; if any patch still permits the demonstrated exploit, the security-fixing count would drop below 15.

Watch

Extended reading notes

Core claim

The paper claims TemVUR is the first automated vulnerability repair approach that works at the Java binary level, and that template-based repair actions can be transferred from source code to bytecode. Its central result is that scanning bytecode for template-matching instructions and mutating them directly, instead of recompiling source, repairs 11 vulnerabilities correctly and 15 in the security-fixing sense on Vul4J, surpassing 14 APR and AVR baselines under perfect fault localization and remaining competitive under spectrum-based localization. The same pipeline on ManyVuls4J correctly fixes 20 vulnerabilities and securely fixes 15, roughly the same rate as on Vul4J, which the authors read as evidence against dataset overfitting.

Load-bearing premise

The headline counts of 11 correct and 15 security-fixing repairs rest on two co-authors manually judging patches, not on an independent re-exploitation test of each patch against the vulnerability.

Editorial extensions

If this is right

  • Users and security analysts who only have compiled jars can patch vulnerabilities themselves instead of waiting for a vendor release.
  • Because binary patches skip compilation, repair cost drops: TemVUR averages 61.5 seconds per vulnerability versus thousands of seconds for many baselines.
  • Vulnerability-specific templates contribute fixes that general-bug templates miss, and two vulnerabilities in Vul4J are fixed by TemVUR and by no other evaluated tool.
  • The similar fix rate on the 103-vulnerability ManyVuls4J suggests the approach is not tuned to a single benchmark.
  • Source-level and binary-level repair are complementary, so combining them in an ensemble would plausibly fix more vulnerabilities than either level alone.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An independent security expert running actual exploit proofs against the 15 security-fixing patches would test whether the manual classification overstates protection; the paper relies on two co-authors' manual review rather than re-exploitation.
  • Because Java bytecode is shared by Kotlin, Groovy, and Scala, the same templates may port to other JVM languages without reimplementation at the source level.
  • The paper's own partial-repair example, where a cross-site scripting fix leaves the dash character unescaped, shows that 'security-fixing' is a graded risk-reduction measure rather than a guarantee of complete vulnerability elimination.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 7 minor

Summary. This paper proposes TemVUR, a template-based automated vulnerability repair tool that operates directly on Java bytecode. The approach transfers 33 fix templates in 14 categories from source-level APR/AVR literature to bytecode mutation, uses Ochiai spectrum-based fault localization with line-number mapping, performs template matching via the ASM framework, and validates candidate patches against the test suite. The evaluation on the Vul4J benchmark reports 16 plausible, 15 security-fixing, and 11 correct patches under perfect fault localization, compared with best-baseline counts of 9 security-fixing and 7 correct. The paper also introduces a larger dataset, ManyVuls4J, with 103 vulnerabilities, and reports efficiency gains from avoiding compilation. The authors position TemVUR as the first binary-level AVR approach for Java and release a replication artifact.

Significance. If the reported classifications can be independently substantiated, TemVUR fills a genuine gap: it enables vulnerability repair for users and analysts who only have access to compiled Java artifacts, and it demonstrates that template-based repair actions can be transferred from source code to bytecode. The paper has real strengths: the template collection is grounded in prior literature rather than fitted to the benchmark, the tool has no learned parameters and is therefore less exposed to training-data overfitting, and the artifact and dataset release support replication. The authors also openly discuss the partial-repair limitation of their Vul4J-23 patch. However, the headline security-fixing counts rest on manual classification by the two co-authors, and the paper's own example violates the stated definition of a security-fixing patch. Because the counts are small (15 vs. 9 and 11 vs. 7), one or two reclassifications materially change the reported percentage improvements. The significance is therefore conditional on a careful re-evaluation of the per-patch labels, especially for the four non-correct security-fixing patches.

major comments (2)
  1. [§4.2.2, §6.1, Figure 4, Table 2] The definition of a “security-fixing patch” in §4.2.2 is a manually confirmed plausible patch that prevents the exploitation of a vulnerability. Section 6.1 then describes the Vul4J-23 patch, identified as such in the caption of Figure 4, as one that “does not completely repair the vulnerability” and only “prevents most malicious input,” because the dash is not escaped and can still be used in a JavaScript subtraction or comment context. Table 2 nevertheless counts the sling-org-apache-sling-xss vulnerability as security-fixing. This is an internal inconsistency in the load-bearing metric: the 15 security-fixing count and the 66.7% improvement over the best baseline's 9 depend on including this partial patch. The authors should either reclassify Vul4J-23, introduce a graded security notion with explicit residual risk, or provide an independent exploit-level retest that attempts the remaining dash-based vector for the four non-correct security-fixing patches. Without this, the headline security claim is not supported by the manuscript as written.
  2. [§3.4, §6.4, Figure 4, Table 2] The correctness classification is not reconciled with the paper's own definition. Section 6.4 states that a patch is correct only if both authors find it semantically equivalent to the ground-truth developer patch. For Vul4J-23, Figure 4 shows that TemVUR's patch omits the developer's dash-escaping replacement, and §6.1 explicitly says the patch does not completely repair the vulnerability. Yet Table 2 reports the sling-org-apache-sling-xss vulnerability as correctly fixed. The authors should provide a per-vulnerability mapping of the 11 correct claims to the corresponding developer patches, or revise the correct count for any patch that is not semantically equivalent to the ground truth. This matters because the “11 correct vs. 7” comparison in Table 5 is one of the two headline improvements.
minor comments (7)
  1. [§5.3.2, Table 6] The first sentence of the ManyVuls4J result swaps the dataset labels: the text says TemVUR securely fixes 19.0% (15/79) in ManyVuls4J and 19.4% (20/103) in Vul4J, while Table 6 shows 20 security-fixing and 15 correct for ManyVuls4J. The sentence also says “correctly fix 20 and 15,” which conflicts with the table. These numbers should be corrected to avoid confusion in the generalizability claim.
  2. [§4.3.2, Table 1] The text says 23 new vulnerabilities were added, but the rows in Table 1 sum to 24, which is consistent with the stated total of 103 (79 + 24). Please reconcile the number and clarify whether ManyVuls4J is the original 79 plus these 24 cases or a disjoint extension.
  3. [§5.1.4, Table 5] The prose misreports differences from Table 5 under perfect fault localization: TemVUR has 15 security-fixing fixes versus GAMMA's 7, a difference of 8, not 7, and the stated 83%/40% percentages do not match the table. Under spectrum-based FL, the security-fixing margin over GAMMA is 5, not 4. Please align the prose with the table.
  4. [§5.2.2, Table 7] The sentence on learning-based time efficiency says the range is approximately 700 to 7,000 seconds, but Table 7 lists SeqTrans at 207.1 seconds and GAMMA at 6,779.7 seconds; the stated range should be corrected.
  5. [Table 3] Table 3 lists 15 vulnerability IDs while Table 2 reports 16 plausible vulnerabilities; please reconcile the row set or clarify the formatting so that the per-vulnerability template counts are auditable.
  6. [Table 4] Please clarify whether the “Security-fixing Proportion” includes correct patches; as written, a correct patch is presumably also security-fixing, which makes the two proportions nested and complicates interpretation of the CWE-level results.
  7. [Abstract and §2.2] The abstract's claim that existing techniques exclusively repair vulnerabilities at the source level is too broad because PraPR, one of the paper's own baselines, is a bytecode-level APR technique; please qualify the claim to automated vulnerability repair techniques, as the body of the paper already does.

Circularity Check

0 steps flagged · score 2.0 of 10

No derivation-level circularity; only a minor non-load-bearing self-citation and a self-constructed generalizability check.

full rationale

TemVUR's fix templates are collected from prior APR/AVR literature and vulnerability-specific analyses (Sections 1 and 3.1), not fitted to the Vul4J evaluation benchmark, and no numeric parameter inside the repair logic is tuned on the evaluated data. The headline counts (11 correct, 15 security-fixing) are empirical results obtained by running the tool on the externally curated Vul4J benchmark against 14 external baselines, so they are not forced by construction. The manual 'security-fixing' label defined in Section 4.2.2 is a measurement-validity concern rather than a circular derivation, especially because Section 6.1 admits that the Vul4J-23 patch does not fully repair the vulnerability and may leave a dash-based XSS vector; this could inflate the count but does not make the repair result equivalent to the paper's inputs. The ManyVuls4J generalizability check (Sections 4.3.2 and 5.3) is self-constructed from the same ProjectKB source and the same selection criteria as Vul4J, which weakens the independence of that check but still constitutes an empirical re-run rather than a tautology. The only self-citation, reference [43], is used alongside [23], [41], and [42] to support a patch-ranking heuristic and is not load-bearing. Overall, the central claim is self-contained against external benchmarks and does not reduce to its own definitions or fitted parameters.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The ledger records the hand-built template set as the main chosen-by-hand ingredient, plus five domain assumptions about test-oracle adequacy, manual security review, line number availability, bytecode template semantic equivalence, and the SecureA naming heuristic. No invented entities or fitted numeric parameters are introduced.

free parameters (1)
  • Repair template set (33 templates in 14 categories)
    Manually collected from APR and AVR literature and hand-implemented at the bytecode level (Section 3.1); the success of the tool depends on this design choice, though no numeric value is fitted.
assumptions (5)
  • domain assumption Test suites with a passing PoV test are a sufficient oracle to determine a plausible repair
    Used throughout Sections 3.4 and 4.2.2 to classify patches that pass all tests and PoV checks as plausible, and then as the basis for human review.
  • domain assumption Manual review by two co-authors reliably determines semantic equivalence and security-fixing status
    Section 6.4 describes the manual validation procedure; the correctness and security-fixing counts depend on this judgment.
  • domain assumption Line number information is present in the target binary
    Section 3.2 maps instruction coverage to source lines using LineNumberTable, and Section 6.3 argues that over 90% of Java binaries retain it; without this the fault localization step fails.
  • ad hoc to paper Source-code repair templates can be faithfully translated to bytecode mutations without semantic loss
    Section 3.1 defines the templates and shows bytecode examples, but the equivalence between the source-level template semantics and the bytecode-level implementation is not formally proven.
  • domain assumption A class B named SecureA whose parent is A is the secure version of A
    Template T1 in Section 3.1 uses this naming heuristic to replace object instantiations with secure versions, relying on Java documentation conventions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of There are More Fish in the Sea: Automated Vulnerability Repair via Binary Templates." pith.science (2026). https://pith.science/paper/TFQDV3D3

@misc{pith2026241118088,
  author       = {Pith},
  title        = {Pith review of: There are More Fish in the Sea: Automated Vulnerability Repair via Binary Templates},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TFQDV3D3}},
  note         = {Machine review of arXiv:2411.18088}
}
read the original abstract

As software vulnerabilities increase in both volume and complexity, vendors often struggle to repair them promptly. Automated vulnerability repair has emerged as a promising solution to reduce the burden of manual debugging and fixing activities. However, existing techniques exclusively focus on repairing the vulnerabilities at the source code level, which has various limitations. For example, they are not applicable to those (e.g., users or security analysts) who do not have access to the source code. Consequently, this restricts the practical application of these techniques, especially in cases where vendors are unable to provide timely patches. In this paper, we aim to address the above limitations by performing vulnerability repair at binary code level, and accordingly propose a template-based automated vulnerability repair approach for Java binaries. Built on top of the literature, we collect fix templates from both existing template-based automated program repair approaches and vulnerability-specific analyses, which are then implemented for the Java binaries. Our systematic application of these templates effectively mitigates vulnerabilities: experiments on the Vul4J dataset demonstrate that TemVUR successfully repairs 11 vulnerabilities, marking a notable 57.1% improvement over current repair techniques. Moreover, TemVUR securely fixes 66.7% more vulnerabilities compared to leading techniques (15 vs. 9), underscoring its effectiveness in mitigating the risks posed by these vulnerabilities. To assess the generalizability of TemVUR, we curate the ManyVuls4J dataset, which goes beyond Vul4J to encompass a wider diversity of vulnerabilities. With 30% more vulnerabilities than its predecessor (increasing from 79 to 103). The evaluation on ManyVuls4J reaffirms TemVUR's effectiveness and generalizability across a diverse set of real-world vulnerabilities.

Figures

Figures reproduced from arXiv: 2411.18088 by the authors.

Figure 1
Figure 1. The overall workflow of TemVUR. #idx_C_init and #idx_SecureC_init refer to the in￾dexes of the constructor for C and SecureC, respectively. T2. Insert Validity Checker. Insert a validity checker to a statement that contains an expression which might be invalid, such as a null pointer checker. T2.1: + if (check(exp)) { T2.1 Bytecode Example: ...exp...; ...... + aload idx_obj + } + invokevirtual #idx_check T2.2: + if … view at source ↗
Figure 2
Figure 2. The overlaps of the vulnerabilities fixed by different approaches. (i.e., GAMMA), and six more than the best-performing AVR tools (i.e., VulRepairE-J). This means that TemVUR can prevent about 83% and 40% more exploits, respectively, than existing state-of-the-art APR and AVR techniques. Looking at the number of correctly fixed vulnerabilities, TemVUR generates five and four more correct patches than state-of￾the-ar… view at source ↗
Figure 3
Figure 3. The patch from the developer for the Vul4J-46 vulnera￾bility. public String encodeForJSString(String source) { - return source == null ? null : Encode. forJavaScriptSource(source); + return source == null ? null : Encode.forJavaScript( source).replace("\\-", "\\u002D"); // Developer’s patch + return source == null ? null : Encode.forJavaScript( source);// TemVUR’s patch } [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

72 extracted references · 68 canonical work pages

  1. [1]

    Software fault prediction metrics: A systematic literature review,

    D. Radjenovi ´c, M. Heri ˇcko, R. Torkar, and A. ˇZivkoviˇc, “Software fault prediction metrics: A systematic literature review,” Informa- tion and software technology, vol. 55, no. 8, pp. 1397–1418, 2013

    work page 2013

  2. [2]

    Seven years of software vulnera- bilities: The ebb and flow,

    H. Homaei and H. R. Shahriari, “Seven years of software vulnera- bilities: The ebb and flow,” IEEE Security & Privacy , vol. 15, no. 1, pp. 58–65, 2017

    work page 2017

  3. [3]

    Vulnerabilities by year,

    CVE, “Vulnerabilities by year,” Website, 2023, https://www. cvedetails.com/vulnerabilities-by-types.php

    work page 2023

  4. [4]

    State of software security,

    Veracode, “State of software security,” Website, 2022, https://info. veracode.com/report-state-of-software-security-volume-12.html

    work page 2022

  5. [5]

    Apr4vul: an empirical study of automatic program repair techniques on real-world java vulnerabilities,

    Q.-C. Bui, R. Paramitha, D.-L. Vu, F. Massacci, and R. Scandari- ato, “Apr4vul: an empirical study of automatic program repair techniques on real-world java vulnerabilities,” Empirical software engineering, vol. 29, no. 1, p. 18, 2024

    work page 2024

  6. [6]

    Software vulnerability detection using deep neural networks: a survey,

    G. Lin, S. Wen, Q.-L. Han, J. Zhang, and Y. Xiang, “Software vulnerability detection using deep neural networks: a survey,” Proceedings of the IEEE, vol. 108, no. 10, pp. 1825–1848, 2020

    work page 2020

  7. [7]

    Identify- ing the characteristics of vulnerable code changes: An empirical study,

    A. Bosu, J. C. Carver, M. Hafiz, P . Hilley, and D. Janni, “Identify- ing the characteristics of vulnerable code changes: An empirical study,” in Proceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering , 2014, pp. 257–268

    work page 2014

  8. [8]

    Deep learning based vulnerability detection: Are we there yet,

    S. Chakraborty, R. Krishna, Y. Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet,” IEEE Transactions on Software Engineering, 2021

    work page 2021

Show all 72 references
  1. [9]

    Linevul: A transformer-based line-level vulnerability prediction,

    M. Fu and C. Tantithamthavorn, “Linevul: A transformer-based line-level vulnerability prediction,” in Proceedings of the 19th Inter- national Conference on Mining Software Repositories , 2022, pp. 608– 620

    2022

  2. [10]

    Linevd: Statement- level vulnerability detection using graph neural networks,

    D. Hin, A. Kan, H. Chen, and M. A. Babar, “Linevd: Statement- level vulnerability detection using graph neural networks,” in Proceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 596–607

    2022

  3. [11]

    Are vulnerabilities discovered and resolved like other defects?

    P . J. Morrison, R. Pandita, X. Xiao, R. Chillarege, and L. Williams, “Are vulnerabilities discovered and resolved like other defects?” in Proceedings of the 40th International Conference on Software Engi- neering, 2018, pp. 498–498

    2018

  4. [12]

    Deep domain adaptation for vulnerable code function identification,

    V . Nguyen, T. Le, T. Le, K. Nguyen, O. DeVel, P . Montague, L. Qu, and D. Phung, “Deep domain adaptation for vulnerable code function identification,” in 2019 international joint conference on neural networks (IJCNN). IEEE, 2019, pp. 1–8

    2019

  5. [13]

    Data preparation for software vulnerability prediction: A systematic literature review,

    R. Croft, Y. Xie, and M. A. Babar, “Data preparation for software vulnerability prediction: A systematic literature review,” IEEE Transactions on Software Engineering , vol. 49, no. 3, pp. 1044–1063, 2022

    2022

  6. [14]

    Active learning for structural reliability: Survey, general framework and benchmark,

    M. Moustapha, S. Marelli, and B. Sudret, “Active learning for structural reliability: Survey, general framework and benchmark,” Structural Safety, vol. 96, p. 102174, 2022

    2022

  7. [15]

    Program vulnerability repair via inductive inference,

    Y. Zhang, X. Gao, G. J. Duck, and A. Roychoudhury, “Program vulnerability repair via inductive inference,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022, pp. 691–702

    2022

  8. [16]

    Beyond tests: Program vulnerability repair via crash constraint extraction,

    X. Gao, B. Wang, G. J. Duck, R. Ji, Y. Xiong, and A. Roychoudhury, “Beyond tests: Program vulnerability repair via crash constraint extraction,” ACM Trans. Softw. Eng. Methodol. , vol. 30, no. 2, feb

  9. [17]

    Using safety properties to generate vulnerability patches,

    Z. Huang, D. Lie, G. Tan, and T. Jaeger, “Using safety properties to generate vulnerability patches,” in 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp. 539–554

    2019

  10. [18]

    Seqtrans: automatic vulnerability fix via sequence to sequence learning,

    J. Chi, Y. Qu, T. Liu, Q. Zheng, and H. Yin, “Seqtrans: automatic vulnerability fix via sequence to sequence learning,” IEEE Transac- tions on Software Engineering, vol. 49, no. 2, pp. 564–585, 2022. 14

    2022

  11. [19]

    Vulrepair: A t5-based automated software vulnerability repair,

    M. Fu, C. Tantithamthavorn, T. Le, V . Nguyen, and D. Phung, “Vulrepair: A t5-based automated software vulnerability repair,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ser. ESEC/FSE 2...

    2022

  12. [20]

    Neural transfer learning for repairing security vulnerabilities in c code,

    Z. Chen, S. Kommrusch, and M. Monperrus, “Neural transfer learning for repairing security vulnerabilities in c code,” IEEE Transactions on Software Engineering , vol. 49, no. 1, pp. 147–165, 2022

    2022

  13. [21]

    Memfix: static analysis-based repair of memory deallocation errors for c,

    J. Lee, S. Hong, and H. Oh, “Memfix: static analysis-based repair of memory deallocation errors for c,” in Proceedings of the 2018 26th ACM Joint meeting on European software engineering conference and symposium on the foundations of software engineering , 2018, pp. 95–106

    2018

  14. [22]

    Binary rewriting with- out control flow recovery,

    G. J. Duck, X. Gao, and A. Roychoudhury, “Binary rewriting with- out control flow recovery,” inProceedings of the 41st ACM SIGPLAN conference on programming language design and implementation, 2020, pp. 151–163

    2020

  15. [23]

    Contract-based program repair without the contracts,

    L. Chen, Y. Pei, and C. A. Furia, “Contract-based program repair without the contracts,” in Proceedings of the 32nd IEEE/ACM In- ternational Conference on Automated Software Engineering , 2017, pp. 637–647

    2017

  16. [24]

    Vul4j: A dataset of reproducible java vulnerabilities geared towards the study of program repair techniques,

    Q.-C. Bui, R. Scandariato, and N. E. D. Ferreyra, “Vul4j: A dataset of reproducible java vulnerabilities geared towards the study of program repair techniques,” in Proceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 464–468

    2022

  17. [25]

    A manually-curated dataset of fixes to vulnerabilities of open- source software,

    S. E. Ponta, H. Plate, A. Sabetta, M. Bezzi, and C. Dangremont, “A manually-curated dataset of fixes to vulnerabilities of open- source software,” in Proceedings of the 16th International Conference on Mining Software Repositories, May 2019

    2019

  18. [26]

    2020 cybercrime economic costs: No measure no solution,

    J. Armin, B. Thompson, D. Ariu, G. Giacinto, F. Roli, and P . Kijew- ski, “2020 cybercrime economic costs: No measure no solution,” in 2015 10th International Conference on Availability, Reliability and Security. IEEE, 2015, pp. 701–710

    2020

  19. [27]

    Common weakness enumeration,

    CWE, “Common weakness enumeration,” Website, 2024, https:// cwe.mitre.org

    2024

  20. [28]

    GenProg: A generic method for automatic software repair,

    C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “GenProg: A generic method for automatic software repair,” IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 54–72, 2012

    2012

  21. [29]

    Arja: Automated repair of java programs via multi-objective genetic programming,

    Y. Yuan and W. Banzhaf, “Arja: Automated repair of java programs via multi-objective genetic programming,” IEEE Transactions on Software Engineering, vol. 46, no. 10, pp. 1040–1067, 2020

    2020

  22. [30]

    TBar: Revisiting template-based automated program repair,

    K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyand ´e, “TBar: Revisiting template-based automated program repair,” in Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis. ACM, 2019, pp. 31–42

    2019

  23. [31]

    Coconut: combining context-aware neural translation models using ensemble for program repair,

    T. Lutellier, H. V . Pham, L. Pang, Y. Li, M. Wei, and L. Tan, “Coconut: combining context-aware neural translation models using ensemble for program repair,” inProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis , 2020, pp. 101–114

    2020

  24. [32]

    Gamma: Revisiting template-based automated program repair via mask prediction,

    Q. Zhang, C. Fang, T. Zhang, B. Yu, W. Sun, and Z. Chen, “Gamma: Revisiting template-based automated program repair via mask prediction,” arXiv preprint arXiv:2309.09308, 2023

    2023 arXiv

  25. [33]

    A comparative study of automatic program repair techniques for security vulnerabilities,

    E. Pinconschi, R. Abreu, and P . Ad ˜ao, “A comparative study of automatic program repair techniques for security vulnerabilities,” in 2021 IEEE 32nd international symposium on software reliability engineering (ISSRE). IEEE, 2021, pp. 196–207

    2021

  26. [34]

    Automatic discovery and patching of buffer and integer overflow errors,

    S. Sidiroglou-Douskos, E. Lahtinen, and M. Rinard, “Automatic discovery and patching of buffer and integer overflow errors,” 2015

    2015

  27. [35]

    Automatic error elimination by horizontal code transfer across multiple applications,

    S. Sidiroglou-Douskos, E. Lahtinen, F. Long, and M. Rinard, “Automatic error elimination by horizontal code transfer across multiple applications,” in Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation , 2015, pp. 43–54

    2015

  28. [36]

    Automatic buffer overflow warning validation,

    F.-J. Gao, Y. Wang, L.-Z. Wang, Z. Yang, and X.-D. Li, “Automatic buffer overflow warning validation,” Journal of Computer Science and Technology, vol. 35, pp. 1406–1427, 2020

    2020

  29. [37]

    Klee: unassisted and automatic generation of high-coverage tests for complex systems programs

    C. Cadar, D. Dunbar, D. R. Engler et al. , “Klee: unassisted and automatic generation of high-coverage tests for complex systems programs.” in OSDI, vol. 8, 2008, pp. 209–224

    2008

  30. [38]

    Vurle: Automatic vulnerability detection and repair by learning from examples,

    S. Ma, F. Thung, D. Lo, C. Sun, and R. H. Deng, “Vurle: Automatic vulnerability detection and repair by learning from examples,” in Computer Security–ESORICS 2017: 22nd European Symposium on Research in Computer Security, Oslo, Norway, September 11-15, 2017, Proceedings, Part ...

    2017

  31. [39]

    Learning to repair software vulnerabilities with generative adversarial networks,

    J. Harer, O. Ozdemir, T. Lazovich, C. Reale, R. Russell, L. Kim et al., “Learning to repair software vulnerabilities with generative adversarial networks,” Advances in neural information processing systems, vol. 31, 2018

    2018

  32. [40]

    Cvefixes: automated collection of vulnerabilities and their fixes from open-source soft- ware,

    G. Bhandari, A. Naseer, and L. Moonen, “Cvefixes: automated collection of vulnerabilities and their fixes from open-source soft- ware,” in Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering , 2021, pp. 30–39

    2021

  33. [41]

    Context- aware patch generation for better automated program repair,

    M. Wen, J. Chen, R. Wu, D. Hao, and S.-C. Cheung, “Context- aware patch generation for better automated program repair,” in Proceedings of the 40th International Conference on Software Engineer- ing. ACM, 2018, pp. 1–11

    2018

  34. [42]

    S3: syntax-and semantic-guided repair synthesis via programming by examples,

    X.-B. D. Le, D.-H. Chu, D. Lo, C. Le Goues, and W. Visser, “S3: syntax-and semantic-guided repair synthesis via programming by examples,” in Proceedings of the 11th Joint Meeting on Foundations of Software Engineering. ACM, 2017, pp. 593–604

    2017

  35. [43]

    Automated patch correctness assessment: How far are we?

    S. Wang, M. Wen, B. Lin, H. Wu, Y. Qin, D. Zou, X. Mao, and H. Jin, “Automated patch correctness assessment: How far are we?” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. ACM, 2020

    2020

  36. [44]

    Practical program repair via bytecode mutation,

    A. Ghanbari, S. Benton, and L. Zhang, “Practical program repair via bytecode mutation,” in Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis . ACM, 2019, pp. 19–30

    2019

  37. [45]

    Java®platform, standard edition & java development kit ver- sion 9 api specification,

    “Java®platform, standard edition & java development kit ver- sion 9 api specification,” Website, 2017, https://docs.oracle.com/ javase/9/docs/api/overview-summary.html

    2017

  38. [46]

    Lindholm, F

    T. Lindholm, F. Yellin, G. Bracha, and A. Buckley, The Java virtual machine specification. Addison-wesley, 2013

    2013

  39. [47]

    Less training, more repairing please: revisiting automated program repair via zero-shot learning,

    C. S. Xia and L. Zhang, “Less training, more repairing please: revisiting automated program repair via zero-shot learning,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022, pp. 959–971

    2022

  40. [48]

    Neural program repair with execution-based backpropagation,

    H. Ye, M. Martinez, and M. Monperrus, “Neural program repair with execution-based backpropagation,” in Proceedings of the 44th International Conference on Software Engineering , 2022, pp. 1506– 1518

    2022

  41. [49]

    A syntax-guided edit decoder for neural program repair,

    Q. Zhu, Z. Sun, Y.-a. Xiao, W. Zhang, K. Yuan, Y. Xiong, and L. Zhang, “A syntax-guided edit decoder for neural program repair,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2...

    2021

  42. [50]

    You cannot fix what you cannot find! an investigation of fault localization bias in benchmarking automated program repair systems,

    K. Liu, A. Koyuncu, T. F. Bissyand ´e, D. Kim, J. Klein, and Y. L. Traon, “You cannot fix what you cannot find! an investigation of fault localization bias in benchmarking automated program repair systems,” in Proceedings of the 12th IEEE International Conference on Software T...

    2019

  43. [51]

    GZoltar: an eclipse plug-in for testing and debugging,

    J. Campos, A. Riboira, A. Perez, and R. Abreu, “GZoltar: an eclipse plug-in for testing and debugging,” in Proceedings of the 27th IEEE/ACM International Conference on Automated Software En- gineering. ACM, 2012, pp. 378–381

    2012

  44. [52]

    On the accuracy of spectrum-based fault localization,

    R. Abreu, P . Zoeteweij, and A. J. Van Gemund, “On the accuracy of spectrum-based fault localization,” in Testing: Academic and Industrial Conference Practice and Research Techniques-MUTATION . IEEE, 2007, pp. 89–98

    2007

  45. [53]

    Java agent,

    Oracle Corporation, “Java agent,” https://docs.oracle.com/ javase/8/docs/api/java/lang/instrument/package-summary. html, 2018, accessed: February 8, 2024

    2018

  46. [54]

    Java decompiler diversity and its application to meta-decompilation,

    N. Harrand, C. Soto-Valero, M. Monperrus, and B. Baudry, “Java decompiler diversity and its application to meta-decompilation,” Journal of Systems and Software, vol. 168, p. 110645, 2020

    2020

  47. [55]

    Asm: a code manipula- tion tool to implement adaptable systems,

    E. Bruneton, R. Lenglet, and T. Coupaye, “Asm: a code manipula- tion tool to implement adaptable systems,” Adaptable and extensible component systems, vol. 30, no. 19, 2002

    2002

  48. [56]

    Using asm framework to implement common byte- code transformation patterns,

    E. Kuleshov, “Using asm framework to implement common byte- code transformation patterns,” Proc. of the 6th AOSD, ACM Press , 2007

    2007

  49. [57]

    Ppt4j: Patch presence test for java binaries,

    Z. Pan, X. Hu, X. Xia, X. Zhan, D. Lo, and X. Yang, “Ppt4j: Patch presence test for java binaries,” arXiv preprint arXiv:2312.11013 , 2023

    2023 arXiv

  50. [58]

    Circle: Continual repair across programming languages,

    W. Yuan, Q. Zhang, T. He, C. Fang, N. Q. V . Hung, X. Hao, and H. Yin, “Circle: Continual repair across programming languages,” 15 in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022, pp. 678–690

    2022

  51. [59]

    Cure: Code-aware neu- ral machine translation for automatic program repair,

    N. Jiang, T. Lutellier, and L. Tan, “Cure: Code-aware neu- ral machine translation for automatic program repair,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, pp. 1161–1173

    2021

  52. [60]

    Pit: a practical mutation testing tool for java,

    H. Coles, T. Laurent, C. Henard, M. Papadakis, and A. Ventresque, “Pit: a practical mutation testing tool for java,” in Proceedings of the 25th international symposium on software testing and analysis , 2016, pp. 449–452

    2016

  53. [61]

    ASTOR: a program repair library for java (demo),

    M. Martinez and M. Monperrus, “ASTOR: a program repair library for java (demo),” in Proceedings of the 25th International Symposium on Software Testing and Analysis. ACM, 2016, pp. 441– 444

    2016

  54. [62]

    An empirical study on fine-tuning large language models of code for automated program repair,

    K. Huang, X. Meng, J. Zhang, Y. Liu, W. Wang, S. Li, and Y. Zhang, “An empirical study on fine-tuning large language models of code for automated program repair,” in Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineer- ing, 2023, pp. 1–13

    2023

  55. [63]

    Exploring the limits of transfer learning with a unified text-to-text transformer,

    C. Raffel, N. Shazeer, A. Roberts, K. Lee, S. Narang, M. Matena, Y. Zhou, W. Li, and P . J. Liu, “Exploring the limits of transfer learning with a unified text-to-text transformer,”Journal of Machine Learning Research, vol. 21, pp. 1–67, 2020

    2020

  56. [64]

    A manually-curated dataset of fixes to vulnerabilities of open- source software,

    S. E. Ponta, H. Plate, A. Sabetta, M. Bezzi, and C. Dangremont, “A manually-curated dataset of fixes to vulnerabilities of open- source software,” in 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR). IEEE, 2019, pp. 383–387

    2019

  57. [65]

    National vulnerability database,

    NVD, “National vulnerability database,” Website, 2024, https:// nvd.nist.gov

    2024

  58. [66]

    A c/c++ code vulnerabil- ity dataset with code changes and cve summaries,

    J. Fan, Y. Li, S. Wang, and T. N. Nguyen, “A c/c++ code vulnerabil- ity dataset with code changes and cve summaries,” in Proceedings of the 17th International Conference on Mining Software Repositories , 2020, pp. 508–512

    2020

  59. [67]

    Cerberus: a program repair framework,

    R. Shariffdeen, M. Mirchev, Y. Noller, and A. Roychoudhury, “Cerberus: a program repair framework,” in 2023 IEEE/ACM 45th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). IEEE, 2023, pp. 73–77

    2023

  60. [68]

    Vulnerability type distributions in cve,

    CWE, “Vulnerability type distributions in cve,” Website, 2007, https://cwe.mitre.org/documents/vuln-trends/index.html

    2007

  61. [69]

    Practical program repair via preference-based ensemble strategy,

    W. Zhong, C. Li, K. Liu, T. Xu, J. Ge, T. F. Bissyand ´e, B. Luo, and V . Ng, “Practical program repair via preference-based ensemble strategy,” in Proceedings of the 46th IEEE/ACM International Confer- ence on Software Engineering, 2024, pp. 1–13

    2024

  62. [70]

    Time complex- ity of genetic algorithms on exponentially scaled problems,

    F. G. Lobo, D. E. Goldberg, and M. Pelikan, “Time complex- ity of genetic algorithms on exponentially scaled problems,” in Proceedings of the 2nd annual conference on genetic and evolutionary computation, 2000, pp. 151–158

    2000

  63. [71]

    Empirical review of java program repair tools: A large-scale experiment on 2,141 bugs and 23,551 repair attempts,

    T. Durieux, F. Madeiral, M. Martinez, and R. Abreu, “Empirical review of java program repair tools: A large-scale experiment on 2,141 bugs and 23,551 repair attempts,” in Proceedings of the 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the...

    2019

  64. [2021]

    Available: https://doi.org/10.1145/3418461

    [Online]. Available: https://doi.org/10.1145/3418461

    doi

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.