curl Project Exposes AI Code Auditing Shortcomings: 6 CVEs Found by Humans After AI Detected Zero

A Reality Check for AI Security Auditing

The well-known open-source project curl, after undergoing AI-assisted security auditing, revealed a thought-provoking result: AI models from both OpenAI and Anthropic found zero vulnerabilities in their initial audit, yet subsequent human review uncovered 6 CVE-level security issues. This incident throws cold water on the current hype around AI code auditing and compels the industry to reassess the boundaries of AI's applicability in the security domain.

curl is a widely used command-line tool and library for transferring data via various network protocols. Created by Swedish developer Daniel Stenberg in 1998, curl has over 25 years of history and supports dozens of network protocols including HTTP, HTTPS, FTP, SMTP, and more. It's estimated that curl is installed on over 20 billion devices — virtually every operating system, embedded device, and internet service depends on it directly or indirectly. Its underlying library, libcurl, is integrated into countless software projects. As a critical piece of internet infrastructure, its security is paramount. The curl project has long operated a bug bounty program through platforms like HackerOne and has historically fixed hundreds of security issues. The project maintainers' decision to conduct a security audit using the most advanced AI models available was a proactive attempt to explore AI-assisted development within their continuous security improvement framework — but it unexpectedly exposed glaring shortcomings of AI in complex security scenarios.

Why AI Came Back with "Zero Findings": A Systemic Challenge

As leading companies in the AI space, OpenAI and Anthropic have models that genuinely excel at code understanding and generation. However, in the curl project's security audit, both AI systems turned in a "zero findings" scorecard. This wasn't a fluke — it exposed systemic challenges that AI faces in the security auditing domain.

Discovering security vulnerabilities requires deep contextual understanding, keen awareness of edge cases, and comprehensive knowledge of attack vectors. Current AI code auditing primarily relies on the code comprehension capabilities of large language models (LLMs), feeding source code into models for static analysis. This approach is fundamentally based on reasoning from the vast number of code patterns and known vulnerability samples the model learned during training. However, it differs fundamentally from traditional static analysis tools (such as Coverity and CodeQL) and dynamic analysis techniques (such as fuzz testing and symbolic execution). Traditional tools trace variable states through precise data flow and control flow analysis, while fuzz testing generates massive amounts of random inputs to trigger abnormal behavior. LLM analysis is closer to "reading comprehension" — it understands the surface-level semantics of code but struggles with precise state tracking across files and function call chains, and it cannot actually execute code to discover runtime vulnerabilities the way fuzz testing does.

While AI models can identify common code patterns and known vulnerability types, they often fall short when facing complex logic bugs, race conditions, or security issues requiring multi-layered reasoning. The 6 CVEs found in the curl project likely involved deep issues such as memory management, protocol parsing, or concurrency handling — areas that are difficult to cover through traditional pattern matching. Notably, curl is written in C and has over 150,000 lines of code. C's manual memory management characteristics make it inherently prone to buffer overflows, use-after-free, double-free, integer overflow, and other memory safety issues. These vulnerabilities often lurk in complex conditional branches and error handling paths, triggered only under specific input sequences and state combinations. For example, a buffer overflow might only occur when a specific field of a particular protocol exceeds a certain length threshold while a particular connection state simultaneously exists. This kind of "combinatorial explosion" scenario — requiring multiple conditions to align — is precisely why AI models struggle to detect such issues through pattern matching alone.

It's worth explaining what the CVE system means here. CVE (Common Vulnerabilities and Exposures) is a global vulnerability identification system maintained by MITRE Corporation, where each CVE number corresponds to a confirmed, independent security vulnerability. Receiving a CVE number means the vulnerability has been formally recognized by the security community and cataloged in public databases such as the National Vulnerability Database (NVD). CVEs are typically rated for severity using CVSS (Common Vulnerability Scoring System), on a scale from 0 to 10. Six CVE-level security issues means these aren't simple code quality problems — they are real security threats that could potentially be exploited by attackers for remote code execution, information disclosure, or denial of service.

