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

Файл xmlrpc.php, тихий, але надзвичайно небезпечний елемент будь-якої інсталяції WordPress. Він живе в корені вашого сайту з моменту встановлення CMS і десятиліттями залишається улюбленою точкою входу для ботів і зловмисників. За даними звіту Wordfence за 2024 рік, атаки через XML-RPC входять до п'ятірки головних векторів загроз для WordPress-сайтів, і в 2026 році нічого не змінилося.

При цьому більшість власників сайтів гадки не мають, навіщо цей файл взагалі існує і як його знешкодити. У цьому посібнику, чотири робочі способи заблокувати xmlrpc.php, від швидкого правила в .htaccess до фаєрволу рівня CDN. Без води, з перевіреним кодом і поясненням, який метод коли застосовувати.

💡 Швидкий огляд:

• Перевірте, чи відповідає ваш xmlrpc.php на POST-запити, скоріш за все, відповідає
• Виберіть спосіб блокування: htaccess, код у functions.php, плагін або WAF
• Додайте правило блокування і переконайтеся, що endpoint повертає 403 Forbidden
• Якщо користуєтеся Jetpack, налаштуйте точковий захист через фаєрвол замість повного вимкнення

Що таке xmlrpc.php і чому він досі у WordPress

XML-RPC (Remote Procedure Call), протокол, що дає змогу зовнішнім застосункам спілкуватися з WordPress. Він з'явився в ядрі ще у версії 1.5 і десятиліттями слугував єдиним API для віддаленої публікації: через нього працювали мобільні застосунки WordPress, десктопні клієнти на кшталт Windows Live Writer і сторонні сервіси.

З виходом WordPress REST API у версії 4.7 (2016 рік) потреба в XML-RPC практично відпала. Сучасний REST API покриває все, що раніше робив XML-RPC, і робить це безпечніше, швидше та з нормальною автентифікацією через nonce або OAuth.

Але файл xmlrpc.php досі лежить у корені кожної інсталяції WordPress. За замовчуванням віддалену публікацію через нього вимкнено, однак сам endpoint приймає запити. Достатньо відкрити вашсайт.com/xmlrpc.php у браузері, щоб побачити: «XML-RPC server accepts POST requests only». Це означає, що endpoint живий і готовий до атаки.

Чому xmlrpc.php небезпечний: головні вектори атак

Зловмисники використовують xmlrpc.php для двох основних типів атак, і обидва можуть покласти ваш сайт.

Brute force через system.multicall. Метод system.multicall дає змогу запакувати в ОДИН HTTP-запит сотні спроб авторизації. Замість того щоб перебирати паролі по одному (як через wp-login.php), бот надсилає масив логінів і паролів разом. Звичайні плагіни обмеження спроб входу (login limiters) такий запит не бачать, для них це «одна спроба». Результат: зловмисник перебирає тисячі комбінацій за секунди, не потрапляючи під блокування.

Pingback DDoS. Функція пінгбеків дає змогу іншому сайту повідомити ваш WordPress про посилання на нього. Зловмисник надсилає підроблений пінгбек-запит, підставляючи як «джерело» IP-адресу жертви. Ваш сервер чесно йде перевіряти посилання й атакує цільовий хост, який нічого не підозрює. Масштабуйте це на тисячі скомпрометованих WordPress-інсталяцій, виходить розподілена DDoS-атака, де ваш сайт виступає гарматним м'ясом.

Хостинг-провайдери відстежують вихідний трафік такого роду і можуть заморозити акаунт за «участь у DDoS». А сам сервер у цей час витрачає процесор, пам'ять і bandwidth на обслуговування сміттєвих запитів.

Перевірте: чи відповідає ваш xmlrpc.php

Перед тим як блокувати, переконайтеся, що endpoint справді відкритий. Відкрийте в браузері:

1
https://вашсайт.com/xmlrpc.php

Якщо бачите рядок «XML-RPC server accepts POST requests only», endpoint живий, і зловмисники можуть надсилати на нього запити. Якщо отримуєте 403 Forbidden або 404, захист уже працює.

Другий спосіб, надіслати тестовий POST-запит через термінал:

1
curl -X POST https://вашсайт.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Відповідь із 200 OK і XML-структурою підтверджує: XML-RPC приймає запити і готовий до експлуатації.

