Let's assume that the password hash consists of an 128-bit MD5 hash over the password. Due to the birthday problem there is a >98%† chance that, among 11-characters passwords consisting of ASCII letters and digits (62 possible values, giving $2^{\approx65.5}$ passwords), two have the same hash. Thus what's asked most likely mathematically exists.
However, the fast techniques we know to obtain MD5 collisions are for 64-byte (or more) inputs. They are not applicable in the context.We thus need brute force, that is in the order of $2^{65}$ MD5 computations, when a GeForce RTX 3090 does in the order of $2^{36}$ MD5/s (source), thus we'd need running like 200 such GPUs for a month. High-end FPGAs would also do, I imagine with less power.
In order to avoid tremendous RAM requirements, algorithms to find collision of a hash function by brute force use some cycle finding technique. The simplest re-hashes the previous hash result (or a surjective remapping of the hash to the message space, e.g. encoding the hash to Base64 before hashing again if we want collision between ASCII messages), until finding a cycle. With near certainty there is a collision where the cycle closes, which can be identified e.g. by Floyd's technique. Variations allow to distribute the work with feasibly little RAM, and identify where the cycle closes with less work. The standard references is Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999.
One issue with the technique that I summarized is that the message domain must be as large as the hash domain, requiring $2^{128}$ passwords, like 20 characters among 85. I'm not sure existing password systems accept that.
I asked for techniques allowing shorter passwords, and now I'm given references showing that's been studied and is possible to some degree. I'll update the present answer when I'll have that ironed out.
Unfortunately I have no sponsor for the GPUs or FPGAs.
† Computed as $1-e^{-62^{11}/2^{129}}$
