This is a known issue, and should be fixed in the next version. For the cases we’ve seen, a workaround for the moment (for all compressors other than BC3n) is to make sure you’re using the GPU compressor instead of the CPU compressor (more details on why below) - you can check which compression qualities use a CPU or a GPU compressor by looking at the tooltips for the different compression qualities in the standalone exporter GUI (the text will change depending on the format and whether or not the GPU supports CUDA), or the command-line version will sometimes print out messages when using the CPU version. It looks like not all CPU compressors are affected by this.
What I think is going on here is that although all of the compressors process images block-by-block, some of the older CPU compressors might be trying to read from uninitialized memory (or possibly reading from memory that was used for past computation results) when processing blocks that extend past the boundaries of the image (which happens when the image isn’t divisible by the block size, as you pointed out). The GPU compressors all seem to handle this correctly to the best of my knowledge - they use a map to ignore texels that won’t be visible in the final result. Some of the CPU compressors appear to handle this correctly as well.
BC3n is the only format that doesn’t include a GPU compressor (though it’s the result of composing a swizzle and BC3 compression), so that’s why this workaround doesn’t work for BC3n.
Hope this helps!