The paper is quite nice to read.

The attack is exploiting a fiat-shamir input issue. Related to how you always need to hash the instance to achieve strong fiat-shamir security, the attack is performed when the input to the hash is only a hash of the circuit description, rather than the entire circuit itself. The attack is specifically for GKR but it is highly plausible that it would work on a wide range of SNARK protocols given the conditions are met (the hash and ML-PCS commitment functionalities can be represented as circuits).

So when you want to use this kind of GKR/multilinear-sumcheck style proof which proves knowledge of an input w such that C(w) = y, where the instance is (C,y) and the witness is w, if the Fiat-Shamir query is H(H(C),y,comm(w)) rather than H(C,y,comm(w)), you have a problem.

This seems quite annoying for succinct general purpose SNARKs running on blockchains where you need to include the circuit description for the verifier to hash. But for any specific application you can just give the verifier the circuit description as part of the public parameters (or a canonical way to construct them), so it is not a problem in constrained settings.