Это было бы так, но уязвимости подвержены далеко не все хостинги с PHP как CGI (может быть, подвержено меньшинство из них). Например, применяется вариант с патчем в suEXEC, где интерпретатору PHP через командную строку передается только имя скрипта (до этого проверенное stat()'ом и не только). Shell-wrapper при этом не нужен (и не используется).char *new_argv[] = { php_bin_path, cmd, NULL };
execv(php_bin_path, new_argv);
Вариант с shell-wrapper'ом же всегда следовало считать очень опасным. (Я был удивлен, когда увидел его, кажется, на DreamHost wiki пару лет назад. Это скорее исключение, чем правило.) Он был почти аналогичен размещению самого интерпретатора PHP в cgi-bin, т.е. вся безопасность сводилась к hardening'у PHP на тему такого misuse'а. Это, конечно, не снимает ответственности с разработчиков PHP, которые этот hardening убрали по забывчивости, при этом не поправив информацию на http://www.php.net/manual/en/security.cgi-bin.attacks.php - но полагаться на это было наивно с самого начала (т.е. с 1990-х, когда тема интерпретаторов в cgi-bin была поднята исходно). Также, они зря не называли эти вещи своими именами - hardening и misuse - пытаясь вместо этого документировать будто бы конкретно с PHP, в отличие от других интерпретаторов, так поступать можно.