Отключите WordPress XML-RPC одной строкой: почему xmlrpc.php — угроза безопасности и как его выключить без плагина

Откройте свой WordPress-сайт в браузере, добавьте к URL /xmlrpc.php и нажмите enter. Если вы видите "XML-RPC server accepts POST requests only.", поздравляем, ваш сайт транслирует 21-летний эндпоинт, через который атакующие усиливают брутфорс, разведывают учётки, а в плохой день делают из вашего сервера отражатель атаки на кого-то ещё. Починка — одна строка PHP. Разберём, что такое XML-RPC, почему WordPress его сохранил, что именно может пойти не так, и четыре способа выключить его — от самого простого до самого надёжного.

Что такое XML-RPC, кратко

XML-RPC — это протокол удалённого вызова процедур из 1998 года. Он отправляет XML-пакет поверх HTTP, клиент вызывает именованную функцию на сервере и получает структурированный ответ. WordPress включил поддержку XML-RPC в 2003 году, когда альтернативой было либо заливать PHP-файлы по FTP, либо использовать медленные формы в админке. По меркам того времени это было элегантно.

Через это работали три большие вещи: публикация из десктопных блог-клиентов вроде Windows Live Writer, пингбеки и трекбеки между блогами, и первые функции Jetpack, благодаря которым WordPress.com общался с self-hosted сайтом. Примерно десять лет XML-RPC был единственным официальным способом для софта вне wp-admin читать или писать контент на вашем сайте.

Потом в 2016-м WordPress 4.7 принёс REST API. REST API быстрее, по умолчанию безопаснее, использует обычный JSON, поддерживает OAuth и application passwords, и на нём говорит каждая современная интеграция. XML-RPC остаётся в ядре для обратной совместимости, но ни один активно поддерживаемый инструмент его уже не требует. Редактор Gutenberg использует REST. Мобильные приложения — REST. Новые функции Jetpack — REST.

Протокол остался как старые съезды с трассы: никто ими не пользуется намеренно, но просто так их не снесёшь, не разбив несколько машин.

Почему xmlrpc.php — проблема в 2026 году

Эндпоинт https://vashsait.ru/xmlrpc.php включён по умолчанию в каждой установке WordPress. Это один файл в корне сайта. Удалить его нельзя, следующее обновление ядра вернёт его на место. Проблема с тем, что он включён, не теоретическая — это один из самых атакуемых файлов во всей экосистеме.

1. Усиление брутфорса. Метод wp.getUsersBlogs принимает имя пользователя и пароль как параметры. Каждый запрос пробует одну пару учётных данных, сервер отвечает да или нет. Хуже того, метод system.multicall позволяет атакующему упаковать сотни попыток входа в один HTTP-запрос. Бот может попробовать 500 паролей одним запросом, проскочить наивные правила fail2ban и даже не появиться в access-логе как 500 строк. Мы заходили к клиентам, где xmlrpc.php съедал больше трафика, чем главная, и всё это был брутфорс.

2. Перебор имён пользователей. Даже когда логин не удался, ответ выдаёт информацию. Отправьте на wp.getUsersBlogs предположение с логином admin и любым паролем, и код ошибки скажет, существует ли пользователь admin. Это бесплатная разведка для следующего этапа атаки.

3. Pingback DDoS-отражение. Метод pingback.ping предназначен для того, чтобы один блог сообщил другому: "эй, я на тебя сослался". Ваш сервер скачивает URL, который указал вызывающий, чтобы проверить ссылку. Это значит, что атакующий может попросить тысячи WordPress-сайтов одновременно ударить по одной целевой URL. Ваш сайт становится частью распределённой DoS-атаки, и никто даже не трогает wp-admin. Akamai задокументировал этот сценарий в большом масштабе несколько лет назад, и он никуда не делся.

4. SSRF и сканирование внутренней сети. Поскольку pingback заставляет сервер тянуть произвольные URL, атакующие используют его для разведки внутренних сетей, к которым у публичного интернета нет доступа, — вроде http://192.168.0.1/admin или http://localhost:9200 для забытого Elasticsearch. WordPress-сервер превращается в прокси для атакующего.

5. Поверхность атаки плагинов. Плагины могут подцепиться к XML-RPC и добавить свои методы. Каждый добавленный метод — ещё одна функция на публичном эндпоинте. Несколько исторических CVE в крупных плагинах были эксплуатируемы именно потому, что XML-RPC был включён.

