Yes, that's correct, decrypting broken 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) cipherblock are correct then the decryption will not fail, even though the 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. This is 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. Possible options are HMAC over the IV and ciphertext and to switch mode to e.g. GCM.