MongoDB: fixes for the Go Driver and libmongocrypt (AV26-1024)
Canadian advisory AV26-1024: vulnerabilities in the MongoDB Go Driver before 2.9.2 and in libmongocrypt before 1.20.5. What to update and what to check.

On 9 October 2026 the Canadian Centre for Cyber Security published advisory AV26-1024, covering two MongoDB components that run inside applications: the official Go driver and libmongocrypt, the library that handles client-side encryption. The advisory is currently the only available source on this news and it is very brief: it gives no CVE identifiers, no severity scores and no reports of exploitation. Below you will find what it says, what it does not say and how to check whether your applications are affected.
What happened
According to the Canadian advisory, as of 8 October 2026 MongoDB is affected by vulnerabilities in the following products:
- Go Driver: the advisory lists versions prior to 2.9.0 and prior to 2.9.2, without explaining what each of the two thresholds refers to;
- libmongocrypt: versions prior to 1.20.5.
The Cyber Centre encourages users and administrators to review the links in the advisory and apply the necessary updates. The links point to MongoDB’s security alerts page and to three fixes, whose titles are the only technical detail available.
Technical details
Go Driver: checks on BSON lengths
Two of the fixes concern how the Go driver reads BSON documents, the binary format MongoDB uses to exchange data:
- “Reject int32 length overflow in bsoncore.valueLength”: the driver must reject values whose length, written as a 32-bit integer, overflows. The function belongs to
bsoncore, the package that reads BSON documents at a low level inside the driver; - “Reject BSON lengths below the 5-byte minimum before slicing”: the driver must reject lengths below 5 bytes before slicing the data. In the BSON format every document starts with its own length on 4 bytes and ends with a null byte, so 5 bytes is the smallest possible size.
Both cases are about input validation on binary data: a malformed document with inconsistent lengths was not discarded before processing. The advisory does not say what consequences this has, nor in which scenarios an attacker could get a crafted document to the driver. In general, in Go a missing check before a slicing operation can cause a runtime error (panic) and stop the process if the error is not handled; this is only a general note, not confirmed by the source for this case.
libmongocrypt: duplicate masterKey field
The third fix, “Duplicate masterKey field re-parses into the same KEK”, concerns libmongocrypt. In MongoDB client-side encryption (Client-Side Field Level Encryption and Queryable Encryption) data is encrypted with dedicated keys, which are in turn protected by a master key held in a key management service (KMS): this is the KEK, key encryption key. The masterKey field says which master key to use and appears both in the key creation options and in the documents of the collection that stores the keys (the key vault).
Judging from the title, a document with a repeated masterKey field was parsed again into the same KEK structure. The advisory does not explain the effect: we do not know whether the problem leads to memory errors, to the wrong key being chosen or to something else.
The Go driver uses libmongocrypt when it is built with client-side encryption support, so both components in the advisory can end up in the same application.
What the advisory does not say
Keep this in mind before setting priorities:
- no CVE and no CVSS score;
- no reports of active exploitation or of public proof-of-concept code;
- no indicators of compromise;
- nothing about the 1.x branch of the Go driver: all the versions mentioned belong to the 2.x branch.
For details, the advisory refers to MongoDB’s security alerts page, which is worth checking for any identifiers and severity ratings published later.
Impact for European and Italian companies
The Go driver and libmongocrypt are not network-facing services but dependencies compiled into or loaded by applications: internal microservices, APIs, integration tools, third-party software. This is why the risk is managed on the development and software supply chain side, not only on the server side.
For entities in scope of NIS2, vulnerability management and supply chain security are part of the required security measures: knowing which applications include these components, and in which version, is part of that work. If you use MongoDB client-side encryption to protect sensitive data, such as health or financial data, give priority to updating libmongocrypt.
What to do now
- Take inventory. In Go projects look for the
go.mongodb.org/mongo-driver/v2module (for example withgo list -m all) and note the version. Remember that Go binaries embed their dependencies in the executable: an inventory of system packages will not see them. - Update the Go Driver to 2.9.2 or later. Since the advisory gives two thresholds without explaining them, 2.9.2 is the cautious choice. Rebuild and redeploy your applications, container images included.
- Update libmongocrypt to 1.20.5 or later. It may be installed as an operating system package or shipped with the encryption package of a driver for another language: check both routes.
- Ask your software vendors whether their products include these components and when they will update them.
- Restrict who can write to the key vault used by client-side encryption: it is good practice anyway, and the
masterKeyfield involved in the fix is also found in those documents. - Watch for crashes in applications that use the driver and follow MongoDB’s security alerts page for any CVEs published later.
How ARXDOME helps
ARX Sentry collects the inventory of software, processes and ports from computers and servers, which helps you find where libmongocrypt is installed as a system package and which services run on each machine. ARX Shield shows open vulnerabilities by machine and by package, when they are registered with a public identifier.
Last updated:


