DerManu

Since you pass $prefix through the sanitize filename function of wordpress (which luckily strips slashes), the threat is currently not so immediate. Still, including variable strings that can be changed from outside is very bad practice and may turn into a real include injection exploit some time in the future, when the environment in which your plugin runs, has changed. This is the typical source of such security holes. Imagine the wp guys decide in version 4.3.1 to allow paths in the sanitize filename function. This way one could include any php file on the system, possibly on other shared host accounts. If using relative dirs, you could include an arbitrary php file on any webserver, e.g. one the intruder has uploaded somewhere himself.

No, it’s not generated from input of the website user.

I disagree. Let’s take your Contact Form 7 for example:
on line 123 of modules/captcha.php you call wpcf7_check_captcha with the post parameter ‘_wpcf7_captcha_challenge_’ . $name. This parameter is a hidden field that is absolutely manipulatible by the user, i.e. with firebug or numerous other tools. This function passes this on to the function check() of an instance of the “really simple captcha” class, which finally turns this string into a filename.

Now regarding the performance of hash calculation: don’t worry. modern hash implementations work at a scale of microseconds. Even the generation of the captcha image – let alone writing it to disk – consumes orders of magnitude more time. And talking about increased vulnerability to DoS due to _two_ calls to a hash function seems a bit silly considering we’re talking about a wordpress site that launches myriads of classes, queries and algorithms for every page hit.

Anyway, I’m not dictating anything, it was just a suggestion.