Title: Solr™ Vulnerability Reporting Procedure URL: security-reporting.html save_as: security-reporting.html template: security-reporting
This page documents the procedure for reporting a security vulnerability in Apache Solr and explains what happens after a report is submitted. It also provides canned email templates for PMC members to use when responding to reports.
Apache Solr is maintained by volunteers. The PMC will make every effort to respond promptly, but cannot guarantee specific response times. We appreciate your patience and your contribution to the security of the project.
If you have concerns about how the project team is handling a report, you may also contact security@apache.org directly.
Apache Solr follows the Apache Software Foundation's security process, which covers reporting, responsibility, private discussion, and CVE disclosure in detail. The rest of this page details this plan for the Solr project. If you have questions to these procedures, feel free to use our public mailing lists.
Ensure you have tested against a supported Solr version with both authentication and authorization properly configured. Solr's admin level APIs are designed to be used only by authenticated and trusted administrators.
A valid security report to security@solr.apache.org must:
| Step | Who | Timeframe |
|---|---|---|
| Initial triage / acknowledgment | PMC volunteers | Up to 7 days |
| Full investigation | PMC volunteers | Up to 90 days |
| CVE ID allocation | PMC + ASF Security Team (CNA) | During fix development |
| Fix + CVE publication | PMC + ASF Security Team | Coordinated with you, the reporter |
| Credit in advisory | PMC | At public disclosure |
Public disclosure follows the ASF standard process and is announced on the oss-security mailing list.
The following section documents the internal triage process and provides email templates for responding to incoming reports.
The following templates are provided for PMC members responding to incoming reports. Click each entry to expand and view the template.
We have received your report and created a private issue to track it. The Solr PMC will review your report and aim to update you within 90 days. We will keep you informed through this email thread.
Please do not discuss this report on public channels (mailing lists, GitHub, social media) until we have coordinated public disclosure with you.
If you have additional information, please reply to this email.
Apache Solr Security Team security@solr.apache.org https://solr.apache.org/security.html
We are unable to process reports that consist solely of scanner tool output without a demonstrated reproduction of the vulnerability in Apache Solr.
Scanner reports list dependency CVEs that are often not applicable to how Solr uses those libraries. Before filing a security report, please:
For dependency upgrade discussions, the public Solr users list is the right venue: users@solr.apache.org
Please read https://solr.apache.org/security-reporting.html for the full process.
Apache Solr Security Team
Your email appears to describe several separate potential vulnerabilities. To allow each issue to be tracked, fixed, and disclosed independently, please re-submit each as a separate email to security@solr.apache.org.
Each email should cover exactly one vulnerability with:
We will begin reviewing each issue once we receive the separate reports.
Please read https://solr.apache.org/security-reporting.html for the full process.
Apache Solr Security Team
For security reasons, the Solr PMC does not open zip file attachments or follow external links (Google Docs, Dropbox, etc.) in security reports.
Please re-send your report as plaintext in the body of an email to security@solr.apache.org, including:
We look forward to reviewing your report once re-submitted in plaintext.
Please read https://solr.apache.org/security-reporting.html for the full process.
Apache Solr Security Team
After reviewing your report, we are unable to treat this as a security vulnerability due to either of the following reasons:
a) The behavior requires Solr to be running without authentication. Solr is not designed for unauthenticated operation in any networked environment. Running without authentication is a misconfiguration, not a Solr vulnerability.
b) The action performed was permitted by the role used in your test. A vulnerability requires either that the action exceeded what the role should allow, or that it should never be permitted for any role.
If you believe our assessment is incorrect, please reply with details explaining why the behavior should not be possible under your tested configuration and role.
Please read https://solr.apache.org/security-reporting.html for the full process.
Apache Solr Security Team
Once a report passes initial triage, the PMC follows these steps: