There has been some misleading information about MongoDB and CVE-2025-14847. Below are several misleading claims about MongoDB.
- The internet scanning service Shodan shows 213k MongoDB servers open on the internet
It is true there are 213k MongoDB servers discovered by Shodan, but there are also 2.48 million MySQL servers and 557k PostgreSQL servers open on the internet. A database server should never be open to the internet, and none of these servers are correctly configured. Nothing about the design of MongoDB encourages or makes it more likely to be incorrectly configured to allow access from the internet. All production systems should have external firewalls correctly configured and should never rely solely on the system’s configuration files to control access.
- MongoDB has a fundamentally less secure design than SQL databases
SQL injection attacks have been a persistent problem for decades, including as recently as last month with the injection attack discovered in the Python Django library (CVE-2025-64459). These vulnerabilities impact the database even when it is correctly secured. While MongoDB can experience injection attacks specifically when JSON is directly deserialized into a BSON query, the BSON query format and the MongoDB client libraries have been significantly more resistant to injection attacks than SQL.
- MongoDB has a worse security history than comparable SQL databases
Both MySQL and PostgreSQL have had remote code execution and authentication bypass vulnerabilities. For this reason, no database should ever be made accessible to the internet, even with authentication. MongoDB is written in C++, PostgreSQL in C, and MySQL in C/C++. All of these programming languages are susceptible to memory safety vulnerabilities. Nothing about the design or history of MongoDB has made it more susceptible to vulnerabilities.
MySQL CVE-2012-2122 - Authentication Bypass
MySQL CVE-2016-6662 - Remote Code Execution
MySQL CVE-2019-5482 - Remote Code Execution
PostgreSQL CVE-2019-9193 - Remote Code Execution
PostgreSQL CVE-2020-25695 - Authentication Bypass
- MongoDB had dangerous defaults instead of a localhost bind
When MongoDB was under the AGPL license prior to 2018, several Linux distributions repackaged the software in their distribution repositories, and some of these packages neglected to include a /etc/mongod.conf configuration with bindIp: 127.0.0.1. This resulted in the default value bindIp: 0.0.0.0 being used, and if the server did not have a firewall configured, this would allow the database to be accessible from the internet. This was never the case for the official mongodb-org packages from MongoDB repositories, which always included a configuration file with bindIp: 127.0.0.1. The default was eventually changed by MongoDB so that even if the configuration file did not specify a bindIp, it would default to 127.0.0.1. The Linux distribution MongoDB packages were rarely used, and most did have the correct bindIp configured. The Pritunl documentation has always instructed users to install the mongodb-org packages.
- Additional information on the security of Pritunl
No updates to the Pritunl software are required to address this issue, and the vulnerability cannot be exploited through the Pritunl web console. It requires direct access to the database server on port 27017. There has never been a vulnerability discovered in the Pritunl server, and it is safe to have the Pritunl web server open to the internet. The system is well designed with a two-layer web server architecture that processes and validates requests in the pritunl-web Go web server process before sending the request to the internal Python web server in the root process. If a vulnerability were found, the Pritunl server will automatically shut down vulnerable components due to an hourly check that sends the running version to the app.pritunl.com servers to check for self-shutdown events. More information on the security features in Pritunl is available in the security features documentation and information on securely configuring a Pritunl server is available in the securing Pritunl documentation.