Google Admits It Is Being Overwhelmed by the AI “Mush.”
For this reason, the company has partially paused one of its public bug bounties. Specifically, the Open Source Vulnerability Rewards Programs, which covers its open‑source projects.
Since October 1st, it has stopped accepting submissions for “product vulnerabilities.” That is, design or implementation flaws that “significantly compromise the confidentiality or integrity of user data.”
Requests that fall under the category of “supply chain compromise” (risks to the integrity of a source or a build) are still welcome. Additional exceptions may be made for projects feeding Google Cloud’s ecosystem, under the dedicated bug bounty program (Cloud Vulnerability Reward Program).
Google has set a deadline of the first quarter of 2027 to evolve the “product vulnerabilities” portion. In the meantime, it invites researchers to pivot toward its Patch Rewards Program. This covers external open‑source projects for which Google has reported vulnerabilities, as well as those integrated into OSS‑Fuzz… and about a hundred others including:
- Web and mail servers (Apache httpd, nginx, Postfix, Sendmail…)
- CMS (Drupal, Joomla, Magento, PrestaShop, WordPress…)
- Web frameworks (Angular, Dart, Go, jQuery, Struts…)
- Package managers (apt, npm, pip, yum)
- Network services (BIND, OpenSSH, OpenVPN…)
- Decompression libraries (7z, bzip2, gzip, tar…)
Early steps taken in the spring
Google had already tightened the screws in the spring for the same reason: a sharp rise in AI‑generated reports that were riddled with errors or irrelevant to the project’s security model. It had established a four‑tier priority system:
- Flagship (the most critical projects: Angular, Bazel, Golang…)
- Important (projects with a strong community footprint)
- Standard (active, stable projects available in major package managers)
- Low (experimental and/or small‑scope projects)
For the top two levels, Google required, for memory‑corruption vulnerabilities, a reproduction via OSS‑Fuzz or a fix merged into the target repository. For the other two levels, it removed rewards for “product vulnerabilities” and “other security issues,” leaving only rewards for the supply chain aspect.
Curl backs off; GitHub does not
At the time Google was tightening the screws, Curl was loosening them.
Late January, the project announced the closure of its public bug bounty on HackerOne. The reason boiled down to a single figure: in 2025, the share of reports that actually described “real” vulnerabilities fell below 5%. Whereas it hovered around 15% in previous years.
Curl then shifted to GitHub’s private vulnerability-reporting system—while removing financial rewards. It changed course again in March, not satisfied with the quality of the service… but reassured by an uptick in the quality of “AI contributions” (to the point that the 15% ratio was back in play). Other projects (Django, Firefox, Git, Python, Ruby…) reached a similar conclusion. Not GitHub.
GitHub had, in the spring, first announced the end of financial rewards for reports that enabled code or documentation corrections without demonstrating a meaningful impact. Then, this summer, it reduced the upper bound of rewards for low‑severity vulnerabilities. It tied the larger rewards to VIP status. It also began using the HackerOne reputation index.
arXiv caps submissions of papers for all
The phenomenon does not spare arXiv. The open archive of research papers is receiving more submissions, but many fail to meet core content and formatting criteria. This is accompanied by a trend toward “slicing” the presentation of work into multiple papers. All of these factors eat up a disproportionate share of moderators’ time.
In this environment, arXiv has imposed, with no defined deadline, a limit of two submissions per month for each user.
Meanwhile, Apple is weighing measures to counter another unwanted effect: AI agent mistakes. In its sights is a macOS permission designed for backup tools: full access to the internal disk. Apple does not spell out exactly how it will evolve, but signals that it plans to make the permission more explicit than it currently is (today you must manually grant access in System Settings for the affected apps).
