Google has temporarily stopped accepting new product-vulnerability reports through its Open Source Software Vulnerability Reward Program (OSS VRP), citing a sharp rise in automated submissions whose vast majority were not valid. The pause took effect on October 1, 2026, and Google says it will rework the program before providing an update in the first quarter of 2027.

Security engineer reviewing an overflowing queue of automated open-source vulnerability reports

The change is narrower than a shutdown of Google’s open-source security reporting. It does not cover OSS supply-chain reports, and reports submitted before the pause remain in scope for processing. But it is still a notable operational event: one of the industry’s most visible open-source security programs has decided that the cost of separating useful findings from machine-produced noise has become too high for the existing intake model.

For security teams, the important lesson is not that artificial intelligence cannot find bugs. Google’s own security work makes the opposite case. The lesson is that discovery, verification, and triage are different jobs. If the first step becomes cheap enough to run at massive scale, the later steps become the bottleneck. A vulnerability program can then be attacked without anyone exploiting a system: the queue itself becomes the pressure point.

What Google changed

Google’s public explanation is specific. The company says it is “temporarily” no longer accepting OSS VRP product-vulnerability submissions because of a significant rise in automated submissions, most of which were invalid. It directs researchers toward other Google vulnerability reward programs or the Patch Rewards Program while the OSS VRP is being reformatted.

The affected category covers vulnerabilities in Google open-source products. Google’s program rules distinguish ordinary product vulnerabilities from issues involving source or build integrity that could lead to a supply-chain compromise. That distinction matters during the pause. A researcher who believes a finding concerns a malicious dependency, a compromised release process, or another supply-chain problem should not assume that the ordinary product-vulnerability path is still the right channel. The current rules remain the source of truth for routing and scope.

The pause also does not erase the earlier reporting queue. Google has said that outstanding reports are not affected. That means there are two separate operational states: older submissions continue through existing review, while a new class of product-vulnerability submissions is not being admitted. The difference matters to maintainers and researchers who might otherwise treat the announcement as a blanket ban on reporting.

Google had already signalled that its previous process was under strain. In a March 2026 rule update, the OSS VRP team described a “massive surge” in AI-generated reports and introduced stricter evidence requirements for some tiers. The update called out hallucinated trigger paths, technically real coding errors with little security impact, and findings that were not reachable under the project’s security model. In later changes, Google removed monetary rewards or credit for some lower-tier product-vulnerability categories.

Those measures were an attempt to improve the signal before closing the intake door. The October pause indicates that the incremental controls did not solve the volume problem quickly enough.

This is a triage failure, not proof that AI research is useless

It is tempting to describe the event as a contradiction: technology companies promote AI-assisted vulnerability discovery, then complain when researchers use AI to submit reports. That reading is incomplete. The conflict is between two different uses of automation.

A discovery system can be valuable even when it produces many candidates. A scanner, fuzzer, symbolic-analysis tool, or language model may identify suspicious code that deserves a human investigation. The output is a hypothesis. A reward program, by contrast, receives a claim that a vulnerability exists, can be triggered, has meaningful impact, and falls within a defined scope. That output needs to be a verified case.

When researchers send the raw candidate list directly into a bounty queue, the program inherits the discovery system’s false-positive rate. It also inherits duplicate reports, copied severity labels, incorrect assumptions about configuration, and explanations that sound plausible without establishing a reachable attack path. An AI-generated report can be fluent enough to pass a superficial editorial check while still failing the basic security questions.

A useful report must answer questions that a model cannot answer merely by reading a code fragment: What exact version is affected? What input reaches the vulnerable path? Which permissions are required? Can the behaviour be reproduced in a supported configuration? What boundary is crossed? What is the realistic impact? Has the issue already been fixed or reported?

The practical distinction is simple: AI can help produce leads, but the reporter remains responsible for proving the claim. Google’s March rules made that expectation explicit by requiring stronger proof, such as a reproducible OSS-Fuzz result or a merged patch, for some submission tiers.

Why the timing matters for open-source security

Open-source security programmes depend on scarce human attention. Maintainers, triagers, and security engineers must compare reports with source history, build configurations, release branches, downstream packaging, and existing advisories. A report that is wrong is not free to process. It consumes time that could have been spent validating a real issue, preparing a patch, or answering a maintainer who has found an urgent regression.

The cost is higher for foundational projects. A vulnerability report about a widely used library may need to be assessed across multiple supported versions and build systems. A finding in a compiler, runtime, container component, or build tool may require a broader supply-chain analysis than the original report suggests. Security teams cannot responsibly automate closure simply because a report looks suspicious; they still need enough evidence to distinguish a bad submission from an unfamiliar but serious flaw.

That asymmetry creates a new form of operational risk. Opening a report may take seconds. Reviewing it may take an hour. If a model can generate thousands of reports at low marginal cost, a small number of actors can impose a denial-of-service condition on a programme without touching the protected software. The target is the review function.

This pattern is not limited to Google. The curl project’s current bug-bounty document says that it offers no rewards for reported bugs or vulnerabilities, while still valuing valid vulnerability reports. The project explains that rewards can create incentives for people to make up problems in bad faith and overload the team. That policy predates Google’s October pause, but the direction is similar: a public reporting channel is useful only if its incentives preserve the quality of the queue.

Other projects are trying to manage the same pressure without abandoning outside contributions. GitHub has introduced persistent pull-request limits for users without write access, and those limits count pull requests opened by Copilot or another AI agent. GitHub’s stated aim is to put a cap on the rate at which a contributor can create review work. The mechanism is different from a vulnerability programme, but the operating principle is the same: control the cost of intake before it exceeds the team’s ability to review.

The boundary between product flaws and supply-chain risk

Google’s exception for supply-chain reports deserves attention. Modern open-source security is not only about defects in application code. It also includes repository permissions, release automation, package publication, signing keys, build provenance, dependency substitution, and the integrity of generated artefacts. A report about a vulnerable parser and a report about an attacker being able to publish a poisoned package may arrive through related channels, but they require different urgency, evidence, and responders.

For a maintainer, the distinction should be reflected in the intake form. Ask whether the report concerns a bug in a supported product, a weakness in the build or release system, a compromised dependency, or an issue in a downstream deployment. Requiring the reporter to select a category does not make the classification correct, but it forces the first useful bit of context into the queue.

For an enterprise using open-source software, the distinction changes escalation. A normal product vulnerability may enter the patch-management process. A suspected source or build-integrity problem may require an incident-response process, package inventory review, provenance checks, and a search for affected internal artefacts. Treating both as ordinary tickets can delay the more consequential investigation.

Nothing in Google’s announcement proves that a supply-chain attack is underway, and it would be wrong to imply that the pause reflects a newly discovered vulnerability. The confirmed fact is operational: one submission category has been paused because automated reporting volume and validity became unacceptable. The security implication is an inference: organisations should examine whether their own reporting channels would survive the same change in volume.

What maintainers should change now

Maintainers do not need to wait for a vendor or platform to design a perfect AI filter. A small project can improve its intake with rules that make human verification visible and expensive enough to discourage indiscriminate submission.

Start with a clear scope statement. Name supported versions, excluded configurations, accepted impact classes, and the reporting channel for supply-chain concerns. A vague “please report security issues” page invites researchers and automated tools to fill in the missing policy themselves. Precise scope reduces both accidental submissions and arguments about why a report was closed.

Require a minimal evidence package. At a minimum, ask for a tested version or commit, a reproducible setup, the exact input or action, observed output, security impact, and any relevant permissions. If a report is based on static analysis, require the reporter to show that the code path is reachable in a supported configuration. If the alleged impact depends on a deployment assumption, name that assumption.

Separate a lead from a report. Projects can provide a low-friction channel for unverified observations while reserving the security queue for claims that meet evidence requirements. This allows researchers to share a promising direction without forcing the incident-response team to treat every generated hypothesis as a confirmed vulnerability.

Use rate limits and contributor history. GitHub’s pull-request limits offer one model: contributors without established trust can have a bounded number of open items. A security programme can apply similar controls through submission quotas, staged access, or a requirement to resolve questions on an earlier report before opening more. Rate limiting should be transparent and should not prevent urgent reporting; it should reduce bulk, duplicate, and low-effort traffic.

Make duplicate detection part of the workflow. Search by affected component, function, error signature, and fix commit before assigning a new reviewer. AI systems tend to rediscover the same obvious pattern, and multiple submitters may produce nearly identical reports from the same public prompt. A duplicate is not malicious by definition, but it should not receive a fresh full investigation every time.

Keep humans accountable for closure. Automated checks can reject missing fields, impossible versions, malformed proof-of-concept files, or reports that clearly fall outside scope. They should not silently decide that a subtle security claim is harmless. The more consequential the outcome, the more important it is to retain an auditable reason for rejection, acceptance, or escalation.

Finally, track queue health as an engineering metric. Count reports received, reports with reproducible evidence, duplicates, invalid claims, median time to first meaningful response, and reviewer hours per confirmed issue. Without those measures, teams may know that the queue feels worse but not which control is working. Google has not published the volume or validity percentages behind its pause, so outside observers should avoid inventing a precise cost. Maintainers can still collect the numbers needed for their own decisions.

What security researchers should do differently

The pause is also a warning to researchers who use AI to accelerate vulnerability discovery. The safest workflow is to treat model output as a private notebook of hypotheses, not as a submission generator.

First, reproduce the behaviour yourself. Build the affected version, exercise the relevant input, and record what happens. If you cannot explain the trigger without the model’s prose, you are not ready to file the report. A short, verified report is more valuable than a long explanation that merely repeats a static-analysis label.

Second, establish impact rather than repeating severity language. “Remote code execution” is not an impact description unless the report shows the trust boundary, reachable input, execution context, and conditions. “Buffer overflow” is not automatically a security issue if the code is unreachable, protected by a supported compiler configuration, or only present in a test path. Google’s own rule update highlighted this difference.