Отключение XML-RPC закрывает все пять вещей одним движением. Единственная цена — нельзя пинговать или трекбекать другие блоги, функция, отравленная спамом так давно, что большинство сайтов её и так выключили.

Что-нибудь сломается, если выключить?

Скорее всего, нет. Честный список того, чему в 2026 году XML-RPC реально нужен:

Первичное подключение Jetpack на очень старых установках — современный Jetpack использует REST, но если подключаете сайт со старой версией Jetpack, рукопожатие может всё ещё пробовать XML-RPC. Сначала обновите Jetpack.
Несколько старых десктопных блог-клиентов — Windows Live Writer, Open Live Writer, MarsEdit в некоторых версиях, нишевые сторонние приложения. Если вы всё ещё публикуете из одного из них, придётся либо оставить XML-RPC включённым, либо переехать в WordPress-админку или мобильное приложение на REST.
Пингбеки и трекбеки — их отключение давно воспринимается как плюс, а не как потеря.

Если не уверены, безопасный порядок такой: сделайте бэкап, выключите XML-RPC, пользуйтесь сайтом неделю как обычно. Если ничего не сломалось, готово. Если конкретный инструмент перестал работать, у вас гораздо более узкий вопрос: нужен ли мне этот инструмент, или нужен ли мне этот инструмент именно с XML-RPC.

Однострочное исправление и три более мощных

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

Способ 1, PHP-фильтр (однострочник)

Откройте wp-config.php, или, лучше, маленький mu-plugin файл в wp-content/mu-plugins/, и добавьте:

add_filter( 'xmlrpc_enabled', '__return_false' );

Всё. __return_false — это хелпер из ядра WordPress. Фильтр говорит WordPress отвергать все вызовы XML-RPC. Запросы к xmlrpc.php по-прежнему получают ответ, но это чистое "XML-RPC services are disabled on this site.", а не исполняемая поверхность.

Плюсы: ноль зависимостей, переживает обновления ядра, две секунды на применение, легко откатить. Минусы: PHP всё равно должен запуститься, чтобы вернуть это сообщение об отключении. Если по вам бьют, сервер продолжает тратить CPU на каждый вредоносный запрос.

Почему mu-plugin, а не functions.php: темы меняются, must-use плагины — нет. Положить фильтры безопасности в тему — значит, что смена темы тихо включит XML-RPC обратно. Двухстрочный mu-plugin переживёт всё это.

Способ 2, блокировка на веб-сервере (nginx)

В блок server или location добавьте:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

Return 444 — это nginx-овское "закрыть соединение без ответа", что заставляет сканеры сдаться быстрее, чем чистый 403. Запросы вообще не доходят до PHP, нагрузка на CPU нулевая. Эту версию мы ставим на каждый WordPress-сайт, который хостим.

Способ 3, блокировка на веб-сервере (Apache, .htaccess)

Если у вас Apache, в .htaccess в корне WordPress перед блоком rewrite добавьте:

<Files xmlrpc.php>
    Require all denied
</Files>

Результат тот же, что у nginx-версии, запросы отклоняются до того, как стартует PHP. На старом Apache 2.2 вместо этого пишут Order allow,deny / Deny from all, но всё актуальное уже на 2.4.

Способ 4, allowlist, если он реально нужен

Если конкретному сервису обязательно нужно вызывать xmlrpc.php, не оставляйте дверь открытой всему интернету. В nginx:

location = /xmlrpc.php {
    allow 198.51.100.42;
    deny all;
}

Замените IP на реальный. Jetpack публикует свои IP-диапазоны, если это ваш случай. Так эндпоинт существует только для разрешённого трафика.

Как проверить, что реально сработало

Три быстрых проверки с ноутбука:

Откройте https://vashsait.ru/xmlrpc.php в браузере. Должно быть либо пустое 403/444 (блок на веб-сервере), либо короткое XML-сообщение об отключении XML-RPC (PHP-фильтр). Если видите "XML-RPC server accepts POST requests only.", эндпоинт всё ещё жив.
Из терминала: curl -d "<methodCall><methodName>system.listMethods</methodName></methodCall>" https://vashsait.ru/xmlrpc.php. С отключённым XML-RPC получите пустой массив или 403. С включённым — длинный список имён методов, включая wp.getUsersBlogs и pingback.ping.
Посмотрите access-лог за следующие 24 часа. Запросы к xmlrpc.php должны упасть с "сотен и тысяч в день" либо до нуля, либо до сплошных 403/444. Если они продолжают возвращать 200, блок стоит не в том файле.

