XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack или внешняя публикация через сторонний сервис. Проблема в том, что это не просто лишний endpoint: у него есть реальные потребители, и перед отключением их нужно проверить.
Если задача стоит именно в снижении атаки на сайт, а не в абстрактной «чистке», правильный подход такой: сначала найти, кто обращается к /xmlrpc.php, затем решить, можно ли заменить этот канал на REST API или вообще убрать интеграцию. Только после этого отключать endpoint.
Когда XML-RPC действительно можно отключить
Отключение оправдано, если сайт не использует старые внешние клиенты, публикацию через приложения, pingback/trackback через XML-RPC и Jetpack-функции, завязанные на этот канал. На практике это типично для сайтов, где админка используется только через браузер, а интеграции уже переведены на REST API или вообще отсутствуют.
Если у вас есть хотя бы один из следующих сценариев, сначала проверьте совместимость:
- мобильное приложение WordPress;
- Jetpack с подключением через XML-RPC;
- публикация из сторонних редакторов и CMS;
- старые интеграции с сервисами автопостинга;
- плагины, которые используют XML-RPC для удалённых операций.
Диагностика: кто вообще использует xmlrpc.php
Перед изменениями полезно посмотреть логи веб-сервера. Если запросы к xmlrpc.php идут регулярно, это не всегда атака: иногда это легитимные обращения от сервисов или ботов. Но если вы видите только перебор методов и много 403/404, отключение имеет смысл.
Что искать в логах
Ищите строки с /xmlrpc.php, а также частые POST-запросы с одинаковых IP и подозрительными user-agent. Если доступ к логам ограничен, можно временно включить логирование на уровне сервера или посмотреть статистику в панели хостинга.
grep