logo

Port 5984 – Apache CouchDB (HTTP/REST Document Database API)

Service:

Apache CouchDB

Protocol:

TCP

Port:

5984

Used for:

Default listener for Apache CouchDB's HTTP/REST API, the interface clients and admins use to read, write, and manage JSON documents over plain HTTP

Port 5984 is the default port for Apache CouchDB, an open-source document-oriented NoSQL database. Unlike most databases, CouchDB has no separate binary wire protocol — everything happens over an ordinary HTTP/REST API on port 5984, so you administer it, query it, and read or write JSON documents with nothing more than curl and a web browser. That design is elegant, but it also means an exposed 5984 hands the entire database to anyone who can send an HTTP request. The marquee risk is “Admin Party”: older CouchDB ships with no administrator account configured, and in that state every visitor is effectively an admin — free to read every database, create and delete data, and set themselves up as a real admin. On top of that open front door sit two famous 2017 remote-code-execution CVEs that chain together to run shell commands, and a 2022 Erlang-clustering bug that can reach code execution through a different door. CouchDB also runs a bundled web admin UI — Fauxton — at /_utils, which turns an exposed instance into a point-and-click data browser.

Why It’s Open

CouchDB has to listen on 5984 to do its job: it is an HTTP server, and clients, replication partners, and the Fauxton admin UI all talk to it over that port. In a correct deployment CouchDB binds to loopback (127.0.0.1) or a private network and sits behind an authenticated reverse proxy. The problem is how easily that gets undone. To make replication or a remote app “just work,” operators change chttpd’s bind_address to 0.0.0.0, and a docker run -p 5984:5984 couchdb or an over-broad cloud security group publishes the port straight to the internet.

The historical defaults made exposure catastrophic. CouchDB before 3.0 (released 2020) started in Admin Party mode — no admin user, so anyone with network access has full administrative rights until someone creates the first admin. CouchDB 3.0 finally refused to start without an admin configured and defaults to binding loopback, but the enormous installed base of 1.x and 2.x instances predates that change, and any of them re-bound to all interfaces without also creating an admin is wide open. Because CouchDB is built on Erlang/OTP, a full node also runs the Erlang Port Mapper Daemon (epmd) on 4369 and an Erlang distribution listener for clustering — a second, separate attack surface that has nothing to do with the 5984 HTTP API but ships in the same package. CouchDB shares this fate with every other data store that ends up on a public interface without authentication — Redis on 6379 and PostgreSQL on 5432 among them — where the port being open is fine but the service being reachable by strangers is not.

Common Risks

  • Admin Party — unauthenticated full access (the big one). On CouchDB before 3.0 with no admin configured, anyone who can reach port 5984 can list every database (GET /_all_dbs), read and overwrite documents, create databases, and promote themselves to admin. No exploit required — just HTTP.
  • Data theft and ransom wipes. Like other exposed data stores — MongoDB on 27017 and Elasticsearch on 9200 among them — open CouchDB instances get scraped for data and hit by automated campaigns that delete the databases and drop a ransom-note document demanding cryptocurrency.
  • Privilege escalation to admin (CVE-2017-12635). A JSON-parser inconsistency lets an unauthenticated user create an account with admin roles, escalating to full control even where an admin was configured (see CVEs).
  • Remote code execution (CVE-2017-12635 + CVE-2017-12636 chain). Once admin, an attacker can point CouchDB’s query_server config at an OS binary and run arbitrary shell commands as the CouchDB user.
  • Erlang cluster RCE (CVE-2022-24706). A default/weak Erlang magic cookie and an exposed distribution port let an attacker join the Erlang cluster and execute code — targeting the epmd/distribution surface, not 5984 itself.
  • Fauxton admin UI exposure. The bundled /_utils web console gives a browser-based, point-and-click interface to browse, edit, and replicate databases if it’s reachable.
  • Information disclosure. GET / returns the exact CouchDB and Erlang version, and /_membership, /_utils, and stats endpoints reveal topology — telling an attacker precisely which bugs apply.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

logo-cta

Enumeration & Testing

Because CouchDB is pure HTTP, enumeration is mostly curl — you can read the whole database with the same tool you’d use to fetch a web page. Start with a version scan, then probe the REST endpoints.

Detect the service and version

Terminal window
nmap -sV -p 5984 <target>

Grab the welcome banner and version

Terminal window
curl -s http://<target>:5984/

A live CouchDB replies with JSON like {"couchdb":"Welcome","version":"2.1.0","git_sha":"...","features":[...]} — note the exact version, it decides which CVEs apply.

List every database (the Admin Party test)

Terminal window
curl -s http://<target>:5984/_all_dbs

If this returns an array of database names without credentials, the instance is unauthenticated — read any of them with curl -s http://<target>:5984/<dbname>/_all_docs?include_docs=true.

