At the parser level you would find a "b" character that's not between brackets, signalling a binary header is coming. A binary header is actually just the number of bytes that follow in binary format. The following bytes are then a binary file, to be assigned to a string as if it were a variable. We have a binarybuffer in javascript, that sort of thing. It would contain the NULL byte if you like it to.

That may break some parsers, but this is the real life. Parsers must deal with malformed input securely already > being unaware of bencoding2 should not cause problems.

If the length-indicating thingy is short of what it should binary will spill over into your JSON document. It may represent perfectly fine JSON, and thus opens up binary overflow as a possible JSON hack. Someone that can alter that number can already hack your JSON, so that doesn't actually change any attack profile. 

If it's too long it will gobble up your JSON file, which opens up reading the rest of the file and maybe even into random memory and treating it as a file in your JSON. That's much more serious but requires the JSON parser to have bugs.

The thing is that if you don't cut yourself in the fingers it can be nice to have a knife. If you don't write some pretty obvious bugs you will be fine.

I think it's much more serious that you have to serve the BJSON completely as a binary file. It's not like you can dump it onto a webpage anymore. You can't slip it into your normal HTTP text transfer bodies either, has to work with attachments. Attachments should be secure when facing malformed transfers* etc. Inconvenient, but not the end.

* It would be pretty wack to mess with the HTTP protocol. Maybe you could confuse a keep-alive connection to serve a file before it should be, confusing a webapp or sending a redirect. Haven't really looked into it and haven't really heard about it either. Maybe servers are just secure enough against those attacks?