This is a follow-up to MongoDB 3.6 major security vulnerability, which is already closed.
It looks like attempting even the most basic mitigation to satisfy the security people who only see the db version and will not accept the reasoning for the enabled compression type not being affected by the mongobleed cve is not trivial.
The question becomes, can we reconfigure cryosparc to make sure mongod only listens on 127.0.0.1 for cluster-integrated installations? If that’s possible, will there be adverse effects for the CS functionality?
For example:
If I add ‘export CRYOSPARC_MONGO_EXTRA_FLAGS=“–bind_ip 127.0.0.1”’ to config.sh nothing happens as the ‘–bind_ip_all’ is injected into in the mongod command by the supervisord script.
If I modify supervisord.conf to remove ‘–bind_ip_all’ I get an error from pymongo on startup as it’s trying to connect to ROOT_URL:39002 and not 127.0.0.1:39002
Thinking that I can force the mongo url I looked 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’, so it seems unsupported.
It would be great to get advice from CS folks at this point. We need a procedure to limit mongod to listening only on the ‘127.0.0.1’ interface.
Structura can correct me if I’m wrong, but I don’t think that binding the port to the loopback interface will work. It seems that workers (running on Slurm nodes) connect directly to the MongoDB instance, so it needs to be open to at least the network that the cluster nodes live on.
cryosparcuser@cryosparc5:~/cryosparc_master/bin$ ./cryosparcm mongo
MongoDB shell version v3.6.23
connecting to: mongodb://cryosparc5.semc.nysbc.org:39001/meteor?authSource=admin&gssapiServiceName=mongodb
Implicit session: session { “id” : UUID(“1df24ab5-549a-4c9c-a852-31676c8c661c”) }
MongoDB server version: 3.6.23
Welcome to the MongoDB shell.
For interactive help, type “help”.
For more comprehensive documentation, see
Questions? Try the support group
Server has startup warnings:
2025-12-26T17:34:36.815-0500 I CONTROL [initandlisten]
2025-12-26T17:34:36.815-0500 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2025-12-26T17:34:36.815-0500 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2025-12-26T17:34:36.815-0500 I CONTROL [initandlisten]
meteor:PRIMARY> db.currentOp(true).inprog.reduce((accumulator, connection) => { ipaddress = connection.client ? connection.client.split(“:”)[0] : “unknown”; accumulator[ipaddress] = (accumulator[ipaddress] || 0) + 1; accumulator[“TOTAL_CONNECTION_COUNT”]++; return accumulator; }, { TOTAL_CONNECTION_COUNT: 0 })
{
“TOTAL_CONNECTION_COUNT” : 277,
“192.168.32.155” : 5,
“192.168.33.179” : 18,
“192.168.32.68” : 1,
“127.0.0.1” : 231,
“unknown” : 21,
“192.168.32.149” : 1
}
(Connection status command from here since I’m not a MongoDB expert)
You might be able to limit exposure to the MongoDB instance by putting it behind a firewall that only allows traffic to port 39001 (assuming default port settings) for the subnet that contains your nodes.
@moskalenko thanks for posting. @jpellman is correct: CryoSPARC workers connect directly to the MongoDB database to write updates during processing that are then relayed to the UI for real time monitoring and visualization. Therefore it is not possible to limit MongoDB to bind only to the loopback interface. @jpellman’s suggestion to limit traffic to the database port via firewall for the subnet containing worker nodes may be helpful.
Thank you for the clarification! It is unfortunate, but I understand how it works.
I hope that Structura is considering a feature to have CryoSPARC workers talk to an api instead of mongod directly in the future as there is a possibility that Mongo will become an unacceptable security risk for larger environments.
Thank you again.
Alex