Its space character manipulation, from things that cause character encoding processes to produce the security violation. Using common practices that were copied and pasted everywhere arbitrarily can lead to issues.
for example, The php mail() exploitation of the 5 parameter:
filter_var($email, FILTER_VALIDATE_EMAIL)
not all characters that are necessary to exploit the security issue in mail() are forbidden by this filter. It allows the usage of escaped whitespaces nested in double quotes. Due to the nature of the underlying regular expression it is possible to overlap single and double quotes and trick filter_var() into thinking we are inside of double quotes, although mail()s internal escapeshellcmd() thinks we are not.
so:
```
'a."'\ -OQueueDirectory=\%0D<?=eval($_GET[c])?>\ -X/var/www/html/"@a.php
For the here given url-encoded input, the filter_var() function returns true and rates the payload as a valid email address. This has a critical impact when using this function as a sole security measure: Similar as in our original attack, our malicious “email address” would cause sendmail to print the following error into our newly generated shell "@a.php in our webroot.
<?=eval($_GET[c])?>\/): No such file or directory
Remember that filter_var() is not appropriate to be used for user-input sanitization and was never designed for such cases, as it is too loose regarding several characters.
You’re thinking maybe its simpleton code from example web sites that are effected… Guess what, its everyone that is using php mail() function.
Roundcube <= 1.2.2 CVE-2016-9920
MediaWiki < 1.29 Discussion
PHPMailer <= 5.2.18 CVE-2016-10033
Zend Framework < 2.4.11 CVE-2016-10034
SwiftMailer <= 5.4.5-DEV CVE-2016-10074
SquirrelMail <= 1.4.23 CVE-2017-7692
Is a small list, but due to the integration of these affected libraries, other widely used applications, such as Wordpress, Joomla and Drupal, were partly affected as well.
