Assuming the mod 11 check digit is among
0123456789X, disclosing it reduces the number of possible plaintexts among 8-digit numbers by a factor of about 11 (from 100000000 to about 9090909; exactly how much depends very slightly on the value of the check digit), thus reveals about $\log_2(11)$ bits of information about the plaintext, that is just a little less than 3.46 bits.
The consequences vary depending on context. If the goal of an adversary is to rule out that a plaintext is a certain value, there are about 10 chances out of 11 that knowing the check digit allows the adversary to succeed.
In the hypothesis of "a single 3DES encrypted CBC block for which the check digit of the plaintext is known" because it is used to derive an IV using a deterministic method allowing to recover that check digit (as in the example where the IV is the MD5 hash of the check digit, truncated to 8 bytes), the worse problem might not be that the check digit is revealed by the IV. Another serious issue is that the same plaintext is always enciphered to the same ciphertext, which is foremost among what an IV is designed to prevent. If that's tolerable, we could just as well use 3DES in ECB mode on a single block, and live happier with a simpler system using no IV, and leaking less about the plaintext.
Knowing the check digit of the plaintext does not much help recovering the key. In the example, the key can best be found by enumerating the candidate keys (assumed to be the MD5 hash of a small string of decimal digits), and deciphering the ciphertext until the plaintext makes sense. The check digit still helps, in that it reduces the (already remote) odds of guessing the wrong key, by a factor of 11; however another ciphertext helps even more in this regard.