I'm surveying old Bitcoin DoS vectors and came across CVE-2013-4267, for which there appears to be little public information available. This thread should shed some light on this CVE.

There's a description in this blog post:

Transactions are also first deserialized in order to be parsed, but they are stored “as is” in a temporary cache called MapRelay, and forwarded without being serialized again. I really don’t know why this is done. But the point is that the storage of messages as they are received leads to the possibility that an attacker creates messages much bigger than the actual transaction object contained, which, when stored in MapRelay memory, can be used to exhaust the memory of a node.

There is also this relevant thread which appears to say the network was under attack using this vector.

Based on the transaction serialization and deserialization code in ~v0.8.2, it looks like the attack may have been: add large amount of random data at the end of a valid serialized transaction. The deserializer finds what it looks for (the valid blob prefix), but appears to ignore what comes after. If a serialized transaction with random data at the end of the transaction is sent to the victim node, it will be deserialized, passed to the mem-pool and then placed in mapRelay in its full size (and then possibly forwarded further, which seems like a pretty powerful attack vector).

So: was the attack described by CVE-2013-4267 based on adding random data at the end of (valid) serialized transaction data?

1 Answer 1


Yes. The attack was adding junk to the end of otherwise valid transactions to cause the junk to get relayed around. (as an aside, if we hadn't fixed that, segwit would have been easier to deploy...)

  • Interesting. Was it (in hindsight) fixed in a bad way, too rigid perhaps? Would a less hastily fix perhaps allowed for more forward-compatible flexibility?
    – Jannes
    Jan 9, 2019 at 13:02
  • 1
    Well, any fix was going to have to refuse to relay data that couldn't be validated.
    – G. Maxwell
    Jan 9, 2019 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.