Сайт тормозит, хостинг-провайдер шлёт предупреждения о превышении лимитов, а в логах, бесконечная лента POST-запросов к xmlrpc.php. Если вы администрируете WordPress, этот кошмар вам наверняка знаком.

Файл xmlrpc.php, тихий, но чрезвычайно опасный элемент любой установки WordPress. Он живёт в корне вашего сайта с момента установки CMS и десятилетиями остаётся любимой точкой входа для ботов и злоумышленников. По данным отчёта Wordfence за 2024 год, атаки через XML-RPC входят в пятёрку главных векторов угроз для WordPress-сайтов, и в 2026 году ничего не изменилось.

При этом большинство владельцев сайтов понятия не имеют, зачем этот файл вообще существует и как его обезвредить. В этом руководстве, четыре рабочих способа заблокировать xmlrpc.php, от быстрого правила в .htaccess до фаервола уровня CDN. Без воды, с проверенным кодом и объяснением, какой метод когда применять.

💡 Быстрый обзор:

• Проверьте, отвечает ли ваш xmlrpc.php на POST-запросы, скорее всего, отвечает
• Выберите способ блокировки: htaccess, код в functions.php, плагин или WAF
• Добавьте правило блокировки и убедитесь, что endpoint возвращает 403 Forbidden
• Если пользуетесь Jetpack, настройте точечную защиту через фаервол вместо полного отключения

Что такое xmlrpc.php и зачем он всё ещё в WordPress

XML-RPC (Remote Procedure Call), протокол, позволяющий внешним приложениям общаться с WordPress. Он появился в ядре ещё в версии 1.5 и десятилетиями служил единственным API для удалённой публикации: через него работали мобильные приложения WordPress, десктопные клиенты вроде Windows Live Writer и сторонние сервисы.

С выходом WordPress REST API в версии 4.7 (2016 год) потребность в XML-RPC практически отпала. Современный REST API покрывает всё, что раньше делал XML-RPC, и делает это безопаснее, быстрее и с нормальной аутентификацией через nonce или OAuth.

Но файл xmlrpc.php до сих пор лежит в корне каждой установки WordPress. По умолчанию удалённая публикация через него отключена, однако сам endpoint принимает запросы. Достаточно открыть вашсайт.com/xmlrpc.php в браузере, чтобы увидеть: «XML-RPC server accepts POST requests only». Это значит, endpoint жив и готов к атаке.

Почему xmlrpc.php опасен: главные векторы атак

Злоумышленники используют xmlrpc.php для двух основных типов атак, и оба могут положить ваш сайт.

Brute force через system.multicall. Метод system.multicall позволяет упаковать в ОДИН HTTP-запрос сотни попыток авторизации. Вместо того чтобы перебирать пароли по одному (как через wp-login.php), бот отправляет массив логинов и паролей разом. Обычные плагины ограничения попыток входа (login limiters) такой запрос не видят, для них это «одна попытка». Результат: злоумышленник перебирает тысячи комбинаций за секунды, не попадая под блокировку.

Pingback DDoS. Функция пингбеков позволяет другому сайту уведомить ваш WordPress о ссылке на него. Злоумышленник отправляет поддельный пингбек-запрос, подставляя в качестве «источника» IP-адрес жертвы. Ваш сервер честно идёт проверять ссылку, и атакует ничего не подозревающий целевой хост. Масштабируйте это на тысячи скомпрометированных WordPress-установок, получается распределённая DDoS-атака, где ваш сайт выступает пушечным мясом.

Хостинг-провайдеры отслеживают исходящий трафик такого рода и могут заморозить аккаунт за «участие в DDoS». А сам сервер в это время расходует процессор, память и bandwidth на обслуживание мусорных запросов.

Проверьте: отвечает ли ваш xmlrpc.php

Перед тем как блокировать, убедитесь, что endpoint действительно открыт. Откройте в браузере:

1
https://вашсайт.com/xmlrpc.php

Если видите строку «XML-RPC server accepts POST requests only», endpoint жив, и злоумышленники могут слать на него запросы. Если получаете 403 Forbidden или 404, защита уже работает.

Второй способ, отправить тестовый POST-запрос через терминал:

1
curl -X POST https://вашсайт.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Ответ с 200 OK и XML-структурой подтверждает: XML-RPC принимает запросы и готов к эксплуатации.

