Как отключить XML-RPC в WordPress и защитить сайт от brute force

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

XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки: перебор паролей через xmlrpc.php, шум в логах и ненужную нагрузку. При этом отключать его вслепую тоже нельзя: некоторые интеграции до сих пор используют этот endpoint для публикации и удалённого доступа.

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

Когда XML-RPC действительно мешает

Сам по себе файл /xmlrpc.php не является уязвимостью, но он часто становится точкой входа для массовых попыток авторизации. Это особенно заметно на сайтах, где:

в логах много запросов к xmlrpc.php с system.multicall;
админка начинает тормозить без видимой причины;
хостинг показывает всплески POST-запросов, хотя контента и трафика немного;
сайт не использует мобильные приложения WordPress, Jetpack, внешние публикации и старые клиенты для записи в блог.

Если вы не уверены, нужен ли endpoint, сначала проверьте реальные сценарии использования. Отключение XML-RPC ломает не «WordPress вообще», а конкретные интеграции, которые на него завязаны.

Что обычно использует XML-RPC

старые мобильные приложения WordPress;
Jetpack в некоторых сценариях подключения;
публикацию через внешние клиенты и сервисы;
часть устаревших интеграций с CMS и редакторами.

Если ничего из этого у вас нет, отключение обычно безопасно.

Диагностика: нужен ли вам XML-RPC на самом деле

Перед изменениями проверьте, обращается ли сайт к этому endpoint не только снаружи, но и изнутри инфраструктуры. Самый простой способ — посмотреть логи веб-сервера и запросы в WAF/панели хостинга. Если доступа к логам нет, можно временно открыть /xmlrpc.php в браузере: нормальный ответ WordPress обычно содержит сообщение о том, что XML-RPC сервер принимает только POST-запросы.

Для более точной проверки полезно пройтись по чек-листу:

используете ли вы Jetpack;
публикуете ли записи из мобильного приложения WordPress;
есть ли внешние сервисы автопостинга;
есть ли старые интеграции, которые давно не проверяли;
есть ли в логах регулярные обращения к xmlrpc.php с ошибками авторизации.

Если хотя бы один пункт вызывает сомнение, сначала протестируйте отключение на staging-копии или в окне низкой нагрузки.

Как отключить XML-RPC: три рабочих подхода

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

Способ	Когда подходит	Минус
Код в `functions.php` или mu-plugin	Нужен точечный контроль в теме или плагине	Надо следить за обновлениями и местом подключения
Плагин безопасности	Нужна быстрая настройка без правки кода	Лишняя зависимость от стороннего плагина
Отключение на уровне сервера	Есть доступ к конфигу Nginx/Apache	Требует аккуратности и понимания стека

1. Отключение через код

Если вы ведёте проект как разработчик, самый прозрачный вариант — mu-plugin. Так код не потеряется при смене темы и не зависит от активного шаблона.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

Этот вариант отключает сам XML-RPC на уровне WordPress. Запросы к /xmlrpc.php перестанут обслуживаться штатно, а часть атак потеряет смысл.

2. Блокировка только доступа к файлу

Если вы хотите не трогать логику WordPress, а просто закрыть endpoint на входе, можно сделать это на сервере. Для Apache часто используют правило в .htaccess:

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

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

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

Этот подход хорош тем, что запросы даже не доходят до WordPress. Но если у вас несколько сайтов на одном сервере, важно не задеть нужные исключения и не копировать правило вслепую.

3. Через плагин безопасности

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

В проектах, где уже используется Clearfy Pro, отключение XML-RPC можно держать в одном месте вместе с другими техническими настройками сайта. Это не обязательное решение, но оно удобно, если вы централизуете чистку и SEO-опции в одном интерфейсе.

Пошаговое решение без лишнего риска

Проверьте, используется ли XML-RPC реально, а не «когда-то использовался».
Сделайте резервную копию файлов и базы.
Выберите один способ отключения: код, сервер или плагин. Не смешивайте сразу три.
Внедрите изменение на staging или в окно низкой нагрузки.
Проверьте, не сломались ли внешние публикации, мобильное приложение и Jetpack.
Посмотрите логи на предмет 403/404/500 по xmlrpc.php.

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

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php напрямую и убедитесь, что ответ соответствует выбранному способу блокировки:

при отключении через WordPress — endpoint не должен работать как обычный XML-RPC сервер;
при блокировке на сервере — должен быть 403 Forbidden или аналогичный отказ;
в логах не должно быть новых успешных обращений к XML-RPC от неизвестных источников;
если у вас есть мониторинг, проверьте, не выросло ли число ошибок авторизации в админке или на внешних сервисах.

Дополнительно можно протестировать POST-запрос вручную через curl:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Если endpoint закрыт правильно, вы не должны получить нормальный ответ XML-RPC со списком методов.

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

Отключили XML-RPC, а потом перестал работать Jetpack

Значит, вы отключили endpoint раньше, чем проверили зависимость. Решение простое: либо вернуть XML-RPC, либо отказаться от Jetpack в этом сценарии, либо перенести нужную функцию на другой механизм подключения.

Поставили правило в .htaccess, но атаки всё равно идут

Так бывает, если сайт работает на Nginx, а правило добавили только в Apache-конфиг, который не используется. Проверьте реальный веб-сервер и место, где он читает правила. На shared-хостинге это особенно частая ошибка.

Отключили через код, но endpoint всё ещё отвечает

Причина обычно в кэше, CDN или в том, что код лежит не там. Если вы добавили фильтр в тему, а активная тема сменилась, правило исчезло. Для таких задач mu-plugin надёжнее.

Сломали внешнюю публикацию, но не поняли, кто виноват

Проверьте список интеграций по очереди: мобильное приложение, автопостинг, редакторы, сторонние сервисы. Не возвращайте XML-RPC «на всякий случай» без понимания, что именно его использует.

Безопасность и производительность: что ещё имеет смысл сделать

Отключение XML-RPC — не панацея. Если сайт регулярно атакуют, полезно дополнительно:

ограничить попытки входа в админку;
включить двухфакторную аутентификацию для администраторов;
проверить, не открыт ли wp-login.php для массового перебора;
убрать неиспользуемые плагины и темы;
следить за логами 401/403 и аномальной нагрузкой.

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

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