Как запретить выполнение PHP в uploads в WordPress

Автор: Анна Соколова | Опубликовано: 18.09.2026

Каталог wp-content/uploads должен хранить только медиафайлы. Если туда по ошибке или через уязвимость попадает PHP-файл, он может выполниться на сервере. Это уже не вопрос «красоты» настройки, а базовая защита сайта.

Задача решается на уровне веб-сервера, а в WordPress — только дополняется проверками. Ниже разберём, как закрыть выполнение PHP в uploads, как понять, что проблема действительно устранена, и какие ошибки чаще всего мешают.

Когда это нужно делать

Ограничение особенно полезно, если на сайте:

есть формы загрузки файлов от пользователей;
используются старые плагины с собственными загрузчиками;
сервер работает на Apache или Nginx без жёстких правил для uploads;
в логах уже встречались попытки загрузить .php, .phtml или похожие расширения;
есть подозрение, что в uploads могли остаться файлы после взлома.

Если сайт небольшой и доступ к серверу есть только через панель хостинга, всё равно стоит проверить, не даёт ли хостинг добавить правила для каталога. Это самый надёжный вариант.

Диагностика: как понять, есть ли риск

Сначала проверьте сам каталог. В норме в uploads не должно быть исполняемых файлов. Исключения редки и обычно связаны с нестандартной логикой плагинов, но для обычного сайта это плохой признак.

Что искать в файловой системе

файлы с расширениями .php, .phtml, .php5, .phar;
подозрительные имена вроде image.php.jpg или avatar.phtml;
вложенные каталоги с правами, которые позволяют веб-серверу писать и выполнять код без ограничений.

Если есть SSH, можно быстро просканировать каталог:

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.php5' -o -name '*.phar' \)

Пустой результат — хороший знак, но он не заменяет запрет на выполнение. Файл может появиться позже.

Как запретить выполнение PHP: рабочие варианты

Способ зависит от веб-сервера. Для Apache и Nginx правила разные, и это важно: копирование чужого сниппета без учёта окружения часто не работает.

Вариант	Где применять	Плюсы	Ограничения
`.htaccess`	Apache, LiteSpeed	Можно внедрить без доступа к конфигу сервера	Не работает на Nginx
Правило в конфиге Nginx	Nginx	Надёжно блокирует исполнение	Нужен доступ к конфигу или поддержка хостинга
Плагин безопасности	Если нет доступа к серверу	Удобно для базовой защиты	Не всегда закрывает именно выполнение на уровне веб-сервера

Apache: правило для uploads через .htaccess

Если сайт работает на Apache или LiteSpeed, в каталог wp-content/uploads можно добавить отдельный .htaccess:

<FilesMatch "\.(php|phtml|php5|phar)$">
    Require all denied
</FilesMatch>

Если сервер старый и не понимает директиву Require, иногда используют более совместимый вариант:

<FilesMatch "\.(php|phtml|php5|phar)$">
    Deny from all
</FilesMatch>

Файл нужно положить именно в wp-content/uploads, а не в корень сайта. Тогда правило будет действовать только на этот каталог.

Nginx: запрет на исполнение PHP в uploads

Для Nginx правило обычно добавляют в конфигурацию сайта:

location ~* ^/wp-content/uploads/.*\.(php|phtml|php5|phar)$ {
    deny all;
    return 403;
}

Если у вас Nginx работает в связке с PHP-FPM, не пытайтесь решать задачу только через обработчик PHP. Нужен именно запрет на уровне location, чтобы запрос даже не доходил до интерпретатора.

Если доступа к серверу нет

Когда конфиг веб-сервера недоступен, можно использовать плагин безопасности или защиту хостинга. Это компромисс, а не идеал. Плагин полезен для обнаружения подозрительных файлов и базовой блокировки, но он не всегда заменяет серверное правило.

Если нужен более системный подход к чистке сайта и удалению лишнего технического мусора, иногда удобнее использовать набор настроек в Clearfy Pro. Но даже в этом случае серверное ограничение лучше не откладывать.

Пошаговая настройка без поломки загрузки медиа

Проверьте, какой веб-сервер используется: Apache/LiteSpeed или Nginx.
Сделайте резервную копию текущего .htaccess или конфигурации виртуального хоста.
Добавьте правило только в wp-content/uploads.
Очистите кэш сайта и, если есть, кэш на уровне сервера или CDN.
Проверьте, что обычные изображения и PDF по-прежнему открываются.
Попробуйте запросить тестовый PHP-файл и убедитесь, что сервер отдаёт 403 или 404, а не выполняет код.

Для теста можно временно создать файл test.php в uploads с безопасным содержимым:

<?php echo 'test';

После настройки при обращении к этому файлу браузер не должен показать выполненный PHP-вывод. Если файл открывается как текст или сервер отдаёт запрет — правило сработало. После проверки файл нужно удалить.

Проверка результата после внедрения

Проверять лучше не только в браузере, но и по ответу сервера. Это исключает ситуацию, когда кэш маскирует реальное поведение.

Что смотреть в ответе

HTTP-статус 403 Forbidden или 404 Not Found для PHP-файла в uploads;
отсутствие выполнения PHP-кода;
открытие обычных изображений, PDF и других медиа без ошибок;
отсутствие новых ошибок в логах веб-сервера.

Проверить статус можно через curl:

curl -I https://example.com/wp-content/uploads/2026/01/test.php

Если в ответе не видно 403 или 404, а файл исполняется, правило либо не применилось, либо перекрывается другой конфигурацией.

Частые ошибки и как их исправить

Правило добавили не в тот каталог

Самая частая ошибка — положить .htaccess в корень сайта и ждать, что он закроет только uploads. В итоге правило либо не срабатывает как нужно, либо мешает другим разделам. Файл должен лежать именно в каталоге загрузок.

На Nginx вставили .htaccess

.htaccess на Nginx не работает. Если сайт на Nginx, нужно править конфиг сервера или просить хостинг добавить правило. Иначе защита существует только «на бумаге».

Сломались старые медиа-ссылки

Иногда после жёсткой настройки начинают жаловаться на доступ к файлам. Обычно причина не в самом запрете PHP, а в неверных правах, ошибках rewrite или CDN-кэше. Сначала проверьте, что обычные .jpg, .png и .pdf открываются напрямую.

Оставили тестовый файл в uploads

После проверки test.php нужно удалить. Иначе вы сами создаёте лишний объект для сканеров и журналов безопасности.

Плагин безопасности конфликтует с серверным правилом

Если плагин тоже пытается блокировать доступ к uploads, можно получить дублирующие правила и путаницу в логах. В таком случае оставьте один источник истины: либо серверное правило, либо плагин как временную меру.

Что ещё стоит сделать для безопасности uploads

Запрет выполнения PHP — это базовый слой. Он не заменяет остальные меры:

обновляйте ядро, темы и плагины;
ограничьте загрузку файлов по типам там, где это возможно;
проверяйте права на каталоги;
следите за подозрительными файлами в uploads после установки новых плагинов;
не храните в каталоге загрузок исполняемые скрипты «для удобства».

Если на сайте уже есть признаки компрометации, сначала удалите подозрительные файлы и проверьте логи, а уже потом закрывайте каталог. Иначе можно просто спрятать проблему, но не решить её.

Для сайтов, где важна не только безопасность, но и чистота технической базы, полезно периодически пересматривать набор активных плагинов и скрытых служебных файлов. Это снижает шанс, что в uploads снова появится лишний исполняемый код.