Even more concerning is the misleading effect of AI's "confident" output. When an AI system reports "no issues found," developers can easily develop a false sense of security, which in turn lowers the priority of manual review. This "AI endorsement" effect is particularly dangerous in the security domain — it can allow real vulnerabilities to remain hidden for extended periods.

Human-AI Collaboration Is the Optimal Approach to Security Auditing

This incident isn't meant to entirely dismiss AI's value in security — rather, it clarifies its proper role: AI should serve as an assistive tool, not a replacement. In the code auditing workflow, AI can efficiently handle a large volume of foundational checks — syntax errors, known vulnerability pattern matching, coding standard violations — thereby saving security experts time and allowing them to focus on complex problems that require deep thinking and creative reasoning.

In practice, mature security auditing follows a multi-layered methodological approach. Beyond code review, it includes Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), penetration testing, and other techniques. Each method has its own coverage and blind spots; combining them is the only way to minimize false negatives. AI should be a new layer within this multi-layered system, not an attempt to replace the other layers.

Future AI security tools need continuous improvement in three directions:

• Contextual understanding: Enhance understanding of project-specific context, including historical vulnerability patterns, codebase evolution, and domain-specific risks. For example, the curl project has historically experienced multiple vulnerabilities related to URL parsing and certificate validation. If AI could learn from these historical patterns, it might more effectively target similar code paths.
• Explainability: Let auditors clearly understand AI's reasoning process and inspection coverage. When AI reports "no vulnerabilities found," it should simultaneously provide a checklist of the attack surfaces examined and explain which areas it couldn't cover, rather than offering a blanket "secure" conclusion.
• Capability boundary labeling: Clearly inform users which types of issues AI excels at finding and which still require human intervention. For instance, AI may be adept at finding injection vulnerabilities like SQL injection and XSS, but may have limited capability with logic bugs and business-level authorization bypasses.

In recent years, the rise of memory-safe languages like Rust has addressed the security challenges of C-language projects from another angle. The curl project itself is exploring the possibility of gradually introducing Rust, using language-level guarantees to eliminate entire classes of memory safety vulnerabilities. This "prevention over detection" philosophy complements AI auditing.

The curl project's case reminds the open-source community and enterprises alike: in security auditing of critical infrastructure, you cannot over-rely on any single tool or method. A multi-layered auditing strategy — combining automated tools, AI-assisted analysis, and manual review by senior security experts — remains the most reliable practice today. AI's role should be to amplify human experts' capabilities, not to replace their judgment.

Technical Boundaries and Accountability: Who Pays for AI False Negatives?

This incident also raises a deeper question: when AI tools are used in security-critical scenarios, who should be held responsible for false negatives? The AI service provider, the developer using the tool, or the project maintainer? The industry has yet to reach consensus, but one thing is clear — over-marketing AI capabilities without adequately disclosing their limitations may create both legal and ethical risks.

This issue ties into the broader AI governance discussion. The EU's AI Act has classified safety-critical infrastructure as a high-risk AI application category, requiring providers to meet stringent requirements around transparency, traceability, and human oversight. NIST in the United States has also emphasized clear labeling of AI system capability boundaries in its AI Risk Management Framework. In the software security domain, compliance frameworks such as SOC 2 and ISO 27001 still center on human auditing as a core requirement, and AI tool audit results are generally not accepted as compliance evidence. This means that even if enterprises use AI auditing tools, they still need to go through traditional audit processes to satisfy regulatory requirements. In the future, the industry will need to establish dedicated evaluation standards and certification systems for AI security auditing tools, clearly defining the legal status and accountability boundaries of AI tools in security auditing.

For developers, the key is to maintain a rational view of AI capabilities. Incorporating AI code auditing into development workflows is encouraged, but it must be paired with traditional testing, review, and verification methods. For AI providers, transparently labeling model performance boundaries across different tasks, and providing confidence scores and coverage reports, is essential for building healthier technical trust relationships.

The 6 CVEs ultimately discovered in the curl project remind us: in the security domain, there is a vast chasm between "looks fine" and "actually is fine." AI can help us approach answers more quickly, but bridging that final gap still requires human wisdom, experience, and sense of responsibility.