Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't really be completely fixed. More New3DS keys could be generated differently/etc in an updated arm9loader which also fixes arm9loaderhax, but that's about all really.
+
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax and it is mandatory to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed as long as one has the proper FIRM xorpads. However, if one doesn't have said FIRM xorpads, a FIRM update could prevent the obtention of useful xorpads to downgrade his FIRM. For that, the updated sections would need to start after the size of the latest vulnerable FIRM. The "hole" would be filled with random data generated on first boot. Thus, as we don't know the decrypted value, we can't generate the relevant xorpad without ARM9 access.
| arm9loaderhax which automatically occurs at hard-boot.
| arm9loaderhax which automatically occurs at hard-boot.