GHSA-qx36-8mw2-4r3x: Input Validation
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/pymongoto a version that resolves this vulnerability.Fixed in 4.18.2 - Upgrade
Upgrade
PyMongoto a version that resolves this vulnerability.Fixed in 4.18.2 - Compensating control
Restrict write access to the key vault collection to trusted principals only.
- Compensating control
Validate masterKey.endpoint on created data keys and audit existing key vault documents for endpoints ending in .sock.
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications using client-side field level encryption (CSFLE) or Queryable Encryption are affected when an attacker can write to the application's key vault collection. The issue concerns data keys whose masterKey.endpoint value can be modified.
What does an attacker need to do to trigger the behavior?
The attacker needs write access to the key vault and must set a data key's masterKey.endpoint to a string ending in .sock. When the application next makes a KMS request for that key, it may connect to the chosen Unix-domain socket path; the key cache TTL is approximately 60 seconds.
How can I check whether key vault data indicates attempted exploitation?
Review data key documents in the key vault for masterKey.endpoint values ending in .sock. Such values can cause the driver to treat the endpoint as a Unix-domain socket path rather than a TCP hostname and port.