Reports Are Engineering Documents
A vulnerability report is not only a message to a bounty platform or vendor. It is an engineering document. It should describe a broken security assumption, show reproducible evidence, explain impact, and help the maintainer fix the root cause.
The best reports are concise but complete. They avoid vague claims, unnecessary screenshots, and dramatic language. They give enough detail for a developer or triager to reproduce the issue without guessing.
Clear Impact
Impact should be stated in terms of what an attacker can do that should not be possible. Can a low-privilege user access another user's data? Can unauthenticated input reach an internal network request? Can stored content execute in an administrator session? Can a file be read, written, deleted, or executed?
I avoid relying only on vulnerability class names. Saying 'IDOR' or 'XSS' is not enough. The report should explain the boundary crossed and the consequence of crossing it.
Reproduction Steps
Reproduction steps should be exact. I include role, version, configuration, request sequence, important parameters, and expected result. If a step requires a special condition, such as a plugin setting, user role, cache state, or existing object, that condition should be explicit.
For request-based findings, I prefer to include the minimal HTTP request and response evidence. For source-based findings, I include the relevant code path and explain how the attacker reaches it. For chain-based findings, each step should have its own proof.
Root Cause
A good report identifies the failing control. Missing capability check, missing object ownership validation, unsafe path normalization, unescaped output, weak parser behavior, SSRF allowlist bypass, insecure deserialization, and unsafe command construction all require different fixes.
If the root cause is clear, the fix is more likely to be correct. If the report only shows payload behavior, the patch may block the payload but leave the vulnerable design intact.
Communication
Disclosure is a technical process and a communication process. Triagers may ask for clarification, reduced proofs, affected versions, or safer impact demonstrations. Keeping notes organized makes those responses easier.
I try to keep communication factual. If the issue is valid, the evidence should show it. If the impact is limited, the report should say so. Trust is built by being accurate, reproducible, and clear.