This isn't a vulnerability in WHOIS. It's a vulnerability in the procedures of various CAs and DNS services. I.e. It's a social engineering problem not a technical one.
Yes and no. The vulnerability in WHOIS is that records are completely unsigned, so there's no way to verify that the WHOIS server really is legitimate. And this is pretty much fundamental in the protocol design. It was never designed to be used for any sort of purpose where security matters, and the very fact that WHOIS is being used for any sort of authorization is in itself a flaw, but that doesn't mean that the protocol itself shouldn't be rethought to fix the underlying flaw.
There's no good alternative for domain name transfers other than using WHOIS to reach out to the owners by email, but because registrar disallow outgoing transfers without pre-authorization at the registrar level, there's not really a security issue there unless someone also cracks your account at the registrar (in which case you have bigger problems than not getting the notification email).
For other uses of WHOIS, requiring people to put content on the web server or in the DNS record to prove that something is authorized is a reasonable means of authentication, and WHOIS really shouldn't be used at all. Any use of WHOIS data for anything other advisory purposes is fundamentally a design flaw, because data from WHOIS should be considered fundamentally untrusted.
Of course, WHOIS data is also not intended to be consumed by software in the first place. WHOIS servers return an arbitrary human-readable blob of text. If I wanted to, I could create a WHOIS server that, in response to a query, serves up an ASCII art version of Star Wars Episode IV, and it would be a technically valid response. And if I could somehow get real systems to point at it and try to parse the results like this security researcher did, doing so would probably create absolute chaos, with crashing processes on certificate authority servers all over the place, and who knows what else.
What we really need is a modern WHOIS protocol that provides structured data in a computer-parseable format, with proper delegation through a tree of DNS records, where the gTLD server has something similar to a glue record for each domain that says which registrar currently maintains it and either A. provides all of the data that would be served by WHOIS or B. provides the hostname for a server at the registrar that can return the data in some reasonable, machine-parseable format.
Or you could make the glue record contain a reference to the domain name of the registrar (delegation) whose glue record then points at the correct hostname for the WHOIS 2 server. This is probably the cleanest approach with the fewest opportunities for things to go horribly wrong.
Either way, at that point, as long as the registrar doesn't fail to push its glue record changes to the root servers, and as long as any server uses TLS to verify that the registrar server is legitimate (using HTTPS for WHOIS 2 seems like the most straightforward approach with the least integration pain), this sort of attack shouldn't be possible.
You won't believe it, but we conducted a study on a new class of vulnerabilities in two-factor authentication in our college. I managed to complete my work with the help of https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fessays.edubirdie.com%2Fjava-assignment but It was an amateur study . To be honest, I found it quite difficult to find some factors, but this service handled everything, for which I am sincerely grateful.
IOT trap -- core dumped