Check the Fauxton admin UI and cluster membership

Terminal window
# Fauxton web console (open in a browser)
curl -sI http://<target>:5984/_utils/
# Cluster nodes (CouchDB 2.x / 3.x)
curl -s http://<target>:5984/_membership

Nmap NSE scripts for CouchDB

Terminal window
nmap -p 5984 --script couchdb-databases,couchdb-stats <target>

couchdb-databases lists the databases and couchdb-stats pulls runtime statistics and reports whether authentication is enabled — a quick way to confirm Admin Party mode.

Metasploit modules

Terminal window
# Enumerate databases / detect CVE-2017-12635, optionally create an admin
use auxiliary/scanner/couchdb/couchdb_enum
# Full RCE chain (CVE-2017-12635 + CVE-2017-12636)
use exploit/linux/http/apache_couchdb_cmd_exec

Record every open port 5984, the exact version banner, whether /_all_dbs answered unauthenticated, and any database contents you confirm, so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Checkpoint What it means
GET / returns {"couchdb":"Welcome",...} A live CouchDB HTTP API — note the exact version for CVE scoping
GET /_all_dbs returns databases without auth Admin Party / no authentication — full unauthenticated read/write
/_utils/ serves the Fauxton UI Browser-based admin console reachable — data browsing and editing
Version 1.x < 1.7.0 or 2.x < 2.1.1 Vulnerable to the CVE-2017-12635 + CVE-2017-12636 RCE chain
Version < 3.2.2 with Erlang epmd (4369) exposed Potentially vulnerable to CVE-2022-24706 Erlang-distribution RCE
couchdb-stats reports auth disabled Confirms no admin configured — Admin Party mode
Reachable from the internet / 0.0.0.0 bind Database published far beyond its intended app/replication peers

Known CVEs and Exploits

CouchDB’s all-HTTP design means its worst bugs are network-reachable with plain requests. The two 2017 CVEs are the canonical chain, and they still turn up on unpatched instances:

  • CVE-2017-12635Remote privilege escalation. CouchDB uses two different JSON parsers (Erlang and JavaScript) that disagree on duplicate keys. By submitting a _users document with two roles keys, an unauthenticated attacker gets the second key used for the write authorization check while the first is stored for the account — letting a non-admin create an account carrying the _admin role. Affects CouchDB 1.2.0–1.6.1 and 2.0.0–2.1.0. CVSS 9.8 (Critical).
  • CVE-2017-12636Remote code execution via config. An admin user can set configuration options — including query_server / OS-binary paths — over the HTTP API. CouchDB then launches those binaries, so an admin can execute arbitrary shell commands as the CouchDB user, including pulling and running scripts from the internet. Affects CouchDB before 1.7.0 and 2.x before 2.1.1. CVSS 7.2 (High) — it requires admin, which is exactly what CVE-2017-12635 grants. Chained together (privilege escalation → config RCE), an unauthenticated attacker reaches shell access.
    • The chain is weaponised as Metasploit’s exploit/linux/http/apache_couchdb_cmd_exec (both CVEs), published as Exploit-DB 45019 (“Apache CouchDB - Arbitrary Command Execution (Metasploit)”). Metasploit’s auxiliary/scanner/couchdb/couchdb_enum detects CVE-2017-12635 and can create an admin.
  • CVE-2022-24706Erlang-distribution RCE. An attacker can access an improperly secured default installation without authenticating and gain admin privileges, leading to code execution. The root cause is CouchDB’s Erlang clustering: a weak/predictable default Erlang magic cookie and an exposed Erlang distribution port let an attacker join the cluster and run code. Affects CouchDB before 3.2.2. CVSS 9.8 (Critical).
    • Scope note: CVE-2022-24706 targets the Erlang distribution / epmd surface (epmd on 4369 plus a dynamic distribution port), not the 5984 HTTP API itself. An instance can be patched or firewalled on 5984 and still be exposed here if the Erlang ports are reachable — check and firewall them separately.

All CVEs above were verified on NVD against the Apache CouchDB product and this port’s service before inclusion. This page is a fresh write, so it carried no fabricated or wrong-service CVEs to remove.

