GitHub Now Rate-Limits Vulnerability Reports

Two changes landed in GitHub's changelog on the same day, and they are the same change. Rate limits for private vulnerability reports caps how many reports one account can file per day. Structured forms for private vulnerability reports replaces the free-text box that made bulk filing cheap.

GitHub is unusually direct about why: "Open source maintainers are receiving more low-quality and automated vulnerability reports, which can bury the reports that matter." That is a platform admitting its intake is being used as a dumping ground.

What the form actually demands

Four required fields, per GitHub's changelog: "summary, details, proof of concept (at least 150 characters), and impact." Organisations can go further and require a CWE classification before submission, under Settings › Advanced Security › Private vulnerability reporting.

Only one of those is a real filter. A summary, a details blob and an impact statement are exactly what a language model produces on request, at length, convincingly. A proof of concept with a 150-character floor is different in kind: it is the one field where a fabricated answer has to be specific enough to be checked, and checked quickly, against the actual source.

That is not a claim that 150 characters stops anything. It is a claim about where triage time goes. A maintainer reading a structured report can jump straight to the PoC, try it, and close the thread. The old single text box forced them to read the whole thing to find out whether there was anything in it. The win is in time-to-dismissal, not in submission volume.

The AI checkbox is voluntary and unverifiable

Reporters can tick "I used AI assistance to find or write up this report." Nothing enforces it. There is no detector behind it, no penalty for leaving it blank, and the people filing the reports that prompted this change are the least likely to tick it.

It is still worth having, for a reason that has nothing to do with filtering: it generates a consent signal and a dataset. Honest researchers who used a model to speed up a write-up will tick it, and over a year GitHub will have some idea of the ratio among reports that turned out to be real. That is more than anyone has now. Treat it as instrumentation, not enforcement — the same mistake people make with self-declared AI labelling in content, which we covered in the context of Copilot's default enablement deadline.

The rate limits exist but are not documented

The changelog says limits "cap how many new reports a single account can submit in a day, both to your repository and across GitHub," that repository administrators "can set a custom daily overall reporting limit," and that trusted reporters can be allowlisted past them.

What it does not say is any number. And GitHub's reference page, Privately reporting a security vulnerability, documents none of it — no daily cap, no allowlist, no CWE requirement. It carries the form requirement ("By default, you must provide a summary, details, proof of concept, and impact statement") and stops there.

This gap is a recurring pattern, not an accident of one week. GitHub's action metadata reference still listed node20 after the runtime was pulled; the REST artifacts reference still describes fields that stopped appearing, as we traced in the Actions API artifact changes; npm's CLI docs kept describing an audit fallback that had started returning 410, covered in npm's retired audit endpoints. If you need the current behaviour of a GitHub feature, read the changelog entry and treat the reference page as a lagging indicator.

curl ran this experiment and quit

The strongest evidence that intake quality has collapsed is not a vendor changelog. It is curl, which shut its bug bounty on 31 January 2026 after nearly seven years.

Daniel Stenberg's announcement, the end of the curl bug bounty, published 26 January 2026, has the numbers. The programme launched in April 2019, paid out over 100,000 USD and confirmed 87 vulnerabilities. The confirmation rate fell from north of 15% historically to below 5% during 2025. Fewer than one submission in twenty was real, and the reward was what made filing the other nineteen worth someone's time.

Worth being precise about what curl did and did not do, because this gets misreported. curl did not stop accepting security reports. Its own policy page now states plainly: "There is no bug bounty and the curl project never offers rewards for reported vulnerabilities." Reports still go through HackerOne, where "Issues filed there reach a handful of selected and trusted people," and email reports are still refused. The bounty went; the channel stayed.

The two responses are opposites worth noticing. curl removed the incentive. GitHub raised the cost of a submission while keeping the channel open to everyone. GitHub's approach is the only one available to a platform that cannot decide, per project, who deserves to be heard — but it is also the weaker lever, because effort is cheap for exactly the submitters it is aimed at.

This is now a design problem for every intake form

Vulnerability reports are the loudest case, not a special one. Any form that accepts unstructured text from strangers and routes it to a human is now cheap to flood: bug trackers, feature request boards, support queues, product submissions, job applications.

GitHub's two levers generalise cleanly. Require a field that is expensive to fake — a reproduction, a version number, a URL that has to resolve — rather than more prose, because prose is the thing that got cheap. And rate-limit per identity rather than per IP, since the submitters worth stopping have one account and a script, not a botnet.

The levers that do not generalise are the ones based on sentiment. Asking submitters to self-declare intent, promising to deprioritise low-effort entries, adding a politely worded warning — none of these change the cost of submitting. We run structured feedback and request boards on TechLogHub and the lesson has been identical: the field you make mandatory decides the quality of the queue, and everything else is decoration.

If you maintain a public repo, do this

Turn the CWE requirement on. It is the highest-signal toggle in the set, because assigning a weakness class forces a reporter to commit to a claim that can be wrong. A report that cannot pick between CWE-79 and CWE-89 is telling you something before you read a line of it.

Set a custom daily limit lower than you think you need. The cost of a limit that is slightly too tight is one researcher waiting a day. The cost of one that is too loose is the thing GitHub just shipped a feature to fix.

Allowlist the people who have been right before, by name. A trusted-reporter list is the only part of this that improves rather than degrades over time, and it costs nothing to start.

And write down your actual policy, in the repo, next to the code. If you accept reports but pay nothing, say so in the words curl used. Ambiguity about rewards is what generates speculative volume. If you are cataloguing a project's maintenance posture more broadly — license, governance, report channel — the open-source listings on TechLogHub are organised around exactly those signals, and the developer tools category is where most of this tooling lands. Drafting the policy file itself is a two-minute job with the Markdown to HTML converter if you need to preview it.

FAQ

What is the daily limit on vulnerability reports?

GitHub has not published a number. The changelog says limits apply per account, both to a single repository and across GitHub, and that repository administrators can set a custom daily overall limit for their own repo. The reference documentation does not mention the limits at all yet.

Which repositories and plans does this apply to?

Public repositories with private vulnerability reporting enabled, on GitHub Free, Pro, Team and Enterprise Cloud. It went live on 1 October 2026.

Can I still get around the new form?

Not on the submission path. Summary, details, proof of concept and impact are required, and the proof of concept must be at least 150 characters. A CWE is required only if the repository's owners have turned that on.

Does ticking the AI-assistance box hurt my report?

GitHub does not say it carries any consequence, and the checkbox is optional. Practically, a maintainer reading a well-constructed report with a working proof of concept cares about the proof of concept. Disclosure costs an honest reporter nothing.

Did curl stop accepting vulnerability reports?

No. curl ended its bug bounty on 31 January 2026 but still takes reports through HackerOne. Its policy page states there is no bounty and that the project never offers rewards. Email reports are not accepted.

Will rate limits reduce the number of bad reports?

Probably at the margin, and mostly by spreading them out. The structured form is the more useful half, because it cuts the time it takes a maintainer to decide a report is empty. Volume and triage cost are different problems, and only one of them has been addressed properly.

Verified against GitHub's 1 October 2026 changelog entries, GitHub's private vulnerability reporting documentation and curl's own disclosure policy on 3 October 2026.