Also, you have to explicitly run it in debug mode for this to happen, which probably only a small percentage of end users will do. Kind of seems like the equivalent of running Flask apps in debug mode, which by default will handle exceptions by showing a traceback with an interactive debugger that can be used to execute arbitrary code.
There could be some backdoors in it, but I'm leaning towards that not being an intentional one. (But I definitely could be totally wrong; you never know when it comes to intelligence agencies.)
It is, but usually the best way to do is to make it look like a mistake that's very subtle and difficult to notice without careful testing and analysis, kind of like Apple's infamous SSL "goto fail". That's a classic example of a vulnerability that really could be either an honest mistake or a very insidious backdoor.
This is more like leaving the house's sliding glass door to the backyard wide open for everyone to see.
This makes the whole release even more interesting, I wonder if we'll get a statement on why they have that debug mode.
As an aside, this is no longer precisely the case, though it was for quite some time.
With modern Flask (> 1.0.0), the debug server will start with a randomly generated PIN output to STDOUT when the server starts. In turn this PIN must be entered on the web interface to execute commands.