Apple Rate-Limits AI-Generated Vulnerability Reports

Apple is adding a “traffic valve” to the channel security researchers use to submit vulnerability reports.

According to information Apple disclosed to the Financial Times, the company adjusted its internal vulnerability submission process in June this year: it limited the number of new reports each researcher can have open at the same time and introduced a 30-day cooldown period. If the default quota is insufficient, researchers must separately apply for a higher limit. Apple’s reason is straightforward—large volumes of low-quality reports produced by generative AI are consuming the security team’s review capacity.

By August 2, the change had already exposed a rather ironic outcome: AI may indeed help researchers find genuine vulnerabilities faster, but when everyone can mass-produce reports that “look like vulnerabilities,” the risks that truly matter are more likely to be buried in the noise.

This problem is not unique to Apple. It is a process overhaul that the software industry will inevitably have to confront as AI-assisted programming becomes widespread.

Apple Is Limiting the Review Queue, Not AI

Apple has not prohibited researchers from using AI, nor has it announced that it will reject reports generated with AI assistance. Instead, it has adopted a more typical platform-governance approach: controlling access and limiting concurrency.

The rules currently available to the public include:

• Each researcher may have only a limited number of new vulnerability reports open at the same time;
• After reaching the limit, the researcher must wait through a cooldown period of up to 30 days;
• Researchers may apply for a higher quota so they can continue submitting reports;
• Every report is still ultimately reviewed and confirmed by a human;
• Apple is also using AI to assist with processing and triaging new reports.

Apple has not disclosed the exact default quota, nor has it explained the processing time for quota increase requests, the criteria used to prioritize them, or whether urgent vulnerabilities can automatically bypass the cooldown period. These details will determine whether rate limiting serves as an effective spam filter or becomes a new bottleneck in the responsible disclosure process.

From Apple’s perspective, rate limiting is not difficult to understand. Vulnerability reports are not ordinary support tickets that can simply be closed after keyword matching. Reviewers typically need to confirm affected versions, reproduce triggering conditions, trace call chains, assess the prerequisites for exploitation, and determine whether a flaw can be combined with others to form an exploit chain. The more authentic a report appears, the more expensive it may be to validate.

And AI is particularly good at producing exactly this kind of content: “complete in format, correct in terminology, and questionable in its conclusions.”

A model can write a security report complete with a risk rating, attack path, pseudocode, and remediation recommendations within minutes. But if the submitter has not actually reproduced the issue, the function names, privilege boundaries, or system behavior described in the report may simply have been filled in by the model based on context. Proving that a report is genuine may require a reviewer to set up an environment and reproduce the issue step by step; proving that it is false can likewise take hours of ruling out every possibility.

This creates a clearly asymmetric cost structure: generating a report costs almost nothing, while disproving one still requires the time of specialized engineers.

In practice, this closely resembles an application-layer DDoS attack against the security response process. The only difference is that what arrives is no longer network packets, but a stream of confidently worded, neatly structured Markdown documents.

Low-Quality Reports and Genuine Breakthroughs Are Arriving Together

Italian cybersecurity startup Bynario is the other party in this controversy. The company says its team used OpenAI’s ChatGPT to discover more than 50 vulnerabilities in the latest version of macOS within three weeks, including a privilege-escalation exploit chain.

If Apple ultimately confirms this claim, it would be significant. Privilege escalation means an attacker may be able to break through system boundaries from a restricted account or process and obtain higher privileges. When multiple vulnerabilities are chained into a complete exploit, an attacker may even be able to take further control of the device.

For now, however, two concepts need to be distinguished: Bynario’s claim that it discovered vulnerabilities does not mean Apple has reproduced and rated all of them. In particular, until Apple completes its review, outsiders cannot determine how many of the “more than 50” findings are independent vulnerabilities, duplicate issues, low-risk flaws, or model misjudgments.

Bynario says the submission limit has prevented it from promptly sending Apple all of the serious issues it found. Apple responded that it had contacted Bynario and was reviewing the information the company submitted.

This conflict shows that while simple per-account rate limits can reduce the total volume of junk reports, they may not identify which reports are valuable. A newly registered researcher with no reputation history may be submitting model hallucinations—or may genuinely possess an undisclosed critical exploit chain. Until the first round of technical validation is complete, the two look very similar within the system.

This is also the greatest weakness of Apple’s current approach: it controls the queue based on “who has submitted how much,” rather than allocating review resources according to “how much verifiable evidence each submission contains.”

Vulnerability Discovery Has Become Cheaper; Validation Has Not

In the past, the barriers to vulnerability research included reverse engineering, debugging, fuzz testing, knowledge of system architecture, and extensive manual experimentation. Generative AI has not eliminated these requirements, but it has substantially reduced the cost of the surrounding work.

Researchers can ask models to assist with:

• Reading enormous codebases and decompiled output;
• Finding dangerous APIs, incorrect privilege checks, and boundary conditions;
• Generating fuzzing inputs and test scripts;
• Categorizing crash logs, system calls, and patch differences;
• Organizing scattered clues into more complete attack hypotheses.

For mature teams, this is a productivity tool. AI can act like a fast but unreliable junior analyst, identifying potentially valuable leads before human researchers reproduce them, remove duplicates, and assess the conditions required for exploitation.

The problem is that a growing number of submitters skip the second half of this process. They package the model’s statement that “a vulnerability may exist” directly into a formal report that vendors are expected to investigate, effectively outsourcing their internal validation work to Apple, open-source maintainers, or bug bounty platforms.

Economic incentives amplify this behavior. As long as the cost of bulk submissions is low enough, submitters may consider the strategy worthwhile even if the vast majority of reports are invalid, provided that an occasional report identifies a vulnerability eligible for a bounty. For vendors, however, every false positive still incurs a fixed review cost.

