XML-RPC WordPress

До появления REST API это был единственный стандартный способ работать с WordPress без браузера. Через XML-RPC писали посты из настольных редакторов вроде Windows Live Writer, из первых мобильных приложений, принимали уведомления pingback от других блогов. Помимо собственных методов wp.* файл понимает старые интерфейсы Blogger API, metaWeblog и Movable Type, поэтому с ним совместимы программы, написанные ещё под другие блог-платформы.

Каждый вызов — это POST-запрос на /xmlrpc.php с XML-документом внутри. Логин и пароль передаются прямо в теле запроса, без отдельного токена.

Как выглядит вызов

<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value><string>admin</string></value></param>
    <param><value><string>пароль</string></value></param>
  </params>
</methodCall>

Ответ тоже приходит в XML: список сайтов пользователя или ошибка авторизации.

Почему его закрывают

Именно этот формат сделал xmlrpc.php любимой мишенью ботов. Метод system.multicall позволяет уложить сотни попыток входа в один запрос, и защита от перебора на странице входа его не видит. Pingback злоумышленники использовали, чтобы заставить тысячи сайтов одновременно обращаться к жертве. Если сайту протокол не нужен, его лучше выключить. Фильтр add_filter( 'xmlrpc_enabled', '__return_false' ); отключает только методы с авторизацией, поэтому надёжнее закрыть файл на уровне веб-сервера:

location = /xmlrpc.php {
    deny all;
}

Что проверить перед отключением

Некоторые сервисы до сих пор опираются на XML-RPC: старые версии Jetpack, отдельные десктопные редакторы, интеграции с внешними системами публикации. Современные инструменты переходят на REST-интерфейс и пароли приложений. Перед блокировкой стоит посмотреть журнал доступа: если запросы к /xmlrpc.php приходят только с незнакомых адресов, файл можно смело закрывать. После взлома это одна из первых точек, которые проверяют при восстановлении сайта на WordPress.