Способ 1: быстрая блокировка через.htaccess

Самый простой и действенный метод, заблокировать доступ к файлу на уровне веб-сервера. Запрос отбрасывается до того, как доходит до WordPress, это экономит ресурсы сервера и работает, даже если сайт лежит под нагрузкой.

Добавьте в корневой .htaccess (тот, что рядом с wp-config.php):

1
Блокировка xmlrpc.php — защита от brute force и DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Директива Require all denied, синтаксис Apache 2.4+, актуальный для всех современных хостингов. После сохранения откройте xmlrpc.php в браузере, должны получить 403 Forbidden.

Если сервер на nginx, правило добавляется в конфиг виртуального хоста:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

После изменения конфига nginx не забудьте перезагрузить сервер: sudo nginx -s reload.

Этот метод подходит, если вам ТОЧНО не нужен XML-RPC, ни для Jetpack, ни для мобильных приложений WordPress, ни для WooCommerce-интеграций.

Способ 2: отключение через functions.php (программный метод)

Если вы предпочитаете решать проблему на уровне кода, а не серверных конфигов, вот два проверенных сниппета для functions.php активной темы или Code Snippets.

Полное отключение XML-RPC (WP 3.5+):

1
// Отключить XML-RPC полностью
2
add_filter('xmlrpc_enabled', '__return_false');

Одна строка, и WordPress перестаёт обрабатывать любые XML-RPC запросы. При попытке обратиться к xmlrpc.php клиент получит ответ с ошибкой, сам файл остаётся на сервере, но функционально мёртв.

Очистка заголовков wp_head от RSD и WLW-ссылок:

Даже после отключения XML-RPC WordPress продолжает вставлять в <head> две строки, которые выдают информацию о вашем сайте:

1
// Убрать ссылки RSD и WLW Manifest из заголовков
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Хуки rsd_link и wlwmanifest_link добавляют в <head> теги <link rel="EditURI"> и <link rel="wlwmanifest">, они нужны исключительно для XML-RPC клиентов и не несут практической пользы в 2026 году. Убираем.

⚠️ Важно: правки в functions.php темы слетят при обновлении. Используйте дочернюю тему или плагин Code Snippets для постоянного хранения кастомного кода.

Способ 3: плагины безопасности

Не хотите лезть в код, установите плагин. Три проверенных варианта:

• Wordfence Security. Самый популярный WordPress-фаервол. Помимо блокировки XML-RPC даёт сканер вредоносного кода, защиту логина и мониторинг трафика. В настройках Wordfence → Login Security → отметьте «Disable XML-RPC authentication».

• Disable XML-RPC-API. Лёгкий плагин, который делает ровно одно: вешает фильтр xmlrpc_enabled и отключает endpoint. Никаких дополнительных настроек, активировал и забыл.

• iThemes Security (Solid Security). Комплексный плагин с модулем WordPress Tweaks, где XML-RPC отключается одной галочкой. Заодно закрывает другие векторы: смену префикса таблиц, отключение редактора файлов из админки, защиту от перебора паролей.

После активации любого из плагинов обязательно проверьте, что xmlrpc.php возвращает ошибку, а не приветствие.

Способ 4: блокировка на уровне фаервола (Cloudflare / Sucuri)

Самый мощный уровень защиты, веб-фаервол, который отбрасывает вредоносные запросы ещё до того, как они достигают вашего хостинга.

Cloudflare** WAF.** Создайте кастомное правило: поле URI Path содержит xmlrpc.php → действие Block. Запросы фильтруются на уровне сети Cloudflare (более 330 точек присутствия по миру), сервер их даже не видит. В тарифе Free доступно 5 кастомных правил, этого достаточно. Бонус: Cloudflare показывает статистику заблокированных запросов, и вы своими глазами увидите масштаб атак.

Sucuri Website Firewall. Аналогичный подход, WAF правило на URI /xmlrpc.php. Sucuri также предлагает мониторинг целостности файлов и автоматическую очистку от вредоносного кода.

Правило фаервола удобно сочетать с .htaccess или программным отключением: фаервол отсекает массовый мусор, а локальный блок, запасной рубеж на случай, если трафик по какой-то причине обошёл WAF.

Что делать, если вы пользуетесь Jetpack

