GitHub Private Vulnerability Reports Now Have Daily Rate Limits and Trusted Reporter Allow Lists

What GitHub changed​

The changelog lists these points:

• Per-user daily limits on new reports. GitHub now caps how many new private vulnerability reports a single account can submit per day, both to one repository and across GitHub overall. That's two separate checks: one per repository and one across the whole platform.
• A "try again later" message. Reporters who hit the limit see a message to try again later.
• Comments are exempt. The limit only covers new submissions. Ongoing discussion with a researcher about an already-filed report can continue without being throttled, while only the submission of brand-new reports is capped per account per day.
• Custom repository limit. Repository administrators can set their own daily limit. GitHub's full changelog text calls it a "custom daily overall reporting limit" for the repository. The word "overall" suggests a cap on total incoming reports, separate from the per-user limits, but GitHub doesn't explain how the two interact.
• An allow list for trusted reporters. Repository administrators can set a custom daily limit and add trusted researchers to an allow list so they're never rate limited.

Eligibility: rate limits for private vulnerability reporting are available on public repositories with the feature enabled, across GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. GitHub's documentation says PVR itself is only for public repositories. A GitHub issue thread published this week says the same thing: GitHub offers the feature for public repositories only.

What GitHub hasn't said:

• The default numeric limits
• When the daily counter resets
• Whether API submissions are treated differently from the web form
• Whether administrators get any analytics to help them choose a limit

Be wary of anyone quoting a specific number.

Summary: One account can now file only so many new reports per day, per repository and across GitHub. Maintainers can adjust their repository's limit and exempt trusted reporters. Comments on existing advisories aren't affected.

Why GitHub is doing this​

The background is a sharp rise in reporting volume. In a June 2026 post about the GitHub Advisory Database, GitHub said private vulnerability reports went from about 550 a week in January to more than 3,000 a week for most of May. Repository advisories rose from about 650 a week to more than 5,000. Help Net Security covered those figures and added that GitHub's work as a CVE Numbering Authority pulled in close to 4,000 CVE requests in May alone, many times the count from a year earlier. It also reported that private vulnerability reporting now runs on a large base of projects, more than 1.7 million repositories in total.

The curation team kept up as best it could. GitHub kept up more than 6,000 advisory decisions a month from March through May, a span covering new advisories, updates, and inbound reviews. GitHub still admitted that, since mid-April, processing times had grown to multiple weeks for a meaningful share of submissions. It also warned that slower publication can lengthen exposure windows.

The June post also explained that well-formed advisories take curators minutes to check. Incomplete ones can take much longer, because curators have to work out version ranges from commits, tags and conflicting upstream data. A tool that generates dozens of thin reports doesn't just irritate one maintainer. Every one of those reports has to be read by someone somewhere along the chain.

One caution: GitHub hasn't claimed that rate limits will fix the backlog or speed up advisory review. The changelog presents the feature as a way to protect maintainers from bulk and automated submissions. That's a narrower goal than fixing the pipeline, and it's best to read it that way.

How the PVR workflow fits together​

The feature only makes sense once you know what a "new report" is. GitHub's documentation describes the flow like this:

1. A researcher opens an eligible public repository's Security and quality tab and clicks Report a vulnerability.
2. They fill in the advisory form. Only the title and description are required, although GitHub urges researchers to give as much detail as they can.
3. After they click Submit report, GitHub notifies the maintainers. It also adds the reporter as a collaborator and credited user on the proposed advisory.
4. The researcher can optionally start a temporary private fork to work on a fix. Only the maintainer can merge it.

Researchers can also submit through the REST API. That has been possible since general availability in 2023, when security researchers can also use the new repository security advisories API to open a private vulnerability report on multiple repositories (when packages share a common vulnerability). The new limits only affect step 3. Back-and-forth discussion after a report is filed isn't capped.

Summary: The limit counts new submissions only. The rest of the disclosure process works as it did before.

How to configure the new settings​

GitHub's changelog and its repository configuration documentation give this route:

1. Go to the repository's main page and click Settings. If you don't see the tab, open the dropdown menu first.
2. In the Security and quality section of the sidebar, click Advanced Security.
3. Make sure Private vulnerability reporting is enabled. If it's off, click Enable.
4. Click Settings next to "Private vulnerability reporting" to reach the new controls. From there you can set a custom daily limit for the repository and add trusted reporters to the allow list.

Who can do this: GitHub's documentation lists repository owners, organization owners, security managers and users with the admin role.

Related setting worth checking: Notifications. GitHub notifies administrators and security managers about new reports only if they're watching the repository with All Activity or Custom → Security alerts selected, and have notifications turned on. If you've just tightened your limit, it's a good time to confirm the reports that do arrive reach someone.

Who benefits, and who might be hurt​

Maintainers of popular projects gain the most. A small open-source library with one part-time maintainer can't easily absorb a flood of machine-generated findings. A daily limit and an allow list give that maintainer some control over the flow.

Legitimate high-volume researchers are the obvious risk. Think of a team that finds one bug pattern across many packages, or a security lab running coordinated disclosure campaigns. The platform-wide limit applies however good the reports are. A repository allow list only helps once a maintainer has added you, and the changelog doesn't mention any exemption from the platform-wide limit. Someone reporting the same flaw to 40 repositories could hit a wall that no single maintainer can remove.

Abusers will look for workarounds. Per-account limits are a sensible first step, but a determined operator can register more accounts. GitHub hasn't said what else, if anything, it does to stop that. My read, based on general industry experience with rate limiting rather than anything GitHub has said: limits like these push out the laziest automated spam and raise costs for the rest. They don't replace triage.

So who decides what counts as "low quality"? Under this design, nobody does. GitHub limits volume per account rather than judging content. That's blunt, but also fair: it doesn't try to second-guess whether a finding is AI-assisted or human-written.

Practical takeaways​

For maintainers:

• Look at the new PVR settings on your public repositories, especially ones that already get a lot of reports.
• Add researchers you've worked with before to the allow list so a busy disclosure week doesn't block them.
• Don't set a very low custom limit and forget about it. A real critical report arriving on a heavy day still needs a way in.

For researchers:

• If you see the "try again later" message, wait. GitHub hasn't published any other escalation route.
• Write complete reports with affected version ranges, root cause and reproduction steps. GitHub's June post said these make the biggest difference to how fast advisories get reviewed.
• If you report to the same projects regularly, ask the maintainers to allow-list you.

For enterprise IT and AppSec teams whose software depends on open-source packages: this is a supply-chain story. Advisory delays mean Dependabot alerts arrive later. Anything that cuts noise further upstream should, in principle, help real alerts reach you sooner.

GitHub published this change alongside a related changelog entry on structured forms for private vulnerability reports. Both are attempts to keep a fast-growing disclosure channel usable for the maintainers on the receiving end.