Bad random events are still happening in the bitcoin blockchain, such events are observed on a regular basis.
They are probably due to some yet unpatched software (cf. section Mitigation Points here).

Here is the latest such event at the moment of writing, it has occurred on 29 November 2014, see here.
Two different bitcoin private keys use the same random which makes that the value r=
695667597cf77bfcfd6df2d65b250531c5af7d5730b4385d77d5d300a81ab717 in hex appears in two distinct ECDSA signatures.

More Repeated Random Events

Here is a more complete list of repeated random events in bitcoin blockchain.

How Bad Can This Get?

Here in both events of 26 and 29 Nov the same random number on 256 bits was used twice in the same transaction. However the good news are:

• In both cases, the same random was used with two different private keys, which does not facilitate the theft. Following the recent paper on this topic, with two different private keys, the owner of each private key to steal the bitcoins of the other owner.
• Possibly both keys belong to the same person (they are used in the same transaction), in this case potentially there is no harm other than loss of privacy/anonymity.
• In all such recent events known to us there is no bitcoins which can be stolen, moneys are already transferred to other accounts and there is 0 BTC left in the vulnerable accounts.
• So we are not all in the situation from 2013 where bitcoins could be stolen by anyone, cf. here. Interestingly these stolen bitcoins have not been spent so far.

So possibly there is no harm.
Now the bad news are:

• There is no harm… unless both keys were derived using BIP032 !
  Then there are various recent combination attacks.
  The result can be very bad: lots of bitcoins could be stolen from lots of accounts, not only the two accounts involved in the problematic transactions themselves.
  For more details, see the paper.
• Moreover in addition to repeated random events, visible in the blockchain, there are also related random events, much harder to detect in the blockchain, until possibly it is too late. Again, see the paper (we have not yet disclosed an efficient method to find such events, it will appear in a future update of the paper).