Sharing is caring

Whether you hack to find vulnerabilities or build tools to protect networks, your work is appreciated. It's even more appreciated when you decide to share it with others. At Packet Storm, we welcome any sort of data you think will be relevant to the security community — with a few exceptions, as noted below. We have a project in the pipeline to streamline this process via the web, but for now, we are continuing the process already in place. All new submissions should be emailed to submissions at packetstormsecurity.com.

Preparing to submit a news article

Submitting a news article is as simple as sending us the link and a note stating why you think we should provide the article to our audience. If you send just the URL, there's a non-zero chance it will end up in a spam folder.

Preparing to submit a file

Packet Storm tries very hard to ensure quality metadata around entries. The more accurate the data provided by the party submitting the entry, the better. If the necessary data is provided inside of a file, we can usually extract it with little overhead. But to be 100% certain we get it right, we ask that you provide the following details. Metadata should be provided in English, even if the content of the data is in another spoken language. We will note as such in the description. The metadata can be sent in the body of your email, with the file attached. Packet Storm reserves the right to modify metadata (such as titles and descriptions) to ensure clarity for entries. Below is a full breakdown of the required metadata. Use the table to ensure a speedy submission process and minimize the need for us to ask questions and delay the posting.

Title	The title of entry is the first thing a user will see when your entry comes up. Titles can be up to 150 characters long and should not contain any special characters. Whitepapers and arbitrary research may have a title that is more freeform, but the title still needs to be descriptive. Advisories and exploits would ideally follow the syntax of software name, latest software version affected, and the types of vulnerabilities discussed (e.g. Fake CMS 1.2.3 Shell Upload.
Description	The description is a verbose explanation of what's in the file. Keep this under 1,024 characters, if possible.
Source URL	If there's a related homepage or project page for the given file and/or research, please provide it.
Source Name/Email	If there is an author, researcher, or individual who deserves credit related to the file, please provide these details. Multiple sources may be provided to us. For each name provided, provide an email address if you want it included on Packet Storm. Please also note, that if a source also has an account on Packet Storm, the addition of a matching email address is required in order to link the entry to their personal page.
CVEs	If a CVE or set of CVEs have been provided for your findings, please include them so we can ensure they are mapped.
Software URL	A URL for the source of the software is appreciated and helps our users validate whether or not they are using the software identified. Software can frequently have very similar names.

Example email body

Title: Example CMS 1.2.3 Remote Shell Upload

Description: Example CMS version 1.2.3 suffers from a remote shell upload due to a lack of validation in the profile picture upload flow.

Source URL: https://packetstormsecurity.com/help/8

Source Name/Email: John Smith (jsmith@packetstormsecurity.com), Jane Smith

CVEs: CVE-2024-9999999

Software URL: https://examplesite/



[ Proof of concept or any additional useful data explaining the issue ]

Version inclusion

We tend to draw a hard line requiring inclusion of the versions affected when adding vulnerabilities. Occasionally, if a version is not provided by the software or there are extenuating circumstances, we may add an entry without this data. However, we aim to always include affected versions. Doing so ensures that when a patch is released to address the security issue, the entry in our database does not become invalid. Producers of software complain if they have addressed an issue but there is still data out there saying otherwise, so it's important that both software vendors and researchers are very open about versions affected and when versions are patched fully. We archive historical artifacts regarding past versions of software, regardless if patches have addressed the issue. As no one is capable of time travel (yet) and no one is capable of guaranteeing that all vulnerable versions have been sought out and backpatched, these records are retained in perpetuity.

Quality expectations

When creating reports, it can be second-nature to leave out critical details that our brains automatically tell us are a given. But if you want your research to educate the most people possible, be verbose. If you can, explain the vulnerabilities discovered, what the implications are, the data at risk, the vector of attack, any mitigations (if they exist), ways to be contacted, interaction you've had with the software vendor (if any), and any other details you feel might be relevant.

Types of data we post

Freeware / open-source tools

It is rare we will ever post binary executables unless you are a well-known user and also provide the source code. It is preferred that your tool is built in a way that it is more than a simple script. At the very least, provide versioning in your tool if you plan to provide more than one release. For the sake of integrity, Packet Storm does not generally swap out files that have already been published unless there is a typo or other issue that makes it unavoidable. We do this to ensure we can go back and reference the exact tool on file in case there are reports of malfeasance that need to be investigated. For tools, we expect to archive the older versions and publish new versions as they come out.

Whitepapers

Research papers and technical specifications are always important to us.

Advisories / exploits

Advisories and exploits are usually submitted as text files or PDFs. Some researchers are very verbose and provide great overviews of how they came to find the issue, exactly what caused the issue, and how it can be remediated, along with their discussion data with the vendors affected. Some researchers just provide a few lines of text that identify the exact issue. Mileage varies and Packet Storm doesn't control the reports that come in — nor their level of quality.

Formats we post

Text, PDF, scripts, and compressed archives (.tgz, .zip, etc.) will be accepted.

General things we do not post

Videos
Word documents
Any document that boils down to a marketing or sales pitch
Personal data on individuals including data dumps from breaches

Denials and rollups

Duplicative entries will be denied. Packet Storm receives a large amount of data to triage on a daily basis. In order to be able to adequately ensure all data is pushed live in a timely fashion, we have to do this in the most streamlined fashion possible. If a researcher found a cross-site scripting (XSS) vulnerability in Packet Storm version 0.1 and we published it, and then another researcher finds the same issue (or same type of issue) for that exact software and exact version of the software, we will not publish the second submission because the data is duplicative. We give you kudos for discovering it (again), and sometimes a case is to be made for the extra data being posted, but in general, duplicates are denied. You can search Packet Storm to see if a given vulnerability already exists in a given piece of software prior to submission.

Similarly, if a researcher sends us multiple findings for the same type of vulnerability that affects the same version of software, we will not post the findings as individual entries. If Packet Storm 0.1 has 30 XSS findings submitted to us as individual findings, we will concatenate the data together and it will be added as one entry. This saves us valuable time in getting the data to our audience.

If you have any questions or thoughts prior to a submission, just shoot us an email.

Securely submitting your work

Use our GPG key and make sure we have yours. Packet Storm's key can be found here.