> Swamped curl maintainers take low-level flaws public to survive vulnerability 'avalanche'

An "avalanche of vulnerability reports" is forcing curl to move lower-severity cases into public view, reserving private handling for high and critical flaws. From October 26, low and medium-severity reports should be filed in the open source data transfer tool's public GitHub repository, maintainer Daniel Stenberg said. "Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90 percent of all submissions could quickly be assessed to be less than HIGH." Stenberg already shuttered curl's bug bounty scheme this year as AI-generated submissions piled work onto its security team. Stenberg has previously acknowledged that not all AI-assisted reports are bad, but the workload now demands another response. "This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. "We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown." Public handling would let more people assess reports, develop fixes, write advisories, and check for related problems before releases ship, Stenberg said. Handling vulnerability reports publicly won't reduce the work per report, he admits, though it could spread the load and make the resulting lessons and documentation easier to find. At least that's the theory. Public disclosure also gives attackers more time to exploit flaws before fixes arrive. The maintainer agrees this is unfortunate yet unavoidable. "We limit this practice to less than HIGH for this reason: at least these problems are not terrible." Stenberg said researchers using AI are generating unusual option combinations unlikely to occur in real applications, then treating minor discrepancies as vulnerabilities. "We can't continue down this spiraling path with our sanity intact. We don't have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way." ®