AES-GCM vulnerabilities

1. Does AES-GCM take replay attacks into consideration?
2. If an attacker intercepts the AES-GCM secured message and gains access to the initialization vector (IV), can they inject falsely fabricated data (ciphers) or replay past data (replay attack) to confuse the recipient? (Since the IV is also sent along with the message for decryption)
3. Could an attacker misuse an IV by reusing it if the key is still unknown? An IV is concatenated with the counter, followed by the creation of a cipher using an AES key, which is then XORed with the plaintext.
4. Please suggest some additional vulnerabilities related to AES-GCM, assuming the attacker may have knowledge about the structure/content of plaintext and the value of the initialization vector(IV). Thanks and regards!!

I've attempted to explore the vulnerabilities associated with AES-GCM data packets, considering that an attacker may have knowledge about the structure of the plaintext and the value of the initialization vector.

However, I didn't find any relevant solution

1. Does AES-GCM take replay attacks into consideration?

The GCM decryptor is stateless and so it cannot prevent replay attacks by itself. What GCM does is give the tools for the protocol using GCM to detect replays. One common approach is to include a message counter into the AAD (Additional Authenticated Data) - this message counter could either be kept on both sides (and so any replay would fail because of AAD mismatch), or be included with the message (and the receiver would check to see if the message counter is being incremented as expected; we know the attacker can't modify the message counter in the message because it's used in the AAD).

2. If an attacker intercepts the AES-GCM secured message and gains access to the initialization vector (IV), can they inject falsely fabricated data (ciphers) or replay past data (replay attack) to confuse the recipient? (Since the IV is also sent along with the message for decryption)

Question 1 addressed replay attacks. As for injecting a nonreplayed message, well, the attacker would have no idea to put into the tag field, and so that message injection would be detected. This is true whether the attacker reuses an IV that he has seen a legitimate message for, or whether he selects a fresh IV.

3. Could an attacker misuse an IV by reusing it if the key is still unknown? An IV is concatenated with the counter, followed by the creation of a cipher using an AES key, which is then XORed with the plaintext.

Same answer: the tag is a function of the IV, the ciphertext and the secret key; if the attacker modifies the ciphertext, he wouldn't know what to put in there as the tag (and so the modified message would be rejected, unless the attack gets real lucky with his guess of the tag)

4. Please suggest some additional vulnerabilities related to AES-GCM, assuming the attacker may have knowledge about the structure/content of plaintext and the value of the initialization vector(IV).

The major kryptonite for GCM is if the sender uses the same IV to encrypt two different messages. If that happens, the 'attacker can't compute the appropriate tag value' property I cited above falls apart.

A similar weakness can occur if the protocol decides to severely truncate the length of the tag; if (say) you truncate the tags to 32 bits, and the attacker manages to guess a tag for a modified packet, again, things fall apart.

Assuming neither of the above happens, you're golden. Even if the attacker had a plausible guess of the entire plaintext, he could not verify it (confidentiality); even if he knew the entire plaintext, he could not modify it (integrity). And this is assuming the attacker knows what IVs are being used.