The killCursors and releaseMemory authorization checks have potential for a "time-of-check to time-of-use" race allowing a malicious user to intentionally kill cursors from other users:

In the authorization check for both commands, if the cursor does not exist, it will let the command continue running, expecting that when the command tries to kill the cursor, it will find again that it still does not exist, and fail.

However, it may happen that the cursor is allocated right after the auth check. The chance that this succeeds is not random because cursor IDs are predictable: They are allocated using a non-cryptographically secure pseudo-random number generator, which is shared.

In a multi-user/multi-tenant environment, a malicious user may be able to reconstruct the state of the PRNG from observed cursor IDs, use it to guess the next cursor IDs to be allocated by other users, then attempt to kill them, which will occasionally succeed, when the cursor gets allocated right after the auth check.