Спосіб 1: швидке блокування через.htaccess

Найпростіший і найдієвіший метод, заблокувати доступ до файлу на рівні вебсервера. Запит відкидається до того, як доходить до WordPress — це економить ресурси сервера і працює, навіть якщо сайт лежить під навантаженням.

Додайте в кореневий .htaccess (той, що поруч із wp-config.php):

1
Блокировка xmlrpc.php — защита от brute force и DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Директива Require all denied, синтаксис Apache 2.4+, актуальний для всіх сучасних хостингів. Після збереження відкрийте xmlrpc.php у браузері, маєте отримати 403 Forbidden.

Якщо сервер на nginx, правило додається в конфіг віртуального хоста:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Після зміни конфіга nginx не забудьте перезавантажити сервер: sudo nginx -s reload.

Цей метод підходить, якщо вам ТОЧНО не потрібен XML-RPC, ні для Jetpack, ні для мобільних застосунків WordPress, ні для WooCommerce-інтеграцій.

Спосіб 2: вимкнення через functions.php (програмний метод)

Якщо ви віддаєте перевагу розв'язанню проблеми на рівні коду, а не серверних конфігів, ось два перевірені сніпети для functions.php активної теми або Code Snippets.

Повне вимкнення XML-RPC (WP 3.5+):

1
// Отключить XML-RPC полностью
2
add_filter('xmlrpc_enabled', '__return_false');

Один рядок, і WordPress перестає обробляти будь-які XML-RPC запити. При спробі звернутися до xmlrpc.php клієнт отримає відповідь із помилкою, сам файл залишається на сервері, але функціонально мертвий.

Очищення заголовків wp_head від RSD і WLW-посилань:

Навіть після вимкнення XML-RPC WordPress продовжує вставляти в <head> два рядки, які видають інформацію про ваш сайт:

1
// Убрать ссылки RSD и WLW Manifest из заголовков
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Хуки rsd_link і wlwmanifest_link додають у <head> теги <link rel="EditURI"> і <link rel="wlwmanifest">, вони потрібні виключно для XML-RPC клієнтів і не несуть практичної користі у 2026 році. Прибираємо.

⚠️ Важливо: правки у functions.php теми злетять при оновленні. Використовуйте дочірню тему або плагін Code Snippets для постійного зберігання кастомного коду.

Спосіб 3: плагіни безпеки

Не хочете лізти в код, встановіть плагін. Три перевірені варіанти:

• Wordfence Security. Найпопулярніший WordPress-фаєрвол. Крім блокування XML-RPC, дає сканер шкідливого коду, захист логіну і моніторинг трафіку. У налаштуваннях Wordfence → Login Security → позначте «Disable XML-RPC authentication».

• Disable XML-RPC-API. Легкий плагін, який робить рівно одне: вішає фільтр xmlrpc_enabled і вимикає endpoint. Жодних додаткових налаштувань, активували й забули.

• iThemes Security (Solid Security). Комплексний плагін із модулем WordPress Tweaks, де XML-RPC вимикається однією галочкою. Заодно закриває інші вектори: зміну префікса таблиць, вимкнення редактора файлів з адмінки, захист від перебору паролів.

Після активації будь-якого з плагінів обов'язково перевірте, що xmlrpc.php повертає помилку, а не привітання.

Спосіб 4: блокування на рівні фаєрволу (Cloudflare / Sucuri)

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

Cloudflare** WAF.** Створіть кастомне правило: поле URI Path містить xmlrpc.php → дія Block. Запити фільтруються на рівні мережі Cloudflare (понад 330 точок присутності по світу), сервер їх навіть не бачить. У тарифі Free доступно 5 кастомних правил, цього достатньо. Бонус: Cloudflare показує статистику заблокованих запитів, і ви на власні очі побачите масштаб атак.

Sucuri Website Firewall. Аналогічний підхід, WAF правило на URI /xmlrpc.php. Sucuri також пропонує моніторинг цілісності файлів і автоматичне очищення від шкідливого коду.

Правило фаєрволу зручно поєднувати з .htaccess або програмним вимкненням: фаєрвол відсікає масове сміття, а локальний блок, запасний рубіж на випадок, якщо трафік з якоїсь причини обійшов WAF.

