What Makes a Vulnerability Report Excellent

Curl maintainer Daniel Stenberg, who has triaged over 1,000 vulnerability reports, published a field guide on how to report vulnerabilities effectively. The guide emphasizes making reports easy for maintainers by including a clear summary, a reproducer, a patch, version details, and human communication. This guidance is crucial as AI-generated slop reports overwhelm open-source maintainers.

What Makes a Vulnerability Report Excellent curl maintainer Daniel Stenberg has triaged 1,000+ vulnerability reports. His field guide on reporting well is the other half of safe harbor — and the antidote to AI-generated slop. Cross-posted with commentary. The original — "Do excellent vulnerability reports" by Daniel Stenberg — is well worth reading in full. A huge amount of what we do at disclose.io is about one half of the disclosure handshake: making it safe for a researcher to walk up to an organization and say "here's a problem." Safe harbor, clear policy, a published point of contact — all of it exists to lower the cost of doing the right thing. But there's a second half, and it gets talked about far less: once you've got a safe channel to report through, report well . Daniel Stenberg — who maintains curl and has personally handled over a thousand vulnerability reports — just published a field guide on exactly that, and it's the clearest short version we've seen. What he's saying Stenberg's framing is blunt and correct: most maintainers are overloaded volunteers, and a vulnerability report lands as work on someone else's desk. The best researchers minimise that work. His checklist, in short: Open with the point. A few sentences up front: what the problem is and why it matters. Don't make the reader excavate it. Include a reproducer. Standalone, runnable code that demonstrates the issue beats any amount of prose. Offer a patch — even an imperfect one. As he puts it, "getting 80% towards the target is still valuable." Pin the versions. Where you found it, and the earliest version affected. Teams need this to write the advisory. Use the front door. Follow the project's stated reporting method; don't route around it. Confirm it's real before you send — not documented, intended behaviour. Stay in the conversation. Be available for follow-ups on severity, scope, and the advisory wording. Sound like a human — even especially when AI helped you find it. His one-line thesis: "Make your report as easy as possible for the team to manage." Our take Two things make this land for us. First, it's the other half of safe harbor. We spend a lot of breath arguing that organizations should protect the people who report to them. The reciprocal is just as real: a researcher who sends a tight, reproducible, good-faith report is protecting the maintainer's time and attention. That mutual consideration is the whole game. The internet's immune system only works when both sides hold up their end — policy that welcomes the report, and a report that respects the person receiving it. Second, the "sound like a human" point is quietly the most important one right now. AI has made it trivial to generate something that looks like a vulnerability report. Maintainers across open source are drowning in confident, well-formatted, completely wrong submissions — the curl project has been one of the loudest voices about exactly this. As the cost of producing a report falls to zero, the signal that matters is no longer formatting; it's whether a competent human stands behind it, has actually reproduced the issue, and will stay in the conversation. Stenberg's checklist is, read one way, a list of the things AI slop reports consistently fail to do. If you're building or refining a disclosure program, this is a useful companion piece: your VDP tells researchers how to report https://disclose.io/?ref=blog.disclose.io ; guidance like Daniel's tells them how to report well . The two meet in the middle, and that's where good outcomes actually happen. Read the full post: Do excellent vulnerability reports — daniel.haxx.se https://daniel.haxx.se/blog/2026/06/29/do-excellent-vulnerability-reports/?ref=blog.disclose.io