Jetpack от Automattic использует XML-RPC для связи вашего сайта с серверами WordPress.com. Если полностью отключить xmlrpc.php, Jetpack перестанет работать: статистика, подписки, CDN для картинок, модуль Related Posts и защита от brute force через Jetpack отвалятся разом.

Решение, не глушить XML-RPC целиком, а точечно пропускать запросы от серверов Jetpack:

• Оставьте xmlrpc.php доступным (НЕ блокируйте через .htaccess и НЕ вешайте фильтр xmlrpc_enabled).

• Настройте Cloudflare WAF так: разрешить запросы к xmlrpc.php ТОЛЬКО от IP-диапазонов Automattic (список обновляется в документации Jetpack), остальные блокировать.

• Как минимум, уберите RSD и WLW-заголовки сниппетом из способа 2, чтобы не светить endpoint в <head> без необходимости.

• Установите Wordfence и включите защиту от brute force конкретно для xmlrpc.php, она не блокирует легитимные запросы Jetpack, но режет попытки подбора паролей.

⁉️🤔 Частые вопросы

Можно ли просто удалить файл xmlrpc.php с сервера?

Можно, но это плохая практика. При следующем обновлении WordPress файл восстановится, и вы снова уязвимы. Лучше заблокировать доступ через .htaccess или отключить функциональность фильтром в коде: эффект тот же, но обновления ядра не сломают защиту. Если всё же удалили файл, обязательно уберите rsd_link из wp_head, иначе посетители получат 404 при переходе по ссылке EditURI.

Сломает ли отключение XML-RPC WooCommerce?

Нет. WooCommerce полностью перешёл на WordPress REST API и не зависит от XML-RPC. Магазин продолжит работать без изменений. Единственное исключение, если вы используете древнее кастомное решение, завязанное на XML-RPC, но таких практически не осталось.

Как быть, если хостинг-провайдер сам блокирует xmlrpc.php?

Если провайдер уже отключил XML-RPC на уровне сервера, вам ничего делать не нужно, endpoint недоступен. Проверьте: откройте xmlrpc.php, если 403, защита работает. Единственное, что стоит добавить, удаление RSD и WLW-заголовков через functions.php, потому что провайдер их не трогает.

Надо ли отключать XML-RPC, если я сижу на managed WordPress-хостинге?

Большинство managed-хостингов (Kinsta, WP Engine, SiteGround) блокируют или жёстко ограничивают xmlrpc.php на уровне платформы. Проверьте, открыт ли endpoint через браузер. Если заблокирован, дополнительных действий не требуется. Если открыт, добавьте .htaccess правило: managed-хостинги его не перезаписывают.

Как узнать, что сайт атакуют через xmlrpc.php прямо сейчас?

Три признака: резкий скачок нагрузки на сервер при неизменном трафике, сотни однотипных POST-запросов к xmlrpc.php в логах доступа и ошибки превышения лимитов памяти/процессора от хостинг-провайдера. Включите мониторинг (Wordfence → Live Traffic или Cloudflare → Security Events), вы увидите источник и масштаб атаки в реальном времени.

Стоит ли отключать xmlrpc.php в 2026 году

Короткий ответ: да, если вы не пользуетесь Jetpack и не публикуете посты через мобильное приложение WordPress.

XML-RPC, наследие эпохи WordPress 1.5. REST API давно занял его место, а сам xmlrpc.php превратился в открытую дверь для brute force и DDoS-атак. Закрыть её, дело пяти минут. Выберите способ под свою ситуацию:

• Не хотите трогать код, поставьте Disable XML-RPC-API, два клика.
• Есть доступ к файлам сервера, добавьте правило в .htaccess, серверный уровень надёжнее.
• Любите чистоту в коде, сбросьте фильтр xmlrpc_enabled и уберите заголовки двумя сниппетами в functions.php.
• Хотите максимум защиты, настройте WAF-правило в Cloudflare и комбинируйте с локальным блоком.

После блокировки обязательно проверьте, что xmlrpc.php возвращает 403 Forbidden, и мониторьте логи хотя бы неделю, вы удивитесь, сколько мусорного трафика исчезло. А заодно подпишитесь на обновления WordPress: история показывает, что старые протоколы умирают медленно, и новые уязвимости в XML-RPC могут всплыть и после 2026 года.