Кожен сайт на 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 або десктопні клієнти (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-запитом і спіть спокійно.