CVE-2026-81525: Cross-Tenant Database Retargeting via Dot and Null Injection in MongoDB PHP Driver

The MongoDB Client Library for PHP (mongodb/mongodb) and the underlying native PHP C Extension (ext-mongodb) are vulnerable to database and collection namespace injection. The flaw arises from an architectural pattern where fully qualified namespace strings are built by joining database and collection names with a period delimiter. When applications dynamically construct these names using untrusted inputs, they expose a highly sensitive interface to manipulation.

The vulnerability stems from the improper neutralization of special structural characters within these identifier inputs. Specifically, the software fails to reject period (.) characters in database names and null bytes (\0) in both database and collection names. This oversight allows remote users to alter the logical boundaries of database operations.

By injecting these characters, attackers can break out of their designated tenant databases and access administrative or restricted system namespaces. This vulnerability represents a class of injection that bypasses logical access controls, threatening data confidentiality and integrity across multi-tenant deployments.

MongoDB uses fully qualified namespace strings of the format databaseName.collectionName to direct read and write operations. The period character acts as a structural separator between the database component and the collection component. If an application accepts a database name containing a period character, the server parses the string using the first period as the delimiter. This shifts the target database and collection boundaries, allowing dot injection attacks.

In addition to dot injection, a severe binary-to-string representation mismatch exists between the PHP engine and the native C extension. PHP handles strings as length-prefixed, binary-safe structures that can natively contain null bytes (\0) without indicating string termination. Conversely, the underlying C library, libmongoc, relies on standard null-terminated C-style strings.

When a PHP string containing a null byte is passed to the C layer, the C library stops parsing at the first null byte. This causes string truncation, dropping the remainder of the namespace. An attacker can construct a string that passes user-land validation checks in PHP but is truncated in the C driver, silently redirecting operations to unauthorized databases.

The vulnerability in the PHP userland library was addressed by introducing strict validation within the Database and Collection class constructors. The patch introduces a centralized validation helper, create_namespace(), to enforce structural rules before names are combined.

// File: src/functions.php - Centered validation helper
function create_namespace(string $databaseName, string $collectionName): string
{
    if ($databaseName === '' || str_contains($databaseName, '.') || str_contains($databaseName, "\0")) {
        throw new InvalidArgumentException('$databaseName is invalid: ' . $databaseName);
    }
 
    if ($collectionName === '' || str_contains($collectionName, "\0")) {
        throw new InvalidArgumentException('$collectionName is invalid: ' . $collectionName);
    }
 
    return $databaseName . '.' . $collectionName;
}

Prior to this fix, the constructors in Collection.php only verified that the length of the database and collection names was greater than zero. This allowed arbitrary characters, including dots and null bytes, to propagate down to the native driver.

// File: src/Collection.php - Updated validation check
public function __construct(private Manager $manager, private string $databaseName, private string $collectionName, array $options = [])
{
    if (strlen($databaseName) < 1 || str_contains($databaseName, '.') || str_contains($databaseName, "\0")) {
         throw new InvalidArgumentException('$databaseName is invalid: ' . $databaseName);
    }
 
    if (strlen($collectionName) < 1 || str_contains($collectionName, "\0")) {
         throw new InvalidArgumentException('$collectionName is invalid: ' . $collectionName);
    }
}

In the C extension layer (ext-mongodb), safety checks were added using memchr() to guarantee validation even when developers bypass the PHP library. The C function phongo_validate_dbname() now checks for the presence of null bytes and dots using the explicit length of the Zend string.

/* Rejects database name with NUL or period */
bool phongo_validate_dbname(const char* db, size_t db_len)
{
	if (db == NULL) {
		return true;
	}
 
	if (memchr(db, '\0', db_len) != NULL) {
		phongo_throw_exception(PHONGO_ERROR_INVALID_ARGUMENT, "%s", "Invalid database name provided: database names may not contain a null byte");
		return false;
	}
 
	if (memchr(db, '.', db_len) != NULL) {
		phongo_throw_exception(PHONGO_ERROR_INVALID_ARGUMENT, "%s: %s", "Invalid database name provided: database names may not contain a '.' character", db);
		return false;
	}
 
	return true;
}

Exploiting this vulnerability requires an application to use untrusted user input to select or build the database or collection names. This pattern is commonly found in multi-tenant SaaS applications where tenant IDs are used directly to partition databases dynamically. An attacker must have network access to the application interface that processes these database-backed requests.

In a dot injection scenario, the attacker supplies a payload containing a dot character in a parameter intended to define the database name. For example, supplying admin.system as the database name causes the combined namespace to become admin.system.collectionName. The MongoDB server interprets admin as the database name and system.collectionName as the target collection, bypassing tenant database constraints.

In a null byte truncation scenario, the attacker injects a null character into the database name parameter, such as admin\x00tenant_db. PHP validates the full string length, but when passed to the C driver, the namespace string is truncated to admin. Any subsequent write or query commands are executed within the context of the administrative database, leading to privilege escalation.

The severity of CVE-2026-81525 is categorized as High, with a CVSS v3.1 score of 8.1 and a CVSS v4.0 score of 8.6. The primary impact is the collapse of logical access boundaries between different database tenants. Attackers can leverage this bypass to read, write, or delete documents belonging to other users or the platform itself.

A major consequence is unauthorized administrative database access. An attacker who can write to arbitrary namespaces can target internal system collections like system.users or system.views. In standard MongoDB deployments, writing to these collections can result in full database takeover and persistent privilege escalation.

Additionally, this vulnerability does not require authentication beyond the basic access needed to reach the vulnerable endpoint. If an unauthenticated public endpoint dynamically routes data to collections based on request headers or query variables, the vulnerability is fully exploitable by external actors.

The most effective remediation is upgrading the MongoDB PHP Client Library and the PHP C Extension to the patched versions. Applications running on the 1.x branch must upgrade the userland library to version 1.21.4 or higher, and the native extension to version 1.21.6 or higher. Teams running the 2.x branch must upgrade both components to version 2.4.1.

If immediate package upgrades are not possible, temporary input filtering must be applied in the application layer. All user inputs that influence database or collection identifiers must be rigorously sanitized. A strict allowlist approach should be used, rejecting any input containing dots, null bytes, or non-alphanumeric characters.

// Temporary verification helper
function secure_validate_db_identifier(string $input): bool
{
    if (str_contains($input, "\0") || str_contains($input, ".")) {
        return false;
    }
    return (bool) preg_match('/^[a-zA-Z0-9_-]+$/D', $input);
}

In addition to code-level changes, organizations should audit database user privileges. Ensuring that application database credentials adhere to the principle of least privilege limits the potential damage of a namespace injection attack. For example, restricting the user's scope so they cannot access the admin database minimizes the impact of a successful injection attempt.