Как отключить открытые XML-RPC методы в WordPress

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

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

Когда это действительно нужно

Отключать отдельные XML-RPC методы имеет смысл, если:

• в логах видны частые запросы к /xmlrpc.php;
• сайт не использует внешние клиенты, которым нужен полный XML-RPC;
• нужно оставить совместимость с чем-то точечным, но убрать массово используемые методы;
• вы не хотите трогать серверные правила, потому что на хостинге несколько сайтов и нужен более мягкий вариант.

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

Диагностика: какие методы обычно оставляют лишнюю поверхность атаки

Самые проблемные сценарии обычно связаны с методами, которые позволяют:

• проверять логин и пароль через многократные запросы;
• отправлять публикации удалённо;
• получать данные о сайте и пользователях без необходимости;
• использовать старые интеграции, которые давно можно заменить REST API.

Проверить, что XML-RPC вообще отвечает, можно обычным запросом:

curl -i https://example.com/xmlrpc.php

Если endpoint доступен, это ещё не значит, что он нужен. Дальше важно понять, какие именно методы реально используются. Для этого обычно смотрят логи веб-сервера, WAF или плагина безопасности. Если видите обращения к system.multicall, wp.getUsersBlogs и похожим методам, это уже повод ограничить доступ.

Как отключить только нужные XML-RPC методы

Самый практичный способ — отфильтровать список разрешённых методов через хук xmlrpc_methods. Так вы не ломаете сам endpoint, но убираете то, что не нужно.

Пример: убрать методы для брутфорса и удалённой публикации

<?php
add_filter('xmlrpc_methods', function ($methods) {
    // Удаляем методы, которые часто используют для перебора логинов и массовых запросов.
    unset($methods['system.multicall']);
    unset($methods['wp.getUsersBlogs']);
    unset($methods['wp.newPost']);
    unset($methods['wp.editPost']);
    unset($methods['wp.deletePost']);
    unset($methods['wp.uploadFile']);

    return $methods;
});

Код можно добавить в functions.php дочерней темы, но лучше — в небольшой mu-plugin, чтобы он не зависел от темы. Для production это надёжнее: при смене темы правило не исчезнет.

Вариант аккуратнее: оставить только нужные методы

Если вы точно знаете, что нужен только ограниченный набор, проще собрать белый список. Но делать это стоит осторожно: разные интеграции могут использовать неожиданные методы.

<?php
add_filter('xmlrpc_methods', function ($methods) {
    $allowed = array(
        'system.getCapabilities' => $methods['system.getCapabilities'] ?? null,
        'system.listMethods'      => $methods['system.listMethods'] ?? null,
    );

    return array_filter($allowed);
});

Такой вариант подходит только если вы точно понимаете, какие клиенты обращаются к сайту. Для большинства проектов безопаснее точечно отключать опасные методы, а не строить белый список с нуля.

Сравнение подходов: плагин, код или сервер

Подход	Что даёт	Минус
Плагин безопасности	Быстрое отключение XML-RPC или части функций без кода	Меньше контроля, возможны лишние ограничения
Код через xmlrpc_methods	Точечное управление методами	Нужно следить за обновлениями и местом подключения кода
Серверное правило	Жёсткая блокировка на уровне nginx/Apache	Можно сломать легитимные интеграции, если не проверить заранее

Если задача именно в частичном ограничении, код обычно даёт лучший баланс. Серверный блок уместен, когда XML-RPC не нужен вообще.

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

1. Проверьте, какие интеграции используют XML-RPC: мобильное приложение, внешние сервисы публикации, старые клиенты.
2. Сделайте резервную копию файла или подготовьте mu-plugin.
3. Добавьте фильтр xmlrpc_methods и уберите только опасные методы.
4. Очистите кеш сайта и, если есть, кеш на уровне CDN или reverse proxy.
5. Проверьте логи и тестовые запросы после изменения.

Если вы используете плагин кеширования или оптимизации, убедитесь, что он не кэширует ответ на xmlrpc.php как обычную страницу. Для этого endpoint кэш обычно не нужен и может мешать диагностике.

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

После внедрения важно проверить не только то, что endpoint отвечает, но и то, что нужные методы действительно недоступны.

Проверка через curl

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

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

Если метод отключён, вы увидите ошибку вида unknown method или аналогичный отказ в обработке. Формат ответа зависит от того, как именно вы ограничили методы.

Проверка в админке и логах

• убедитесь, что публикация через нужный инструмент всё ещё работает, если она вам нужна;
• посмотрите access log: число запросов к /xmlrpc.php может остаться, но успешные вызовы опасных методов должны исчезнуть;
• проверьте, нет ли ошибок в PHP error log после добавления фильтра.

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

Отключили не тот метод

Иногда ломают system.listMethods или system.getCapabilities, после чего диагностика становится сложнее. Если вы не уверены, не трогайте служебные методы без необходимости.

Добавили код в родительскую тему

После обновления темы правило исчезнет. Для постоянной защиты используйте mu-plugin или отдельный мини-плагин.

Не проверили сторонние интеграции

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

Смешали отключение методов и блокировку на сервере

Если одновременно поставить жёсткий запрет в nginx и фильтр в WordPress, потом будет трудно понять, что именно сломалось. Лучше менять по одному слою и проверять результат.

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

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

• ограничение попыток входа;
• двухфакторную аутентификацию для админов;
• актуальность ядра, темы и плагинов;
• наличие WAF или правил на стороне хостинга.

Если задача шире и вы чистите сайт от технического мусора, полезно посмотреть в сторону инструментов для удаления дублей и лишних сущностей. Например, Clearfy Pro от WPShop закрывает часть типовых задач по технической оптимизации и чистке WordPress, но применять такие решения стоит только после проверки, что они не конфликтуют с вашей конфигурацией.

Главная идея простая: не обязательно выбирать между «всё открыть» и «всё сломать». В WordPress можно оставить нужный функционал и убрать только те XML-RPC методы, которые реально создают риск.