GitHub adds daily caps and a required form to private vulnerability reports, to cut AI-generated spam

An open-source maintainer who opens private vulnerability reports has had the same problem as every security team since large language models reached the public: a report is easy for a stranger to write with a model, hard for a maintainer to read, and the real report lands in a queue alongside many that are not. GitHub changed two things in that queue today, both in the same release, and both aimed at the shape of a report rather than at the person writing it.

The first change caps how many new private vulnerability reports a single account can file in a day, both against one repository and across all of GitHub. A reporter who hits the limit is told to try again later, and comments on existing advisories still go through. GitHub says the goal is to hold back "bulk and automated submissions, while legitimate researchers can still reach you". The setting lives under a repository's Advanced Security page.

The free text box is gone by default

The second change replaces the single free-text box that used to carry a report. Reporters now have to fill in four required fields: a summary, details, a proof of concept of at least 150 characters, and the impact. GitHub's own reason, in the changelog: "A single free-text box made it easy to submit low-quality or AI-generated reports and hard for you to find the signal in them." The four answers are stitched into the advisory description that the maintainer already reviews.

A maintainer can replace the default form with their own. Adding a .github/VULNERABILITY_REPORT.yml file to the default branch overrides it for that repository, and adding one to the organization's .github repository overrides it for every repository the organization owns. The syntax is the same one GitHub uses for issue forms, and every field can carry a min_length so a reporter cannot pass through with two words of detail. An invalid form falls back to the default.

Two optional controls go with it. A maintainer can require the reporter to assign a CWE before they submit, under Settings, Advanced Security, Private vulnerability reporting; an organization owner can enforce the setting across every repository through a policy. And a reporter now sees a checkbox labelled "I used AI assistance to find or write up this report", which is self-declared and tells the maintainer what to prepare for.

What is on by default and what the maintainer has to switch on

Both changes are live on public repositories with private vulnerability reporting enabled, on GitHub Free, GitHub Pro, GitHub Team and GitHub Enterprise Cloud. The rate limit is on by default; the structured form is on by default; the CWE requirement and the custom form are off unless the maintainer turns them on. GitHub says it will add the ability to export the structured fields later.

For a team that runs an open-source project, the shape of the vulnerability queue is now the maintainer's to set, and the cost of filing a weak report has gone up by three required fields and a minimum length. The format change is small; the shift it causes is that a reporter now has to write a proof of concept of at least 150 characters before the message reaches the maintainer. Teams whose security policy already lists what a report should include can encode that policy as a form file in a repository, so a reporter cannot skip any of it.

Source

• Primary source: GitHub Changelog: Rate limits for private vulnerability reports, 1 October 2026
• Related: GitHub Changelog: Structured forms for private vulnerability reports, 1 October 2026