PyMongo: PYTHON-5990 Forced Unix domain socket connection via a .sock KMS endpoint in client-side field level encryptionGHSA-qx36-8mw2-4r3x
MEDIUMFix: mongodb/mongo-python-driver#3066GHSA-qx36-8mw2-4r3x is a medium-severity (CVSS 5) Server-Side Request Forgery (SSRF) vulnerability in pymongo. A fix is available for pymongo — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-qx36-8mw2-4r3x.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-qx36-8mw2-4r3x by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
pymongoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.endpointon data keys you create, and audit existing key vault documents for endpoints ending in.sock.
Details
_EncryptionIO.fetch_keysreads key vault documents from the server and hands them to libmongocrypt, which surfaces the storedmasterKey.endpointverbatim askms_context.endpoint._EncryptionIO.kms_requestpassed that string toparse_host(endpoint, 443).parse_hostreturns entities ending in.sockverbatim, skipping the hostname and port validation applied to every other input._create_connection(and the async equivalent) checkshost.endswith(".sock")and performs anAF_UNIXsock.connect(host), treating the string as a filesystem path.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | pymongo | ≥ 3.9.0&&< 4.18.2 | 4.18.2pip install --upgrade 'pymongo==4.18.2' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pymongo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update pymongo to 4.18.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qx36-8mw2-4r3x is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated as Moderate severity because an attacker requires existing write privileges to alter database key management metadata, and the operational blast radius is constrained by the inability to inject arbitrary payloads. In standard Red Hat product deployments, applications leveraging pymongo do…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for GHSA-qx36-8mw2-4r3x (CC BY 4.0)
Frequently Asked Questions
Is GHSA-qx36-8mw2-4r3x in your dependencies?
Find it across PyPI, including transitive dependencies.