Earlier this year, cURL founder Daniel Stenberg shut down the long-running bug bounty program. He described AI-generated bogus reports as a DDoS attack against open-source projects: maintainers were not facing smarter attacks, but a sudden surge in noise. Apple has a larger budget and dedicated teams, but it cannot expand its human review capacity without limit either.

Apple’s rate limit is therefore more of an industry signal: after AI accelerates software development, the first resource to become scarce is not code, but people capable of determining whether code and security conclusions are correct.

Submission Caps Alone Treat the Symptoms, Not the Cause

Apple’s cooldown period can quickly reduce pressure on the queue, but it is not an ideal long-term solution. What security response systems truly need is to “raise the cost of fabricating evidence,” rather than merely limiting how often everyone can submit reports.

A vulnerability report entering the high-priority queue should provide at least enough machine-verifiable material, such as the exact version of the affected system, a minimal reproducible example, crash logs, a call stack, a before-and-after comparison of privilege changes, environment configuration, and an explanation showing that the issue is not intended behavior. If a report claims privilege escalation, it should also clearly specify the initial privileges, trust boundaries, user-interaction requirements, and the final privileges obtainable.

Vendors could use this information to establish tiered submission channels:

1. General Leads Queue: Accepts suspected issues that have not yet been fully validated, but does not promise a high-priority response.
2. Reproducible Vulnerability Queue: Requires minimal reproduction materials and performs an initial round of validation in an automated environment.
3. Critical Emergency Channel: Covers issues such as remote code execution, privilege escalation, and sandbox escapes, allowing them to bypass normal quotas while imposing greater penalties for abuse.
4. Reputation-Based Quotas: Dynamically adjusts submission limits based on historical validity rates, report completeness, and follow-up cooperation, rather than applying a permanent uniform cap.
5. Duplicate-Issue Clustering: Uses AI to compare call stacks, trigger paths, and affected components, merging reports with a common root cause before sending them for human confirmation.

AI should not make the final decision here. Asking a model that may hallucinate to determine whether another report—potentially generated by a model—is genuine can easily create a self-reinforcing loop of “AI reviewing AI.” A more appropriate role is triage, deduplication, and evidence extraction; final conclusions must still rely on reproducible experiments and human judgment.

Apple is right to retain human review. The severity of a security issue depends heavily on context: the same out-of-bounds access may cause nothing more than a crash in an isolated process, but could become an entry point for an exploit chain if it occurs in a system service with sensitive privileges. A model can summarize code, but it may not understand the product’s complete trust boundaries.

For Developers, the Reporting Bar Has Actually Risen

This change also serves as a reminder to security researchers and ordinary development teams: AI can participate in vulnerability discovery, but it cannot assume responsibility for the submitter’s conclusions.

If developers use large language models for code audits, the safer process is not to have the model directly produce a “vulnerability report,” but to ask it to propose falsifiable hypotheses and then eliminate them one by one through testing. Before submitting a report, researchers should at minimum reproduce the issue, confirm affected versions, assess the impact, and search for duplicate vulnerabilities. Issues that cannot be reproduced reliably can be retained as leads, but should not be rushed into a vendor’s high-priority channel.

Reports should also clearly distinguish between findings confirmed by experiments and those that remain speculative. Rather than submitting ten lengthy reports packed with security terminology, it is better to submit one short report containing a minimal reproducible example, logs, and clearly defined prerequisites for exploitation. For review teams, evidence density matters far more than text length.

Development teams also need to adjust their internal processes. Findings produced by AI code-auditing tools should not go directly into the highest-priority tier of a defect-tracking system, or the company’s own security team will likewise be overwhelmed by false positives. A sensible approach is to add a pre-validation stage, using static analysis, unit tests, sandbox reproduction, or manual spot checks before findings enter the formal remediation process.

By Closing the Gate, Apple May Also Miss the Window

Apple’s rate limit is a pragmatic choice, but it is not an elegant answer.

It can immediately reduce duplicate and low-quality reports, but it shifts some of the filtering responsibility to submitters and may delay genuine vulnerabilities discovered by new teams. In the disclosure of critical vulnerabilities, 30 days is not a period that can be casually dismissed: if attackers already know about a similar issue, every additional day before the vendor receives complete information exposes users to another day of risk.

More importantly, the volume of AI-generated content will continue to grow. Simply lowering the submission limit for each account will quickly encourage multi-account submissions, proxy submissions, and automated quota-increase requests. Platforms will ultimately have to return to the more difficult questions of evidence validation, identity reputation, and risk classification.

Nor should this change be interpreted simply as evidence that “AI cannot find vulnerabilities.” The reality is likely the opposite: AI is increasing both genuine discoveries and false discoveries, but the latter are growing faster. What the industry lacks today is not more suspected vulnerabilities, but a standardized process that can quickly turn model-generated speculation into reproducible evidence.

Apple’s rate limit marks the beginning of a new phase in vulnerability response. In the past, vendors worried that researchers would be unwilling to report vulnerabilities; now, they are beginning to worry that everyone can generate reports with a single click.

AI has dramatically shortened the first mile of security research, but the last mile—reproduction, validation, severity assessment, and remediation—still depends on people. Only those who redesign this part of the process will truly gain productivity from AI security tools. Otherwise, so-called automated vulnerability discovery merely creates to-do items faster.

References

• ITHome: Apple Limits Security Researchers’ Vulnerability Submissions Due to Large Volumes of Low-Quality AI-Generated Reports—Covers Apple’s June 2026 changes to its vulnerability submission process, including submission caps and a 30-day cooldown period, as well as responses from both Bynario and Apple.