Title
Vulnerability type, where it is, what it allows. HackerOne’s own example sets a stored XSS in a named field, with its effect, against a bare vulnerability class.
Vulnerability type in feature or endpoint allows what the attacker does
Summary
The form asks for asset, weakness and severity before the write-up. Since 21 September 2026 a severity is required on every programme that has not opted out. Use the calculator the programme lists: CVSS 3.0, 3.1, 4.0 or manual.
- Asset: the in-scope asset, exactly as the programme lists it
- Weakness: the weakness you selected on the form
- Severity: None, Low, Medium, High or Critical, vector
CVSS vector in the version the programme uses - Tested on: URL or build, version, release or commit, date and time in UTC
One paragraph: what the vulnerability is and what an attacker gets from it.
Steps to Reproduce
Numbered steps a triager follows without asking a question. Give the URL, the parameter and the role of every account. A report left in Needs More Info for more than 30 days closes as Informative.
Accounts: attacker account and its role, victim account and its role. Both are test accounts you own.
- Log in as the attacker account and open the URL.
- Send this request, with the parameter and the value.
- Observe the response or the state change, with the exact value.
Expected vs Actual Behavior
One line each. The expected line cites where the rule comes from: documentation, the permission model, the programme’s own policy.
- Expected: what the application should do, and the source of that rule
- Actual: what it does
Impact
What an attacker does with it, to whom, at what scale. Not Applicable is the state for a report whose security implications were not demonstrated, and it costs 5 reputation. Argue each CVSS metric you set: self sign-up means Privileges Required is None, and an unpredictable ID means Attack Complexity is High until you show how the ID is obtained.
What the attacker reads, changes or takes over, for which users, and how many.
- Preconditions: none, or what the attacker needs first
- User interaction: none, or what the victim has to do
- Mitigations already in place that do not stop it: list
Supporting Material
The request and the response, or the command and its output, in code blocks. Attach screenshots and recordings as files. A link to a hosted video is not accepted.
{The request}
{The response, trimmed to the part that proves the point}
Attached: file names of screenshots or the recording
Remediation
Optional on HackerOne. Include it when you know where the check belongs.
The check that is missing and where it belongs.
Limits and non-claims
Say where testing stopped. The platform standards require testing to stop the moment sensitive personal data is exposed, and the core ineligible list closes findings that rest on unlikely interaction.
- Testing stopped at: the point you stopped, for example after reading one record of your own second account
- Not claimed: what this report does not say, for example no access to other tenants
- Depends on: browser, configuration or feature flag the behaviour needs
Known issues checked
A report on something the programme already knows closes as Duplicate, or as Informative when the issue is listed on its security page. Name the nearest known item and state the difference.
- Programme policy, exclusions and known issues: date checked, the nearest item, why this differs
- Disclosed reports on this programme: the nearest report, why the root cause or the endpoint differs
- Core ineligible findings: the nearest category, and the demonstrated impact that takes this out of it
Markdown sourcehackerone.md
> HackerOne report template from https://bountyoperator.com/templates/hackerone. Platform rules checked 2 Oct 2026.
> Replace every {placeholder}. Delete this note before you submit.
# {Vulnerability type} in {feature or endpoint} allows {what the attacker does}
## Summary
- Asset: {the in-scope asset, exactly as the programme lists it}
- Weakness: {the weakness you selected on the form}
- Severity: {None, Low, Medium, High or Critical}, vector `{CVSS vector in the version the programme uses}`
- Tested on: {URL or build}, {version, release or commit}, {date and time in UTC}
{One paragraph: what the vulnerability is and what an attacker gets from it.}
## Steps to Reproduce
Accounts: {attacker account and its role}, {victim account and its role}. Both are test accounts you own.
1. {Log in as the attacker account and open the URL.}
2. {Send this request, with the parameter and the value.}
3. {Observe the response or the state change, with the exact value.}
## Expected vs Actual Behavior
- Expected: {what the application should do, and the source of that rule}
- Actual: {what it does}
## Impact
{What the attacker reads, changes or takes over, for which users, and how many.}
- Preconditions: {none, or what the attacker needs first}
- User interaction: {none, or what the victim has to do}
- Mitigations already in place that do not stop it: {list}
## Supporting Material
```http
{The request}
```
```http
{The response, trimmed to the part that proves the point}
```
Attached: {file names of screenshots or the recording}
## Remediation
{The check that is missing and where it belongs.}
## Limits and non-claims
- Testing stopped at: {the point you stopped, for example after reading one record of your own second account}
- Not claimed: {what this report does not say, for example no access to other tenants}
- Depends on: {browser, configuration or feature flag the behaviour needs}
## Known issues checked
- Programme policy, exclusions and known issues: {date checked, the nearest item, why this differs}
- Disclosed reports on this programme: {the nearest report, why the root cause or the endpoint differs}
- Core ineligible findings: {the nearest category, and the demonstrated impact that takes this out of it}