To be perfectly clear, this attack IS just an update on normal authentication session phishing, where the attacker gets the target to authenticate a copy of the login form while the attacker is the custodian of the associated session cookie. If the user is inattentive it will work with all normal authentication methods and sadly also SQRL et-al when used in remote authentication (QR-Code) mode**. Thus most of these authentication methods exclude it from their designs as being out of scope.
That said, SQRL was not designed to address this currently intractable issue (people are lazy observers), it was designed to address the other big problem (people are bad at picking passwords). It does this by only sharing public information (site specific public key) with the server which it proves with zero knowledge that it has secret information (site specific private key) by signing a random challenge from the server. Which just happens to also have a 1:1 hidden relationship to the login page session cookie.
This is when you use the QR-Code and client on a device separate from the device the browser is running on. In SQRL it is more common and more secure to have your client running on the same device such that instead of scanning the code you click/tap it and launch the associated sqrl:// scheme link. In that case hard same IP protections are enforced which would then refuse to complete an authentication unless the attacker is also present on the same WAN IP as the victim (a very much less likely scenario).
In closing, all these early zero knowledge and token authentication schemes will be updated soon after release to include methods and means to thwart this normally intractable attack mode but that will have to wait for parts of the client to be migrated into the browser agent codebase, where they can either respond more precisely to errors forced upon the attacker or be able to bypass the attacker altogether (see SQRL-V2 CPS mode).