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:
# Exploit Title: [title] # 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.