On 26 January 2026 the curl maintainer announced the end of curl's bug bounty, effective 31 January 2026. He wrote that the share of confirmed vulnerabilities among reports had been "somewhere north of 15%" in earlier years and "plummeted to below 5%" starting in 2025. Over the life of the program curl had confirmed 87 vulnerabilities and paid over 100,000 USD.
You do not need a bounty to get this problem. A published security@ address and a security.txt file are enough. This post is about what to do when the inbox fills with scanner output.
What's affected
Any team with a public reporting channel. Seth Larson of the Python Software Foundation described the pattern in December 2024: reports that "appear legitimate at first, requiring time to refute." The usual contents, grouped by what to do about them:
| Report says | Usual verdict | Notes |
|---|---|---|
| Missing security header on a marketing page | Not a vulnerability by itself | Real only if you show an exploit path |
| SPF, DKIM or DMARC records | Out of scope | GitHub's ineligible list names "DMARC, SPF and DKIM email policy" |
| Clickjacking | Depends on the page | GitHub lists "Clickjacking a static site" as ineligible |
| No rate limiting | Out of scope without impact | Listed as ineligible by GitHub |
| Username or email enumeration | Usually out of scope | Listed as ineligible by GitHub |
| Outdated library version | Needs a reachable flaw | GitHub lists "Use of known-vulnerable software" |
| Host header injection | Needs a demonstrated attack | Also on GitHub's list |
GitHub's list is one company's rules, not a standard. It is still a good starting point for your own out-of-scope section.
How to check if you're exposed
Read your last 20 reports and tag each one: real, partly real, scanner output, or unreadable. If more than half are noise, the problem is your intake, not your product.
# What does a scanner see on your marketing site?
curl -sI https://example.com | grep -i -E 'strict-transport|content-security|x-frame|x-content-type'
If that shows missing headers, fix them. It is cheaper than answering the same report forty times.
What to do now
- Add an out-of-scope list to your policy, and include "automated scanner output without a demonstrated impact."
- Ask for three things in every report: the affected URL or version, steps to reproduce, and what an attacker gains. Reports without them get one reply asking for them.
- Use a short template. Larson's advice is to put in the same effort the reporter did, reply briefly, ask for justification, and move on if nobody answers.
Thanks for writing. We could not reproduce an impact from this report.
Please send the steps, the affected URL and what an attacker gains.
If we hear nothing in 7 days we will close it. Our scope is at
https://example.com/security.
- Check the reporter. A brand new account, no public identity or a trail of low quality credited reports is a signal.
- Check whether the flaw is in your product or in the reporter's proof of concept.
- Keep a "closed as not applicable" label so you can count and, later, tighten the policy.
- Never switch the channel off. Real reports are rare and valuable.
How to avoid this trap
- Publish scope, so a reporter knows in advance that header nits are out.
- Do not pay for volume. The curl post suspects the money incentive drives much of the abuse.
- Fix cheap findings in bulk, such as missing headers, so the same scanner stops producing the same report.
- Keep one person on triage with a rotation, so the work does not wear down one maintainer.
Why it matters
The curl announcement lists three trends: an explosion in low quality AI reports, lower quality in reports that were not obviously slop, and reporters with a bad faith attitude. The result is a team that stops reading. A brief template and a clear scope are how a small team stays able to read the one report in twenty that is real.
Try it yourself
Run a scan against a test copy of your own app, then sort every finding into "reachable by an attacker with impact" and "not." That is the same sort you will apply to inbound reports.
Click through it at your own pace, or open it full screen.
Quick check
Is a missing security header always safe to ignore?
No. It is not a vulnerability on its own, but it can matter on a page with sensitive actions. Ask for the exploit path.
What should a first reply to a vague report ask for?
The affected URL or version, reproduction steps, and what an attacker gains.
