Hard to read code hides bugs and issues. The challenge is about finding hard c++ bugs, not about being able to read bad code. If the developer you are interviewing can't find the bug you wont know if it is because of your horrible code or if he didn't know about that aspect of c++.
Fix the hygiene and then lets talk about the actual code
No. We didn't write the example. We're not going to clean it up. Find the bug in this messy code, or (allegorically) ship code that attackers can take over and explain why you did it to your customers.
Now you're starting to see what a nightmare these problems are for developers.
> Find the bug in this messy code, or (allegorically) ship code
, or rewrite this code to use proper checking of untrusted data. I don't know the specifics of your code audits, but the only verdict for the code like this should be to redo it.
If the client is uncooperative or if the reviewer has spare time, then, yeah, try and find the actual exploit. Perhaps, if it is an interview question, it's understandable too. Other than that I don't see a clear reason for going this deep into analyzing dirty code. It may or may not contain an exploitable bug, so just clean it up and move on.
If the obscurity of the codes impedes your capability to see the bug, then refactor it so that obstacle is removed. I think cleaning up code so bugs become clear is a skill that one may consider a prerequisite for this challenge.
Fix the hygiene and then lets talk about the actual code