I assume, though you don't say it, that you've been hacked and are looking for ways to prevent it from happening again.
I don't think you can control what type of file apache will execute in this way, if you have your handlers set up in such a way that they see everything in a directory to be a CGI. If you change your handlers so that only files with a certain extension type are interpreted as CGI executables, the attacker could just change the filename. Linux will interpret any executable pretty much the same way, so as long as it has an ELF header or a shebang at the top, or is otherwise executable, it doesn't really matter what it's called (and apache doesn't need to care either). So, preventing apache from running shell scripts is not easily done (I don't think it's actually possible). Moreover, the real problem was that an attacker was able to put arbitrary files into trusted locations on your box.
What I would suggest you do is determine how this happened. With wordpress plugins, this could be a few ways. For instance, it certainly could have been uploaded using a stolen FTP account, or SSH account. It could also have been uploaded through a rootkit (which is why I rebuild any box which has been popped). However, since it is in wordpress, the most likely scenario is much sillier.
When wordpress is allowed to update itself and its plugins, and install content using its web UI, you open yourself up to this possibility. If anyone gets access to a privileged wordpress account, or spoofs a server from which this content can be downloaded, or just adds their payload to a plugin and waits for you to update, you have been owned. Although wordpress seems to like this feature, I and everyone I know in the infosec field recommend strongly that it be disabled; apache should never have write access to its own webroot, and that is especially true for CGI locations.