My _guess_ at this point is that there's a bunch of scary corner cases with the behaviour that makes this possible so that if your bulk host or CDN does this you need to be _very_ careful even if Let's Encrypt abolishes tls-sni family proofs of control. If I'm right, fixing this is pretty urgent for anyone with untrusted users sharing an IP address.

It looks very much as if affected hosts/CDNs are letting any customer impersonate any other customer with the only caveats being that you've got to get in first and you need the victim customer to make the config change that causes this to be useful.

Suppose I am victim.example, I have a contract with Funky Jim's Hosting, and I have configured *.clowns.victim.example to go to a server at Funky Jim's but I've only every bothered setting up www.clowns.victim.example, images.clown.victim.example and js.clowns.victim.example in Funky Jim's config system. I use HTTPS, so the valuable Clown Login tokens available on www.clowns.victim.example are protected - aren't they?

Some loser, let's call her Sad Carol buys a basic account from Funky Jim, and tells Funky Jim they want to add a new site, busted.clowns.victim.example. Funky Jim OKs it, because that's "harmless" right? No need for Carol to prove to Jim that she owns it, if not why would it matter? But wait, actually busted.clowns.victim.example matches my wildcard DNS entry, it goes to the right server and serves up Carol's site - now Sad Carol can get all my bloody Clown Login cookies sent to "her" web site just by injecting "her" site into an ad inventory or whatever.