I suppose that case can be made, but in this case the direct cause of the vulnerability is the WebSocket server not checking the HTTP Origin header in direct violation of the standard (RFC6455), which is spells out at that doing so is a MUST. I could maybe understand whitelisting localhost and file URLs, but giving a carte blanche -on every single interface no less- is just absurdly negligent.

This websocket was also listening on external interfaces so a non-browser client could have sent whatever headers it wanted.

In fairness, couldn't the same things still be accomplished with cross-origin POST/GET requests? Not that there isn't some regretability to not making those strictly same-origin as well.