Summary

PyMongo percent-decoded the entire host section of a connection string before splitting it into individual host:port entries. A percent-encoded , or : in a hostname therefore decoded into a real delimiter, injecting an additional attacker-chosen host and port into the client's seed list.

Impact

An application that interpolates untrusted input into a MongoDB connection string -- for example, a tenant name or hostname fragment taken from a request -- could be made to add an attacker-controlled server to the seed list. Because %2C and %3A survive most URL-safety checks and only become delimiters inside PyMongo's parser, input that looks like a single hostname to the application becomes two hosts to the driver. The client may then perform topology discovery and authentication against the attacker's host, exposing credentials, or route operations to it.

Unix domain socket paths, the only host identifiers that legitimately require percent-encoding, are not affected.

Patches

Fixed in PyMongo 4.18.2. Percent-decoding was moved into splithosts and now applies only to Unix domain socket paths, identified by an unescaped .sock suffix before decoding, and only after splitting on ,.

Workarounds

Do not interpolate untrusted input into the host portion of a connection string. If unavoidable, reject or percent-decode-and-validate the value before building the URI.

Details

The decoding was introduced in PyMongo 3.5.0 (PYTHON-1282), where unquoteplus was applied to the whole host section in validateuri and, later, parsesrv, before the string was split on , and :.

An integer overflow in the BSON document encoding component of the MongoDB Python Driver's bundled native extension may occur when a single document is built from an unusually large amount of caller-supplied data. Size arithmetic is performed in a signed 32-bit type, and the guard meant to catch the overflow is written in a form whose behavior is not defined by the C language standard. A party with no privileges who can place a very large value into data that an application encodes may, depending on how the native extension was built, cause a write outside the bounds of an allocated buffer inside the application's own process.

Impact

When reading/writing via an ID with the GridFS API, require an exact match on the given ID. Otherwise, if a Hash is given in place of the ID, it may be interpreted as criteria, overriding the ID match.

Patches Patch available in pymongo >= 4.18.1

Workarounds Ensure your existing workflow only supports exact matching on the GridFS API.

The MongoDB Python Driver's binary accelerator can read outside a buffer when an application decodes malformed BSON containing a truncated regular-expression element without a trailing NUL byte. An actor who can supply BSON to the documented decode or decodeall API can cause the application process to terminate when the C extension is loaded. The driver's normal database wire-protocol path does not reach this code.

Summary

PyMongo passed the KMS endpoint of a data key verbatim into parsehost(), which returns any string ending in .sock unchanged instead of validating it as a hostname and port. The driver's connection code then treats such an address as a Unix domain socket path and connects to it with AFUNIX. Because the endpoint originates from masterKey.endpoint in a key vault document, a party who can write to the key vault could redirect the driver's KMS connection to an arbitrary Unix domain socket path on the application host.

Impact

An application using client-side field level encryption (CSFLE) or Queryable Encryption is affected if an attacker can write to its key vault collection. Setting masterKey.endpoint on a data key to a .sock-suffixed string causes the next KMS request for that key (key cache TTL is ~60 seconds) to open an AFUNIX connection to the attacker-chosen filesystem path from inside the victim application process. The documented custom KMS endpoint feature supports TCP hosts only, so this crosses a boundary the feature was never intended to allow.

Impact is limited to the side effects of the connection itself. The socket is still wrapped in a verifying TLS context using the .sock string as serverhostname, and insecure KMS TLS options are rejected, so the handshake always fails and the KMS message is never sent. The attacker controls the connect target but not the transmitted bytes (a fixed TLS ClientHello).

Applications that do not use CSFLE or Queryable Encryption are not affected. Applications whose key vault is not writable by untrusted parties are not affected.

Patches

Fixed in PyMongo 4.18.2 EncryptionIO.kmsrequest now rejects a .sock-suffixed KMS endpoint with pymongo.errors.ConfigurationError immediately after parsing, before any connection is attempted, on both the synchronous and asynchronous paths. No application code changes are required beyond upgrading.

Workarounds

If you cannot upgrade immediately:

- Restrict write access to the key vault collection to trusted principals only. This is the recommended configuration regardless of this issue. - Validate masterKey.endpoint on data keys you create, and audit existing key vault documents for endpoints ending in .sock.

Details

- EncryptionIO.fetchkeys reads key vault documents from the server and hands them to libmongocrypt, which surfaces the stored masterKey.endpoint verbatim as kmscontext.endpoint. - EncryptionIO.kmsrequest passed that string to parsehost(endpoint, 443). parsehost returns entities ending in .sock verbatim, skipping the hostname and port validation applied to every other input. - createconnection (and the async equivalent) checks host.endswith(".sock") and performs an AFUNIX sock.connect(host), treating the string as a filesystem path.