Antaeus: Hunting Repository-Level Logic Vulnerabilities via Context-Grounded LLM Reasoning

Source: arXiv:2607.01138 · Published 2026-07-01 · By Michele Armillotta, Nicolò Romandini, Rebecca Montanari, Lorenzo Cavallaro

TL;DR

This paper addresses the challenging problem of detecting logic vulnerabilities in large C/C++ repositories—bugs that violate application-specific security invariants rather than following known syntactic or dataflow patterns. Existing LLM-based detectors excel at memory-safety or dataflow bugs but struggle to identify these subtle logic flaws due to the implicit, repository-wide security assumptions involved. Antaeus presents a new framework that grounds LLM reasoning in explicit repository context by combining multi-stage function prioritization, local code augmentation, repository-level security summaries, structured reasoning about security-sensitive sinks and safety conditions, and comparative validation to distinguish genuine anomalies from project-wide norms. Evaluated on 28 real-world repos with confirmed logic vulnerabilities, Antaeus detects 15 issues and outperforms both function-level LLM analyses and powerful agentic baselines like Opus 4.8 and Codex 5.4, all while using comparable token budgets and cost. This work demonstrates that careful, evidence-grounded context inclusion significantly improves LLM detection of complex logic bugs that hinge on repository-specific invariants rather than local patterns.

Key findings

• Antaeus identified 15 confirmed logic vulnerabilities in 28 real-world C/C++ repositories, substantially more than function-level LLM analysis and frontier agentic baselines.
• Function prioritization using lightweight repo-wide signals effectively reduced the number of expensive LLM calls while maintaining recall for security-relevant functions.
• Local code augmentation with depth-one callee expansion and embedding repository-level security summaries enabled the LLM to ground reasoning in concrete project evidence rather than generic priors.
• Structured reasoning outputs included security-sensitive sinks, explicit safety conditions, and local satisfaction flags with code-bound justifications, improving explanation faithfulness and auditability.
• Comparative validation pruned false positives by discarding repeated unsatisfied safety conditions seen uniformly across similar sinks in the repository, differentiating anomalies from norms.
• Antaeus matched or stayed within the same token usage and cost budget as baseline models, showing that richer context grounding need not increase analysis expense.
• The method successfully recovered implicit security invariants distributed across a repo, overcoming challenges such as missing syntactic/dataflow anchors and buried non-local security checks.
• The pipeline design stages—prioritization, grounding, reasoning, validation, reporting—worked synergistically to improve precision in detecting logic vulnerabilities.

Threat model

The adversary interacts through intended software interfaces (APIs, config, command-line, network) and cannot alter program source code. Their attack consists of choosing inputs and execution contexts that violate implicit, application-specific security invariants to trigger unsafe operations, for example by bypassing authorization. The defender attempts static detection from source repositories without runtime information or exploit traces.

Methodology — deep read

The paper's core methodology revolves around a five-stage pipeline designed specifically to detect repository-level logic vulnerabilities characterized by implicit security invariants.

1. Threat Model & Assumptions: The adversary is assumed to exploit the software via intended interfaces (APIs, config, CLI args, network requests) without modifying the codebase. They can supply malicious inputs or call sequences violating safety conditions embedded implicitly in the repository. The detection assumes access to the full source repository but no runtime traces or execution environment. The goal is static detection of candidate logic vulnerabilities violating invariants, excluding memory-safety or purely syntactic bugs.

2. Data & Preprocessing: Experiments used 28 real-world C/C++ repositories with confirmed logic vulnerabilities mainly in the CWE-200 and CWE-284 classes (information disclosure and access control). Each repo was analyzed in its entirety. Functions were extracted, pruned, and compressed to create lightweight representations (signatures plus callees) for prioritization.

3. Architecture / Algorithm: Antaeus consists of: (a) Prioritization stage uses keyword heuristics and a compressed repo-level representation of all functions stripped of implementation logic but including callees, fed to an agentic LLM to rank functions likely relevant to logic vulnerabilities. (b) Context Grounding creates for each prioritized function a local augmentation bundle with: function code, direct callee bodies (depth one), macros, constants, typedefs, imports from the repo via a static analysis pass (Tree-sitter based). Additionally, a repo-level security context bundle is generated by prompting an LLM with the whole repository to summarize system purpose, principals, protected objects, outputs, and trust topology along with code evidence. Together these form explicit evidence grounding LLM reasoning. (c) Structured Reasoning queries the LLM constrained to identify security-sensitive sinks within a function, infer necessary safety conditions for their safe use, label each condition as locally satisfied or not, and justify with code or repo evidence, outputting fixed-format structured findings (sink, condition, satisfaction flag, explanation). This enforces faithful justification rather than free-form rationale. (d) Comparative Validation compares each candidate vulnerability condition with analogous sinks in the same repository using code embeddings (UniXcoder) and natural language embedding similarity (all-MiniLM-L6-v2) to detect whether unsatisfied conditions recur project-wide (norms) or are distinctive anomalies, pruning false positives accordingly. (e) Reporting generates triage-oriented structured reports linking sinks, violated conditions, and supporting evidence for human auditors.

4. Training Regime: The system primarily uses zero-shot or few-shot prompting of off-the-shelf LLMs (including agentic models Opus 4.8 and Codex 5.4) for prioritization and reasoning phases. Static analysis is deterministic. No training epochs or finetuning was performed. Hyperparameters focused on prompt construction, chunking repository data to fit transformer context limits (~4k tokens per chunk), and LLM temperature settings (not precisely specified).

