AugurProject
All code paths that deal with user input should be protected against exceptions.
https://github.com/AugurProject/augur/blob/b380634f04fcf5fa18e3ae3f7739c70f1dc41026/packages/augur-artifacts/src/templates.ts#L330-L334
The simple example here is that template.inputs could be undefined, false, 0, etc. but the code here is assuming that it is something with a .length property. While this specific issue should be fixed, the larger issue here is that this validation code lives outside of the try/catch block which means an exception like TypeError: template.inputs is undefined will bubble up. This may lead to the database being corrupted (if the exception isn't well handled) as it will be missing the market creation but there may be trades that happen on that market and that corruption can propagate over time, especially if an attacker exploits this corruption.
At a higher level, returning errors as out parameters rather than throwing exceptions when processing fails is likely to lead to this class of problems all over the place and they are unlikely to all be caught by code reviews and audits because such problems are so subtle. All code should assume that exceptions can be thrown, and if you already have error handling for exceptions then you might as well use that as your primary error handling path rather than having two code paths for error handling, one via out parameters and one via exceptions.
Nice one, there is a try catch that starts on line 336. Will include the above lines in the try catch.
Note: The fix proposed by @bthaile will address this particular instance of the problem, but I think the underlying problem is deeper and should be addressed architecturally to avoid this class of problems.
The style of returning false with error message as an out parameters seems to be used in a number of places and code that is calling into such functions isn't wrapping them in try/catch blocks to ensure that all failure paths are handled. While the false with errors isn't bad by itself, the lack of try/catch blocks at the top level turning exceptions into errors is problematic because it becomes really easy for an error to be introduced that unwinds your whole stack and potentially corrupts your system. If a full stack unwind is desirable, then that is a good thing but a cursory glance suggests that the code isn't well prepared to handle a full stack unwind in these code paths.