| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An insecure direct object reference in the nested attributes handling of the Mongoid object-document mapper may allow a user with basic application privileges to reference a record identifier that is not their own. Processing such a request can cause that record to be looked up without the usual ownership or scoping restrictions, then updated and linked to the requesting user's own record. This may result in unintended disclosure and unauthorized modification of data belonging to other users of the application. |
| Mongoid contains an unsafe reflection weakness in the document persistence layer of its object-document mapping code. Input whose keys are passed through from an unauthenticated party by an embedding application can cause unintended internal method invocation instead of the intended array field update. This may result in unintended removal of stored records and in the embedding application becoming unresponsive. |
| Mongoid may omit encryption rules for fields declared on embedded models when generating the client-side field-level encryption schema. Applications that enable this feature can therefore store values intended to be encrypted in readable form, with no error or warning. A party with routine read access to the database, a backup, or the underlying data files may then see data that was meant to remain unreadable outside the application. |
| An inefficient regular expression complexity issue in the in-memory query evaluation component of the Mongoid library may allow an unauthenticated party to cause excessive processing within an embedding application process. Applications that place user-supplied text into a pattern-matching query condition on an embedded association may become unresponsive. |
| A protection mechanism failure in the object-document mapper's encryption configuration generation can cause fields that an application declared for client-side field-level encryption to be written and kept in cleartext, without any error or warning. A party holding ordinary read access to the database can then read values that were intended to be protected from that party. This may result in unintended disclosure of sensitive information. |
| Mongoid contains an unsafe reflection weakness in the query path used for embedded documents. An application that passes an externally supplied field name to certain in-memory query methods may allow an unauthenticated party to obtain unintended disclosure of stored document data and to permanently remove stored records. |
| Mongoid does not restrict which query operators may come from caller-supplied filter data when an application hands that data to its query-building methods. In an application that forwards externally supplied filter parameters in this way, a party with no credentials may influence how the database evaluates the query. This may result in unintended disclosure of stored field values and in reduced database performance. |
| Mongoid does not neutralize a string-typed query criterion supplied to its query builder, and instead passes it to the database as a server-side JavaScript expression. An unauthenticated party able to influence the value an application supplies as a query argument may cause code of their choosing to be evaluated by the database engine. This may result in unintended disclosure of stored field values, unintended selection of documents for application-initiated writes, and reduced database performance. |
| A flaw in libmongoc's SCRAM authentication implementation caused the client to continue the authentication handshake and transmit the client proof even when a nonce mismatch was detected in the server's first message. An unauthorized party with a man-in-the-middle position could exploit this by injecting a crafted server-first-message containing a controlled salt and low iteration count, then capturing the resulting client proof to perform offline password cracking. This vulnerability is mitigated by TLS, which is standard in production deployments. |
| Applications built on MongoDB Entity Framework Core Provider which combine independent encryption settings and this provider's encryption settings may silently lose TLS and schema-map settings leading to protected fields being stored unencrypted in the database. |
| If logging mode is set to DEBUG or a malformed MongoDB connection string is used, application logs may collect sensitive information (if in use) such as passwords and AWS secure access keys. |
| Applications built on MongoDB Entity Framework Core Provider which place a database name in the connection string may inadvertently disable field level encryption. |
| A heap-based buffer overflow exists in the TLS transport layer of the MongoDB C Driver when built with the Windows platform TLS backend. A remote endpoint that the client connects to can cause the driver to write uncontrolled data outside the bounds of a heap allocation while processing incoming encrypted traffic after the TLS handshake completes. No authentication or user interaction is required, because the affected processing occurs before any application-level authentication completes. Triggering this issue may lead to memory corruption in the client process, disclosure of adjacent heap memory, or termination of the process. |
| A missing lower-bound validation in the bson_new_from_buffer() function of libbson allows an integer underflow when processing BSON data with a zero-length prefix. The function reads a 32-bit document length from the input buffer but does not verify that the value is at least 5 (the minimum valid BSON document size) before using it in an array index calculation. When the length field is zero, the expression used to check the document's null terminator wraps to UINT32_MAX, causing a heap out-of-bounds read that crashes the process. An unauthorized party who can supply crafted BSON input to an application using this API can cause a denial of service. |
| An authenticated user with write privileges on a Queryable Encryption-enabled collection may be able to modify internal encryption metadata fields that are intended to be server-controlled, by sending crafted write commands through the mongos router on a sharded cluster. This can result in corruption of encrypted query correctness. |
| An authenticated user with limited read privileges may be able to access documents from collections they are not authorized to read, due to an inconsistency in how the $graphLookup aggregation stage is evaluated during authorization and during execution. Affected scenarios involve collections referenced within existing view pipeline definitions. |
| The MongoSQL Transition Readiness Tool writes database and collection names into its generated CSV reports without neutralizing leading characters that spreadsheet applications treat as formulas. A user with write privileges on the cluster can choose a namespace name that is later evaluated as a formula when an operator opens the generated report in a spreadsheet application, which may result in unintended disclosure of report contents or execution of external content on the operator's workstation. Generating a report for the affected namespace and opening it in a spreadsheet application is required. |
| The MongoSQL Transition Readiness Tool writes query text and user names read from BI Connector log files into its generated HTML report without encoding them for that output context. A user able to issue queries through the BI Connector can influence log content so that markup supplied in a query is interpreted by the browser when an operator later generates and opens the report, which may disclose other users' logged query text and user names to an external party or present misleading content to the operator. Generating a report over logs containing the affected entries and opening that report in a browser is required. |
| MongoSQL Transition Readiness Tool does not sufficiently encode database metadata before including it in generated HTML. A MongoDB user with write access can introduce crafted metadata that may cause script code to run when another user generates and opens the report, potentially exposing report contents or altering its display. |
| An unauthorized user with key vault write access may cause an authorized client to issue arbitrary authenticated Google Cloud KMS API calls under the authorized user's identity, escalating database-level access into cloud key control and defeating client-side encryption. |