Third, check history and scope. Look for a fixing commit, an existing advisory, a previously discussed issue, and the project’s current support policy. Confirm that the code path exists in a released or supported version. A model may confidently describe a branch that was removed months earlier.

Fourth, disclose the role of automation honestly when a programme asks for it. The important issue is not whether a model helped draft a sentence. It is whether a human researcher validated the technical claim. A useful disclosure can state which tools generated the initial lead, which tests were run, and what evidence was independently confirmed.

Fifth, submit only when the report adds information. If five projects are affected by the same library flaw, coordinate the report or identify the shared upstream issue instead of sending five near-identical narratives. If the observation is uncertain, use the project’s discussion or contact path where policy allows. The objective is to improve the maintainer’s position, not to transfer an unfiltered search log into their inbox.

The incentive problem is bigger than “AI slop”

The phrase “AI slop” is memorable, but it can hide a broader design problem. Low-quality security reports existed before language models. Bounty payments, public leaderboards, reputation incentives, and easy submission forms have always created pressure to maximise volume. Generative tools change the economics by reducing the cost of producing a plausible report and making it easier to scale behaviour that was previously limited by writing time.

That means banning a particular model or trying to detect machine-written prose will not solve the underlying problem. A careful human can submit a bad report, and a model-assisted researcher can submit an excellent one. Text style is a weak signal. Reproducibility, reachability, demonstrated impact, contributor history, and duplicate analysis are stronger signals.

It also means the remedy cannot be only a stricter CAPTCHA. If the programme rewards quantity, people will optimise quantity. If it rewards validated impact, accepts only evidence-backed submissions, and gives maintainers tools to cap intake, the incentives change. Some researchers may prefer a more selective programme with fewer rewards. That is a legitimate trade-off if it keeps the channel open for serious work.

Projects should also recognise that accessibility and quality are not opposites. A newcomer may need help understanding the reporting format, and an AI-assisted researcher may uncover a real flaw. The answer is to make the path to a valid report clearer: provide examples of accepted evidence, explain common non-issues, publish scope boundaries, and offer a discussion route for uncertain leads. Stronger gates should remove unverified workload, not turn security reporting into a private club.

What enterprises should ask their suppliers

Organisations that depend on open-source components should treat this as a supplier-assurance question. Ask vendors and critical upstream projects how they receive vulnerability reports, whether they have separate channels for product and supply-chain issues, and what happens when automated submissions create a queue spike. A programme that cannot explain its intake controls may still be effective, but the uncertainty belongs in the risk assessment.

The same review should cover internal security channels. Many companies now accept findings from scanners, bug-bounty platforms, code assistants, red teams, and external researchers in a single ticketing system. If every source has the same priority and no evidence threshold, the queue can become noisy enough to hide urgent issues. Establish a distinction between a candidate finding and a verified vulnerability, then define who is responsible for moving an item from one state to the other.

For software used in production, maintain an inventory that links a component to its exact version, build source, package provenance, and owner. This does not prevent low-quality reports, but it makes valid reports easier to validate. A security engineer who knows which versions are deployed can reject an irrelevant claim quickly or escalate a relevant one with confidence.

The company should also test the operational path. Send a controlled set of synthetic findings through the intake process and measure time to classification, duplicate handling, escalation, and closure. The exercise should not create a burden for an upstream project; it can be performed against internal channels or with explicit permission. The goal is to discover whether a sudden rise in candidate reports would overwhelm the people who must verify them.

What to watch before Google’s Q1 2027 update

Google’s next update will show whether the programme returns with a redesigned funnel or a narrower permanent scope. The useful signals will be more concrete than whether submissions reopen. Watch for changes to proof requirements, per-researcher limits, identity or reputation signals, automated duplicate handling, separate paths for supply-chain reports, and public data about review quality.

A strong redesign would preserve a route for independent researchers while making evidence the unit of work. It could accept early leads in a lower-cost channel, reserve rewards for verified impact, and route high-confidence supply-chain findings directly to specialised responders. It might also publish clearer examples of why a report failed, allowing researchers to improve instead of simply trying again with more polished prose.

A weak redesign would focus mainly on detecting AI-generated language. That would encourage researchers to hide the use of tools without improving technical quality. It would also miss human-written reports that are wrong and model-assisted reports that are well tested. The programme’s central problem is not authorship; it is the mismatch between the price of creating a submission and the labour required to verify it.

The wider ecosystem is likely to face the same choice. Open-source maintainers cannot absorb unlimited machine-generated work, yet they cannot afford to discard automation that finds real vulnerabilities. The durable answer is a layered process: machines generate candidates, humans validate claims, policies limit intake, and evidence determines escalation.

Google’s pause is therefore best understood as an incident in security operations, not as a verdict on artificial intelligence. The technology has made both discovery and submission faster. Only one of those improvements is automatically useful. Until reporting systems are redesigned around proof, a faster stream of claims can reduce the amount of real security work a team is able to complete.