Yeah, this essentially the old "parse json with eval" (or more generally configuration file is code, but json vs eval was a ceaseless problem that was fairly regularly actually exploited rather than just being theoretically exploitable).
Fun fact: the reason json has as many constraints as it does is because rather than simply parsing json (a trivial thing) the json[2].js implementation used a regex to "validate" it before .. throwing it at eval. That necessarily required huge restrictions on what could be there - you can't use "undefined" in json because it's not actually a keyword, no comments (can't handle those with regex), etc all come from that :-/
I read that comments were forbidden in json because some json generators/parsers started putting data about how to interpret them in comments, fracturing the standard.
Loading json as javascript also led to seemingly odd patterns, like putting an infinite loop before the start of a json payload to prevent injected javascript stealing data.
Fun fact: the reason json has as many constraints as it does is because rather than simply parsing json (a trivial thing) the json[2].js implementation used a regex to "validate" it before .. throwing it at eval. That necessarily required huge restrictions on what could be there - you can't use "undefined" in json because it's not actually a keyword, no comments (can't handle those with regex), etc all come from that :-/