Каждый сайт на WordPress хранит в корне «тихий» файл, о котором большинство владельцев узнаёт только после атаки. Его имя, xmlrpc.php. Сам по себе он не вредоносен: WordPress честно предупреждает, что это интерфейс для удалённого взаимодействия. Но именно через него боты годами подбирают пароли, рассылают спам-пингбеки и гонят DDoS-трафик.

По данным Wordfence за 2024 год, атаки через XML-RPC входят в пятёрку главных векторов атак на WordPress-сайты. Один запрос system.multicall позволяет злоумышленнику перебрать сотни паролей за раз, вместо одного, как через форму входа. Хостинги фиксируют миллионы таких попыток ежемесячно на среднестатистическом сайте.

Разберёмся, зачем файл вообще нужен, кому его стоит оставить, а главное, покажем пять способов отключить или надёжно заблокировать xmlrpc.php, от плагина в один клик до точечной правки .htaccess.

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

• Узнайте, что такое xmlrpc.php и какие функции WordPress от него зависят (pingback, мобильное приложение, Jetpack)
• Оцените реальные риски: brute-force-амплификация, pingback-DDoS и сканирование каталогов ботами
• Выберите подходящий способ защиты: отключение плагином, блокировка через .htaccess, закрытие доступа на уровне веб-сервера или удаление файла
• Настройте мониторинг: как убедиться, что xmlrpc.php больше не отвечает на запросы

Что такое xmlrpc.php и какие функции WordPress от него зависят

XML-RPC, это протокол удалённого вызова процедур, который работает поверх HTTP и передаёт данные в формате XML. Технология появилась в конце 1990-х, задолго до REST API, и WordPress унаследовал её на заре своего развития. Файл xmlrpc.php в корне сайта принимает XML-запросы, обрабатывает их и возвращает ответ, например, публикует пост, загружает медиафайл или проверяет права пользователя.

На практике через xmlrpc.php работают несколько сценариев:

• Пингбеки и трекбеки. Когда кто-то ссылается на ваш пост, его сайт отправляет XML-RPC-запрос с уведомлением. Ваш WordPress проверяет ссылку и, если она реальна, добавляет пингбек в комментарии.

• Удалённая публикация. Приложения вроде старого Windows Live Writer или desktop-клиенты (TextMate, MarsEdit) использовали XML-RPC для написания и отправки постов без захода в админку.

• Мобильное приложение WordPress. Официальное приложение для iOS и Android долгое время полагалось на XML-RPC, хотя сейчас всё активнее переходит на REST API.

• Интеграции. Сервисы вроде Jetpack (часть функциональности), IFTTT и некоторые SEO-инструменты до сих пор используют XML-RPC для соединения с сайтом.

С выходом WordPress REST API в версии 4.7 (декабрь 2016) большинство современных интеграций переехало на новый протокол. REST API быстрее, работает с JSON вместо XML и лучше документирован. Тем не менее WordPress до сих пор включает xmlrpc.php в каждую установку, ради обратной совместимости.

Важный нюанс: начиная с WordPress 2.6 (ещё в 2008 году) функциональность удалённой публикации через XML-RPC отключена по умолчанию. Чтобы включить её, нужно явно поставить галочку в «Настройки → Написание». Пингбеки и трекбеки при этом продолжают работать.

Чем опасен xmlrpc.php: три главных вектора атак

Разработчики WordPress не раз латали xmlrpc.php. В версии 2.1.2 аутентифицированный пользователь с правами «участника» мог опубликовать пост в обход ограничений. В 2.3.1 обнаружили утечку информации через XML-RPC. Обе дыры быстро закрыли, но сам протокол остался архитектурно уязвимым для трёх классов атак, актуальных и в 2026 году.

Brute-force-амплификация через system.multicall

Главная проблема, метод system.multicall. Он позволяет упаковать в один HTTP-запрос множество вызовов wp.getUsersBlogs. Каждый вызов проверяет пару «логин + пароль». Так, вместо одного угадывания за запрос атакующий делает сотни. Cloudflare фиксировал пики в десятки тысяч таких запросов за час на одном сайте.

