Is there a contingency plan in the event of a catastrophic attack on AES?
I'm not aware of any official NIST policy on the matter, so I can only make educated guesses. 

I guess new algorithms have sprung up and are already in place. ChaCha20 is used in TLS 1.2 and 1.3. For hash functions, neither SHA-2 nor SHA-3 are depending on AES in any way. The sponge function in Keccak (SHA-3) can also be used as a symmetric cipher (Ketje, Keyak and Kravatte) and - with a bit of tweaking - as MAC (KMAC). So rather than to move backwards I think NIST would simply standardize on existing ciphers together with more modern ciphers based on Keccak.

Although I see merit in the answer of AleksanderRas, I personally don't think that one of the original AES candidates would be chosen as new AES (or FES, for fixed encryption standard). The world has moved on; there are likely more secure and certainly faster block ciphers around. For instance, I could see that Bruce Schneier and the Skein team would choose Threefish over Twofish. Possibly Serpent would make a chance if Rijndael is broken, as runner up with a high security margin. It does seem to have much in common with AES though, so maybe a break could also influence the security of Serpent, even if it does have a high number of rounds.

This brings us to an important final point: possibly a broken AES could simply be fixed by upping the number of rounds. In that case: the king is dead, long live the king. The hardware is there after all, and quite often the number of rounds can be configured. This would make the most sense in the short term and would allow NIST some breathing space to think of a replacement.