When I was first starting bug hunting it was fairly unclear still what you should include into your vulnerability reports, especially if you don't have a reporting platform with required* fields.

I've been doing this on/off for some time now and I decided to create a template for reporting these if you end up filing these via email.

First things first, most companies actually have public facing emails (pr, press, contact etc.) and contact forms that can be useful to initiate first contact.
It is recommended that you don't send a report directly using these unless you know you reach the right people, as in some cases these might be some 3rd party customer support team somewhere down the supply chain, without direct contact to your actual customers security team, but let them know that you've found a vulnerability with rating X and that you'd like to have contact for, or be contacted by the information security team.
Getting through these channels can take number of days to weeks, usually just days, patience is a virtue.

When you have the right person on the line, you should send the report. BUT due note, if you have a super critical RCE or SQLi vulnerability that may affect a large number personal data, it is also worth considering using asymmetric encryption algoritms to protect the email communications, but I will not cover this here.

Please remove Example details from the report below before using 😅

TEMPLATE:
Vulnerability Type(s):

[List any vulnerabilities that may be connected to this single vulnerability, this can be basically contain anything from misconfiguration or an open redirect to an RCE]

• Open Redirection

Vulnerable Assets:

[List Assets here, this list could contain anything from indivual URLs to installed server components affected]

https://example.com/webshop/checkout-cancel?redirect=

Description:

[Explain the vulnerabilities and their impact in DETAIL and explain the path you took to reach that vulnerability, this portion can be long and should be well centered around the problems(s) found.]

I was doing shopping on your website, I was about to checkout but remembered another product which I still needed to add to my cart so I cancelled the process, while doing so I noticed that you were doing a redirect on the cancel button.

I decided to test putting random URLs after the redirect and it seems that it allows redirection to any URL.

POC Exploit:

[I Exploit available. Ask how the customer prefers these to be delivered, attaching a zip or a script file to an email may just end up in quarantine]

I will not be providing an exploit for this vulnerability as it is easy for you to reproduce, instead I'll write an example attack scenario:

1. Domain exampie.com is currently free and can be typosquatted (social engineering)
2. Set up email records for this domain and generate example rewards template for your webshop showing them that they've been rewarded product X, I'll get this template and the product details directly from your previous marketing campaign emails from date: xx.xx.xxxx (social engineering)
3. Setup a copy website of your login page to gather users credentials (phish)
4. On login, forward them to a form for shipping details (phish)
5. After shipping details forward to a postage details asking for credit card details (phish)

Attacker will walk out with: Username, Password, Home Address, Creditcard

Recommended Remediation Options:

[Add here X number of examples on how this should and could be fixed detailing possible dendencies or affected components if known.]

It is recommended that any redirection functions operate with separate Allow lists to fulfill operational needs. [if you have idenfied their web framework you can give articles here]

[Additional Notes]

Hope to hear from you in the near future 😊

[Signature]