As long as the IV is not published as it usually is with CBC in the first crypt text block (I assume you wouldn't have asked in that case), the main problem I see is that encryption is deterministic, that means if you encrypt the same plain text twice you will get the same cipher text twice. As CBC works by iterating the through the plain text in blocks that also translate to full block prefixes. Remember that a block is only 16 bytes long with AES128. For many applications these are only 16 characters out of a small charset.
This is especially problematic if the service offers an encryption oracle in some form or another, i.e. you can feed it values that will be encrypted using the secret key. In that case you can test blocks against the first block until you find the correct value. In some applications the entropy of the data that is to be encrypted is low enough to find the original value.
Even if there is no encryption oracle when the messages have low entropy you can still gain the information which messages share the same prefixes and which don't. Imagine for example some ajax requests that only access 6 different urls:
GET /appA/routine1 HTTP/1.1
GET /appA/routine2 HTTP/1.1
GET /appA/routine3 HTTP/1.1
GET /appB/callA HTTP/1.1
GET /appB/callB HTTP/1.1
GET /error HTTP/1.1
Split them up in blocks and you will get:
GET /appA/routin e1 HTTP/1.1\nHos …
GET /appA/routin e2 HTTP/1.1\nHos …
GET /appA/routin e3 HTTP/1.1\nHos …
GET /appB/callMy A HTTP/1.1\nHost …
GET /appB/callMy B HTTP/1.1\nHost …
GET /error HTTP/ 1.1\nHost: www.e …
Or more abstractly the following pattern:
Without even knowing any other information you can identify which calls were made to
/appB and which to
/error just by observing the crypt text patterns.