Yes, that's correct, decrypting altered ciphertext data or data with the wrong key may result in the wrong plaintext without producing an error. Actually, the chance is slightly more than 1/256.
First of all, we need to assume that the data is still a multiple of the block size. If it isn't then it won't decrypt at all.
Furthermore, if the key is correct and the last (and the last few bytes of the first-to-last) ciphertext block are correct then the decryption will not fail, even though the resulting data in the first blocks may be incorrect.
If the data is a multiple of the block size then the AES-CBC decryption will never fail. However, OpenSSL uses PKCS#7 padding by default - that is if the high level EVP functions are used instead of the lower level AES functionality. That means that the plaintext data is always padded before being encrypted, even if the data is a multiple of the block size. This is also true for the command line interface of OpenSSL by the way.
During PKCS#7 unpadding there is a 1/256 chance that the decryption of the last block ends with
01 if the key is incorrect or if the last ciphertext block is incorrect.
However, there is also the chance that the last block ends with
02 02 which is also valid padding. The chance of this happening is however just 1/65536 so it is almost negligible compared to the chance that the last decrypted block ends with
01. This is even more true for
03 03 03,
04 04 04 04 of course. As padding / unpadding must always be performed according to PKCS#7 the chance that a random ciphertext block is accepted is therefore close to 1/256.
An adversary can always change any ciphertext block up to the last as the error propagation properties of CBC are limited to the current block and (part of) the next block. You need to authenticate the ciphertext to avoid this and to avoid padding oracle attacks where those are applicable. For that, calculate a HMAC over the IV and ciphertext or to switch mode to e.g. GCM and perform the necessary verification before decryption.