Що робити, якщо ви користуєтеся Jetpack

Jetpack від Automattic використовує XML-RPC для зв'язку вашого сайту з серверами WordPress.com. Якщо повністю вимкнути xmlrpc.php, Jetpack перестане працювати: статистика, підписки, CDN для зображень, модуль Related Posts і захист від brute force через Jetpack відваляться разом.

Рішення, не глушити XML-RPC цілком, а точково пропускати запити від серверів Jetpack:

• Залиште xmlrpc.php доступним (НЕ блокуйте через .htaccess і НЕ вішайте фільтр xmlrpc_enabled).

• Налаштуйте Cloudflare WAF так: дозволити запити до xmlrpc.php ТІЛЬКИ від IP-діапазонів Automattic (список оновлюється в документації Jetpack), решту блокувати.

• Як мінімум, приберіть RSD і WLW-заголовки сніпетом зі способу 2, щоб не світити endpoint у <head> без потреби.

• Встановіть Wordfence і увімкніть захист від brute force конкретно для xmlrpc.php, він не блокує легітимні запити Jetpack, але відсікає спроби підбору паролів.

⁉️🤔 Часті запитання

Чи можна просто видалити файл xmlrpc.php із сервера?

Можна, але це погана практика. При наступному оновленні WordPress файл відновиться, і ви знову вразливі. Краще заблокувати доступ через .htaccess або вимкнути функціональність фільтром у коді: ефект той самий, але оновлення ядра не зламають захист. Якщо все ж видалили файл, обов'язково приберіть rsd_link із wp_head, інакше відвідувачі отримають 404 при переході за посиланням EditURI.

Чи зламає вимкнення XML-RPC WooCommerce?

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

Як бути, якщо хостинг-провайдер сам блокує xmlrpc.php?

Якщо провайдер уже вимкнув XML-RPC на рівні сервера, вам нічого робити не потрібно, endpoint недоступний. Перевірте: відкрийте xmlrpc.php, якщо 403, захист працює. Єдине, що варто додати,, видалення RSD і WLW-заголовків через functions.php, тому що провайдер їх не чіпає.

Чи треба вимикати XML-RPC, якщо я сиджу на managed WordPress-хостингу?

Більшість managed-хостингів (Kinsta, WP Engine, SiteGround) блокують або жорстко обмежують xmlrpc.php на рівні платформи. Перевірте, чи відкритий endpoint через браузер. Якщо заблокований, додаткових дій не потрібно. Якщо відкритий, додайте .htaccess правило: managed-хостинги його не перезаписують.

Як дізнатися, що сайт атакують через xmlrpc.php прямо зараз?

Три ознаки: різкий стрибок навантаження на сервер при незмінному трафіку, сотні однотипних POST-запитів до xmlrpc.php у логах доступу та помилки перевищення лімітів пам'яті/процесора від хостинг-провайдера. Увімкніть моніторинг (Wordfence → Live Traffic або Cloudflare → Security Events), ви побачите джерело і масштаб атаки в реальному часі.

Чи варто вимикати xmlrpc.php у 2026 році

Коротка відповідь: так, якщо ви не користуєтеся Jetpack і не публікуєте пости через мобільний застосунок WordPress.

XML-RPC, спадщина епохи WordPress 1.5. REST API давно зайняв його місце, а сам xmlrpc.php перетворився на відкриті двері для brute force і DDoS-атак. Закрити їх, справа п'яти хвилин. Виберіть спосіб під свою ситуацію:

• Не хочете чіпати код, поставте Disable XML-RPC-API, два кліки.
• Є доступ до файлів сервера, додайте правило в .htaccess, серверний рівень надійніший.
• Любите чистоту в коді, скиньте фільтр xmlrpc_enabled і приберіть заголовки двома сніпетами в functions.php.
• Хочете максимум захисту, налаштуйте WAF-правило в Cloudflare і комбінуйте з локальним блоком.

Після блокування обов'язково перевірте, що xmlrpc.php повертає 403 Forbidden, і моніторте логи хоча б тиждень, ви здивуєтеся, скільки сміттєвого трафіку зникло. А заодно підпишіться на оновлення WordPress: історія показує, що старі протоколи вмирають повільно, і нові вразливості в XML-RPC можуть спливти й після 2026 року.