A threshold has been reached for vulnerability reporting, and the curl project is sounding the alarm over a surge of AI-assisted submissions that its maintainers describe as “AI slop.” The open source tool’s leadership says the flood of AI-generated reports is not only unhelpful but actively disruptive, threatening to overwhelm a project that has stood for a quarter of a century as a bedrock utility for interacting with Internet resources. The tension underscores a broader debate in the software ecosystem: how to harness AI to improve security research without letting noise, inaccuracies, or deceptive prompts dilute the quality of vulnerability disclosures. What began as a routine process for curl to triage and address issues has turned into a tense, high-stakes test of governance, tooling, and community norms in open source security reporting.
The Threshold, the DDoS Metaphor, and the Stance of curl’s Founder
Curl, also known as cURL in some contexts, reached a notable milestone by turning 25 years old in 2023 and remains a foundational command-line tool and library for interacting with Internet resources. Its ongoing health depends on a steady flow of quality bug reports and security issues directed through multiple channels, notably including HackerOne, a reporting service that helps organizations manage vulnerability disclosures and bug bounty programs. The landscape around vulnerability reporting has grown more complex in recent years as AI-enabled tools have proliferated, offering new capabilities to researchers while raising questions about report quality, reproducibility, and the reliability of AI-generated content. On LinkedIn this week, curl’s original author and lead maintainer, Daniel Stenberg, articulated a stark perspective: “A threshold has been reached. We are effectively being DDoSed. If we could, we would charge them for this waste of our time.”
Stenberg’s comments frame a broader concern about the administrative and engineering burden posed by a deluge of reports that may rely on AI to identify or craft vulnerabilities. The curl project’s history, deeply rooted in open-source collaboration, makes this issue especially acute. Curl’s scope extends beyond a single tool: it represents a long-standing ecosystem of developers who have built, tested, and maintained a sophisticated suite of utilities used by countless organizations and individuals to retrieve and manipulate HTTP resources, FTP endpoints, and other networked services. The project’s 25-year trajectory underscores a culture of meticulous disclosure and careful triage, which now faces disruption from AI-assisted submissions that critics argue often lack the rigor necessary to substantiate real security risks.
Stenberg’s public stance—characterized by determination to curb what he described as “crazy” submissions—centers on a proposed verification process for reports suspected to be generated with AI assistance. His plan, as outlined, would require reporters to confirm whether AI tools were used to discover the issue or to generate the submission. If a report is deemed “AI slop,” the implication is that the reporter would be banned from the vulnerability-disclosure channel. The rhetoric is pointed and uncompromising: “We still have not seen a single valid security report done with AI help.” These words reflect a deep skepticism about the reliability of AI-generated vulnerability reports, particularly when AI is used to compile or summarize issues rather than to drive solid, verifiable findings through rigorous methodology.
This stance has implications that ripple outward: it signals to the broader security community that a portion of AI-assisted disclosures may fail to meet the standards curl applies to its vulnerability intake, standards that are designed to protect users and maintainers from false positives, misrepresentations, or speculative claims. It also raises questions about how to implement governance across a distributed, volunteer-driven project without dampening legitimate innovation or discouraging researchers, especially those for whom language barriers or resource constraints make it harder to produce perfectly polished reports in English. The tension at curl highlights the broader risk: when AI becomes part of the vulnerability-disclosure workflow, maintaining trust requires careful curation, transparent criteria, and robust processes that prevent low-quality submissions from eroding the reliability of the ecosystem.
In this moment, curl’s leadership asserts a protective stance: preserving the project’s time and resource budgets by enforcing higher standards for AI-assisted submissions while continuing to welcome high-quality, human-driven security research. The emphasis is not on halting AI research or hindering legitimate vulnerability discovery; rather, it is on ensuring that AI technologies augment human researchers without compromising the integrity and efficiency of the disclosure pipeline. The underlying question is how best to integrate AI into open-source security workflows so that it elevates the signal-to-noise ratio rather than inflating the noise level.
The Vulnerability-Disclosure Landscape, AI Tools, and HackerOne’s Role
HackerOne sits at the nexus of modern vulnerability reporting and crowd-sourced security research. The platform has evolved into a central hub where researchers, vendors, and security teams coordinate the discovery, validation, and remediation of security vulnerabilities. In recent years, the service has leaned into AI-driven tooling, reflecting a broader industry trend: AI is increasingly embedded in the workflow of vulnerability research, triage, and patch generation, with promises of higher efficiency and broader reach. The firm’s homepage has embraced this dual approach—presenting AI as a force multiplier for human researchers, a characterization that aligns with a growing expectation that AI can accelerate discovery and improve coverage across diverse linguistic backgrounds and skill levels. The platform’s positioning is that AI can empower researchers, speed up analysis, and help scale the impact of security work, particularly for researchers who rely on English as a second language or who face constraints in time and resources.
HackerOne’s leadership has repeatedly sought to balance the opportunity and the risk inherent in AI-assisted submissions. In a statement to Ars Technica, Alex Rice—co-founder, chief technology officer, and chief information security officer of HackerOne—emphasized that reports containing hallucinated vulnerabilities, vague or incorrect technical content, or other low-effort noise are treated as spam and subject to enforcement. He framed AI as a powerful tool when used responsibly, capable of enhancing researchers’ productivity, scale, and impact. Rice noted that innovation in AI-enabled security research is accelerating and that the company supports researchers who use AI to improve the quality and efficiency of their work. He also stressed that, while the aggregate trend shows AI helping researchers bring clarity to their work—particularly for non-native English speakers—the objective remains to ensure AI strengthens the report rather than introducing noise.
The nuanced stance from HackerOne underscores a broader industry debate: AI can lower barriers to entry and broaden participation in vulnerability discovery, but it can also introduce hallucinations, misinterpretations, and superficial findings if not properly governed. The emphasis on maintaining uniform high standards across submissions suggests a path forward where AI serves as an assistive tool—able to structure and translate complex technical information, but constrained by automated checks, verification steps, and human review to prevent the degradation of report quality. In this framing, AI functions as a force multiplier, but not as a substitute for rigorous method, reproducibility, and careful validation of security assertions.
Curl’s leadership welcomed this shift in conversation as a timely opportunity to reexamine how AI should interact with vulnerability reports, especially within open-source ecosystems that rely on transparency and reproducibility. The curl team views AI-enhanced reporting as potentially beneficial when harnessed correctly, but they remain wary of the pitfalls described by AI researchers themselves, including the propensity for AI to facilitate the creation of plausible-sounding but technically inaccurate content. The tension between AI’s potential and the risk of noise has become a focal point for many open-source maintainers, who must balance inviting broader participation with preserving the reliability of the vulnerability intake pipeline.
The broader open-source security community is watching how AI-based tools will shape vulnerability disclosure norms. Advocates point to the possibility that AI can help identify patterns across thousands of reports, enable faster triage, and assist researchers who may have limited time or language proficiency to articulate findings clearly. Critics counter that AI-generated content can misrepresent risks, misapply vulnerability patterns, or fail to account for the intricacies of specific codebases, libraries, or protocol stacks. The curl controversy captures this tension vividly: the project’s leadership wants to ensure that AI-borne submissions reinforce, rather than compromise, the integrity of vulnerability disclosures that affect critical software infrastructure.
The May 4 incident added a practical dimension to the debate. A report alleged a novel exploit leveraging stream dependency cycles in the HTTP/3 protocol stack, a vulnerability class that could enable remote code execution in worst-case scenarios. Curl’s maintainers noted that the patch file referenced in the submission did not apply to the latest versions of a Python tool used by the reporter. In a sequence of exchanges that read like a cautionary tale for AI-assisted security reporting, the reporter responded in a manner that resembled an automated, prompt-driven dialogue rather than a traditional, interactive bug report. They answered questions not posed by curl staff, and they included what appeared to be basic instructions on how to apply a patch using Git. They failed to supply a new patch file, and they cited functions that do not exist in the underlying libraries, while suggesting hardening strategies for tools other than curl. The curl team ultimately closed the report but chose to publish the submission publicly to illustrate the kinds of AI-generated inputs they were seeing and why the quality, governance, and verification processes matter.
This sequence—alleged AI-generated exploit content, a mismatch with current tooling, and a flagged attempt at guiding the maintainers away from curl’s domain—served as a concrete example of how AI-generated reports can diverge from the reality of a project’s codebase and its modern dependencies. It also highlighted the need for robust triage workflows that can rapidly identify when an AI-generated submission lacks credibility, does not align with current versions, or relies on non-existent or misnamed API calls. In practice, the curl team’s approach demonstrates how to curate reports in a way that maintains the project’s security posture while not stifling legitimate researcher participation.
The May 4 Report: Details, Implications, and Technical Context
The narrative around the May 4 vulnerability report centers on a claim of a novel exploit in the HTTP/3 stack tied to stream dependency cycles. For readers and practitioners, it is important to unpack what stream dependency means in the context of modern HTTP implementations. In many software systems, a stream dependency graph describes how one operation or data flow depends on the outcome of another. If the dependency chain is mishandled, the program can be exposed to synchronization issues, race conditions, or data-injection vulnerabilities. In the HTTP/3 environment, where multiplexed streams operate concurrently over a single connection, the possibility exists that mismanaging stream priorities, cancellations, or simultaneous data flows could lead to conditions where an attacker could influence the behavior of a client or server, potentially enabling the execution of arbitrary code on a vulnerable host—an outcome that cybersecurity researchers would classify as remote code execution in the worst case.
Curl’s maintainers acknowledged that the report described a vulnerability with theoretical implications for HTTP/3-enabled curl deployments. They noted that the patch file provided by the submitter did not correspond to the latest version of a Python tool referenced in the report. This discrepancy raised questions about whether the claimed exploit could be reproduced or even validated against current curl releases. The exchange underscored the critical need for precise, version-aligned evidence when describing security issues that could affect widely used software components. Without reproduction steps that align with current software states, the risk is that such reports may mislead users or divert attention from genuine, verifiable vulnerabilities that pose real risk to systems.
The submitter’s approach in this particular case also drew scrutiny for its communication style. There were indications of prompt-like interactions, with the submitter answering questions in a way that did not match the investigative process curl staff expected. The respondent’s message included rudimentary guidance on applying patches via Git and asked questions about cyclic dependencies—topics that curl staff considered outside the scope of the report’s stated aim. The mismatch between the report’s content and curl’s current tooling, combined with the absence of a concrete patch tailored to the latest code, contributed to the report’s eventual closure. In the eyes of curl’s maintainers, this sequence demonstrated why automated AI-generated content, if not properly anchored to the project’s versioned code and the current state of dependencies, risks generating misinformation that wastes the time of volunteers and maintainers.
Nevertheless, curl’s decision to publish the report as an example served a dual purpose. It provided a transparent, real-world case study of AI-generated vulnerability content and illustrated the kinds of issues that can arise when AI writes or assembles technical submissions without sufficient domain-grounded checks. The public disclosure—distinct from typical private triage processes—was intended to educate the community on the gaps between AI-generated content and verified security findings, and to underscore the necessity of rigorous verification, reproducibility, and alignment with current software stacks. This approach aligns with the broader objective of maintaining integrity in vulnerability disclosure pipelines and ensuring that AI-assisted tools contribute to, rather than detract from, credible security research.
The Human and Organizational Reactions: Reassessing AI’s Role in Open Source Security
Industry voices, including those at HackerOne and others in the security community, have weighed in on the broader implications of AI-generated vulnerability disclosures. Alex Rice’s remarks emphasize a balanced, standards-driven approach: AI can be a powerful assistive technology, but it must not erode the quality of reports. The claim that AI can improve report quality—especially for researchers whose first language is not English—frames AI as a potential bridge to greater participation and more comprehensive disclosures. Yet the insistence on safeguarding report quality means that AI-generated content requires stricter validation, better integration with project versioning, and more robust verification steps. The goal is to realize the benefits of AI—such as more rapid triage, clearer summaries, and scalable analysis—without letting the system become overrun with hallucinations and low-effort noise.
Stenberg’s reaction to the ongoing discourse reflects a combination of pragmatism and urgency. He told Ars Technica that the post’s wide circulation and engagement—roughly 200 comments and nearly 400 reposts as of a given morning—are a positive sign that the community is paying attention to the issue. His conclusion remains that large-language models (LLMs) cannot reliably identify security problems in the way that human researchers can, at least not with the current usage patterns described in AI-generated submissions. This sentiment has resonated with other developers in the space, who worry about AI’s ability to parse complex codebases, reconstruct reproducible steps, and verify underlying conditions needed to demonstrate a vulnerability. The problematic trend is visible in real-world examples where AI-generated reports present polished prose and plausible narratives that, upon closer inspection, do not align with actual security risks in existing code.
The phenomenon has spurred discussions about the characteristics of AI-generated vulnerability reports. Stenberg pointed to four such reports in a single week that appeared to be AI-assisted and potentially misguided, with one notable example where the prompt supposedly instructed the AI to “sound alarming.” He suggested that a human would never produce such a well-formed yet ungrounded report as a first attempt, highlighting the difference between human-authored vulnerability research—grounded in reproduction, testing, and verifiable impact—and AI-generated drafts that can misrepresent dependencies or patch-status. These observations have fueled a broader call within the community for more careful deployment of AI tools, including governance mechanisms, process checks, and, perhaps, new features within vulnerability-disclosure platforms to filter, verify, and validate AI-assisted inputs before they are accepted into the official bug-bounty or vulnerability-triage pipelines.
In parallel, other voices in the community have proposed concrete steps to improve the ecosystem’s resilience against AI-generated noise. Tobias Heldt, from the open-source security firm XOR, suggested leveraging existing networks and infrastructure to strengthen the verification layer in bug-bounty programs. One idea discussed in the online discourse is for security researchers to post a form of assurance—such as a bond or a verifiable submission statement—when submitting for review, in order to help separate signal from noise and to signal a commitment to rigorous validation. The broader proposal envisions a governance enhancement where bug-bounty programs and vulnerability-disclosure platforms implement mechanisms that better differentiate high-quality, reproducible reports from AI-generated prompts that lack substantive technical grounding. Stenberg’s involvement in the conversation and his engagement with practitioners across the ecosystem reflect a growing awareness that AI’s role in security research must be regulated by a combination of policy, tooling improvements, and community norms.
The response from HackerOne’s leadership further clarifies the industry position. The company’s stance acknowledges the potential benefits of AI in enabling researchers to articulate findings more clearly and to overcome language barriers, while simultaneously reaffirming a commitment to keeping the standard bar high for all submissions. HackerOne asserts that while AI can help researchers improve clarity, the system will continue to enforce existing standards and enforce enforcement actions when AI content fails to meet those standards. The tension between enabling broader participation and preserving rigorous, credible vulnerability disclosures remains central to ongoing policy debates in the vulnerability-disclosure space.
Stenberg has treated these discussions as invitations to action. He has expressed a desire for more robust public education around the use of AI in vulnerability discovery, along with stronger support from the vulnerability-disclosure platforms themselves to detect and filter AI-driven noise. His conversations with AI researchers and security professionals around AI’s limitations in identifying security weaknesses have emphasized that human oversight remains essential. The sense in the community is that AI, if harnessed with thoughtful governance, can augment security research; but without proper controls, it risks undermining the trust that underpins responsible disclosure and the collaborative repair of critical software. The curl case illustrates a broader truth: AI is not a silver bullet for security; it is a tool that can either raise the floor of reporting quality or become a source of confusion, depending on how it is deployed and governed.
The Path Forward: Tools, Standards, and Policy Implications for Open Source Security
The ongoing conversations around curl’s AI-related vulnerability submissions highlight several actionable considerations for the wider open-source and vulnerability-disclosure communities. First, there is a clear need for stricter alignment between AI-assisted reports and the current software stack. A vulnerability described for an HTTP/3 implementation must be testable against the latest releases, with precise reproduction steps and patched code that actually exists in the targeted version. This alignment reduces the risk of expending energy on non-existent or outdated constructs and ensures that security concerns address real, verifiable weaknesses in the codebase. It also helps maintain trust with users who rely on the project for secure networking capabilities.
Second, there is merit in enhancing the tooling around vulnerability submissions to detect and flag potential AI-generated content that may not reflect actual technical risk. This could include automated checks for patch-version alignment, validation against the project’s public code, verification of cited functions and APIs, and checks for plausibility in the described attack scenario. The goal is not to suppress AI’s benefits but to ensure that AI proves itself by adhering to the same standards of evidence and reproducibility that human researchers are expected to meet. For maintainers, this translates into a more efficient triage process, since AI-assisted submissions would be filtered through objective checks before they reach human analysts.
Third, governance models for AI in vulnerability reporting require careful design. Platforms like HackerOne may need to refine their workflows to incorporate AI content governance—potentially including mechanisms such as validated prompts, transparent provenance of AI-generated text, and a clear policy on the use of AI in submissions. The aim is to empower researchers who use AI responsibly while reducing the likelihood that AI-generated content creates noise that can mislead or delay remediation. Implementing such policies could involve programmatic checks, human-in-the-loop verification, and explicit criteria that differentiate AI-assisted drafts from independently verified vulnerability reports.
Fourth, the curl experience underscores the importance of education and community engagement. It is essential to cultivate a shared understanding among maintainers, researchers, and platform operators about what constitutes a credible vulnerability in practice and how AI can be used to improve not only writing quality but the underlying analysis, replicateability, and impact assessment. The community would benefit from clear guidelines, best practices, and case studies that illustrate how AI can be used to enhance vulnerability discovery without compromising the rigor and accuracy required for responsible disclosure.
Fifth, the broader security ecosystem should consider innovation in incentive structures that encourage high-quality AI-assisted research while deterring low-effort or misaligned submissions. As Heldt suggested, exploring approaches such as bonding or reputation-based mechanisms could serve as filters to distinguish serious vulnerability reports from noise. If implemented thoughtfully, such mechanisms can encourage researchers to invest time in rigorous verification and reproducible findings, while providing maintainers with a faster way to triage and validate claims. This approach aligns with the overarching objective of improving security outcomes while maintaining fairness and process integrity across bug bounty programs and vulnerability-reporting platforms.
The curl episode also emphasizes the continued importance of human expertise in security research. While AI can accelerate analysis, categorize issues, and help researchers draft clearer reports, it cannot (yet) replace the nuanced understanding that comes from hands-on testing, code review, and environment-specific replication. The community’s ongoing dialogue reflects a recognition that AI tools should be integrated as accelerants for human investigators—not as substitutes for the careful, reproducible work that underpins credible vulnerability disclosures. As open source software continues to underpin critical infrastructure, the need for robust, well-governed processes becomes ever more important.
In the broader arc of curl’s history, this moment is a reminder that maturity in open-source projects hinges on both technical excellence and governance discipline. Curl’s maintainers have repeatedly proven their commitment to responsible disclosure, thorough triage, and transparent communication with users. The AI-related tension reveals how even well-established projects must adapt to evolving tools and practices in the security research landscape. The path forward is likely to involve a combination of stricter verification, enhanced tooling, clearer governance policies, and continued education about the proper use of AI in vulnerability reporting. If the community can align on these elements, AI may eventually contribute positively to the security ecosystem—improving the speed and clarity of legitimate vulnerability disclosures while keeping the integrity and trust that underpins open-source collaboration.
The conversations also reflect the evolving role of AI within the security domain: from a novelty to a critical component of research, triage, and communication. The tension between AI-driven productivity and the risk of noise is not unique to curl; it echoes across many open-source projects, bug bounty programs, and vulnerability-disclosure platforms. The episode invites developers, researchers, and platform operators to reexamine processes and to adopt more sophisticated, yet practical, governance models that can harness AI’s benefits while mitigating its downsides. It is a reminder that in the realm of security, quality assurance and reproducibility matter as much as speed and scale—and that AI’s true value will be measured not by how quickly it can generate text, but by how reliably it helps reveal and remediate real weaknesses in software that billions rely upon.
The Continued Dialogue: Updates, Community Voices, and Next Steps
This article’s developments include an acknowledgment of an update to the record: the post was updated to include a comment from HackerOne. The ongoing dialogue reflects the dynamic nature of AI’s role in vulnerability research and how platforms, researchers, and maintainers respond to new patterns of submissions. The evolving narrative demonstrates that AI-assisted vulnerability reporting will continue to be scrutinized, refined, and integrated into security workflows as best practices emerge. The community’s willingness to engage, ask hard questions, and propose practical solutions is a critical input into shaping how vulnerability disclosures will be handled in the future.
The broader media coverage around this topic includes reporting by veteran technology journalists who cover open-source software, PC gaming and home automation, with a long history of examining how AI intersects with software security. These discussions emphasize the need for credible, reproducible, and verifiable vulnerability disclosures while also recognizing the value that AI can bring in terms of clarity, scale, and accessibility for researchers worldwide. The curl case, in particular, underscores the importance of maintaining high standards in vulnerability reporting, even as AI tools become more prevalent and capable. The balance between openness and rigorous validation remains at the heart of responsible vulnerability disclosure in open-source ecosystems.
This ongoing conversation also illustrates the role of individual researchers—such as Stenberg and his collaborators—in shaping policy and practice through public discourse, blog posts, and direct engagement with vulnerability-disclosure platforms. It is through such public-facing dialogue that communities learn and adapt, establishing norms and best practices that future researchers can follow. The exchange with HackerOne and the diversity of perspectives across the security landscape contribute to a more nuanced understanding of how AI can be harnessed to benefit security research without compromising the reliability and trust that users rely on.
The curl narrative demonstrates that even well-established tools must continuously adapt to a rapidly evolving technological environment. The project’s leadership has made clear that they will push for stronger controls against AI-induced noise and will seek collaborative solutions with vulnerability-disclosure platforms to improve the infrastructure around AI tools. The aim is to create a cybersecurity reporting framework in which AI acts as a force multiplier for high-quality, reproducible research, while maintaining the integrity of vulnerability disclosures that protect users worldwide.
Conclusion
The curl situation spotlights a pivotal moment in the intersection of open-source software, vulnerability disclosure, and artificial intelligence. It underscores the need for rigorous verification, robust governance, and clear communication about how AI is used in vulnerability research. The discussions surrounding the May 4 report, the patch mismatches, and the response from HackerOne reveal both the opportunities and the hazards of AI-assisted vulnerability submissions. As curl and the broader open-source community navigate this terrain, the focus remains on preserving the quality and reliability of security disclosures while ensuring that AI can contribute meaningfully to faster, clearer, and more effective remediation. The path forward will likely involve enhanced tooling for validation, stronger governance policies, and continued education—together with a commitment to the human-centered, meticulous approach that has long defined responsible vulnerability research in open-source ecosystems.
