Apache CouchDB 3.5.3: Six CVEs and a Prefixed _users Auth Bypass

Apache CouchDB disclosed six vulnerabilities on 20 October 2026, all affecting CouchDB 3.5.2 and earlier on every platform and all fixed in 3.5.3. The worst lets a server admin run shell commands on the host. Another exposes prefixed _users and _replicator databases to unauthorised reads. Upgrade to 3.5.3. No exploitation is reported.

This is a vulnerability disclosure, not a breach. No attacks have been reported, none of the six is in the CISA Known Exploited Vulnerabilities (KEV) catalog as of its 23 October release, CISA's enrichment of each record says "Exploitation: none", and we found no public proof of concept. One oddity, covered in Technical details: Apache's CVSS vector for the most severe issue carries a threat value of Attacked, which nothing else in the disclosure explains.

The six issues are uneven. One needs server admin credentials, one needs a configuration Apache calls rare, three need an account or a replication endpoint, and one can be triggered by anyone who can reach port 5984. One upgrade fixes all six; how fast you need it, and what to check afterwards, depends on how you run CouchDB.

What happened

The CouchDB project released 3.5.3 first and published the details later. The source tarball appeared on the Apache download servers on 10 October 2026. On 12 October, Jan Lehnardt posted the release announcement for the CouchDB Project Management Committee. It listed the six CVE IDs with no descriptions and said details would follow "seven (7) days after this release" so users had time to upgrade. The full advisories went out on 20 October through the oss-security list, the Apache CouchDB mailing lists and the CouchDB documentation, and the CVE records went live on cve.org the same afternoon.

That pattern matters if you only watch CVE feeds. For ten days a fixed release existed with no public description of what it fixed. Teams that watch upstream releases directly had more than a week of head start.

The six CVEs at a glance

All six CVE records use the same affected range: versions from 0 up to, but not including, 3.5.3, with a default status of unaffected. In plain terms, every release before 3.5.3 is affected, including the 3.4, 3.3 and older lines, and 3.5.3 is the only fixed release.

Timeline

All times are UTC unless noted. Mailing list times are as shown by lists.apache.org and openwall.com.

The CouchDB CVE pages date each issue 12 October 2026, matching the announcement. Neither the release notes nor the advisories map pull requests to CVE IDs; the pairing in Technical details is our own reading. Note that the fixes sat in the public repository for up to five weeks before the advisories.

Who is affected

Every server before 3.5.3 has the code for all six issues. Whether each is reachable depends on your setup.

Where CouchDB hides

CouchDB is often not something a team remembers installing. Check the official couchdb image and anything built FROM couchdb (the 3.5.3 Dockerfile builds on debian:trixie-slim and installs the Debian package couchdb at 3.5.3~trixie), Helm charts and operators, the Apache CouchDB Linux package repositories, Windows and macOS installs, and products that bundle CouchDB as an internal datastore. For bundled copies and managed services, the vendor or operator controls the upgrade; we did not confirm the status of any of them, so ask.

How the issues work

This section explains each issue in plain terms, from the advisories and the CouchDB documentation pages for each CVE. It deliberately stops short of anything that would help someone trigger them.

CVE-2026-86471: an admin setting that became a shell command

