CTR mode turns a block cipher into a synchronizable/seekable stream cipher. The IV in this case is a nonce (number used once), and in general practice for a 128-bit block cipher is 96-bits (12 bytes), leaving 32-bits (4 bytes) for the block counter.
How insecure is this?
Not at all, given the following VERY important considerations:
- The 2nd 8 bytes are also used for the block counter
- The first 8 bytes are never repeated under the same key
Therefore, if you are choosing the first 8 bytes randomly, you would need to keep track of them, as randomly being identical is possible. The best way is to increment the first 8 bytes on a per message basis, modulo 2^64
But do similar IVs have the same vulnerability or a different way to attack them?
As long as the underlying block cipher (in this case AES) behaves like a random permutation, then there is not a practical attack against CTR mode. The best attack is a known plaintext attack, where the output of the cipher can be recovered, and compared with the nonce/counter to recover the key. The workload of this attack for AES in the best case is over 2^96, with massive plaintext requirements, so it is not practical. Changing keys well before 2^64 blocks is common practice.
If you are especially concerned, you can split the nonce in half, and choose half randomly. This will assure that the input to the cipher is more dissimilar, while also preventing nonce reuse. The other option is to change the key more frequently, say after 2^16 blocks, which may be very practical or very impractical depending on application.