[SECURITY] MongoDB CVE-2025-14847

MongoDB has disclosed CVE-2025-14847. This vulnerability allows for up to 48MB of uninitialized heap memory to be leaked without authentication if the attacker has access to the MongoDB server on port 27017. Pritunl servers should never be configured with the MongoDB database open to the internet, even with a password. The Pritunl installation documentation has always instructed the database to be configured with a localhost bind. Assuming the installation instructions were followed, there will be no vulnerability. Having access to the Pritunl web console does not allow the MongoDB vulnerability to be exploited. This can only be exploited with direct access to the MongoDB server on port 27017.

Update the mongodb-org-server package, then run mongod --version and check the version against the patched versions: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30. If the database is older than 4.4, the mitigation must be used instead. If it is the correct version, run sudo systemctl restart mongod.service to verify the patched version is running. This will not disrupt VPN connections or server availability.

To mitigate the issue without updating the database, disable the vulnerable zlib compression by editing /etc/mongod.conf and adding the compressors option with zlib excluded as shown below. This should be done with caution, as adding an additional net section will result in the previous net section being ignored. With older versions of MongoDB that default the bindIp to 0.0.0.0, this would result in the database becoming open to the internet. For all single instance Pritunl configurations, the bindIp should be 127.0.0.1. Once this is done, run sudo systemctl restart mongod.service.

net:
  port: 27017
  bindIp: <VERIFY_BIND_IP_IS_INCLUDED>
  compression:
    compressors: snappy,zstd

The vulnerability is caused by using the buffer size return {output.length()} instead of the decompressed size return {length} set by the decompressor. This results in loading uninitialized memory up to the size of the buffer. The client controls the size of the buffer with compressionHeader.uncompressedSize with a maximum of 48MB set by MaxMessageSizeBytes.

StatusWith<std::size_t> ZlibMessageCompressor::decompressData(ConstDataRange input,
                                                              DataRange output) {
    uLongf length = output.length();
    int ret = ::uncompress(const_cast<Bytef*>(reinterpret_cast<const Bytef*>(output.data())),
                           &length,
                           reinterpret_cast<const Bytef*>(input.data()),
                           input.length());

    if (ret != Z_OK) {
        return Status{ErrorCodes::BadValue, "Compressed message was invalid or corrupted"};
    }

    counterHitDecompress(input.length(), output.length());
    return {output.length()};
}
1 Like

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.

1 Like