16. Security Issues Information¶
- 16.1. CVE-2010-0009: Apache CouchDB Timing Attack Vulnerability
- 16.2. CVE-2010-2234: Apache CouchDB Cross Site Request Forgery Attack
- 16.3. CVE-2010-3854: Apache CouchDB Cross Site Scripting Issue
- 16.4. CVE-2012-5641: Information disclosure via unescaped backslashes in URLs on Windows
- 16.5. CVE-2012-5649: JSONP arbitrary code execution with Adobe Flash
- 16.6. CVE-2012-5650: DOM based Cross-Site Scripting via Futon UI
- 16.7. CVE-2014-2668: DoS (CPU and memory consumption) via the count parameter to /_uuids
- 16.8. CVE-2017-12635: Apache CouchDB Remote Privilege Escalation
- 16.9. CVE-2017-12636: Apache CouchDB Remote Code Execution
- 16.10. CVE-2018-11769: Apache CouchDB Remote Code Execution
- 16.11. CVE-2018-8007: Apache CouchDB Remote Code Execution
17. 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.
- 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
The private security mailing address is: email@example.com
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.