How to submit a proper report?
Finding a security vulnerability is very cool. However, properly reporting and communicating that vulnerability is equally important. In this article, we go through a detailed overview of how to submit a security vulnerability to Patchstack properly.
Reporting a security issue can be divided into three parts:
- Details of the affected component
- Details of the vulnerability
- Details of the researcher (For first-timers)
Submmiting a Report
Submitting your first report?
You need to go to this page.
Already submitted at least one valid report?
We have a researcher portal for those who’ve submitted at least one valid bug. You can access the portal here.
- Go to https://vdp.patchstack.com/researchers/login and enter your email
- Check your email for the login link (in some cases it’s worth also checking the spam folder)
- Access the portal and click on New report
Make sure to read the Bug Bounty Guidelines & Rules before submitting the report.
Component Details
Now, we’ll go through all the fields of the component details.
Component type
You need to select whether the issue was found in a plugin, theme, or the WP core itself.
Example:
Component Name
This field is self-explanatory. The name of the affected component needs to be entered in this field.
Vulnerable version
This field needs to be filled with the vulnerable version of the plugin/theme. For example, if the vulnerable version is 13.37, the field value should be <= 13.37. While the <= is optional, we recommend setting it up since the vulnerable version is not 13.37 only but up to 13.37.
Component Slug
This field needs to have the slug of the affected component. You can access the plugin slug through the plugin repository in WordPress. The format looks like this: https://wordpress.org/plugins/SLUG where SLUG is the plugin slug. It is the same for themes.
Component Link
A link to the component repository where one can download/access the plugin/theme. For an example: https://wordpress.org/plugins/elementor
Example:
Vulnerability Details
After the component information is completed, it’s time to enter the vulnerability details. This is the most crucial part of the report and plays a huge role in how quickly the report is processed.
OWASP 2017: TOP 10
Vulnerability class
Select the proper OWASP Top 10 vulnerability class from the drop-down menu. If you cannot find the exact match for the issue you’ve found, try to select the closest bug class that resembles the vulnerability.
Vulnerability type
This field offers a wider range of vulnerability types. Select the proper class from the list. If you cannot find the match here too, you can select the Unknown option.
Example:
Pre-requisite
You need to select the least privilege required to exploit the vulnerability.
Example:
Vulnerability details
Short description
This field requires brief information about the vulnerability. It can be a short description of what the vulnerability is, what is affected and what’s the impact of it.
How to reproduce
A clear step-by-step instruction on how to reproduce the issue the issue is the most important part of reporting. This field needs to be filled with that data. You may include HTTP requests, PoC scripts, prerequisite steps, and all the necessary details for reproducing the vulnerability in this field.
Additional information
This is an optional field that can be used to provide additional information that might be a help for triggers and vendors. Code tracing of the vulnerability and mitigating suggestions are examples of such information.
Attach files
This is also an optional field if you wish to attach video PoC or scripts. A full report in a PDF or a text file with all the necessary information is also accepted.
Example:
Submitter details
This field is not needed if you are submitting the report through our researcher portal. For the first reporters, this is required.
How not to report?
- Wrong component information
- Attaching a video PoC only
- Description of the vulnerability without a proper PoC
Contributors
