А он и не нужен в данном случае параметр третий, хотя он указан - пустая строка. Здесь задача иная - запустить код, который внедрен в изображение. Можете установить программу любую, которая добавляет EXIF в файл, проверяйте. Ну если без этого, то запустить и посмотреть что получится:

preg_replace(
    '/.*/e',
    'eval("phpinfo();")',
    ''
);

В данном примере (по ссылке) требуется помощник. Но не рассчитывайте на то, что я делаю безобидное sha1_file(загруженное), а поэтому все проблемы стороной. Это не так, md5, sha1 прожорливы, а значит вас (домен ваш) можно просто положить размером файла, вы не проверяете ничего, как следует из вашего изложения. Уже плохо, так? Ну и все-таки, читайте об wrapper - абстрактный слой для работы с файлами, сетью и другим, из него можно читать, в него можно писать, перемещаться в нем.

На ресурсе, на который я ссылки давал об этом много пишется. Локальный сервер есть? Берите примеры, пробуйте, так будет понятнее. А говорить об этом долго какой смысл, если из одной статьи вы не сделали вывода.

Это так, для "ответной атаки", уж коли об этом речь зашла. :)

Если это и грозит, то далеким предкам.

-Вы никак не поймете, о чем я спрашиваю. Я знаю, что такое preg_replace(), eval() и как делаются взломы такого типа. Я спрашиваю: на том каком-то сайте, где впервые была обнаружена (или применена?) эта уязвимость, зачем там использовался preg_replace()? не в целях же демонстрации уязвимости?? вот я на своем сайте использую такой код:

$s = preg_replace('/[\x00-\x1F]/', ' ', $s);

-здесь есть уязвимость?

-не так.
1. md5, sha1 прожорливы, потому что им нужно подать в параметр всю строку, т.е. она должна быть в памяти. я же буду использовать md5_file()/sha1_file(), которые работают с потоком и не грузят всё содержимое файла в память
2. в PHP есть такие понятия, как post_max_size=1, upload_max_filesize=1. обработки больших файлов не будет, т.к. до этого не дойдет.

laimas,
UPD
когда я говорю, что "никаких проверок не будет" - имеется ввиду, что я не буду никак проверять СОДЕРЖИМОЕ файла. мне всё-равно, что пришлют.
а классические PHP-шные проверки конечно будут!

if (isset($_FILES[$fieldname]))
if ($_FILES[$fieldname]['error'] == 0)
if (!(empty($_FILES[$fieldname]['name'])))
if (move_uploaded_file($tmpfname, $tofile)) 
if ($_FILES[$fieldname]['size'] < $minfilesize) // если размер закачанного файла меньше допустимого

и т.д., равно как и соответствующие SQL-ные проверки

Ну там же написано, что обнаружено, то есть загружено было, а не разработчик с какой-то целю этим занимался. А запустить, так ведь для этого не обязательно preg_replace.

Нет, дело в том, что память занимает, а сам алгоритм не раз, два и готово. При большой длине файла, это время. Если post_max_size=1, upload_max_filesize=1 (макс. размер POST доложен быть более чем макс. загружаемый файл), таким образом урезав все и если это административным задачам не будет помехой, защищайтесь. Но это только ограничение, но еще не значит "безопасно теперь".

Согласен. Это беспокоит. На мой взгляд программно это не решить. Тут только методом умощнения процессора.
Однако давайте обсуждать мой подход в СРАВНЕНИИ с классическим вводом логина/пароля. При передаче пароля злоумышленник может с тем же успехом передать 2ГБ символов в POST-запросе, по которым PHP-должен будет посчитать md5(), чтобы потом найти в базе. Как с таким борются??

if (!(empty($_FILES[$fieldname]['name'])))
и
if (move_uploaded_file($tmpfname, $tofile))

Что такое в этом случае $tofile?

та не важно. это же код не из боевой системы, это мой "черновичек". это я проверял разные аспекты и временно сохранял принятый файл в папке..

Ну такой на объем конечно не каждый хост настроен, это уже тарифы повыше, видеохостинги и прочее. Кроме того, поле ввода формы на такие объемы не рассчитаны, то есть на стороне клиента уже будет обрезано, невозможно будет поместить в поле. Ну и в данном случае мы знаем точно с чем имеем дело - строка, а при загрузке файлов могут слать что угодно, под видом одних иное или просто мусор маскирующийся под ценное.

Еще как важно. Если проверять загрузку так, то это не проверка, уж точно. Кстати !(empty($_FILES[$fieldname]['name'])) здесь скобки лишние.

Ну и самая беда, это конечно содержимое, то есть не важно что там шлют, посчитал md5 и все. Но если пароль 1234 "живет", то с таким же успехом может быть и паролем собственная аватарка, другими словами пароль у всех на виду. Это надо тоже не сбрасывать со счетов. Ну и снифферы никуда не исчезли. Так что хрен редьки не слаще, то есть картина будет более надежным только лишь потому, что это картинка, это далеко не так.