Обычная форма входа wp-login.php ограничена одним логином за попытку и легко защищается плагином вроде Wordfence или Limit Login Attempts. xmlrpc.php обходит все эти лимитеры, потому что работает через другой эндпоинт.

Pingback-DDoS

Функция пингбеков задумана как безобидное уведомление. Но злоумышленник может отправить поддельный pingback-запрос от имени сотен сайтов, и ваш сервер пойдёт проверять каждую «ссылку», нагружая процессор, сеть и базу данных. При достаточном масштабе сайт ложится. Sucuri в отчёте за 2023 год называет pingback-атаки одним из самых распространённых DDoS-векторов против WordPress.

Сканирование каталогов ботами

Боты ищут xmlrpc.php не только в корне, но и по выдуманным поддиректориям вроде /2026/01/xmlrpc.php и /blog/xmlrpc.php. Каждый такой запрос возвращает 404 и тратит ресурсы сервера. Даже если атака не удалась, десятки тысяч мусорных запросов замедляют сайт и забивают логи. На практике владельцы видят, как graphing в cPanel уходит в красную зону, а причина именно в ботах, сканирующих xmlrpc.php.

5 способов отключить или обезопасить xmlrpc.php

Ниже, пять методов, от самого простого до наиболее радикального. Выбирайте под свою ситуацию: пользуетесь ли вы мобильным приложением, нужны ли пингбеки, какой у вас хостинг.

1. Отключить через плагин

Самый безопасный путь для тех, кто не хочет трогать код. Установите плагин, и он перекроет доступ к xmlrpc.php на уровне WordPress, до того как начнётся обработка запроса.

Плюсы: не нужно править .htaccess или functions.php; легко включить обратно. Минусы: добавляет ещё один плагин в админку; при деактивации защита снимается.

Пара проверенных вариантов:

• Disable XML-RPC, минималистичный, одно действие: активировали, и доступ закрыт. Никаких настроек.
• Wordfence Security, комплексный брандмауэр, в котором отключение XML-RPC, лишь одна из функций. Подойдёт, если вы уже пользуетесь Wordfence или планируете установить.

2. Заблокировать через.htaccess

Если вы работаете на Apache-сервере, файл .htaccess в корне сайта позволяет перекрыть доступ раньше, чем запрос дойдёт до WordPress. Это снижает нагрузку: Apache возвращает 403 Forbidden сразу, без запуска PHP.

Добавьте в .htaccess следующий блок в начало файла, до # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

Директива RedirectMatch 403 ловит любой URL, оканчивающийся на /xmlrpc.php, включая поддиректории вроде /2025/06/xmlrpc.php, и мгновенно возвращает 403.

Плюсы: не трогает код WordPress; работает до загрузки PHP, экономит ресурсы. Минусы: нужно править .htaccess руками; при смене хостинга или темы файл может перезаписаться.

Важно: перед правкой .htaccess сделайте резервную копию. Ошибка в синтаксисе .htaccess может положить сайт (ошибка 500 Internal Server Error).

3. Убрать ссылки через functions.php

Этот метод не блокирует сам файл, а убирает HTML-ссылки на xmlrpc.php и wlwmanifest.xml из секции <head> сайта. Польза, снижение заметности: боты, парсящие HTML, не видят прямого указания на XML-RPC-эндпоинт.

Добавьте в functions.php активной темы (или через плагин Code Snippets):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

Хук rsd_link выводит <link rel="EditURI">, ссылку на xmlrpc.php для клиентов Really Simple Discovery. Хук wlwmanifest_link, для Windows Live Writer (давно не поддерживается, но WordPress до сих пор его выводит).

Плюсы: чистый <head> без мусорных ссылок. Минусы: xmlrpc.php физически остаётся доступным по прямому URL; это не блокировка, а маскировка.

4. Закрыть доступ через WAF или Cloudflare

Web Application Firewall (брандмауэр уровня веб-приложений) блокирует запросы к xmlrpc.php ещё до того, как они достигают вашего сервера. Это самый эффективный подход для сайтов на любом хостинге.

Варианты настройки:

• Cloudflare (бесплатный тариф): Правило WAF → Block → поле URI Path содержит /xmlrpc.php. Запрос отбивается на уровне сети Cloudflare, ваш сервер его даже не видит.
• Wordfence WAF: Встроенная функция «Disable XML-RPC» в разделе брандмауэра.
• Хостинговые WAF: Kinsta, WP Engine и другие управляемые хостеры дают отключить XML-RPC в пару кликов через панель управления.