Раз уж залезли, четыре дешёвых усиления WordPress

Если вы и так редактируете wp-config или .htaccess, эти пятиминутные дополнения стоят того, чтобы добить их за один заход. Полный предзапускной чек-лист — в нашем техническом SEO-чек-листе, а по безопасности конкретно:

Отключите редактирование файлов из админки. В wp-config.php добавьте define( 'DISALLOW_FILE_EDIT', true );. Если атакующий угонит админский аккаунт, он не сможет просто вставить вебшелл в тему.
Принудительный SSL для админки. В wp-config define( 'FORCE_SSL_ADMIN', true );. У любого нормального хостинга уже включено, но стоит проверить.
Заблокируйте перебор пользователей через WordPress REST API для неавторизованных. ?rest_route=/wp/v2/users выдаёт те же имена, что и XML-RPC. Фильтруйте или ограничьте авторизованными.
Переименуйте или rate-limit-ните /wp-login.php. Либо на веб-сервере, либо маленькой функцией для усиления логина. Связка "выключенный XML-RPC + rate-limit на wp-login.php" закрывает две главные двери для брутфорса.

А плагины безопасности, которые "отключают XML-RPC"?

Wordfence, iThemes Security, Sucuri, All In One WP Security — у каждого крупного плагина безопасности есть для этого тумблер. Все они делают по сути то же, что и Способ 1, ставят тот же фильтр. Разница — в накладных расходах. Полный плагин безопасности грузит десятки тысяч строк PHP на каждый запрос, чтобы переключить один булев флаг. Если нужно только это, однострочный фильтр справится без плагинного налога. Плагины оправдывают себя, когда вы хотите ещё и файрвол, сканер вредоносного кода, капчу на логине и прочее. Конкретно по XML-RPC побеждает фильтр.

Это тот же паттерн, что мы видим во всей экосистеме WordPress, и причина, почему мы писали о том, когда WordPress — правильный инструмент, а когда нет: каждая функция — это "один плагин", что делает поверхность огромной, если не держать дисциплину. У малого бизнеса этот же компромисс возвращается шаг за шагом, как мы разбирали в руководстве по сайтам для малого бизнеса.

Часто задаваемые вопросы

Отключение XML-RPC повлияет на SEO?

Нет. XML-RPC не сканируется и не используется поисковыми системами. Отключение убирает только поверхность атаки.

Перестанет ли работать мобильное приложение WordPress?

Официальные приложения WordPress и Jetpack сегодня авторизуются через REST API по application passwords. Если ваша установка WordPress и Jetpack в актуальных версиях, оба приложения с выключенным XML-RPC работают нормально.

А пингбеки и трекбеки?

Уходят. На практике это почти никому не важно. Уведомления pingback уже больше десяти лет в основном спам. Большинство активных админов WordPress давно отключили их в Настройки → Обсуждение. Закрытие XML-RPC просто делает это надёжнее.

А если мой хостинг уже блокирует XML-RPC?

Некоторые managed WordPress хостинги (Kinsta, WP Engine, SiteGround на отдельных тарифах) блокируют xmlrpc.php на уровне платформы. Откройте /xmlrpc.php на сайте и увидите. Если видите 403 или брендированную страницу-заглушку хостинга — готово. Добавить PHP-фильтр сверху не повредит, это безвредная избыточность.

Можно ли сделать это из админки WordPress без правки кода?

В ядре — нет. WordPress не выводит выключатель XML-RPC в дашборд. Либо вы добавляете фильтр, либо правите конфиг веб-сервера, либо ставите плагин, единственная работа которого — переключить этот же фильтр за вас. Однострочное изменение кода — на сегодня самое маленькое и лёгкое решение.

У меня multisite, есть отличия?

Тот же фикс, применённый на всю сеть. Положите фильтр в network-активированный mu-plugin (в wp-content/mu-plugins/), и он покроет все сайты сети без активации на каждом из них.

Итог

XML-RPC — протокол 1998 года, оставленный в ядре WordPress ради обратной совместимости с софтом, которого по большей части уже нет. В 2026 году оставлять xmlrpc.php публичным — это в одном файле раздавать атакующим брутфорс-усилитель, оракул имён пользователей и DDoS-отражатель. Отключение не стоит ничего, почти ничего не ломает и относится к изменениям безопасности с самым высоким соотношением результат/усилия, которые вы можете сделать на WordPress-сайте.

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