At a glance
Start with the facts a reader needs to judge the issue quickly.
[Specific weakness] in [feature] allows [demonstrated result]
Affected product, feature, and tested version or date.
Program rating, if assigned; otherwise label it as your assessment.
Fixed / mitigated / accepted / pending disclosure.
Context
Describe what the feature is supposed to do and the trust boundary it relies on. State the assumptions needed to reproduce the issue, such as account roles or prerequisite access.
Good summary: “A member of workspace A could request a record owned by workspace B by replacing the record identifier. The server returned the full record without checking workspace membership.”
The example above is illustrative. It does not describe a real target or claim a real finding.
Reproduction
- List the minimum prerequisites, including account permissions.
- Show the normal request or flow that establishes the expected behavior.
- Show the smallest change that triggers the vulnerable behavior.
- Include a redacted request and the relevant response excerpt.
- Explain how you confirmed that the result was not caused by your own access.
Use test data and redact tokens, personal information, internal hostnames, and identifiers that could expose users.
Impact and limits
Explain what an attacker could do with the access and which conditions they would need. Separate what you demonstrated from what might be possible. Avoid broad claims that the evidence does not support.
- Observed: the exact data or action verified in a controlled test.
- Potential: any broader effect, clearly labeled as an inference.
- Limits: permissions, rate limits, or other controls that constrain the issue.
Root cause and fix
Explain the likely broken check without assuming knowledge of private implementation. If the team shared a fix, summarize it at the level they approved for publication. A useful remediation note describes the missing authorization decision and the expected check.
Disclosure timeline
Record the report date, triage response, fix or mitigation, and permission or date of public disclosure. Use exact dates when you can verify them; omit sensitive private correspondence.
Takeaways
Close with the generalizable failure mode, the test that exposed it, and the defense that would have prevented it. Link to public advisories or vendor statements when available.
Use the Markdown starter as a private draft, then publish only after a disclosure check.
Open the starter file ↗