Welcome to the

Central Security Project

Sonatype, Inc. (“Sonatype”) has established the Central Security Project with the goal of keeping the Maven ecosystem safe by providing a place for the security community to report security issues found in open source Maven components (each a “Vulnerability”).

If you believe that you have found a Vulnerability, we encourage you to notify us, and we welcome the opportunity to work with you to resolve the issue promptly. Working together, we hope to make the Maven ecosystem better for everyone who uses it.

How it Works/ Disclosure Timeline

A Vulnerability is submitted to the Central Security Project:

If the Vulnerability is not a self-disclosure and Sonatype deems the Vulnerability valid, project maintainers are notified by HackerOne and have 90 days to make a fix available prior to the Vulnerability being made publicly available;
If the Central Security Project team has evidence of active exploitation or imminent public harm, they may immediately provide remediation details to the public so that users can take protective action.
If the project maintainer makes a fix available within the 90-day period, the public advisory is finalized and a CVE is assigned;
If no fix is available after the 90-day period, the advisory will be made publicly available;
If the project requires more than 90 days, Sonatype will attempt to communicate a timeline with all parties involved and may extend the 90 day non-disclosure period; Sonatype will endeavor to keep the submitter generally informed throughout this process.

Thank you for helping to keep the Maven ecosystem safe!

Disclosure Example

Below is a summary of how a disclosure would be made and evaluated via the Central Security Project process, using CVE-2018-8006 as an example. Note that the information related to this example is fairly complete, and that you may not be able to provide all of the information outlined below. That is ok - just be sure to provide as much as possible when making a submission.

Disclosure Details

Though we strive to provide accurate identification of each vulnerable component, we realize that this is not always easy depending on the technique of discovery. The more information that we receive about a reported Vulnerability, the better equipped we are to evaluate and properly analyze it. If all of the information below is not available for a submission that you would like to make, please provide as much information and detail as possible to assist in locating the root cause of the Vulnerability. The information below will assist our security research team in validating your disclosure:

Component Identification

Please precisely identify the project (group ID) and component (artifact ID). The Central Search and the OSS Index Search are available to help with this identification. Please provide the following information to the extent available to you:

groupId: org.apache.activemq (Note that this was found in the POM file. Also note that if an element such as the does not exist outside of the element, then it inherits from the parent and we use that one.)

artifactId: activemq-web-console (Note that this was found in the same POM file as the Group ID.)
version: 5.15.0 - 5.15.4 are affected (Supply any versions you know to be affected as a list or range. If you have only tested one or two versions that is fine, just list the ones that you know to be affected.)

Vulnerability

Vulnerability Information

Please provide a detailed description of the Vulnerability, how it was found, how it can be exploited, and how it harms package users.

The QueueFilter parameter on the /admin/queues.jsp page reflects back in the response to the browser without any sanitization. An attacker can craft a link with JavaScript injected into the parameter's value, which will execute in the user's browser. The executed script can steal a user's session cookie, modify the page in an effort to phish for information, or any number of other things that can affect confidentiality and integrity.

Additional Details

Please provide any other details that you believe would be helpful when evaluating the Vulnerability including the following (to the extent available):

Source File and Line Number: Specific line of code where vulnerability exists (preferably a link to the repo, i.e. GitHub)
Vulnerable File(s): If not already covered by or is different than the "Source File and Line Number"
Vulnerability Introduction: Where the vulnerability was introduced (preferably a link to a commit)

Source File and Line Number: https://github.com/apache/activemq/blob/04b60cb188932a91be9f59d6cda09290219d8a45/activemq-web-console/src/main/webapp/queues.jsp#L49 and https://github.com/apache/activemq/blob/04b60cb188932a91be9f59d6cda09290219d8a45/activemq-web-console/src/main/webapp/queues.jsp#L57 (In this case links to a publicly available online source repository were provided. This is the easiest way to convey this information. However, if this is not possible, you can just write this information out.)

