You need to be added to the ContributorsGroup to edit the wiki. But don't worry! Just email any Mailing List or grab us on IRC and let us know your user name. |
Security
This page explains the CouchDB and Apache Security Policies and links to a list of known vulnerabilities.
List of Vulnerabilities
31.03.2010: CVE-2010-0009 affects all versions of Apache CouchDB prior to 0.11.0.
21.02.2010: CVE-2010-2234 affects all versions of Apache CouchDB prior to 0.11.2.
28.01.2011: CVE-2010-3854 affects all versions of Apache CouchDB prior to 1.0.1.
14.01.2013: CVE-2012-5641 affects all versions.
14.01.2013: CVE-2012-5650 affects all versions.
14.01.2013: CVE-2012-5651 affects all versions.
Reporting New Security Problems with Apache CouchDB
The Apache Software Foundation takes a very active stance in eliminating security problems and denial of service attacks against Apache CouchDB.
We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum.
Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities in Apache CouchDB and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem in the Apache CouchDB source code will be ignored.
If you need to report a bug that isn't an undisclosed security vulnerability, please use the bug reporting page.
Questions about:
- how to configure CouchDB securely
- if a vulnerability applies to your particular application
- obtaining further information on a published vulnerability
- availability of patches and/or new releases
should be address to the [users mailing list][lists]. Please see the mailing lists page for details of how to subscribe.
The private security mailing address is: security@couchdb.apache.org
Please read how the Apache Software Foundation handles security reports to know what to expect.
Note that all networked servers are subject to denial of service attacks, and we cannot promise magic workarounds to generic problems (such as a client streaming lots of data to your server, or re-requesting the same URL repeatedly). In general our philosophy is to avoid any attacks which can cause the server to consume resources in a non-linear relationship to the size of inputs.