Як увімкнути та вимкнути xmlrpc.php у WordPress (і чому це важливо)

Файл xmlrpc.php є основним компонентом WordPress, який надає кінцеву точку XML-RPC API, дозволяючи віддаленим застосункам автентифікуватися та виконувати серверні операції — публікувати записи, керувати коментарями, надсилати пінгбеки тощо. Оскільки він за замовчуванням приймає неавтентифіковані POST-запити та обробляє їх до активації більшості рівнів безпеки, він є однією з найчастіше використовуваних поверхонь атаки в будь-якій інсталяції WordPress.

Якщо ви не використовуєте мобільний застосунок WordPress, Jetpack або будь-який сторонній сервіс, який явно вимагає XML-RPC, вимкнення xmlrpc.php є правильною стандартною позицією безпеки. Якщо ви покладаєтесь на ці інтеграції, ви можете посилити захист кінцевої точки замість того, щоб повністю її видаляти.

Що таке xmlrpc.php і як він працює

XML-RPC (Extensible Markup Language Remote Procedure Call) — це протокол, який кодує виклики функцій у XML та передає їх через HTTP. WordPress постачається з повноцінним XML-RPC сервером починаючи з версії 3.5, реалізованим у файлі xmlrpc.php, розташованому в кореневому каталозі WordPress.

Коли віддалений клієнт — мобільний застосунок, настільний клієнт для ведення блогу або скрипт автоматизації — надсилає POST-запит до https://yourdomain.com/xmlrpc.php, WordPress розбирає XML-навантаження, автентифікує облікові дані, вбудовані в тіло запиту, та виконує запитаний метод. Весь обмін відбувається за один HTTP-цикл запит-відповідь, що є одночасно його перевагою та фундаментальною слабкістю з точки зору безпеки.

Основні XML-RPC методи, що надаються WordPress

• wp.newPost / wp.editPost — створення та оновлення записів віддалено
• wp.getComments / wp.deleteComment — керування коментарями
• wp.uploadFile — завантаження медіафайлів на сервер
• pingback.ping — сповіщення віддаленого сайту про те, що на нього є посилання
• system.multicall — об’єднання кількох викликів методів в один HTTP-запит

Метод system.multicall є особливо небезпечним. Один HTTP-запит може містити сотні викликів wp.getUsersBlogs, кожен з яких перевіряє інший пароль. Це дозволяє зловмиснику виконувати тисячі спроб автентифікації, генеруючи лише один запис у журналі сервера, обходячи інструменти обмеження частоти запитів, які підраховують окремі запити.

Ризики безпеки при увімкненому xmlrpc.php

Підсилення брутфорс-атак через system.multicall

Традиційні брутфорс-атаки надсилають одну пару облікових даних на HTTP-запит. З XML-RPC зловмисник упаковує 500 спроб входу в один запит system.multicall. Стандартне правило fail2ban або лічильник спроб входу бачить один запит; зловмисник отримує 500 спроб. Це не теоретичний ризик — це найпоширеніший XML-RPC-експлойт, що спостерігається на практиці.

DDoS-атака з підсиленням через пінгбеки

WordPress автоматично обробляє вхідні запити пінгбеків через xmlrpc.php. Зловмисник може надіслати спеціально сформований запит pingback.ping тисячам сайтів WordPress, наказуючи кожному надіслати HTTP-запит на одну URL-адресу жертви. Жертва отримує масований потік запитів, що надходять від легітимних серверів WordPress, що робить блокування на основі IP неефективним. Ваш сервер одночасно стає жертвою (виснаження ресурсів) і мимовільним підсилювачем атаки.

SSRF через пінгбек

Механізм пінгбеків може бути використаний для підробки запитів на стороні сервера (SSRF). Зловмисник надсилає запит pingback.ping, де вихідна URL-адреса вказує на ресурс внутрішньої мережі — наприклад, http://192.168.1.1/admin. Сервер WordPress отримує цю URL-адресу зсередини мережевого периметра, потенційно розкриваючи внутрішні сервіси, які не є публічно маршрутизованими.

Розкриття облікових даних під час передачі

XML-RPC передає облікові дані в тілі POST-запиту як відкритий текст у межах XML-конверта. Якщо ваш сайт не примусово використовує HTTPS, облікові дані доступні будь-якому спостерігачеві в мережі. Навіть при використанні TLS облікові дані вбудовані в кожен окремий запит — немає сесійного токена або потоку OAuth для обмеження вікна розкриття.

Коли слід залишити xmlrpc.php увімкненим

Вимикайте його за замовчуванням, але залишайте увімкненим, якщо ваш робочий процес дійсно залежить від будь-якого з наступного:

• Мобільний застосунок WordPress (iOS/Android): Офіційний застосунок використовує XML-RPC для всіх операцій керування сайтом на самостійно розміщених інсталяціях WordPress.
• Плагін Jetpack: Кілька модулів Jetpack — включаючи publicize, мобільні push-сповіщення та деякі функції статистики — спілкуються через XML-RPC з серверами WordPress.com.
• Настільні клієнти для ведення блогу: MarsEdit, Windows Live Writer та подібні інструменти покладаються виключно на XML-RPC API.
• Автоматизовані конвеєри публікацій: IFTTT, Zapier та власні скрипти, що публікують контент у WordPress, часто використовують XML-RPC, коли REST API не налаштований.
• Пінгбеки/трекбеки між сайтами WordPress: Якщо міжсайтові сповіщення пінгбеків є частиною вашого редакційного процесу, вимкнення xmlrpc.php заглушить їх.

Якщо жодне з перерахованого не стосується вас, немає операційних причин залишати кінцеву точку відкритою.

xmlrpc.php проти WordPress REST API

WordPress представив REST API у версії 4.7 як сучасну заміну XML-RPC на основі токенів. Розуміння відмінностей допомагає вирішити, чи порушить вимкнення XML-RPC щось критичне.

Якщо ви створюєте нову інтеграцію або переносите існуючу, використовуйте REST API. Модель автентифікації значно безпечніша, а кінцеву точку набагато легше перевіряти та обмежувати на рівні інфраструктури.

Як вимкнути xmlrpc.php у WordPress

Оберіть метод, що відповідає вашому рівню доступу до сервера та допустимому ризику. Методи впорядковані від найнижчого до найвищого рівня примусового виконання на рівні сервера.

Метод 1: Вимкнення через плагін (найшвидший, не потребує доступу до сервера)

Для середовищ спільного хостингу або сайтів, де ви не хочете редагувати файли конфігурації сервера, плагін є найдоступнішим варіантом.

Рекомендовані плагіни:

• Disable XML-RPC-API — однофункціональний, мінімальний розмір, активується миттєво
• All In One WP Security and Firewall — ширший пакет безпеки з гранульованим керуванням XML-RPC

Кроки для Disable XML-RPC-API:

1. Перейдіть до Плагіни > Додати новий у панелі керування WordPress.
2. Знайдіть “Disable XML-RPC-API” та натисніть Встановити зараз, потім Активувати.
3. Подальше налаштування не потрібне — плагін підключається до xmlrpc_enabled та негайно повертає false після активації.

Кроки для All In One WP Security and Firewall:

1. Після активації плагіна перейдіть до WP Security > Firewall.
2. Знайдіть розділ XML-RPC.
3. Увімкніть опцію повного блокування XML-RPC запитів.
4. Збережіть налаштування.

Обмеження: Блокування на основі плагіна спрацьовує в контексті виконання PHP WordPress. Сервер все одно запускає PHP, завантажує WordPress та обробляє запит перед його відхиленням. Під час масованої атаки це споживає CPU та пам’ять. Для сайтів з великим трафіком під активною атакою натомість використовуйте метод .htaccess або Nginx.

Метод 2: Вимкнення через .htaccess (Apache — блокування на рівні сервера)

Блокування на рівні .htaccess запобігає виконанню PHP для запитів, спрямованих на xmlrpc.php. Це значно ефективніше під навантаженням.

1. Підключіться до вашого сервера через FTP, SFTP або файловий менеджер хостингу та відкрийте файл .htaccess у кореневому каталозі WordPress (зазвичай public_html/.htaccess).
2. Додайте наступний блок. Розмістіть його перед стандартними правилами перезапису WordPress:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Збережіть файл.

Щоб перевірити, чи активне блокування, виконайте тест з вашого локального комп’ютера:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Ви повинні отримати відповідь 403. Відповідь 200 або 405 означає, що блокування ще не набрало чинності.

Граничний випадок — якщо вам все ще потрібні пінгбеки з певних довірених IP-адрес, ви можете додати їх до білого списку:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Метод 3: Вимкнення через конфігурацію Nginx

Якщо ваш сервер працює на Nginx (поширено в середовищах VPS Хостингу), файли .htaccess не мають ефекту. Додайте блок безпосередньо до конфігурації серверного блоку вашого сайту.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

Директива return 444 закриває TCP-з’єднання без надсилання HTTP-відповіді, що є ефективнішим, ніж 403, оскільки запобігає отриманню зловмисником будь-якого зворотного зв’язку. Після редагування перезавантажте Nginx:

sudo nginx -t && sudo systemctl reload nginx

Розмістіть цей блок location всередині вашого блоку server {}, перед будь-якими директивами try_files або обробки PHP.

Метод 4: Вимкнення через functions.php (хук фільтра WordPress)

Цей метод використовує фільтр WordPress для вимкнення XML-RPC на рівні застосунку. Він менш ефективний, ніж блокування на рівні сервера, але корисний, коли у вас немає прямого доступу до сервера і ви хочете рішення на основі коду без залежності від плагіна.

1. Перейдіть до Зовнішній вигляд > Редактор тем у панелі керування WordPress або отримайте доступ до файлу безпосередньо через SFTP за адресою wp-content/themes/your-theme/functions.php.
2. Додайте наступне в кінець файлу:

// Disable XML-RPC completely
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Збережіть файл.

Важливе застереження: Цей фільтр вимикає автентифіковані методи XML-RPC, але не блокує метод pingback.ping і не запобігає доступу до файлу. Сервер все одно обробляє запит до моменту, коли WordPress оцінює фільтр. Для повного захисту поєднайте це з блоком .htaccess або Nginx.

Якщо ви використовуєте дочірню тему, завжди додавайте власний код до файлу functions.php дочірньої теми, а не батьківської. Оновлення батьківської теми перезапишуть ваші зміни.

Метод 5: Вибіркове вимкнення — блокування лише пінгбеків

Якщо вам потрібен XML-RPC для Jetpack або мобільної публікації, але ви хочете усунути вектор підсилення DDoS, ви можете вимкнути лише метод пінгбеків, залишивши решту API функціональною.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Додайте це до файлу functions.php вашої дочірньої теми або до плагіна для конкретного сайту. Це рекомендована конфігурація для сайтів, що використовують Jetpack, але не потребують отримання пінгбеків.

Як повторно увімкнути xmlrpc.php

Скасування будь-якого з вищезазначених методів відновлює доступ до XML-RPC:

• Метод плагіна: Деактивуйте або видаліть блокувальний плагін у розділі Плагіни > Встановлені плагіни.
• Метод .htaccess: Видаліть блок <Files "xmlrpc.php"> з .htaccess та збережіть.
• Метод Nginx: Видаліть блок location = /xmlrpc.php з конфігурації вашого сервера та перезавантажте Nginx командою sudo systemctl reload nginx.
• Метод functions.php: Видаліть рядок add_filter( 'xmlrpc_enabled', '__return_false' ) та збережіть.

Після повторного увімкнення перевірте, чи кінцева точка відповідає правильно:

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

Дійсна XML-відповідь із переліком доступних методів підтверджує, що кінцева точка активна.

Посилення захисту xmlrpc.php без його вимкнення

Якщо вимкнення неможливе, застосуйте ці заходи для зменшення поверхні атаки:

Примусово використовуйте HTTPS: Переконайтеся, що ваш сайт використовує дійсний TLS-сертифікат. Якщо ви ще цього не зробили, налаштуйте його через свого хостинг-провайдера — SSL Сертифікати запобігають перехопленню облікових даних під час передачі.

Обмежте частоту запитів на рівні брандмауера або CDN: Налаштуйте ваш WAF (Cloudflare, ModSecurity) для обмеження POST-запитів до xmlrpc.php до максимум 5–10 на хвилину на IP.

Заблокуйте system.multicall конкретно:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Це усуває вектор підсилення брутфорсу, зберігаючи всю іншу функціональність XML-RPC.

Обмежте доступ за IP: Якщо ви звертаєтесь до XML-RPC лише з відомих IP-адрес (діапазон IP вашого мобільного застосунку або статичний офісний IP), додайте ці адреси до білого списку в .htaccess або Nginx та заблокуйте всі інші.

Моніторинг журналів доступу: Регулярно перевіряйте журнали сервера на наявність повторних POST-запитів до xmlrpc.php. Стрибок у кількості POST-запитів зі статусом 200 до цього файлу є надійним індикатором поточної брутфорс-кампанії.

На VPS з cPanel або іншому середовищі з керованою панеллю ви можете налаштувати правила ModSecurity безпосередньо з панелі керування для застосування цих обмежень без ручного редагування файлів.

Вибір правильного методу: матриця рішень

Для виробничих сайтів, розміщених на Виділених серверах, блокування на рівні сервера Nginx або Apache завжди є кращим за рішення на основі плагіна, оскільки воно повністю запобігає виконанню PHP для шкідливих запитів, усуваючи навантаження на CPU, яке виникає при блокуванні через плагін під час тривалої атаки.

Практичний контрольний список ключових висновків

• Перевірте, чи будь-який активний плагін або сервіс у вашому стеку дійсно вимагає XML-RPC перед його вимкненням — перевірте Jetpack, мобільні застосунки та будь-які інструменти автоматизації публікацій.
• Якщо залежностей немає, застосуйте блокування на рівні сервера (.htaccess або Nginx), а не плагін — це ефективніше та не залежить від деактивації плагіна.
• Якщо вам необхідно залишити XML-RPC активним, безумовно видаліть system.multicall та pingback.ping через фільтр xmlrpc_methods — ці два методи є причиною переважної більшості зловживань XML-RPC.
• Завжди примусово використовуйте HTTPS на будь-якому сайті WordPress, що приймає автентифіковані запити, включаючи XML-RPC.
• Після застосування будь-якого блокування перевірте за допомогою curl, що кінцева точка повертає 403 або скидає з’єднання — не припускайте, що конфігурація правильна без тестування.
• У середовищах VPS або виділених серверів на основі Nginx використовуйте return 444 замість deny all, щоб не надавати зловмисникам жодного зворотного зв’язку на рівні HTTP.
• Реєструйте та відстежуйте POST-запити до xmlrpc.php — раптовий стрибок є раннім попередженням про кампанію підбору облікових даних або підсилення DDoS.
• Якщо ви керуєте кількома сайтами WordPress, розгляньте можливість централізації цієї конфігурації на рівні сервера або CDN, а не застосування правил плагінів для кожного сайту окремо.

Для сайтів, яким потрібне надійне віддалене керування без ризиків XML-RPC, перенесення інтеграцій на WordPress REST API з паролями застосунків є правильним довгостроковим шляхом. REST API забезпечує відкликання окремих токенів, обмежені дозволи та стандартну семантику HTTP, яку набагато легше захистити та перевірити.

Якщо ви налаштовуєте нове середовище WordPress і хочете мати чисту, безпечну базову конфігурацію з самого початку, Панелі керування VPS з попередньо налаштованим ModSecurity забезпечують захист WAF на рівні сервера без необхідності ручного написання правил.

—

Часті запитання

Чи порушить вимкнення xmlrpc.php роботу WordPress REST API?

Ні. REST API (/wp-json/) є повністю окремою кінцевою точкою з власною автентифікацією та маршрутизацією. Блокування xmlrpc.php не має жодного впливу на функціональність REST API. Ці дві системи є архітектурно незалежними.

Чи порушить вимкнення xmlrpc.php роботу Jetpack?

Це залежить від того, які модулі Jetpack ви використовуєте. Jetpack поступово переносить функції на REST API, але деякі старіші модулі — включаючи певні функції publicize та сповіщень — все ще спілкуються через XML-RPC. Перевірте сторінку налагодження Jetpack у розділі Jetpack > Dashboard > Debug, щоб дізнатися, чи підключення XML-RPC вказане як вимога, перш ніж вимикати його.

Який метод безпечніший — .htaccess чи functions.php?

Метод .htaccess значно безпечніший в умовах атаки. Він блокує запит на рівні веб-сервера до завантаження PHP, споживаючи мінімальні ресурси. Фільтр functions.php спрацьовує в контексті виконання PHP WordPress, тобто сервер все одно завантажує WordPress для кожного заблокованого запиту — що є дорогим при масованій атаці.

Чи може зловмисник все ще використовувати xmlrpc.php, якщо я вимкну його лише через фільтр WordPress?

Частково. Фільтр xmlrpc_enabled запобігає автентифікованим викликам методів, але файл залишається публічно доступним і сервер все одно обробляє вхідні запити. Кінцева точка пінгбеків може залишатися частково функціональною залежно від версії WordPress. Для повного захисту поєднайте фільтр із блокуванням на рівні сервера.

Як перевірити, чи доступний xmlrpc.php на моєму сайті зараз?

Виконайте наступну команду у вашому локальному терміналі, замінивши домен на свій:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Відповідь 200 означає, що кінцева точка відкрита. Відповідь 403 або скидання з’єднання (000) підтверджує, що вона заблокована. Ви також можете скористатися онлайн-інструментом на xmlrpc.eritreo.it для перевірки вразливості пінгбеків зокрема.