Плюсы: нулевая нагрузка на сервер; можно тонко настроить (например, разрешить Jetpack, заблокировав всё остальное). Минусы: требуется настройка на стороне WAF; не все хостинги предоставляют такую возможность.

5. Удалить или переименовать сам файл

Самый радикальный метод. Вы удаляете (или переименовываете) файл xmlrpc.php с сервера. Если файла физически нет, обрабатывать запросы нечему, сервер возвращает 404.

Важный нюанс: при следующем обновлении WordPress файл восстановится. Автоматические обновления ядра перезаписывают все файлы WordPress, включая xmlrpc.php. Поэтому удаление, временная мера, если только вы не настроите регулярную очистку.

Если вы идёте этим путём, дополните удаление правилом .htaccess из способа 2. Без него боты продолжат стучаться по URL xmlrpc.php, и сервер будет честно возвращать 404 на каждый запрос, тысячи ошибок в логах.

А стоит ли вообще отключать xmlrpc.php?

Ответ зависит от того, чем вы пользуетесь. Пройдитесь по чек-листу:

Если вы не пользуетесь мобильным приложением старой версии, не включали Jetpack-управление с WordPress.com и вам не критичны пингбеки, смело отключайте. В 2026 году REST API покрывает практически все реальные сценарии.

Видео: как отключить XML-RPC в WordPress за 5 минут

Посмотрите наглядную инструкцию по отключению xmlrpc.php, с демонстрацией экрана и пояснением каждого метода:

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

Безопасно ли просто игнорировать xmlrpc.php?

В большинстве случаев, нет. Даже если вы не используете XML-RPC, боты сканируют этот эндпоинт постоянно. Каждый такой запрос нагружает сервер. Лучше явно закрыть доступ через .htaccess или плагин, это убирает и риск brute-force, и мусорные запросы в логах.

Сломается ли сайт, если отключить xmlrpc.php?

Сам WordPress продолжит работать без изменений. Проверьте только, не используете ли вы Jetpack-управление с WordPress.com или мобильное приложение старой версии. Если нет, отключайте без опасений. Пингбеки перестанут приходить, но большинство сайтов их и так не используют для реальной коммуникации.

Как проверить, что xmlrpc.php действительно заблокирован?

Откройте в браузере https://ваш-сайт.ru/xmlrpc.php. Если видите белый экран с сообщением «XML-RPC server accepts POST requests only», файл жив и отвечает. Если получаете 403 Forbidden или 404 Not Found, блокировка работает. Для автоматического мониторинга можно использовать онлайн-чекеры вроде xmlrpc.eror.xyz или curl-запрос из консоли.

Что лучше: плагин или.htaccess?

.htaccess блокирует запрос до запуска WordPress, это экономит ресурсы сервера. Плагин проще установить и не требует правки файлов. Для некритичных сайтов разницы почти нет. Для высоконагруженных проектов предпочтительнее .htaccess или WAF-правило.

Нужно ли обновлять WordPress после отключения xmlrpc.php?

Нет. Отключение xmlrpc.php не зависит от версии WordPress и не влияет на обновления ядра. Единственный нюанс: если вы удалили файл физически, обновление восстановит его, потребуется повторное удаление.

Так что же делать с xmlrpc.php на вашем сайте?

Универсального ответа нет, всё решает контекст. Но практика тысяч сайтов на WordPress даёт чёткую картину: если вы не знаете, нужен ли вам XML-RPC, он вам не нужен.

Хотите надёжности без погружения в код, поставьте Disable XML-RPC. Готовы потратить пять минут на .htaccess, получите защиту на уровне сервера, без лишних плагинов. Пользуетесь Cloudflare, настройте правило WAF и забудьте о проблеме.

Главное, не оставляйте xmlrpc.php открытым «по умолчанию». В 2026 году каждый незакрытый эндпоинт WordPress, это цель для автоматических ботов, которым всё равно, блог у вас или интернет-магазин. Закройте доступ одним из способов выше, проверьте результат curl-запросом и спите спокойно.