XML-RPC в WordPress до сих пор часто оставляют включённым «на всякий случай», а потом получают лишнюю точку входа для перебора паролей и запросов к сайту. Если вы не используете мобильное приложение WordPress, внешние сервисы публикации или старые интеграции, этот интерфейс обычно можно закрыть без потерь.
Ниже — практический разбор: как понять, нужен ли вам XML-RPC, как отключить его безопасно, как проверить, что всё сработало, и какие ошибки чаще всего ломают авторизацию или интеграции.
Когда XML-RPC можно отключать, а когда нет
Сначала проверьте не сам факт наличия файла xmlrpc.php, а реальные сценарии использования. Для большинства обычных сайтов он не нужен. Но если сайт подключён к внешним клиентам или сервисам, отключение может сломать публикацию или синхронизацию.
Оставьте XML-RPC включённым, если вы используете
- мобильное приложение WordPress для публикации;
- Jetpack и похожие интеграции, которые завязаны на XML-RPC;
- старые внешние редакторы и сервисы автопостинга;
- какие-то самописные интеграции, где явно вызывается
xmlrpc.php.
Можно отключать, если у вас
- обычный сайт на WordPress без внешней публикации;
- вход и редактирование идут только через админку;
- нет мобильных клиентов и старых API-интеграций;
- нужна минимизация поверхности атаки.
Диагностика: как понять, используется ли XML-RPC сейчас
Перед изменениями проверьте логи и интеграции. Самый простой признак — обращения к /xmlrpc.php в access-логах веб-сервера. Если там есть регулярные запросы от неизвестных IP, это уже повод закрыть доступ или хотя бы ограничить его на уровне сервера.
Ещё один практический тест — открыть https://example.com/xmlrpc.php в браузере. Если файл доступен, это не означает уязвимость, но подтверждает, что endpoint открыт. WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы.
Если у вас есть доступ к логам, ищите такие строки:
grep