5. Evaluation Protocol: The evaluation compared Antaeus to (i) function-level LLM analysis and (ii) frontier agentic models capable of repository navigation. Metrics focused on number of true detected vulnerabilities, explanation faithfulness, and cost measured by token usage and model calls. Candidate findings were manually inspected to confirm correctness and verify explanation consistency with grounded evidence. Comparative validation’s impact was assessed by the false positive reduction on candidate sets.

6. Reproducibility: While the paper does not explicitly mention released code or datasets, it uses publicly available repositories for evaluation and standard LLM APIs. Implementation relies on Tree-sitter for static analysis and widely used embedding models (UniXcoder, all-MiniLM-L6-v2). The method’s details enable replication given access to similar LLMs.

Concrete example: For libvirt’s CVE-2020-10701, function virDomainAgentSetResponseTimeout’s missing read-only check was detected by Antaeus by first prioritizing the function based on call signatures, then augmenting local code with callee bodies and macros, grounding reasoning in a repo-level security summary describing connection models and privilege distinctions, identifying the sink as a privileged configuration operation, formulating safety conditions requiring read-only checks, detecting the unsatisfied condition locally, and pruning unrelated uniform conditions across sibling APIs. This end-to-end pipeline illuminated the implicit security invariant violation and explained it concretely for triage.

Technical innovations

• A repository-level LLM reasoning framework (Antaeus) that grounds vulnerability detection in explicit local and repository-wide context rather than isolated code snippets or broad exhaustive search.
• A function prioritization step compressing the repository into a call-based representation and using a lightweight agentic LLM to rank security-relevant functions, balancing recall and efficiency.
• Local code augmentation bundles that expand each function with depth-one callees, macros, constants, and typedefs extracted via static analysis to anchor the model’s reasoning in precise program artifacts.
• A curated repository-level security summary generated once per repo, describing system purpose, principals, protected objects, outputs, and trust boundaries with code evidence to reconstruct implicit security invariants.
• Comparative validation using code and natural language embeddings to detect recurring, uniform unsatisfied safety conditions across similar sinks in the repo, thus pruning false positives by defining project norms.

Datasets

• 28 real-world C/C++ repositories with confirmed CWE-200 and CWE-284 logic vulnerabilities — size not precisely stated, sourced from public repositories with known CVEs.

Baselines vs proposed

• Function-level LLM analysis: vulnerabilities detected = fewer than 15 vs Antaeus: 15 detected
• Opus 4.8 Agentic baseline: vulnerabilities detected less than Antaeus with comparable token usage
• Codex 5.4 baseline: vulnerabilities detected less than Antaeus with comparable token usage and cost

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.01138.

Fig 1: Overview of the ANTAEUS five-stage pipeline: prioritization, context-grounding, structured reasoning, validation, and reporting.

Fig 2 (page 5).

Fig 3 (page 5).

Fig 4 (page 5).

Fig 5 (page 5).

Fig 6 (page 5).

Fig 7 (page 5).

Fig 8 (page 5).

Limitations

• Does not address memory-safety or syntactic vulnerability classes, focusing solely on logic vulnerabilities.
• Relies on static code and repository context, does not use runtime/exploit inputs or dynamic analysis to validate vulnerabilities.
• Only expands the call graph to depth one for local augmentation; deeper interprocedural dependencies might be missed.
• Comparative validation depends on embedding similarity thresholds, which may misclassify some project norms or anomalies.
• Evaluation covers 28 repositories; broader evaluation on more diverse projects and languages could strengthen conclusions.
• No explicit mention of open-source release limits reproducibility and independent benchmarking.

Open questions / follow-ons

• How would deeper interprocedural analysis beyond depth-onecallee expansion affect detection accuracy and context grounding?
• Can the comparative validation technique be extended to handle evolving codebases where project norms shift over time?
• How effective is Antaeus on other programming languages or logic vulnerability classes beyond CWE-200 and CWE-284?
• Could dynamic analysis or runtime monitoring complement the static, context-grounded approach to improve detection completeness?

Why it matters for bot defense

Logic vulnerabilities involving implicit, project-specific security invariants pose significant detection challenges for bot-defense and CAPTCHA enforcement systems, as unsafe access control or information disclosure can be invisible to pattern-based scanners. Antaeus’s approach highlights that incorporating comprehensive repository context and grounding reasoning in explicitly derived security assumptions enables more precise identification of subtle logic flaws. For bot-defense engineers, this underscores the limits of analyzing isolated code snippets or relying solely on generic vulnerability signatures in safeguarding CAPTCHA backends or related APIs. Instead, detection systems should leverage structured contextual summaries, augment local code with relevant project artifacts, and apply anomaly detection via comparative validation to reduce false positives. This work provides a concrete methodology for deploying LLM-based detectors that maintain security invariant awareness across large codebases while controlling computational costs, informing next-generation automated analysis tools in CAPTCHA-related security infrastructure.

Cite

@article{arxiv2607_01138,
  title={ Antaeus: Hunting Repository-Level Logic Vulnerabilities via Context-Grounded LLM Reasoning },
  author={ Michele Armillotta and Nicolò Romandini and Rebecca Montanari and Lorenzo Cavallaro },
  journal={arXiv preprint arXiv:2607.01138},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.01138}
}

Read the full paper

• arXiv:2607.01138 (abstract)
• arXiv:2607.01138 (PDF)