CVE-2026-96747

Summary

PyMongo passed the KMS endpoint of a data key verbatim into parse_host(), 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 AF_UNIX. 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 AF_UNIX 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 server_hostname, 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.kms_request 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.fetch_keys reads key vault documents from the server and hands them to libmongocrypt, which surfaces the stored masterKey.endpoint verbatim as kms_context.endpoint.
• _EncryptionIO.kms_request passed that string to parse_host(endpoint, 443). parse_host returns entities ending in .sock verbatim, skipping the hostname and port validation applied to every other input.
• _create_connection (and the async equivalent) checks host.endswith(".sock") and performs an AF_UNIX sock.connect(host), treating the string as a filesystem path.

Summary

PyMongo passed the KMS endpoint of a data key verbatim into parse_host(), 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 AF_UNIX. 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 AF_UNIX 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 server_hostname, 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.kms_request 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.fetch_keys reads key vault documents from the server and hands them to libmongocrypt, which surfaces the stored masterKey.endpoint verbatim as kms_context.endpoint.
• _EncryptionIO.kms_request passed that string to parse_host(endpoint, 443). parse_host returns entities ending in .sock verbatim, skipping the hostname and port validation applied to every other input.
• _create_connection (and the async equivalent) checks host.endswith(".sock") and performs an AF_UNIX sock.connect(host), treating the string as a filesystem path.

The client-side field level encryption support in the MongoDB Python Driver can treat a key management endpoint value ending in ".sock" as a local Unix domain socket path rather than a remote host. A user with write access to the encryption key metadata stored in the database can cause an application using the driver to open connections to local sockets on the application host. Data sent over these connections is limited to the start of a TLS handshake, so no chosen content is transmitted.

The client-side field level encryption support in the MongoDB Python Driver can treat a key management endpoint value ending in ".sock" as a local Unix domain socket path rather than a remote host. A user with write access to the encryption key metadata stored in the database can cause an application using the driver to open connections to local sockets on the application host. Data sent over these connections is limited to the start of a TLS handshake, so no chosen content is transmitted.

These are all security issues fixed in the python313-pymongo-4.18.2-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-pymongo fixes the following issues:

Changes in python-pymongo:

• CVE-2026-96749: integer overflow in BSON document encoding allows an unprivileged user to write outside the bounds of an allocated buffer (bsc#1282845)
• CVE-2026-96748: host injection in connection string leading to database connection redirection due to improper connection string parsing (bsc#1282827)
• CVE-2026-96747: improper handling of key management endpoint values ending in .sock allows users with write access to the encryption key metadata to open connections to local sockets on the application host (bsc#1282844)

This update for python-pymongo fixes the following issues:

• CVE-2026-96747: improper handling of key management endpoint values ending in .sock allows users with write access to the encryption key metadata to open connections to local sockets on the application host (bsc#1282844).
• CVE-2026-96748: host injection in connection string leading to database connection redirection due to improper connection string parsing (bsc#1282827).
• CVE-2026-96749: integer overflow in BSON document encoding allows an unprivileged user to write outside the bounds of an allocated buffer (bsc#1282845).