I’m assuming you are referring to this footnote (which isn’t mentioned in the security advisory)?
A similar vulnerability has been discovered in the name wrapper, which would permit the DAO to appoint a malicious upgrade contract; if approved the upgrade contract could seize control of wrapped names, even if the user does not choose to upgrade the name. The mitigation contracts also mitigate this vulnerability.
At the least, a security advisory should be created that includes this.
I would like to advocate that fixing this does not wait for ENSv2. My team has an ENS app that we built and are waiting for a fix to this before we deploy. Our app (which allows users to easily create/extend immutable subnames) was built under the assumption that wrapped ENS names were actually immutable (up to expiration), but at the moment this is not the case due to this issue and we don’t want to endorse a product and make claims about “immutable subnames” when they aren’t actually immutable (just protected by the good grace of the DAO, not terribly different from DNS names).
I feel the same way about the other bug mentioned in that link, it really feels like it should be fixed without waiting for ENSv2 as at the moment ENS is touted as a censorship resistant tool, but one can easily imagine state pressure on ENS DAO token eholders, a hostile takeover of the DAO, or hacked ENS DAO voters causing that censorship resistance guarantee to be compromised.
Delaying this to be fixed in “v2” also assumes that all users will want to move to v2. As I have mentioned in the v2 discussion thread, I already pretty strongly disagree with the pressure being applied to the ecosystem to migrate to v2, and leaving bugs unfixed in v1 feels like a pretty underhanded way to force people to use ENSv2 even if they don’t like it. For this reason alone, I think this should be fixed before ENSv2 so leaving it unfixed cannot be construed as the DAO maliciously forcing users to v2.