We deal with dozens of submittals a day, verifying, testing and cataloging the exploits we receive. When possible, we go as far as testing the exploits in a lab environment, while archiving any vulnerable software on the way. As you can imagine, this process is both extremely time consuming and tedious – but you can help!
You can make our lives easier and more productive by following a few basic guidelines when sending us submissions – following these guidelines will speed the processing of your submission, and will get it to the front page faster. Here they are, read them well!
- We will NOT accept, process, or post any vulnerabilities that are targeted against live websites. This also applies to web/graphic design companies.
- With the exception of papers and shellcode, all submissions must contain exploit or proof-of-concept code. All submissions must be original and not simply ported from one language to another.
- Please submit only 1 exploit per email with the exploit title as the subject and the exploit as a file attachment (txt, c, py, pl, rb, etc.).
- The following types of submissions will not be accepted: Reflected/non-persistent cross site scripting (XSS), DLL hijacking vulnerabilities, Path disclosure vulnerabilities, Open redirect issues, Vulnerabilities that require admin access and Clickjacking vulnerabilities.
- When submitting an exploit, you should include the following headers at a minimum:
# Google Dork: [if applicable]
# Date: [date]
# Exploit Author: [author]
# Vendor Homepage: [link]
# Software Link: [download link if available]
# Version: [app version] (REQUIRED)
# Tested on: [relevant os]
# CVE : [if applicable]
Google Hacking Database Submissions
- Ensure that you make the subject of your email the title of the Google dork. For example: filetype:reg reg HKEY_CURRENT_USER SSHHOSTKEYS.
- Submit only 1 Google dork query per email. Multiple dorks in one email will not be processed.
- Search the database first to ensure that your dork has not already been discovered.