Vulnerabilities (CVE)

Filtered by vendor Apache Subscribe
Filtered by product Couchdb
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2022-24706 1 Apache 1 Couchdb 2022-07-13 10.0 HIGH 9.8 CRITICAL
In Apache CouchDB prior to 3.2.2, an attacker can access an improperly secured default installation without authenticating and gain admin privileges. The CouchDB documentation has always made recommendations for properly securing an installation, including recommending using a firewall in front of all CouchDB installations.
CVE-2020-1955 1 Apache 1 Couchdb 2021-07-21 6.8 MEDIUM 9.8 CRITICAL
CouchDB version 3.0.0 shipped with a new configuration setting that governs access control to the entire database server called `require_valid_user_except_for_up`. It was meant as an extension to the long standing setting `require_valid_user`, which in turn requires that any and all requests to CouchDB will have to be made with valid credentials, effectively forbidding any anonymous requests. The new `require_valid_user_except_for_up` is an off-by-default setting that was meant to allow requiring valid credentials for all endpoints except for the `/_up` endpoint. However, the implementation of this made an error that lead to not enforcing credentials on any endpoint, when enabled. CouchDB versions 3.0.1[1] and 3.1.0[2] fix this issue.
CVE-2017-12635 1 Apache 1 Couchdb 2019-10-03 10.0 HIGH 9.8 CRITICAL
Due to differences in the Erlang-based JSON parser and JavaScript-based JSON parser, it is possible in Apache CouchDB before 1.7.0 and 2.x before 2.1.1 to submit _users documents with duplicate keys for 'roles' used for access control within the database, including the special case '_admin' role, that denotes administrative users. In combination with CVE-2017-12636 (Remote Code Execution), this can be used to give non-admin users access to arbitrary shell commands on the server as the database system user. The JSON parser differences result in behaviour that if two 'roles' keys are available in the JSON, the second one will be used for authorising the document write, but the first 'roles' key is used for subsequent authorization for the newly created user. By design, users can not assign themselves roles. The vulnerability allows non-admin users to give themselves admin privileges.