CouchDB ships a diagnostics module called weatherreport. According to the CouchDB CVE page, weatherreport built shell commands from configuration values without sanitising them. Server admins can change configuration at runtime through the /_config HTTP API, so a server admin could cause CouchDB to run commands as the operating system user it runs under. The fix stops building shell commands from unsanitised values and avoids the shell where it can (release note entry #6153).

Why does a bug that needs admin rights score 9.3? Because CouchDB admin and the host are meant to be separate trust zones. This bug collapses that boundary: if an admin password leaks, is weak or is shared, the attacker gets a shell instead of a database.

CouchDB has history here. Its CVE index lists remote code execution issues in 2017 and 2018, and CVE-2022-24706, an insecure default Erlang cookie that handed out admin access, has been in the CISA KEV catalog since 25 August 2022; it is still the only CouchDB entry there. We covered it in CVE-2022-24706 and Apache CouchDB in KEV. Any future route to admin rights becomes more serious on a server where admin rights also mean code execution.

CVE-2026-90800: prefixed system databases skipped an admin check

This is the headline issue, and it is easy to overstate.

CouchDB has two system databases: _users, which stores user accounts, and _replicator, which stores replication jobs. It also supports prefixed copies such as foo/_users or bar/_replicator, which the CouchDB CVE page says behave like the base databases but allow bespoke access control. Some multi-tenant designs use them to keep tenants apart.

Only server and database admins may call _all_docs and _changes, which list every document, on these system databases. On the prefixed copies that rule was not enforced, so any request could read the full contents. The fix (entry #6149) corrects the name suffix check in the auth handler.

What it is: a read of everything in a prefixed _users database (user documents normally hold password hashes, salts and roles, which is what offline guessing needs) or a prefixed _replicator database (whose documents can hold credentials for other servers).

What it is not: it does not affect the default _users and _replicator databases, and the advisory describes reads, not writes. Apache's vector sets Attack Requirements to Present (AT:P) to reflect the precondition, and Apache says "the use of prefixed system databases is very rare." If you do use them, treat this as your most urgent issue, because no credentials are needed.

CVE-2026-90797: a small compressed request that expands to fill memory

CouchDB accepts gzip compressed request bodies, including on the unauthenticated /_session login endpoint. According to the CouchDB CVE page, only the compressed input was checked against the request body limit, so a small body that expands enormously could push the Erlang VM process, beam.smp, out of memory. No account is needed (PR:N), and the impact is availability, not data access.

The fix (entry #6151) decompresses in chunks and checks the uncompressed length against the limit at each step. That limit, [chttpd] max_http_request_size, defaults to 4294967296 bytes (4 GB) per the configuration reference, so consider lowering it if untrusted clients can reach CouchDB.

CVE-2026-107755: replication passwords visible to the wrong users

Replication documents name a source and a target, either as a URL string with credentials inside it or as a URL object with separate fields. According to the CouchDB CVE page, when a non-owner read someone else's replication document, CouchDB hid credentials in the string form but showed them in the object form. In a shared or prefixed _replicator database, members could see each other's credentials. The fix (entry #6157) also strips credentials from log messages and replication status responses. Upgrading does not undo past reads, so rotate exposed credentials.

CVE-2026-90799: crafted sequence values fill the atom table

CouchDB gives clients opaque tokens, such as _changes sequence values and _search bookmarks, to pass back later. The CouchDB CVE page explains that a client could build its own token whose decoding created new Erlang atoms. Atoms are never garbage collected, and when the atom table fills the BEAM VM aborts. An authenticated user could crash a node this way. The fix parses tokens without creating atoms; release note entry #6115 also made decoding two to three times faster.

CVE-2026-90798: a redirect loop that never ends

The replicator followed HTTP redirects without limit, so the owner of a source or target could tie up a replication job. Now, per the CouchDB CVE page, retry limits apply to all replicator requests and the job fails with too_many_redirects after five retries (entry #6141).

Technical details

Everything in this section comes from the CVE records on cve.org, the six oss-security posts, the CouchDB CVE pages, the 3.5 release notes, the Apache download servers, the CouchDB GitHub repository and Docker Hub. Values are as published on the dates shown.

Affected and fixed versions per CVE

The documentation labels do not track the CVSS scores: CVE-2026-90799 is labelled High but scores 1.3. The CNA also attached textual severities of "important" to CVE-2026-107755 and "moderate" to CVE-2026-90798. Rank by CVSS and your own exposure. The Apache records carry no CWE; those come from CISA's ADP enrichment, which rates only CVE-2026-90797 as automatable.

CouchDB's policy is to fix the current release series and its immediate predecessor, with further backports at its discretion. As of 24 October the source directory shows no new 3.4 release (the latest is still 3.4.3), and the records name only 3.5.3. If you run 3.4.x or older, plan the move to 3.5.3.

CVSS 4.0 vectors as published by Apache

A note on E:A. In CVSS 4.0, the threat metric E (Exploit Maturity) can be A for Attacked, P for a proof of concept, or U for Unreported. Five of the six vectors use E:U. The vector for CVE-2026-86471 uses E:A, and the CVE record's structured field reads ATTACKED. Nothing else in the disclosure supports that: the advisory text describes no attacks, CISA's SSVC enrichment for the same CVE says "Exploitation: none", and the CVE is not in KEV. It may be an error in the vector, or Apache may know something it has not said. We list it under Open questions and do not treat it as evidence of exploitation.

Fixes in the 3.5.3 release notes, paired with the CVEs

The release notes do not cite CVE IDs. This pairing is our reading, based on matching each fix description to each advisory and to the mitigation text on the CouchDB CVE pages.

Two other changes have no CVE but matter for hardening: #6147 makes _search_cleanup and _nouveau_cleanup admin only, and #6090 handles a decoding error when parsing authorization headers. The oss-security posts are numbered 2026/10/20/11 to /16, and each CVE record also references the announcement thread pj83174r8f8f64odf47fwhozbfjtot0f.

Build requirement: Erlang/OTP 27

The 3.5.3 release notes open with a note that Erlang/OTP 27 is now the minimum supported version (#6009, #6036, #6038). This matters if you build CouchDB from source or maintain your own packages. If your build host runs an older OTP, the upgrade is a toolchain change as well as a version bump. The same release also moved CI base images to Debian Trixie.

Release artifacts and checksums

There is no .sha512 file in the 3.5.3 directory; only the SHA-256 checksum and the signature are published.

Official container image

The official couchdb:3.5.3 tag was most recently pushed on 21 October 2026 at 03:33 UTC, with manifest list digest sha256:4e8e0a366208a87d5059b0f4fcbefff13c32401a655d4629c19be6288ea77675 (amd64 image sha256:c0aacf2750f51cb7749472aa3be8acab3430b040494691fc81a786563d99921a, arm64 image sha256:dc4819d8c36c5e9a06ebb5add49bda1fe2c2a3856a7ca42221bdc6e48a913e21). The 3.5, 3, latest and -nouveau tags moved at the same time. Official images are rebuilt periodically, so treat these digests as a record of this week's build, not permanent identifiers.

Indicators of compromise

None are published. The advisories contain no IP addresses, domains, hashes or request signatures, because no attacks have been reported. The log checks later in this post are things to look for on your own servers, not indicators from any official source.

What to do now

1. Find every CouchDB you run

Start with the version each server reports about itself. The root endpoint answers without authentication on a default install:

# Version from a running server
curl -s http://127.0.0.1:5984/ | jq -r '.version'

# Debian and Ubuntu packages
dpkg -l couchdb 2>/dev/null | awk '/^ii/ {print $2, $3}'

# RHEL, Rocky, Alma and Fedora packages
rpm -q couchdb

For containers and Kubernetes:

# Running containers that use a couchdb image
docker ps --format '{{.ID}} {{.Image}}' | grep -i couchdb

# Local images and their tags
docker image ls couchdb

# Ask a running container directly
docker exec <container> curl -s http://127.0.0.1:5984/ | jq -r '.version'

# Kubernetes: every pod image that mentions couchdb
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i couchdb

Check the version the server reports, not the tag: couchdb:3 pulled before 21 October is 3.5.2 or earlier. If you keep SBOMs, search them for couchdb below 3.5.3; our post on SBOMs in incident response covers that workflow.

2. Check whether CVE-2026-90800 applies to you

List every database and look for names that end in /_users or /_replicator. This needs a server admin account:

COUCH=http://127.0.0.1:5984
curl -s -u "$COUCH_ADMIN:$COUCH_PASS" "$COUCH/_all_dbs" \
  | jq -r '.[] | select(test("/_(users|replicator)$"))'

If the command prints nothing, you have no prefixed system databases and CVE-2026-90800 does not expose your data. If it prints names, those databases were readable without authorisation on 3.5.2 and earlier. Upgrade first, then review your logs (step 6) and decide whether to reset passwords for the accounts in each prefixed _users database.

3. Audit who holds server admin rights (CVE-2026-86471)

Server admins are defined in the [admins] section of the configuration. List the admin names on each node:

curl -s -u "$COUCH_ADMIN:$COUCH_PASS" \
  "$COUCH/_node/_local/_config/admins" | jq -r 'keys[]'

Does every name need admin? Is any admin password in a script, CI variable, .env file or app config, or shared between environments? Each yes is a path from a leaked secret to a host shell until you upgrade. Applications should use non-admin users with database roles.

4. Check shared replicator databases (CVE-2026-107755)

Find replication documents that use the object form for source or target. Run this against _replicator and against any prefixed replicator databases from step 2 (encode the slash in the name as %2F):

curl -s -u "$COUCH_ADMIN:$COUCH_PASS" \
  "$COUCH/_replicator/_all_docs?include_docs=true" \
  | jq -r '.rows[].doc
      | select(._id | startswith("_design/") | not)
      | select((.source | type) == "object" or (.target | type) == "object")
      | [._id, (.owner // "no owner field")] | @tsv'

If the database has members who are not admins and who do not own every document listed, plan to rotate the credentials in those documents after the upgrade.

5. Upgrade to 3.5.3

# Debian and Ubuntu (Apache CouchDB repository)
sudo apt-get update && sudo apt-get install --only-upgrade couchdb

# RHEL family (Apache CouchDB repository)
sudo dnf upgrade couchdb

# Docker: pin the fixed version explicitly
docker pull couchdb:3.5.3

Upgrade a cluster one node at a time, after a backup or snapshot of each node's data directory; 3.5.3 also changes purge and file header handling.

If you build from source, verify the tarball before you build:

curl -sO https://downloads.apache.org/couchdb/source/3.5.3/apache-couchdb-3.5.3.tar.gz
curl -sO https://downloads.apache.org/couchdb/source/3.5.3/apache-couchdb-3.5.3.tar.gz.asc
curl -sO https://downloads.apache.org/couchdb/KEYS
gpg --import KEYS
gpg --verify apache-couchdb-3.5.3.tar.gz.asc apache-couchdb-3.5.3.tar.gz
echo "ae0bb374cc89900d6cb1dfb8d8e80c799186dcf2d143ca886296c230af420896  apache-couchdb-3.5.3.tar.gz" | sha256sum -c -

# Confirm the build host has Erlang/OTP 27 or newer
erl -noshell -eval 'io:format("~s~n", [erlang:system_info(otp_release)]), halt().'

6. Review logs for signs of the bugs

There are no official indicators, but some log patterns are worth a look on servers that were exposed. CouchDB's request log lines include the method and path. Adjust the log path for your install:

LOG=/opt/couchdb/var/log/couchdb.log

# Listing calls against prefixed system databases (CVE-2026-90800).
# Look for requests that did not come from your admin tooling.
# Prefixed names appear URL-encoded, with %2F in place of the slash.
grep -E '%2F_(users|replicator)/(_all_docs|_changes)' "$LOG"

# Runtime config changes (relevant to CVE-2026-86471)
grep -E ' (PUT|DELETE) /_node/[^ ]+/_config/' "$LOG"

# Out of memory kills of the Erlang VM (CVE-2026-90797, CVE-2026-90799)
journalctl -u couchdb --since "2026-09-01" | grep -iE 'out of memory|killed|erl_crash'
dmesg -T | grep -iE 'killed process .*beam\.smp'

An unexplained config change is the most important finding; compare each against your change records. An unexplained erl_crash.dump in the CouchDB working directory is also worth reading, since its first lines state why the VM stopped.

7. Interim mitigations if you cannot upgrade today

Every CouchDB CVE page lists the workaround as N/A. The steps below are our general hardening, not Apache's, so test them first.

1. Keep port 5984 off the internet. Set [chttpd] bind_address = 127.0.0.1 where only local apps connect, or firewall it. This removes the outside anonymous path to CVE-2026-90797 and CVE-2026-90800.
2. Reject compressed bodies on /_session at a reverse proxy. Login requests are small and uncompressed. If nginx fronts CouchDB, a rule like this refuses encoded bodies on /_session and caps the size. It narrows exposure; it does not fix the bug.

location = /_session {
    if ($http_content_encoding != "") { return 415; }
    client_max_body_size 16k;
    proxy_pass http://couchdb_upstream;
}

3. Reduce server admins and change any admin password that has lived in a shared place.
4. Require authentication at the proxy for paths containing %2F_users or %2F_replicator if you run prefixed system databases.
5. Alert on memory on CouchDB nodes before the out of memory killer acts.

8. Verify

After upgrading, confirm each node reports 3.5.3, and that clustered nodes all agree:

curl -s http://127.0.0.1:5984/ | jq -r '.version'
curl -s -u "$COUCH_ADMIN:$COUCH_PASS" "$COUCH/_membership" | jq

Then run your application's normal tests against the upgraded cluster, including login, replication and any _changes consumers, since three of the six fixes touch those paths.

What changed since first reports

• The release was announced, not silent. The tarball appeared on 10 October, but the 12 October announcement named all six CVE IDs and urged a timely upgrade. Only the detail was held back.
• The config value behind CVE-2026-86471 is now described. The oss-security post said only "an unvalidated runtime configuration value"; the CouchDB CVE page names weatherreport and the /_config API.
• The endpoints behind CVE-2026-90800 are now named on the CouchDB CVE page: _all_docs and _changes.
• The CVE-2026-107755 fix is wider than the advisory, also covering logs and status responses.
• The Docker image is out, with 3.5.3, 3.5, 3 and latest pushed on 21 October, and no KEV listing followed through 23 October.

Open questions

• Why E:A on CVE-2026-86471? Apache's vector says Attacked; nothing else does, and we have seen no explanation.
• Will 3.4.x get a fix? The policy allows it; none has appeared.
• Which bundled products, hosted services and distribution packages carry 3.5.3? We did not confirm any.
• Does any downstream product create prefixed system databases by default? That would change the CVE-2026-90800 picture for its users.

What would have helped

Nobody was breached here, so "what would have helped" means: what makes a batch like this a one-hour job instead of a two-week scramble.

Practices any team can use

1. Watch upstream releases, not only CVE feeds. The fix shipped on 10 October, was announced on 12 October, and the details arrived on 20 October. Following the CouchDB announce list would have put the upgrade on your board ten days earlier.
2. Know where every copy runs. An inventory covering images, Helm releases, packages and vendor bundles turns step 1 into a query instead of a week of asking around.
3. Pin versions. Floating tags like couchdb:3 hide what is running. Pin couchdb:3.5.3 and change the pin on purpose.
4. Treat database admin as a host-level secret. Keep admin credentials in a secrets manager, rotate them, and give applications non-admin users.
5. Keep database ports off the internet. CVE-2026-90797 needs no account.
6. Do not store credentials where other users can read them. Prefer per-user replication databases or narrowly scoped replication credentials.
7. Make data tier upgrades routine. Tested backups and a node-by-node procedure take the fear out of database upgrades. Our incident response playbook for a compromised dependency covers the inventory side, and our October 2026 incidents roundup shows the same pattern elsewhere.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is the paid service for hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge on regression. We are not claiming Gold had a patched CouchDB build before 3.5.3. The habit that matters is pulling fixed, signed components from a curated source and rebuilding fast once a fix exists.

Where Safeguard fits

Safeguard helps with inventory and upgrade work, not with CouchDB's code.

• Finding affected images. safeguard scan --image <name>, safeguard scan --dir . and safeguard scan --sbom <file> write JSON results under ./output, and the platform shows which projects contain a given component and version, matched against vulnerability databases.
• Policies and gates can stop an image with a vulnerable CouchDB from being promoted, so a stale couchdb:3 base does not return.
• Doing the edit. The Safeguard CLI's assistant can change the FROM couchdb tag, a Helm values file or a Compose file and run your tests, asking before each command under the default permission mode; safeguard exec runs the same work in CI. Autonomous remediation can open fix pull requests and ships off by default.

Where it does not help: it does not patch a running server, change CouchDB configuration, rotate replication credentials or review admin accounts, and it cannot fix CouchDB inside a vendor appliance or hosted service. For CVE-2026-90800 the deciding question is configuration, which the step 2 command answers.

To try the CLI on your own images, download Safeguard and follow the CLI docs.

Common mistakes and troubleshooting

• Assuming CVE-2026-90800 hits every CouchDB. Only prefixed _users and _replicator databases. Run step 2 first.
• Ranking CVE-2026-86471 low because it needs admin. Shared or app-stored admin passwords make that precondition easy.
• Trusting the tag. couchdb:3 or latest pulled before 21 October is 3.5.2 or earlier.
• Skipping credential rotation after CVE-2026-107755. The upgrade does not undo past reads.
• Source build fails early. Check Erlang/OTP; 3.5.3 needs 27 or newer.
• Replications fail with too_many_redirects. That is the CVE-2026-90798 fix. Point the replication at the final URL.
• A _changes consumer gets 400 after upgrading. Validation is stricter (#6115); check whether it sends a hand-built or corrupted token.
• Upgrading every cluster node at once. Go one node at a time and confirm _membership before moving on.

FAQ

What is CVE-2026-90800 in Apache CouchDB?

It is a missing authorisation check on prefixed system databases, such as foo/_users or bar/_replicator. On CouchDB 3.5.2 and earlier, the _all_docs and _changes endpoints on those databases did not enforce the admin-only rule, so any request could read their full contents. It is fixed in 3.5.3. Default _users and _replicator databases are not affected.

Which CouchDB version fixes the October 2026 vulnerabilities?

CouchDB 3.5.3 fixes all six: CVE-2026-86471, CVE-2026-90797, CVE-2026-90798, CVE-2026-90799, CVE-2026-90800 and CVE-2026-107755. Every earlier version is affected according to the CVE records.

Is anyone exploiting these CouchDB vulnerabilities?

No exploitation has been reported. None of the six is in the CISA KEV catalog as of 23 October 2026, and CISA's enrichment records "Exploitation: none" for each. The one oddity is that Apache's CVSS vector for CVE-2026-86471 includes E:A (Attacked) with no supporting explanation.

Do I need to worry about CVE-2026-86471 if only I am the admin?

Less, but still upgrade. The bug turns CouchDB admin rights into commands on the host as the CouchDB user. A strong, unshared admin password lowers the risk; a leaked one means a shell, not just database access.

Can an unauthenticated attacker crash my CouchDB?

On 3.5.2 and earlier, yes, if they can reach the HTTP port. CVE-2026-90797 lets any remote client exhaust memory through a compressed request to /_session. Upgrade, and keep port 5984 off untrusted networks.

Do I need to rotate any credentials after upgrading?

Rotate credentials in object form replication documents in any shared or prefixed _replicator with non-admin members. Consider resetting passwords for users in prefixed _users databases that untrusted clients could reach, and rotate any shared or app-stored admin password.

Is there a fix for CouchDB 3.4?

Not as of 24 October 2026. The CVE records list 3.5.3 as the only fixed version, and the Apache source directory shows no new 3.4 release. Plan to move to 3.5.3.

Who found these issues?

Credits from Apache: Qing Xu and ZeroVuln Labs (CVE-2026-90800, independently), ZeroVuln Labs (CVE-2026-90797), Piotr Karwasz and ZeroVuln Labs (CVE-2026-90799, independently), Sakil Ahamed Gayen (CVE-2026-107755), the CouchDB team after reviewing reports from Piotr Karwasz, Sec-Rex and ZeroVuln Labs (CVE-2026-90798), and an anonymous reporter (CVE-2026-86471).

Fix it without waiting for upstream

In this case upstream did ship a fix, and fast. The gap that remains is the one between 3.5.3 existing and 3.5.3 running in every image and cluster you own, and that gap is the one most teams can close themselves.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows CouchDB; each shows a real flow that maps onto this upgrade. The first is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For CouchDB you would ask it to change FROM couchdb:3 to FROM couchdb:3.5.3, or the tag in a Helm or Compose file, and approve each build and test command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is how you would ask which local repositories and images still carry CouchDB below 3.5.3.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. Here you would point it at your CouchDB deployment repository, let it propose the pinned 3.5.3 tag, and approve each edit and test run.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• oss-security: CVE-2026-86471, admin credentials leading to code execution (openwall.com)
• oss-security: CVE-2026-90797, gzip decompression bomb via POST /_session (openwall.com)
• oss-security: CVE-2026-90798, replicator follows redirects indefinitely (openwall.com)
• oss-security: CVE-2026-90799, atom table exhaustion (openwall.com)
• oss-security: CVE-2026-90800, auth bypass in prefixed _users and _replicator databases (openwall.com)
• oss-security: CVE-2026-107755, credential disclosure via object-form replication URLs (openwall.com)
• Apache CouchDB security issues and CVEs index (docs.couchdb.org)
• CouchDB CVE-2026-86471 page (docs.couchdb.org)
• CouchDB CVE-2026-90797 page (docs.couchdb.org)
• CouchDB CVE-2026-90798 page (docs.couchdb.org)
• CouchDB CVE-2026-90799 page (docs.couchdb.org)
• CouchDB CVE-2026-90800 page (docs.couchdb.org)
• CouchDB CVE-2026-107755 page (docs.couchdb.org)
• CouchDB 3.5.x release notes (docs.couchdb.org)
• Apache CouchDB 3.5.3 release announcement (lists.apache.org)
• CVE-2026-90800 advisory thread (lists.apache.org)
• CVE-2026-86471 record (cve.org)
• CVE-2026-90797 record (cve.org)
• CVE-2026-90798 record (cve.org)
• CVE-2026-90799 record (cve.org)
• CVE-2026-90800 record (cve.org)
• CVE-2026-107755 record (cve.org)
• Apache CouchDB source downloads (downloads.apache.org)
• CouchDB 3.5.3 source artifacts and SHA-256 (downloads.apache.org)
• CISA Known Exploited Vulnerabilities catalog feed (cisa.gov)
• Pull request #6149: fix suffix check for replicator and users dbs (github.com/apache/couchdb)
• Pull request #6151: use incremental gunzip (github.com/apache/couchdb)
• Pull request #6153: improve weatherreport checks (github.com/apache/couchdb)
• Pull request #6157: strip more replicator creds (github.com/apache/couchdb)
• Pull request #6141: improve redirects in replicator (github.com/apache/couchdb)
• Pull request #6115: optimize and improve change sequence decoding (github.com/apache/couchdb)
• CouchDB HTTP server configuration reference (docs.couchdb.org)
• CouchDB base server configuration reference (docs.couchdb.org)
• CouchDB authentication configuration reference (docs.couchdb.org)
• Official couchdb image tags (hub.docker.com)
• Official couchdb image Dockerfile for 3.5.3 (github.com/apache/couchdb-docker)
• Daily CyberSecurity: Apache CouchDB 3.5.3 fixes six flaws, 21 Oct 2026 (securityonline.info)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.