Disclosure Rules Shift Around AI-Found Bugs: Kernel Docs Say Treat Them as Public, GNOME Ended Its Bounty, Google Paused OSS Rewards

Background

The Linux kernel’s published security-bug guidance shows how the usual order of private report, embargoed fix and CVE identifier is being restated for bugs found with AI tools. The kernel document says that a reporter who resorted to AI assistance to identify a bug “must treat it as public”, because the security team’s experience is that bugs discovered this way “systematically surface simultaneously across multiple researchers, often on the same day”. The same document says embargoed fix publication may be postponed for up to 7 calendar days from the start of the release process, with an exceptional extension to 14, and that the kernel security team “does not assign CVEs”.

CVE assignment for the kernel happens elsewhere. According to The Register, the kernel project became a CVE Numbering Authority in February 2024, and its policy is to assign CVEs automatically after fixes have reached a stable kernel tree, a deliberately cautious approach because a bug’s security implications may not be apparent when it is fixed.

The Herald has covered individual pieces of this shift, including Google’s pause of open-source product rewards, curl’s 8.23.0 release and the PHP security release. This analysis compares what several October developments say about two parts of the process: how much report volume projects can absorb, and how long an embargo can hold.

Current situation

Volume

The kernel document says a “significant fraction” of the bug reports sent to its security team result from AI-assisted code review, and that this causes an overload on maintainers, who are “sometimes forced to ignore such reports due to their poor quality or accuracy”.

Debian’s kernel advisory DSA-6528-1, published on September 29, lists 1,313 CVE identifiers, The Register reported. The outlet wrote “We strongly suspect that this number of CVEs is due to LLM bots doing the bug hunting”, and also cautioned that the list “should not be read as a tally of bugs introduced in 6.12.111” because several entries it checked also affect older kernels. The suspicion and the caveat are both the outlet’s own statements.

Other projects describe the pressure in their own numbers. GNOME developer Michael Catanzaro wrote on October 2 that a GNOME bug bounty on the YesWeHack platform received 298 reports in total, of which 71 were accepted and 197 rejected after 30 duplicates were set aside. He wrote that he requested the program’s end “because I was overwhelmed with incoming AI-generated issue reports”. His table of GNOME CVEs counts 13 for 2023 and 141 for 2026 through September 30, and he writes that AI is “the primary cause for the increase”. He also writes that bounty programs are an exception to AI reports being mostly good, because “people will submit bad reports when financially incentivized to do so”.

Google’s open-source program moved in the same direction. The Hacker News reported that, since October 1, the Open Source Software Vulnerability Reward Program no longer takes product vulnerability reports for rewards. Google’s post, which the outlet quotes, cited “a significant rise in automated submissions, the vast majority of which are not valid”. The outlet noted that the post gave no figures and did not say whether AI tools produced the submissions. Supply chain compromise reports keep their listed rewards, and the notice promises an update in the first quarter of 2027.

The Go project’s security policy takes a related position: it asks reporters not to send LLM-generated reports “without proper curation” and says it attributes discoveries only “to reporters with a substantial percentage of real findings”.

Timing

The second strand concerns how long information stays private. The Register reported that Catanzaro announced a reduction of GNOME Security’s disclosure deadline from 90 days to 30, effective August 1.

The PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, show an embargo ending early. BleepingComputer reported that on October 20 the security firm watchTowr said information about the previously embargoed flaws had leaked, and that a since-deleted Hacker News post had listed both CVE identifiers. The same article quotes the PHP security team saying it reserved the right to release early “should details of either vulnerability become public, or should evidence of active exploitation appear in the wild”.

What happened next is disputed. According to The Register, PHP’s own post-incident blog says the two CVE IDs began circulating on Tuesday at around 15:00 UTC, that the planned release was moved forward a day, and that Chainguard published built images containing the fix more than six hours before the coordinated release. The blog calls that a unilateral breaking of the embargo. Chainguard CEO Dan Lorenc told the outlet his company “didn’t leak”. He said Chainguard independently found the same memory-corruption bugs using an AI harness and a frontier model, and shipped the fixes because “People were getting hit in advance”. He described his policy as “coordinated vulnerability disclosure, unless there’s evidence of active exploits in the wild”, and said that “People are able to build an exploit in hours without even knowing what the vulnerability is.”

A third case involves reports arriving on public channels. The Hacker News reported that Trend Micro’s Zero Day Initiative sent reports of two kernel SMB-server (KSMBD) flaws, credited to Trend Micro’s AI scanner, to public mailing lists without patches, which the outlet said appeared to follow the kernel guidance quoted above. Kernel maintainer Greg Kroah-Hartman replied to a separate report in the same batch: “For some reason you sent this to public lists, and did not include a patch, so there’s not much we can do with this.” The outlet also reported that neither KSMBD flaw had a CVE identifier, since the kernel assigns them only after a stable-tree fix, and that the KSMBD maintainer later pointed to an existing fix for one race, written on September 30 and credited to a different reporter.

Implications

The following points are what the cited sources imply; they are not forecasts.

CVE counts measure different processes. The sources describe CVE creation working in different ways. The kernel assigns after a stable fix. Go’s policy says all security issues “will be issued CVE numbers”. Catanzaro writes that GNOME’s CVEs “exist only because I request them myself”, that he has ended security tracking for new reports and that nobody else has volunteered, and that Apple generally creates CVEs for externally found WebKit flaws rather than ones found by its own developers. The Herald has also reported that the Ruby project had not requested CVE IDs for regexp bugs behind four GitLab CVEs. On the Herald’s own count, that is at least four distinct arrangements across the material cited here. One consequence follows from The Hacker News report on KSMBD: while flaws had no CVE, any tooling keyed only to CVE identifiers had nothing to match, even though the reports were already public.

Embargo length and trigger conditions differ by project. The kernel allows 7 to 14 days after the start of the release process, GNOME 30 days, and, as quoted by The Register, PHP’s blog describes its embargo for the PHP2Shell flaws as “weeks of work by many parties”. Both PHP and Chainguard point to an early-release exception for active exploitation, and they differ on whether that condition was met when Chainguard shipped.

Commentary on what to change. A Register column, published October 26, argues that “Disclosure needs to be a discipline, not a protocol”, that the minimum number of people should hold a secret, and that patch liaison should become a formal role. This is the column’s opinion, not a finding. Catanzaro makes a different argument: projects that ban AI-generated vulnerability reports “might as well ban all vulnerability reports”, and he writes that to resume GNOME’s bounty it would need to limit scope to projects that regularly perform their own AI vulnerability scans and would most likely pay only for functional exploits.

Requirements now placed on reporters. The kernel document asks AI-assisted reporters for concise plain-text reports with a tested reproducer, a proposed fix with a Fixes tag, and no public reproducer. Go asks for curation. Google has stopped paying for product vulnerability reports, though not for supply chain compromises.

What is not known

Google has not said whether the automated submissions it cites came from AI tools, nor when product rewards might resume beyond a first-quarter 2027 update. The sources do not establish who leaked the PHP2Shell identifiers; PHP’s blog and Chainguard give conflicting accounts of the final hours. Whether Zero Day Initiative will change how it routes AI-found kernel reports is not reported.