I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seemed like they were releasing the teaser for the next Captain America movie or something.
This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.
The comparison with amdflaws seems unfair. My understanding is that while they demonstrate a flaw in some email clients, it would be enough for an attacker to exploit one vulnerable target amongst the recipients to retrieve the plaintext email. Given that one cannot confirm whether others have taken appropriate steps, this vulnerability seems serious enough, no?
The amdflaws were real vulnerabilities too. The problem in both cases is that they messed up the disclosure so badly (in the case of amdflaws probably purposefully, here probably simply by mistake and maybe hubris) that you end up talking more about the disclosure than the problem itself.
This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.
amdflaws were "if you have admin access, you have admin access". This is "oh shit, mail clients / crypto plugins will stitch together '<img src="' + decrypted content + '">' and send your secrets to the attacker". Sounds much more serious.
Amdflaws was more like "if you have admin access you can backdoor the secure boot infrastructure" while this is "if an attacker manages to intercept an encrypted HTML email and send it to you modified and you use a MUA with dubious security setting with regards to HTML then you're at risk".
The issues are so different that it's probably pointless to try to rank them by severity. I personally always considered that HTML email was a terrible idea security-wise so the idea of HTML PGP sounds a bit like putting mustard on pasta. That being said the PGP/SMIME implementations really ought to detect tampering and error out in this situation, it's always better to fail early.
This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.