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!
Mail exploits, papers, and shellcode to: , but:
- 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
Mail all GHDB submissions to:
- 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.