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()};
}

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 at docs.pritunl.com/kb/vpn/security/features and information on securely configuring a Pritunl server is available at docs.pritunl.com/kb/vpn/security/securing-pritunl

The template format is based on Markdown and uses YAML for the resource specification and a combination of Bash and Python for scripting. This supports seamless transitions between Bash and Python to handle complex deployment tasks. Data is shared between the scripts using environment variables.

Scripts are scheduled to run in three phases. The initial phase runs only once when the instance is created, the reboot phase runs on all reboots, and the reload phase runs anytime the cluster state changes. The live template design allows making dynamic adjustments to configurations.

Below is an Nginx load balancer script that pulls the IP addresses of all the web app servers and updates the reverse proxy configuration. Then the latest certificate is pulled from the Pritunl Cloud certificate manager, which automatically manages Let’s Encrypt certificates.

Templates can also manage DNS entries and firewalls. The template below opens the firewall for web traffic, then creates a DNS entry using the public IP of the deployed instance.

The Markdown template format allows adding all the pod deployment information in one file and including detailed documentation inside the template alongside each block of code.

After changes are made to a template, existing deployments can be migrated in place with a graphical diff view of what changes will occur. The Pritunl Cloud agent running on the instance will then pull the latest template and run a reload phase with the updated scripts.

Output from the deployment scripts can be viewed live from the web console with a full overview of the instance status.

Instances run with a familiar networking structure to most cloud providers. The instance is given a private VPC IP address on the instance network interface. Then the public IP address, if one is configured, is NATed to the private IP address. The instance networking is run inside a network namespace on the host to provide improved isolation and sandboxing.

To enable this pritunl-link must also be updated to the newly released v1.0.3454.46 and the wireguard-tools package must be installed on the link servers. After all the link locations have been prepared the link can be transitioned to WireGuard by changing the Protocol in the link settings to WireGuard. A WireGuard port can be specified or if left blank it will be randomly selected between 30000 and 32000. Some configurations may require opening the WireGuard UDP port on the firewall. But for most firewalls this will not be needed as both sides of the link initiate a connection allowing the network traffic to traverse most stateful firewalls.

View Release Announcement on the Pritunl Forum

Subscribe now