MongoDB 3.6 major security vulnerability

Install, Configure and Update
1

A major vulnerability allowing unauthenticated attackers to remotely leak sensitive data from MongoDB server memory was disclosed on December 25, 2025. Patches are available for MongoDB versions 4.4 and newer. However, CryoSPARC appears to ship with MongoDB 3.6.23, which remains unsupported and vulnerable.

While our CryoSPARC instances do not expose MongoDB ports externally, mitigating immediate risk, running services on software with known vulnerabilities is inconsistent with our security standards and complicates local information assurance efforts.

Are there plans to upgrade CryoSPARC’s bundled MongoDB to a supported version?

Limiting MongoDB to localhost
2

Hi @bbattey, thanks for posting.

We are expecting to upgrade MongoDB to more recent versions in upcoming CryoSPARC versions.
As you mentioned, and as a reminder for other readers, CryoSPARC is only designed to be deployed within a trusted internal network, and no part of CryoSPARC (including the MongoDB database) should ever be exposed to any untrusted network or the public internet. See: CryoSPARC Architecture and System Requirements | CryoSPARC Guide

Regarding the “MongoBleed” vulnerability (CVE-2025-14847) specifically: the official MongoDB ticket indicates that vulnerable databases are those that use zlib network compression and that disabling zlib compression is a workaround that avoids the vulnerability. Furthermore, the official MongoDB documentation for MongoDB v3.6 (used in CryoSPARC v4.7) confirms that zlib compression is not enabled by default in MongoDB v3.6; only snappy compression is enabled by default. CryoSPARC uses default MongoDB compression configuration and therefore the database does not have zlib compression enabled.

It is possible to query the database to confirm that only snappy network compression is active.
In cryosparcm icli, use the following commands:

from cryosparc_compute import database_management

mongo_uri = database_management.get_mongo_uri("meteor", admin=True)
mongo_client = database_management.try_get_pymongo_client(
    mongo_uri,
    directConnection=False,
)
admin_db = mongo_client.get_database("admin")
admin_db.command("serverStatus")['network']

You should see an output like:

{'bytesIn': 30816769444,
 'bytesOut': 569829498218,
 'physicalBytesIn': 30816769444,
 'physicalBytesOut': 569829498218,
 'numRequests': 97083232,
 'compression': {'snappy': {'compressor': {'bytesIn': 0, 'bytesOut': 0},
   'decompressor': {'bytesIn': 0, 'bytesOut': 0}}},
 'serviceExecutorTaskStats': {'executor': 'passthrough',
  'threadsRunning': 201}}

The compression line confirms that only snappy compression is enabled rather than zlib.

2 Likes
3

CryoSPARC is only designed to be deployed within a trusted internal network, and no part of CryoSPARC (including the MongoDB database) should ever be exposed to any untrusted network or the public internet.

This is all good and well, but even the most hardened network is still subject to infiltration despite the best efforts of a security team. If a bad actor were able to install a backdoor to a trusted network, then they could proceed to exploit any additional unpatched vulnerabilities (such as MongoBleed). Ideally risk would be mitigated by ensuring that components within a perimeter (trusted network) would be as secure as possible as well.

As you’ve pointed out, in this case the point is moot since CryoSPARC does not use zlib compression. At the same time, MongoDB is an incredibly complex piece of software with a very large attack surface compared to simpler databases and it’s more intended to be used in distributed environments. As has been discussed in other posts, Structura does not intend to support running a MongoDB instance separately from the CryoSPARC master ( Use of a standalone MongoDB server? - #3 by wtempel ), which somewhat weakens the case for using it, since it can’t be run in a cluster to provide redundancy, etc.

Are there any plans to perhaps switch to using an embedded database (e.g., SQLite, LevelDB, BadgerDB, or DuckDB) on the master possibly with an API endpoint in front of it to translate RPCs from workers into CRUD operations? Such a setup would likely be generally more secure and easier to maintain.

4

@jpellman thanks for posting - yes, every network is subject to infiltration in the worst case, and it is certainly ideal for all components to themselves be fully secure. We try to make CryoSPARC as secure as possible and will continue to do so; for example, by upgrading MongoDB versions in upcoming CryoSPARC versions. That said, we do not attempt to guarantee security hardness of CryoSPARC, which is why (again for the sake of readers who may later see this thread), we require those deploying CryoSPARC at their institutions to provide a trusted network environment that meets their own standards.

Regarding MongoDB: it is currently a key part of CryoSPARC’s architecture due to the way it is used to provide real time synchronization and streaming updates in the UI. Replacing it would require a complete redesign, and is not currently planned.

5

It seems like attempting even the most basic mitigation that will satisfy the security people who only see the db version is not trivial.

Trying to make sure mongod only listens on 127.0.0.1:

  • Step 1:
    Add ‘export CRYOSPARC_MONGO_EXTRA_FLAGS=“–bind_ip 127.0.0.1”’ to config.sh
    Result: –bind_ip_all pops up in the mongod command line and it’s listening on all interfaces
  • Step 2:
    Modify supervisord.conf to remove ‘–bind_ip_all’
    Result: pymongo is crashing the startup as it’s trying to connect to ROOT_URL:39002 and not 127.0.0.1
  • Step 3: Look more at the supervisord.conf more. The ‘[program:app]’ seems to be using ‘ENV_CRYOSPARC_APP_MONGO_URI’. However, that variable is not listed in ‘https://guide.cryosparc.com/setup-configuration-and-management/management-and-monitoring/environment-variables’

It would be great to get advice from CS folks at this point. We need a procedure to make sure only ‘127.0.0.1’ is used for mongod and access from the app code.

6

@malex thanks for posting; please see Limiting MongoDB to localhost for a response.