The most useful vulnerability report is a boring one: a clear title, the exact steps to reproduce, what you expected, and what actually happened. A working proof-of-concept saves everyone hours and removes any doubt about whether the issue is real.
Skip the hype. 'I found a critical!' with no steps is noise; 'here is a request that returns another user's data, step by step' is signal.
Say what an attacker could actually do with the bug, and how hard it would be. Overstating severity burns trust; understating it gets the fix deprioritised. A calm, accurate impact statement is what lets a team triage correctly.
If you're unsure of severity, describe the primitive you have and let the owner weigh it — that's a collaboration, not a competition.
Report privately first and give a reasonable window to remediate before any public write-up. Good disclosure is a conversation: acknowledge, investigate, fix, verify, then agree on if and how it gets published.
The goal was never to embarrass anyone. It's to close the hole and leave the product safer than you found it.