XML-RPC הוא ממשק API ישן של WordPress שמאפשר פעולות מרחוק (פרסום פוסט, ניהול תגובות, ועוד) דרך הקובץ /xmlrpc.php. ב-2026 כמעט אף אתר לא משתמש בו: האפליקציה הניידת של WordPress עברה ל-REST API ב-2018, ו-Jetpack תומך בשני המודלים. עם זאת, ה-endpoint נשאר פעיל בברירת מחדל בכל התקנת WordPress – ולכן הוא וקטור התקפה מועדף.
למה זה משנה
שלוש סכנות עיקריות: brute-force מסיבי דרך method בשם שיטות הגברת התקפה שמאפשר לבדוק התקפות בקצב גבוה שעוקפות מנגנוני הגנה רגילים. Pingback DDoS amplification: התקפה שבה תוקפים מנצלים את ה-method pingback.ping כדי לגרום לאתרי WordPress רבים לשלוח בקשות HTTP בו זמנית לקורבן. השרת שלך הופך לכלי תקיפה. פגיעויות עתידיות: לאורך השנים נמצאו ב-xmlrpc.php כמה CVE קריטיים (RCE, type confusion). כיוון שהקוד עתיק יחסית ולא נבדק תכופות, פגיעויות חדשות עדיין מתגלות.
איך לזהות
בדיקת זמינות:
curl -I https://example.com/xmlrpc.phpתגובה תקינה אם XML-RPC פעיל: HTTP/1.1 405 Method Not Allowed (כי זה GET ולא POST). אם אתה מקבל 200, זה גם פעיל. אם אתה מקבל 403 או 404 – חסום (טוב). בדיקה עמוקה:
curl -X POST -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' \
https://example.com/xmlrpc.phpאם מחזיר רשימת methods (wp.getUsersBlogs, שיטות הגברת התקפה...), XML-RPC פעיל ומסוכן.
איך לתקן
שכבה 1 – PHP filter (כיבוי לוגי בלבד):
// ב-functions.php או mu-plugin
add_filter('xmlrpc_enabled', '__return_false');
add_filter('pre_option_enable_xmlrpc', '__return_zero');זה לא מספיק – הקובץ עדיין רץ ב-PHP, רק שכל הפונקציות מבוטלות. לחסימה אמיתית, חסום ברמת השרת:
<Files xmlrpc.php>
Require all denied
</Files>location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}אם משתמשים ב-Jetpack ורוצים לשמור על integration ספציפי, התר רק את ה-IP-ים של Jetpack:
<Files xmlrpc.php>
Require ip 192.0.64.0/18
Require ip 76.74.255.0/24
</Files>טעויות נפוצות
טעות ראשונה: להפעיל רק את ה-PHP filter ולחשוב שהאתר מוגן. הקובץ עדיין נטען עם כל בקשה, צורך CPU, ופגיעות RCE עתידית עדיין תעבוד. החסימה האמיתית חייבת להיות ברמת השרת. טעות שנייה: לחסום בלי לבדוק. אם משתמשים ב-Jetpack בתצורה ישנה, ב-IFTTT integration, או באפליקציה ניידת ישנה של WordPress, החסימה תשבור אותם. ודא תחילה שאין תלות. טעות שלישית: לחסום רק /xmlrpc.php ולהתעלם מ-?rest_route=/wp/v2/.... אלה ערוצים נפרדים – שניהם דורשים טיפול. טעות רביעית: לסמוך על Wordfence "Login Security" כתחליף. Wordfence מגביל קצב על login, אבל שיטות הגברת התקפה יכול לעקוף את זה כי כל ניסיון נמנה כבקשה אחת ל-WAF.
בדיקה לאחר תיקון
הרץ curl -I https://example.com/xmlrpc.php – חייב להחזיר 403 או 404. הרץ את ה-curl POST מלמעלה – חייב להחזיר 403 או דף ריק, לא רשימת methods. אם משתמשים ב-Jetpack, פתח את לוח הבקרה > Jetpack > Modules ובדוק שהמודולים פעילים. אם הם בכחול עם "Connection broken", צריך להוסיף את ה-IP-ים של Jetpack ל-allowlist.