I also believe that exec() is not dangerous if you use it right, and if your www-data/apache-user do not got any sudo rights to risk someone to take advantage of your machine. This have been proved from various sources, if i know right. I understand it can be a security hole if you let the user write anything, but this is eg. not the case with Linux-dash.
SELinux if left enabled (as it should be...) will help mitigate the risks. But root access often isn't necessary to totally screw you. For example, adding a machine to a botnet does not require root, nor does accessing the data for your application (such as databases and local files owned/manipulated by your apache user).
> I also believe that exec() is not dangerous if you use it right
Just about anything can be "safe" if "used right" - that's a caveat big enough to land a 747 in, one only need define all unsafe uses as incorrect for it to become a truism that tells us nothing. And that's a pretty defensible definition for anything web facing!
Statistics will eventually catch up to us, and we will eventually find new and novel ways to use things wrong despite all attempts not to. Ergo: exec is dangerous. With care, you may safely navigate the danger.
For my own curiosity, I looked at some of the source. I'd fear parsing all those $ and {}s in strings to verify they're all awk variables and not PHP variables would quickly desensitize me to actual errors when reviewing or auditing such code. I'm not a PHP dev: Hopefully you have lint tools or somesuch less ignorable than syntax highlighting to catch the stray typo which eludes human review? As others have mentioned, lack of sudo is far from sufficient protection.
> It is easily extensible from its architecture which just calls the php exec() function and sends it to an ajax request.
I presume the network police have already revoked somebody's license to run a server, yeah?