สรุปคำตอบ
XML-RPC คือระบบที่ให้โปรแกรมภายนอกเชื่อมต่อและสั่งงาน WordPress จากระยะไกลผ่านไฟล์ xmlrpc.php เดิมใช้กับแอปมือถือ Jetpack และระบบ Pingback แต่ปัจจุบัน WordPress มี REST API ที่ทำหน้าที่แทนได้ดีกว่า XML-RPC เปิดอยู่โดย default และถูกใช้ Brute Force ผ่าน system.multicall กับ DDoS ผ่าน Pingback ได้ ถ้าไม่ได้ใช้ Jetpack บางฟีเจอร์หรือเครื่องมือเก่าที่ยังพึ่งมันอยู่ ควรปิด โดยวิธีที่ดีที่สุดคือบล็อกผ่าน .htaccess หรือ Nginx config
XML-RPC เป็นโปรโตคอลเก่าแก่ที่ WordPress ใช้รับส่งข้อมูลจากระยะไกล โดยเปิดใช้งานเป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 3.5 และทุกวันนี้ xmlrpc.php เป็นเป้าหมาย brute force ที่พบบ่อยตามคู่มือ WordPress.org หลายเจ้าของเว็บไม่รู้ด้วยซ้ำว่าตัวเองเปิดใช้งานอยู่ บทความนี้จะอธิบายว่า XML-RPC คืออะไร ทำงานอย่างไร เสี่ยงแค่ไหน และควรปิดเมื่อไหร่
XML-RPC คืออะไร และทำงานอย่างไรใน WordPress
XML-RPC ย่อมาจาก XML Remote Procedure Call คือระบบที่อนุญาตให้โปรแกรมภายนอกเชื่อมต่อกับ WordPress ผ่านไฟล์ xmlrpc.php โดยส่งคำสั่งในรูปแบบ XML ผ่าน HTTP ในอดีตมันถูกใช้กับแอปบนมือถือ WordPress, Jetpack, Windows Live Writer รวมถึงระบบ pingback และ trackback เพื่อแจ้งเตือนเว็บอื่นว่ามีการอ้างอิงบทความ
ปัจจุบัน WordPress มี REST API ที่รองรับ Application Passwords สำหรับยืนยันตัวตนของระบบภายนอก (ตั้งแต่ WordPress 5.6) ทำให้ XML-RPC แทบไม่จำเป็นสำหรับเว็บทั่วไปอีกต่อไป
ทำไม XML-RPC ถึงเป็นความเสี่ยง
ปัญหาหลักของ XML-RPC คือมันเปิดประตูให้แฮกเกอร์โจมตีได้หลายรูปแบบ:
- n
- Brute Force ผ่าน multicall: XML-RPC มีเมธอด system.multicall ที่รวมหลายคำสั่งไว้ในคำขอ HTTP เดียว และ Sucuri รายงานว่าเคยพบการเดารหัสหลายร้อยรหัสในคำขอเดียว แฮกเกอร์จึงเลี่ยงเครื่องมือที่นับความพยายามล็อกอินต่อคำขอได้ และทดสอบรหัสผ่านได้เร็วกว่าการยิงหน้า wp-login.php ทีละครั้ง อ่านเพิ่มเติมเรื่อง Brute Force Attack WordPress คืออะไรและวิธีป้องกัน
- DDoS ผ่าน Pingback: แฮกเกอร์ใช้ฟีเจอร์ pingback ของ XML-RPC เพื่อสั่งให้เว็บ WordPress จำนวนมากส่ง request ไปยังเป้าหมายพร้อมกัน (ครั้งหนึ่ง Sucuri พบเว็บถูกใช้มากกว่า 162,000 เว็บในเหตุการณ์เดียวเมื่อปี 2014) ทำให้เว็บเป้าหมายล่ม
- ยืนยันตัวตนด้วย credential ล้วน ๆ: ทุกการเรียกใช้ XML-RPC ต้องส่ง username และ password ในทุก request ซึ่งเพิ่มความเสี่ยงหาก credential รั่วไหล
n
n
ความเสี่ยงเหล่านี้เป็นส่วนหนึ่งของ Checklist ความปลอดภัย WordPress ที่เจ้าของเว็บควรตรวจสอบเป็นประจำ
วิธีตรวจสอบว่าเว็บเปิด XML-RPC อยู่หรือไม่
สามารถตรวจสอบได้หลายวิธี:
- n
- เปิดเบราว์เซอร์แล้วไปที่
https://yoursite.com/xmlrpc.php— ถ้าเห็นข้อความ “XML-RPC server accepts POST requests only” แสดงว่าเปิดใช้งานอยู่ - ใช้เครื่องมือสแกนอย่าง WPScan ตรวจสอบ endpoint
- ดู access log ของ server ค้นหา request ที่ส่งไป
xmlrpc.phpจำนวนมากผิดปกติ
n
n
วิธีปิด XML-RPC ใน WordPress ทีละขั้นตอน
มีหลายวิธีปิด XML-RPC ขึ้นอยู่กับสิทธิ์การเข้าถึง server ของคุณ:
วิธีที่ 1: ปิดผ่าน Plugin
ติดตั้ง plugin ชื่อ Disable XML-RPC หรือใช้ Wordfence ที่มีตัวเลือกบล็อก XML-RPC ในตัว เหมาะสำหรับผู้ที่ไม่ต้องการแก้ไขโค้ด อ่านเพิ่มเติมว่า Wordfence คืออะไรและเหมาะกับใคร
วิธีที่ 2: บล็อกผ่าน .htaccess (Apache)
เพิ่มโค้ดต่อไปนี้ในไฟล์ .htaccess ที่ root ของเว็บ:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
วิธีนี้บล็อก request ตั้งแต่ระดับ server ก่อนที่ WordPress จะโหลด ประหยัด resource กว่าการปิดผ่าน plugin ถ้าใช้ Apache 2.4 ขึ้นไป ควรเขียนเป็น Require all denied แทน Order/Deny ตามตัวอย่างในคู่มือ Hardening ของ WordPress.org เพราะคำสั่งชุดเก่าถูกจัดเป็นโมดูลที่เลิกใช้แล้ว (deprecated)
วิธีที่ 3: ปิดผ่าน functions.php
เพิ่มโค้ดใน functions.php ของ theme หรือใน mu-plugin:
add_filter('xmlrpc_enabled', '__return_false');
ตามเอกสารของฟิลเตอร์ xmlrpc_enabled วิธีนี้ปิดเฉพาะเมธอด XML-RPC ที่ต้องยืนยันตัวตน ไม่ได้ปิด XML-RPC ทั้งหมด และไฟล์ xmlrpc.php ยังเข้าถึงได้อยู่ จึงไม่ได้ลดภาระ server เท่าวิธี .htaccess
กรณีที่ยังต้องใช้ XML-RPC อยู่
ก่อนปิด ควรตรวจสอบก่อนว่าเว็บของคุณยังใช้ฟีเจอร์เหล่านี้อยู่หรือไม่:
- n
- Jetpack: ถ้าบล็อก xmlrpc.php ทั้งไฟล์ WordPress.com จะเข้าถึงเว็บไม่ได้และการเชื่อมต่อ Jetpack จะขาด (เอกสาร Jetpack เรื่อง XML-RPC) ถ้าใช้ Jetpack ให้จำกัดการเข้าถึงแทนการปิดทั้งหมด และ ตรวจสอบว่าฟีเจอร์ที่คุณใช้จำเป็นหรือไม่
- แอป WordPress บนมือถือ (เวอร์ชันเก่า): คู่มือ WordPress.orgจัดแอปมือถือเป็นกรณีที่อาจยังต้องใช้ XML-RPC ให้จำกัดการเข้าถึงด้วย WAF และ rate limit แทนการปิดทันที
- เครื่องมือ third-party: ตรวจสอบ API ที่ใช้อยู่ว่ายังพึ่ง XML-RPC หรือรองรับ REST API แล้ว
n
n
ถ้าไม่แน่ใจ ให้ลองปิดแล้วทดสอบว่าระบบยังทำงานปกติหรือไม่ก่อนตัดสินใจถาวร
เมื่อไหร่ควรปรึกษาผู้เชี่ยวชาญ
หากคุณพบ request ไปที่ xmlrpc.php จำนวนมากผิดปกติใน log, เว็บช้าลงโดยไม่ทราบสาเหตุ, หรือไม่แน่ใจว่า server ของตัวเองรองรับการแก้ไข .htaccess แบบไหน ควรให้ผู้เชี่ยวชาญเข้ามาดูแล บริการ เสริมความปลอดภัย WordPress ของเราครอบคลุมการปิด XML-RPC, ตรวจสอบ log, และ hardening จุดอื่น ๆ ทั้งหมดในครั้งเดียว นอกจากนี้ยังควรศึกษาเรื่อง Website Security Hardening คืออะไร เพื่อเข้าใจภาพรวมการป้องกันเว็บในระดับลึกขึ้น
ปิด XML-RPC แล้วยังต้องอัปเดต Plugin และสแกนเว็บต่อเนื่อง ถ้าไม่มีคนดูแลประจำ ดูบริการ ดูแลเว็บ WordPress รายเดือน
คำถามที่พบบ่อย
ถ้าปิด XML-RPC แล้ว WordPress จะทำงานได้ปกติไหม?
ในกรณีส่วนใหญ่ทำงานได้ปกติ เพราะ WordPress ใช้ REST API แทนแล้ว เว้นแต่คุณใช้ Jetpack บางฟีเจอร์หรือเครื่องมือเก่าที่ยังพึ่ง XML-RPC อยู่ ลองปิดแล้วทดสอบดูก่อน
XML-RPC เปิดอยู่โดย default ใน WordPress ไหม?
ใช่ WordPress เปิด XML-RPC ไว้โดย default ตั้งแต่เวอร์ชัน 3.5 ขึ้นมา ต้องปิดเองถ้าต้องการลดความเสี่ยง
Jetpack จำเป็นต้องใช้ XML-RPC ไหม?
บางฟีเจอร์ของ Jetpack เดิมพึ่ง XML-RPC แต่ Automattic กำลังย้ายมาใช้ REST API ทีละส่วน ถ้าใช้ Jetpack เวอร์ชันใหม่ และไม่ได้ใช้ฟีเจอร์เก่า ๆ มักปิด XML-RPC ได้โดยไม่มีปัญหา
วิธีบล็อก XML-RPC ผ่าน .htaccess ปลอดภัยกว่า plugin ไหม?
ปลอดภัยและมีประสิทธิภาพกว่า เพราะตัด request ตั้งแต่ระดับ web server ก่อนที่ PHP หรือ WordPress จะโหลด ช่วยลด load server ด้วย แต่ต้องมีสิทธิ์แก้ไขไฟล์ .htaccess บน server
ไฟล์ xmlrpc.php ลบทิ้งได้ไหม?
ไม่แนะนำให้ลบ เพราะ xmlrpc.php เป็นไฟล์ของ WordPress Core และจะถูกสร้างกลับมาเมื่ออัปเดต WordPress ควรบล็อกการเข้าถึงผ่าน .htaccess หรือ Nginx config หรือปิดด้วย Plugin แทน
มี request ไปที่ xmlrpc.php เยอะผิดปกติ แปลว่าอะไร?
มักแปลว่าเว็บกำลังถูกบอทพยายามสุ่มรหัสผ่านผ่าน XML-RPC หรือถูกใช้ Pingback ซึ่งทำให้เว็บช้าลงได้ ควรบล็อก xmlrpc.php ทันทีถ้าไม่ได้ใช้งาน
แหล่งอ้างอิง
- WordPress.org. (ม.ป.ป.). WordPress 3.5 (Version 3.5). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://wordpress.org/documentation/wordpress-version/version-3-5/
- WordPress.org. (ม.ป.ป.). Brute Force Attacks (Advanced Administration Handbook). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://developer.wordpress.org/advanced-administration/security/brute-force/
- Sucuri. (2015). Brute Force Amplification Attacks via WordPress XML-RPC. สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
- Sucuri. (2014). More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack. สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html
- WordPress.org. (ม.ป.ป.). REST API Handbook: Authentication. สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
- WordPress.org. (ม.ป.ป.). xmlrpc_enabled (Hook reference). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/
- WordPress.org. (ม.ป.ป.). Hardening WordPress (Advanced Administration Handbook). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://developer.wordpress.org/advanced-administration/security/hardening/
- Apache Software Foundation. (ม.ป.ป.). Apache Module mod_access_compat (Apache HTTP Server 2.4). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html
- Jetpack. (ม.ป.ป.). Jetpack and XML-RPC. สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://jetpack.com/support/jetpack-and-xml-rpc/
- WordPress.org. (ม.ป.ป.). Disable XML-RPC (WordPress plugin). สืบค้นเมื่อ 3 พฤศจิกายน 2026, จาก https://wordpress.org/plugins/disable-xml-rpc/
