CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them.
Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM.
The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.
Do you have a pointer where I can read about traps of GCM?
Essentially these are implementation specific bugs resulting in oracles, rather than being attacks on CBC itself - basically openssl and some embedded (?) TLS stacks produce different results (delayed hang up and/or different error codes) for padding vs. MAC failures in CBC mode.
I assume that the joy of CBC mode just makes those oracles easier to directly exploit. The exploits are still harder to use than GCM with a reused nonce (reusing a nonce in GCM mode essentially breaks it. GCM is hard).