I don't know enough Javascript to give the analogous exploit myself, but that approach looks dangerously similar to some attempts I have seen at making Python's "eval" safe - attempts which, I might add, all fail to capture corner cases that any sufficiently determined or motivated attacker would eventually discover.
First of all, if native JSON parsing exists, jQuery will use that.
The validation code they use in case there is no native JSON implementation available is borrowed from Douglas Crockford's json2.js ( https://github.com/douglascrockford/JSON-js/blob/master/json... ) which was the inspiration for the native JSON implementations and should really be correct by now, both in terms of correctness but also circumventing regexp weaknesses in some engines.
It's still the Wrong Way™. You want to parse JSON, you write a lexer that recognizes its symbols and a parser that consumes them and spits the JS equivalent. Otherwise you are playing an eternal game of whack-a-mole with the JS eval parser. No. Just no.
If you can find a case in which the validator fails, it's wrong. Otherwise, if it's looks like a JSON parser and works like a JSON parser, i.e. is indistinguishable from a "proper" parser, it makes no sense but satisfying OCD to rework it.
Note that the code is now only a work-around for older browsers. Every modern browser supports native JSON parsing anyway.