Mitigation

  • Upgrade to CouchDB 3.x (or later). 3.0+ abolishes Admin Party — it refuses to start without an admin — and defaults to binding loopback. This alone closes the single biggest risk. Patching to 3.2.2+ also fixes CVE-2022-24706.
  • Never expose 5984 to untrusted networks. Bind chttpd to 127.0.0.1 or a private interface and reach it only through an authenticated reverse proxy over TLS on 443. Audit cloud security groups and Docker/Kubernetes port mappings for an accidental 0.0.0.0:5984.
  • Create a strong admin account immediately on any 1.x/2.x instance you cannot upgrade, so it is never in Admin Party mode, and require authentication for all access.
  • Patch the 2017 chain. If you must run older CouchDB, get to 1.7.0+ / 2.1.1+ to close CVE-2017-12635 and CVE-2017-12636.
  • Lock down the Erlang surface. Set a strong, unique Erlang magic cookie, and firewall epmd (4369) and the Erlang distribution port so only trusted cluster nodes can reach them — this is separate from securing 5984.
  • Restrict Fauxton (/_utils) and admin endpoints to trusted operators, not the public internet.
  • Close 5984 if nothing needs it and rescan to confirm — an unexplained internet-facing CouchDB is a data breach waiting to be indexed. Where you find an exposed instance, capture the version banner and the databases it leaked and track the remediation in your pentest reporting tool so the fix is verified, not assumed.

Real-World Example

The clearest demonstration of why an exposed 5984 is dangerous is the Monero-mining campaign documented by Trend Micro in early 2018. Attackers mass-scanned the internet for CouchDB instances listening on TCP 5984 and ran the exact CVE-2017-12635 → CVE-2017-12636 chain: first they abused the duplicate-roles JSON-parser bug to create an admin account without authenticating, then used that admin access to rewrite the query_server configuration so CouchDB executed a downloaded shell script. The script killed competing miners and installed XMRig to mine Monero on the victim’s hardware, with activity peaking in February 2018. It is the port-5984 lesson in one incident: because CouchDB does everything over HTTP and older versions ship wide open, a self-contained pair of REST requests took unpatched, internet-facing databases from “anyone can read this” to “attacker-controlled code running as the CouchDB user.”

FAQ

What is port 5984 used for?

Port 5984 is the default TCP port for Apache CouchDB’s HTTP/REST API. CouchDB has no separate binary protocol — clients, replication peers, the Fauxton admin UI, and administrators all interact with the database by sending HTTP requests to 5984, reading and writing JSON documents and managing the server through REST endpoints like /_all_dbs, /_users, and /_config.

Why is port 5984 open on my server?

Because a CouchDB instance is running and listening there — it’s the database’s normal port. The concern is scope: CouchDB should be bound to localhost or a private network. If 5984 is reachable from the internet (often after someone set the bind address to 0.0.0.0 or published a Docker container), the database is exposed to anyone who can send an HTTP request.

Is an open port 5984 dangerous?

It can be very dangerous. On CouchDB before 3.0 with no admin configured (Admin Party mode), anyone reaching 5984 has full read/write and admin rights with no exploit at all. Older versions are also vulnerable to the CVE-2017-12635 + CVE-2017-12636 remote-code-execution chain. A patched 3.x instance with an admin account, bound to a private network behind an authenticated proxy, is far safer — but the port should not be publicly exposed regardless.

What is CouchDB’s “Admin Party” mode?

It’s the default state of CouchDB before version 3.0 in which no administrator account exists, so every user is treated as an admin — free to create and delete databases, read and write all data, and configure the server. CouchDB 3.0 removed this behavior by refusing to start until an admin is set. On any older instance you should create a strong admin account immediately.

Does CVE-2022-24706 affect port 5984?

Not directly. CVE-2022-24706 exploits CouchDB’s Erlang clustering — a weak default magic cookie and an exposed Erlang distribution port (with epmd on 4369) — to join the cluster and run code. It’s a separate attack surface from the 5984 HTTP API, so you have to secure it separately: set a strong Erlang cookie and firewall the Erlang ports, and upgrade to CouchDB 3.2.2 or later.

How do I secure or close port 5984?

Upgrade to CouchDB 3.x (which ends Admin Party and binds loopback by default), create a strong admin account, and bind the service to 127.0.0.1 or a private interface behind an authenticated reverse proxy with TLS. Patch older instances to 1.7.0+/2.1.1+ (and 3.2.2+ for the Erlang bug), restrict Fauxton (/_utils) and the Erlang ports (4369) to trusted hosts, firewall 5984 to only the clients that need it, and if nothing legitimately uses it, stop the service and confirm with a rescan.

TL;DR

  • Service: Apache CouchDB — a document-oriented NoSQL database driven entirely through an HTTP/REST API (Fauxton admin UI at /_utils)
  • Default port: 5984/TCP (Erlang epmd on 4369 and a dynamic Erlang distribution port accompany a full node)
  • Biggest risk: “Admin Party” — CouchDB before 3.0 ships with no admin, so an exposed 5984 gives anyone full unauthenticated read/write, and older versions add the CVE-2017-12635 + CVE-2017-12636 RCE chain (with CVE-2022-24706 on the Erlang side)
  • Mitigation: upgrade to CouchDB 3.x, create a strong admin, bind to localhost/private network behind an authenticated TLS proxy, patch to 1.7.0+/2.1.1+/3.2.2+, lock down the Erlang cookie and ports, and never expose 5984 to the internet