{"id":"2547d971-0230-4ab7-816b-ff0af324ddb1","arxiv_id":"2602.07666","paper_version":5,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Reliability and accuracy, not novel techniques, decided DARPA's 2025 AI cyber contest; LLM-based reasoning found 22 vulnerabilities that dedicated fuzzing missed, while auto-generated patches still fail semantic correctness in roughly a quarter of cases.","lead":"This paper is the first systematic post-mortem of DARPA's AI Cyber Challenge, the largest contest to date for AI systems that find and fix bugs in real open-source software. Its central conclusion: the winner won on system reliability and submission accuracy, not on technique novelty — and today's AI reasoning systems still produce semantically wrong patches roughly a quarter of the time.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"KF3's causal claim that the 22 non-PF PoVs are \"thanks to LLM-driven code understanding\" is not established; the paper reports no per-CPV attribution and several CRSs fielded strong non-LLM enhancements.","rationale":"I agree with the reader that the weakest load-bearing assumption is KF3's causal attribution in §7.3. The paper's aggregate count of 22 non-PF PoVs conflates contributions from LLM agents and from traditional enhancements that teams layered on top of parallel fuzzing. Table 3 documents concolic execution, directed fuzzing, dictionary generation, improved sanitizers, and extra fuzzers, with several of the top teams deploying these. Without a per-CPV breakdown, the 'thanks to LLM-driven code understanding' is an interpretation, not a measurement. The FB case is genuinely supportive: FB is a near-pure LLM+parallel-fuzzing system and solved multiple PF-missed CPVs, so it proves LLMs can contribute. But that is existence, not predominance. My proposed attribution check, using logs or ablation, would decide between 'LLMs contributed' and 'LLMs were the primary contributor.' The rest of the paper's qualitative findings (stability/accuracy deciding, patching unreliable) rest on scoreboard evidence and are not threatened by this concern. Therefore the CONDITIONAL verdict remains appropriate pending the artifact release and the attribution analysis.","tokens_in":33942,"tokens_out":9286,"duration_ms":95608,"concrete_test":"Inspect the competition telemetry/CRS logs (or, if unavailable, run an ablation on the open-sourced CRS of the highest-scoring team) to determine, for each of the 22 non-PF CPVs, which component first produced the PoV: an LLM-based agent or a non-LLM enhancement (concolic, directed fuzzing, dictionary, sanitizer). If disabling LLM-based PoV generation removes few or none of these 22, KF3's attribution is unsupported; if it removes most, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"KF3 in §7.3 asserts that CRSs find 22 PoVs that PF cannot, 'thanks to LLM-driven code understanding.' This causal attribution is load-bearing for the paper's central message, but it is not demonstrated. Table 3 shows multiple CRSs deployed non-LLM enhancements beyond parallel fuzzing: concolic execution, directed fuzzing, dictionary generation, improved sanitizers, and added fuzzers, concentrated in teams like AT, SP, and 42. The paper does not report which CRS component generated the first successful PoV for each of the 22 CPVs. The FB example is a good natural experiment — FB relies only on LLM generation plus parallel fuzzing and solved multiple PF-missed CPVs — but it evidences LLM attribution for FB's subset only; it does not establish that the union of 22 is predominantly LLM-driven. 'Improvement over PF is observed across most teams' is a team-level statement, not a CPV-level one, and does not rule out that a few teams' non-LLM components found a large share of the 22. The weaker claim (CRSs exceed PF) survives, but the causal claim 'thanks to LLM-driven code understanding' does not follow without per-CPV attribution.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This SoK paper presents the first systematic analysis of DARPA's AI Cyber Challenge (AIxCC) final competition, covering competition design, the architectures of all seven finalist CRSs, and a per-CPV analysis of results using three foundational baselines: parallel fuzzing (PF), the MultiRetrieval patch agent (MR), and Claude Code (CC). The main findings are: (KF1) stability and accuracy, not raw capability, decided final scores; (KF2) technical sophistication and engineering reliability are distinct challenges; (KF3) CRSs found 22 PoVs that PF could not, attributed to LLM-driven code understanding; and (KF4) automated patch accuracy remains an open problem. The paper draws on organizer data, team codebases, telemetry, and discussions with all finalist teams, and includes substantial new annotation experiments with documented costs and manual patch validation.","tokens_in":34092,"tokens_out":14531,"duration_ms":155259,"significance":"If the results hold, this is an important and timely reference for competition design, autonomous vulnerability discovery, and LLM-based security research. The paper is strongest in its descriptive and taxonomical material: the architecture comparison across all seven finalists is careful and cross-validated, the scoring analysis is grounded in external competition data, and the annotation experiments are concrete, with specified CPU hours, LLM costs, run counts, and two-person-week manual patch validation. The central qualitative message — that winning AIxCC was primarily an engineering-reliability achievement and that automated patching remains semantically unreliable — is credible and significant. The main weaknesses are the unsupported causal attribution in KF3 and an internal arithmetic inconsistency in the key score table. Both are fixable within the scope of a revision.","major_comments":[{"comment":"The Final column is inconsistent with the Pen row as printed. For TI, the component rows sum to 54.3 + 101.6 + 4.9 + 49.8 = 210.7; applying the documented -16.3 penalty would give 194.4, not the printed Final of 210.7. The text says TI's pre-penalty score was higher than TB's, which requires a pre-penalty total of 227.0, not the component sum. The same arithmetic issue appears for every team (e.g., AT 392.8 with Pen -0.4). Since KF1's 'accuracy matters' evidence depends on the size and rank effect of the penalty, please clarify whether the component rows and Final are pre- or post-penalty, and make the table internally consistent under one stated convention.","section":"Table 7 / §7.1"},{"comment":"The existence of 22 non-PF PoVs is supported by the annotation experiment, but the causal claim 'thanks to LLM-driven code understanding' is not established. Table 3 shows that AT, SP, and 42 also fielded non-LLM enhancements (concolic execution, directed fuzzing, dictionary generation, improved sanitizers, added fuzzers), and the paper reports no per-CPV attribution of which component produced the first successful PoV for each of the 22 CPVs. 'Improvement over PF is observed across most teams' is a team-level statement, not a CPV-level one. The FB example is a clean natural experiment only for FB's subset. Please add per-CPV attribution from telemetry where available, or at least a sensitivity analysis restricted to teams without non-LLM fuzzing enhancements, or rewrite KF3 to the weaker, supported claim that CRSs collectively exceeded PF and that FB demonstrates LLM-driven generation c","section":"§7.3, KF3"},{"comment":"The foundational baselines PF and MR are taken from OSS-CRS [54], developed by the authors' own lab, and the winning CRS (AT) is from the same group. The scoreboard data are external, so the central KF1/KF4 claims are not circular, but the 'foundational' annotations underlying KF3/KF4 may be sensitive to baseline selection. Please disclose this overlap explicitly, justify the neutrality of the chosen baseline (e.g., fixed public configuration, standard OSS-Fuzz settings), and ideally add an independent fuzzing baseline such as stock libFuzzer or AFL++ with the same harnesses. Without this, the exact counts 34/63 PF-solvable and 36/63 MR/CC-patchable cannot be independently audited by readers.","section":"§7.2, baseline provenance"}],"minor_comments":[{"comment":"The statement that 'a CRS that reliably applies foundational techniques in real-world conditions would rank among the top three' is asserted without a scoring simulation. Ranking depends on time decay, bundling, SARIF scoring, and accuracy penalties, not only on the number of PF/MR/CC-annotatable CPVs. Please derive this from the actual score model or soften the claim.","section":"§7.2"},{"comment":"The per-CPV matrices are very dense, and the markers for PF/CC/MR annotations and the zero-day submatrices are hard to distinguish in print. Consider providing a machine-readable table of per-CPV annotations so the counts (8 C + 14 Java = 22 beyond PF) can be verified exactly.","section":"Figure 3 / §7.3"},{"comment":"The accuracy multiplier formula AM = 1 - (1 - r)^4 with r = n_acc/(n_acc + n_inacc) is undefined when a team has no counted submissions in a category. Table 17 uses dashes for LC's SARIF and Bundle; please specify the convention for AM in that case.","section":"Appendix C"},{"comment":"The SP patch accuracy of 100% is based on only 11 counted submissions. The paper correctly attributes this to strict filtering and challenge distribution, but adding raw counts with confidence intervals would help readers calibrate the comparison with TI (63 submissions, 31.7%) and FB (60 submissions, 23.3%).","section":"§7.4 / Table 17"}],"recommendation":"major_revision","confidential_remarks":"To the editor: this is a strong SoK and the descriptive portions are reliable. The main risks are the overattribution in KF3 and the arithmetic inconsistency in Table 7, both fixable. The baseline-provenance overlap (OSS-CRS from the authors' own lab) should be addressed prominently in revision. If the authors weaken KF3 to the supported claim and correct Table 7, I would be satisfied. I see no grounds for rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nRead this if you want one source for what actually happened in AIxCC. It is the first systematic analysis of the competition, and it earns that role: the authors got access to all seven CRS codebases, organizer telemetry, and team meetings, and they turned it into an architecture taxonomy (§6), per-CPV score matrices (Figure 3), and annotation experiments (8,906 CPU-hours of parallel fuzzing, plus MR/CC patch runs with manual semantic verification). KF1 (stability and accuracy decided CRS performance) and KF4 (patch semantic correctness still unreliable: 37.7% CC / 45.6% MR incorrect despite passing automated checks) are grounded in the official scoreboard and in careful manual review. KF2, the engineering-versus-technique distinction, is also a fair read of the data. This is a genuinely useful reference, not just a recap.\n\nThe soft spots, in proportion:\n\n- KF3's causal attribution (\"22 PoVs that PF cannot, thanks to LLM-driven code understanding\") is not established. The paper shows CRSs beat PF and that non-LLM enhancements were concentrated in a few teams, but there is no per-CPV attribution of which component produced the first successful PoV. FB is the clean LLM-only-plus-PF case and supports LLM credit for FB's subset only. The weaker claim (CRSs exceed PF) survives; the causal one needs component-level logs or a controlled ablation. The paper itself notes telemetry is incomplete.\n\n- Table 7 has an accounting inconsistency. The Final column shows TI 210.7 vs TB 219.4, but the text says TI's pre-penalty score was higher than TB's. Summing the documented category scores for TI gives 210.7, and the Pen row (-16.3) is not reflected in the printed Final. Either the table or the text is wrong; the official scoreboard settles the ranking, so this is fixable, not load-bearing.\n\n- The foundational baselines (PF, MR) come from OSS-CRS, the same lab that built the winning CRS, and the organizer is on the author list. Disclosed, but it makes the \"CRSs beat foundational techniques\" comparison self-referential in design. Independent replication would help.\n\n- The counterfactual \"a reliable foundational-technique CRS would rank top-three\" is asserted without derivation. It may be true, but it is not a result.\n\nNone of this breaks the central qualitative contribution. Send it to peer review, with the expectation that the authors fix Table 7, soften KF3's causal language, derive the counterfactual, and release the artifacts. It is the reference for anyone studying autonomous LLM security systems.","headline":"First systematic SoK of AIxCC with real new measurements; the stability/accuracy thesis holds, but the LLM-attribution claim for the 22 non-PF PoVs is not established and Table 7's penalty arithmetic is inconsistent.","tokens_in":34836,"tokens_out":5079,"would_cite":true,"duration_ms":52948,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"At the largest autonomous-cyber competition to date, reliability beat raw technique, LLM-driven analysis found 22 vulnerabilities fuzzing missed, and automated patching still demands human review.","keywords":["AIxCC","cyber reasoning systems","LLM vulnerability discovery","automated patching","parallel fuzzing","competition design","system reliability"],"falsifier":"An ablation on the 22 beyond-fuzzing vulnerabilities: run the relevant finalist pipelines with all LLM components replaced by deterministic substitutes while keeping their non-LLM enhancements; if a substantial share still yield triggering inputs, the 'LLM-driven code understanding' attribution fails. A check already available in the paper's data: tabulate which teams produced each of the 22 finds — the most fuzzing-centric finalist had the second-highest discovery score, so the distribution alone would indicate how much of the effect is genuinely LLM-attributable.","tokens_in":33656,"feed_emoji":"🛡️","tokens_out":13915,"duration_ms":143953,"temperature":0.7,"pith_summary":"The AI Cyber Challenge (AIxCC) was the largest test yet of fully autonomous cyber reasoning systems — software that uses large language models to discover and patch vulnerabilities in real open-source C and Java projects while running unattended for roughly 143 hours. The paper's central assertion is that the outcome was decided by reliability, not raw technique: the winning system outscored second place by about 80%, and most of the margin accumulated after rival systems crashed or plateaued mid-competition. Its second claim is that LLM-based analysis contributed genuinely: the seven finalists together produced proof-of-vulnerability inputs for 22 planted vulnerabilities that a dedicated six-hour parallel-fuzzing baseline could not trigger, clustered in code diffs, indirect calls, grammar-heavy formats, and logic-guarded paths — and every team found at least one true, previously unknown vulnerability. Its third claim is that automated patching is the open problem: even under ideal laboratory conditions, off-the-shelf repair agents produced semantically incorrect patches in 38–46% of cases while passing every automated check, and competition systems likewise emitted bursts of invalid patches. If the paper is right, the field's real bottleneck is not model capability but operational reliability, submission accuracy, and patch trust.","feed_headline":"Winning the AI cyber challenge took uptime, not cleverness","feed_subtitle":"LLM-driven teams found 22 bugs six-hour fuzzing missed, plus 25 zero-days — yet machine patches still need human review.","key_machinery":"The argument's load-bearing machinery is a difficulty-annotation methodology: foundational techniques were run under ideal laboratory conditions on the same 63 planted vulnerabilities, and the finalists' results were overlaid on top to separate 'hard for everyone' from 'solvable in principle, unsolved in practice.' The discovery baseline was six hours of parallel fuzzing (16 cores per harness, three runs), which marked 34 of 63 vulnerabilities discoverable — 75% of C but only 17% of Java. The patch baselines were two off-the-shelf repair agents given ground-truth reports, marking 31 and 33 vulnerabilities patchable, with every passing patch manually reviewed. This lets the paper attribute ou","core_discovery":"On competition-scale evidence, the paper establishes three things. First, stability and submission accuracy outweighed analytical capability: decisive score gaps came from systems that stopped functioning or accumulated accuracy penalties, and a hypothetical CRS that merely applied off-the-shelf techniques reliably would have ranked in the top three. Second, LLM-driven code understanding produced measurable discovery gains beyond fuzzing — 22 proof-of-vulnerability inputs across code diffs, indirect calls, grammar-constrained formats, and logic-guarded paths, plus 25 genuine zero-days found by the seven finalists — reasoning that feedback-driven fuzzing cannot match. Third, automated patchin","pith_inferences":["The paper's attribution of the 22 beyond-fuzzing finds to 'LLM-driven code understanding' is a causal claim its own data only partially supports: the same teams also ran non-LLM techniques (concolic execution, directed and grammar-aware fuzzing, dictionaries, improved sanitizers), the most fuzzing-centric finalist posted the second-highest discovery score, and the paper concedes attribution to any","If reliability is the binding constraint, expect near-term deployments to be conservative: deterministic tools doing the heavy lifting with LLM components gated behind verification, rather than the fully autonomous agent fleets the competition showcased.","Only about half of the planted real-world-style vulnerabilities yielded to today's automated discovery, and fewer to trustworthy patching; that ratio implies a near-term division of labour in which machines triage and propose while humans review and dispose.","The baseline-annotation method could be productized as a benchmark axis: pre-rating each challenge by whether off-the-shelf tooling solves it, and scoring systems on baseline-hard vulnerabilities, would change what winning a cyber competition measures — from volume to genuine advance."],"forward_implications":["A system that simply applied off-the-shelf techniques — parallel fuzzing plus a standard repair agent — would have ranked in the top three of the final competition, so dependable execution, not novel analysis, is the near-term path to deployable autonomous security.","LLM-based vulnerability analysis earns its keep precisely where fuzzing is structurally weak: delta-mode code changes, indirect calls, grammar-constrained inputs, and guards such as regexes, encodings, and compression — the 22 beyond-fuzzing discoveries concentrate in exactly those cases.","Machine-generated patches must be treated as candidate fixes, not fixes: a large share pass every automated validation yet change behavior subtly or miss the root cause, so human review remains load-bearing.","Competition telemetry should be designed for retrospective analysis, not just live scoring; the paper's main analytical obstacle was unordered, incomplete execution traces that made per-technique attribution impossible.","Every finalist discovered at least one genuine zero-day — 25 distinct previously unknown vulnerabilities across ten projects, twelve of them patched — showing autonomous systems already contribute real discovery at scale."],"fun_headline_variants":["AIxCC: Uptime beat cleverness for cyber win","LLMs found bugs fuzzing missed, but human review remains","DARPA AI challenge: Stability trumped intelligence","AI cyber contest: Reliability, not reasoning, sealed victory","Study: LLMs found 25 zero-days, yet automation lags"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is the paper's causal attribution: that the 22 vulnerabilities found beyond parallel fuzzing were found thanks to LLM code understanding, rather than the non-LLM enhancements (concolic execution, directed fuzzing, grammars, dictionaries, better sanitizers) that several finalists also deployed — a distinction the paper does not test per vulnerability.","fun_headline_variants_meta":{"raw":{"variants":["AIxCC: Uptime beat cleverness for cyber win","LLMs found bugs fuzzing missed, but human review remains","DARPA AI challenge: Stability trumped intelligence","AI cyber contest: Reliability, not reasoning, sealed victory","Study: LLMs found 25 zero-days, yet automation lags"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000196,"raw_usage":{"total_tokens":1167,"prompt_tokens":683,"completion_tokens":484,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":427,"completion_tokens_details":{"reasoning_tokens":397}},"tokens_in":427,"tokens_out":484,"duration_ms":6415,"temperature":1.0,"reasoning_tokens":397,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T06:08:59.845693+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"An ablation on the 22 beyond-fuzzing vulnerabilities: run the relevant finalist pipelines with all LLM components replaced by deterministic substitutes while keeping their non-LLM enhancements; if a substantial share still yield triggering inputs, the 'LLM-driven code understanding' attribution fails. A check already available in the paper's data: tabulate which teams produced each of the 22 finds — the most fuzzing-centric finalist had the second-highest discovery score, so the distribution alone would indicate how much of the effect is genuinely LLM-attributable.","supporting_citations":[],"review_version":2}