Vulnerable File(s): activemq/activemq-web-console/src/main/webapp/queues.jsp and/or /admin/queue.jsp (Note that if the source file information was already given this field is often times not necessary. This field is useful when the either the source file is not given at all or the source file is different than than the class file. For example the vulnerability exists within an inner class.)
Vulnerability Introduction: https://github.com/apache/activemq/commit/0b767fcb0c622810c01e54bd51bc9680e36f81f5#diff-fc7835a6f811e2959e1af8fdae430b81R47 and https://github.com/apache/activemq/commit/0b767fcb0c622810c01e54bd51bc9680e36f81f5#diff-fc7835a6f811e2959e1af8fdae430b81R55 (Note that tracing the vulnerability back to its introduction can be somewhat time consuming, but is quite valuable. If you have the time and means to do so, it is greatly appreciated. Also note that in this case both instances were introduced in the same commit. If they were not, having the introduction links to both is ideal.)

Steps To Reproduce

Please provide a detailed description of the steps required in order to reproduce the Vulnerability along with all required references/steps/commands. Any sample/exploit code or other proof of concept that you can share would be very helpful.

Craft a link such as http://localhost:8161/admin/queues.jsp?QueueFilter=foo%22%3e%3cscript%3ealert(%22XSS%22)%3c%2fscript%3bar and visit it in your browser. This particular injected script will cause an "XSS" popup to appear.

Patch

If you're able to provide a patch with the fix, please post it in this section (or attach)

Supporting Material/References

Please provide all available technical information about the stack where the Vulnerability was found, such as:

[OPERATING SYSTEM VERSION]
[JAVA VERSION]
[MAVEN VERSION]
[BROWSERS VERSIONS, IF APPLICABLE]
[OTHER SOFTWARE USED TO EXPLOIT VULNERABILITY AND THEIR VERSIONS, IF APPLICABLE]

State all technical information about the stack where the vulnerability was found

macOS Sierra 10.12.6
openjdk version "11.0.1" 2018-10-16, OpenJDK Runtime Environment 18.9 (build 11.0.1+13), OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
Maven 3.6.0
Chrome 70.0.3538.110 (Official Build) (64-bit)

Legal Disclaimer

Sonatype is not responsible for resolving any Vulnerability submitted to the Central Security Project. Instead, Sonatype will evaluate each submitted Vulnerability and, if Sonatype deems the Vulnerability valid, which it shall determine in its sole discretion, Sonatype will work with HackerOne to notify the identified project of the Vulnerability on your behalf. You agree that the identified project may contact you for additional information as it works to resolve the Vulnerability. Except to the extent that Sonatype itself manages the identified project, Sonatype is not responsible for any project maintainers’ actions or omissions, including with respect to your submitted Vulnerability. YOU HEREBY WAIVE ANY AND ALL CLAIMS YOU MAY HAVE AGAINST SONATYPE AND/OR THE CENTRAL SECURITY PROJECT FOR ANY ACTION TAKEN BY, OR OMISSION OF, SONATYPE AND/OR THE CENTRAL SECURITY PROJECT TEAM REGARDING ANY VULNERABILITY SUBMITTED BY YOU TO THE CENTRAL SECURITY PROJECT AND/OR SONATYPE.

Because HackerOne will report the Vulnerability to the identified project on your behalf, you agree to abide by the terms and conditions of HackerOne’s Vulnerability Disclosure Guidelines (subject to the Central Security Project’s alternative disclosure timeline set out above).

Sonatype does not offer or collect any bounties or other rewards in connection with the Vulnerabilities submitted via the Central Security Project. Moreover, to the extent that a project associated with a Maven component offers a bounty or other reward for a Vulnerability that you submit through the Central Security Project, you may be waiving your right to claim the bounty or other reward for such submission. If you are interested in collecting a bounty or other reward offered by a specific Maven project, please refer to the guidelines provided by such project prior to submitting the Vulnerability to the Central Security Project.