Cara Mengaktifkan dan Menonaktifkan xmlrpc.php di WordPress (Dan Mengapa Hal Ini Penting)

File xmlrpc.php adalah komponen inti WordPress yang mengekspos endpoint API XML-RPC, memungkinkan aplikasi jarak jauh untuk mengautentikasi dan menjalankan operasi sisi server — menerbitkan postingan, mengelola komentar, memicu pingback, dan lainnya. Karena secara default menerima permintaan POST tanpa autentikasi dan memprosesnya sebelum sebagian besar lapisan keamanan aktif, ini adalah salah satu permukaan serangan yang paling sering disalahgunakan dalam instalasi WordPress mana pun.

Jika Anda tidak menggunakan aplikasi mobile WordPress, Jetpack, atau layanan pihak ketiga mana pun yang secara eksplisit memerlukan XML-RPC, menonaktifkan xmlrpc.php adalah postur keamanan default yang tepat. Jika Anda mengandalkan integrasi tersebut, Anda dapat memperkuat endpoint daripada menghapusnya sepenuhnya.

Apa Itu xmlrpc.php dan Bagaimana Cara Kerjanya

XML-RPC (Extensible Markup Language Remote Procedure Call) adalah protokol yang mengenkode pemanggilan fungsi dalam XML dan mengirimkannya melalui HTTP. WordPress telah menyertakan server XML-RPC lengkap sejak versi 3.5, yang diimplementasikan dalam file xmlrpc.php yang terletak di direktori root WordPress.

Ketika klien jarak jauh — aplikasi mobile, klien blogging desktop, atau skrip otomasi — mengirimkan permintaan POST ke https://yourdomain.com/xmlrpc.php, WordPress mengurai payload XML, mengautentikasi kredensial yang tertanam dalam isi permintaan, dan menjalankan metode yang diminta. Seluruh pertukaran terjadi dalam satu putaran HTTP, yang merupakan kekuatan sekaligus kelemahan mendasarnya dari sudut pandang keamanan.

Metode XML-RPC Inti yang Diekspos oleh WordPress

• wp.newPost / wp.editPost — membuat dan memperbarui postingan dari jarak jauh
• wp.getComments / wp.deleteComment — mengelola komentar
• wp.uploadFile — mengunggah media ke server
• pingback.ping — memberi tahu situs jarak jauh bahwa situs tersebut telah ditautkan
• system.multicall — menggabungkan beberapa pemanggilan metode dalam satu permintaan HTTP

Metode system.multicall sangat berbahaya. Satu permintaan HTTP dapat menggabungkan ratusan pemanggilan wp.getUsersBlogs, masing-masing menguji kata sandi yang berbeda. Hal ini memungkinkan penyerang melakukan ribuan percobaan autentikasi sambil hanya menghasilkan satu entri log server, melewati alat pembatasan laju yang menghitung permintaan individual.

Risiko Keamanan Membiarkan xmlrpc.php Aktif

Amplifikasi Brute Force melalui system.multicall

Serangan brute force tradisional mengirimkan satu pasang kredensial per permintaan HTTP. Dengan XML-RPC, penyerang membungkus 500 percobaan login dalam satu payload system.multicall. Aturan fail2ban standar atau penghitung percobaan login melihat satu permintaan; penyerang mendapatkan 500 tebakan. Ini bukan risiko teoritis — ini adalah eksploitasi XML-RPC yang paling umum diamati di dunia nyata.

DDoS yang Diperkuat melalui Pingback

WordPress secara otomatis memproses permintaan pingback masuk melalui xmlrpc.php. Penyerang dapat mengirimkan permintaan pingback.ping yang dibuat khusus ke ribuan situs WordPress, menginstruksikan masing-masing untuk mengirimkan permintaan HTTP ke satu URL korban. Korban menerima banjir permintaan volumetrik yang berasal dari server WordPress yang sah, membuat pemblokiran berbasis IP menjadi tidak efektif. Server Anda sekaligus menjadi korban (kelelahan sumber daya) dan penguat serangan yang tidak disengaja.

SSRF melalui Pingback

Mekanisme pingback dapat disalahgunakan untuk Server-Side Request Forgery (SSRF). Penyerang mengirimkan permintaan pingback.ping di mana URL sumber mengarah ke sumber daya jaringan internal — http://192.168.1.1/admin, misalnya. Server WordPress mengambil URL tersebut dari dalam perimeter jaringan, berpotensi mengekspos layanan internal yang tidak dapat dirutekan secara publik.

Eksposur Kredensial dalam Transit

XML-RPC mengirimkan kredensial dalam isi POST sebagai teks biasa di dalam amplop XML. Jika situs Anda tidak menerapkan HTTPS, kredensial terekspos ke pengamat jaringan mana pun. Bahkan dengan TLS, kredensial tertanam dalam setiap permintaan — tidak ada token sesi atau alur OAuth untuk membatasi jendela eksposur.

Kapan Anda Harus Tetap Mengaktifkan xmlrpc.php

Nonaktifkan secara default, tetapi tetap aktifkan jika alur kerja Anda benar-benar bergantung pada salah satu hal berikut:

• Aplikasi mobile WordPress (iOS/Android): Aplikasi resmi menggunakan XML-RPC untuk semua operasi manajemen situs pada instalasi WordPress yang dihosting sendiri.
• Plugin Jetpack: Beberapa modul Jetpack — termasuk publicize, notifikasi push mobile, dan beberapa fitur statistik — berkomunikasi melalui XML-RPC ke server WordPress.com.
• Klien blogging desktop: MarsEdit, Windows Live Writer, dan alat serupa mengandalkan sepenuhnya pada API XML-RPC.
• Pipeline penerbitan otomatis: IFTTT, Zapier, dan skrip kustom yang mendorong konten ke WordPress sering menggunakan XML-RPC ketika REST API tidak dikonfigurasi.
• Pingback/trackback antar situs WordPress: Jika notifikasi pingback lintas situs merupakan bagian dari alur kerja editorial Anda, menonaktifkan xmlrpc.php akan menghentikannya.

Jika tidak ada yang berlaku, tidak ada alasan operasional untuk membiarkan endpoint tetap terbuka.

xmlrpc.php vs. WordPress REST API

WordPress memperkenalkan REST API pada versi 4.7 sebagai pengganti modern berbasis token untuk XML-RPC. Memahami perbedaannya membantu Anda memutuskan apakah menonaktifkan XML-RPC merusak sesuatu yang kritis.

Jika Anda membangun integrasi baru atau memigrasikan yang sudah ada, gunakan REST API. Model autentikasi jauh lebih aman, dan endpoint jauh lebih mudah untuk diaudit dan dibatasi lajunya di tingkat infrastruktur.

Cara Menonaktifkan xmlrpc.php di WordPress

Pilih metode yang sesuai dengan tingkat akses server dan toleransi risiko Anda. Metode diurutkan dari penegakan tingkat server terendah hingga tertinggi.

Metode 1: Nonaktifkan melalui Plugin (Tercepat, Tidak Memerlukan Akses Server)

Untuk lingkungan shared hosting atau situs di mana Anda lebih memilih untuk tidak mengedit file konfigurasi server, plugin adalah opsi yang paling mudah diakses.

Plugin yang direkomendasikan:

• Disable XML-RPC-API — tujuan tunggal, jejak minimal, aktif secara instan
• All In One WP Security and Firewall — suite keamanan yang lebih luas dengan kontrol XML-RPC yang granular

Langkah-langkah untuk Disable XML-RPC-API:

1. Navigasikan ke Plugins > Add New di dashboard WordPress Anda.
2. Cari “Disable XML-RPC-API” dan klik Install Now, lalu Activate.
3. Tidak diperlukan konfigurasi lebih lanjut — plugin terhubung ke xmlrpc_enabled dan langsung mengembalikan false saat diaktifkan.

Langkah-langkah untuk All In One WP Security and Firewall:

1. Setelah mengaktifkan plugin, buka WP Security > Firewall.
2. Temukan bagian XML-RPC.
3. Aktifkan opsi untuk memblokir permintaan XML-RPC sepenuhnya.
4. Simpan pengaturan.

Keterbatasan: Pemblokiran berbasis plugin berjalan di dalam konteks eksekusi PHP WordPress. Server tetap mem-boot PHP, memuat WordPress, dan memproses permintaan sebelum menolaknya. Di bawah serangan berat, ini mengonsumsi CPU dan memori. Untuk situs dengan lalu lintas tinggi yang sedang diserang aktif, gunakan metode .htaccess atau Nginx sebagai gantinya.

Metode 2: Nonaktifkan melalui .htaccess (Apache — Blokir Tingkat Server)

Pemblokiran di tingkat .htaccess mencegah PHP dieksekusi sama sekali untuk permintaan yang menargetkan xmlrpc.php. Ini jauh lebih efisien di bawah beban.

1. Hubungkan ke server Anda melalui FTP, SFTP, atau pengelola file hosting Anda dan buka file .htaccess di root WordPress Anda (biasanya public_html/.htaccess).
2. Tambahkan blok berikut. Tempatkan sebelum aturan penulisan ulang WordPress standar:

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

1. Simpan file.

Untuk memverifikasi blok aktif, jalankan pengujian dari mesin lokal Anda:

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

Anda seharusnya menerima respons 403. Respons 200 atau 405 berarti blok belum berlaku.

Kasus tepi — jika Anda masih memerlukan pingback dari IP tepercaya tertentu, Anda dapat memasukkan mereka ke daftar putih:

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

Metode 3: Nonaktifkan melalui Konfigurasi Nginx

Jika server Anda menjalankan Nginx (umum di lingkungan VPS Hosting), file .htaccess tidak berpengaruh. Tambahkan blok langsung ke konfigurasi blok server situs Anda.

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

Direktif return 444 menutup koneksi TCP tanpa mengirimkan respons HTTP, yang lebih efisien daripada 403 karena mencegah klien penyerang menerima umpan balik apa pun. Setelah mengedit, muat ulang Nginx:

sudo nginx -t && sudo systemctl reload nginx

Tempatkan blok location ini di dalam blok server {} Anda, sebelum direktif try_files atau pemrosesan PHP mana pun.

Metode 4: Nonaktifkan melalui functions.php (Filter Hook WordPress)

Metode ini menggunakan filter WordPress untuk menonaktifkan XML-RPC di lapisan aplikasi. Ini kurang efisien daripada pemblokiran tingkat server tetapi berguna ketika Anda tidak memiliki akses server langsung dan menginginkan solusi berbasis kode tanpa ketergantungan plugin.

1. Buka Appearance > Theme Editor di dashboard WordPress Anda, atau akses file langsung melalui SFTP di wp-content/themes/your-theme/functions.php.
2. Tambahkan yang berikut ke akhir file:

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

1. Simpan file.

Peringatan penting: Filter ini menonaktifkan metode XML-RPC yang terautentikasi, tetapi tidak memblokir metode pingback.ping atau mencegah file diakses. Server tetap memproses permintaan hingga titik di mana WordPress mengevaluasi filter. Untuk perlindungan lengkap, kombinasikan ini dengan blok .htaccess atau Nginx.

Jika Anda menggunakan child theme, selalu tambahkan kode kustom ke functions.php child theme, bukan tema induk. Pembaruan tema induk akan menimpa perubahan Anda.

Metode 5: Nonaktifkan Selektif — Blokir Hanya Pingback

Jika Anda memerlukan XML-RPC untuk Jetpack atau penerbitan mobile tetapi ingin menghilangkan vektor amplifikasi DDoS, Anda dapat menonaktifkan hanya metode pingback sambil menjaga fungsionalitas API lainnya tetap berjalan.

// 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;
} );

Tambahkan ini ke functions.php child theme Anda atau plugin khusus situs. Ini adalah konfigurasi yang direkomendasikan untuk situs yang menjalankan Jetpack tetapi tidak perlu menerima pingback.

Cara Mengaktifkan Kembali xmlrpc.php

Membalikkan salah satu metode di atas memulihkan akses XML-RPC:

• Metode plugin: Nonaktifkan atau hapus plugin pemblokiran dari Plugins > Installed Plugins.
• Metode .htaccess: Hapus blok <Files "xmlrpc.php"> dari .htaccess dan simpan.
• Metode Nginx: Hapus blok location = /xmlrpc.php dari konfigurasi server Anda dan muat ulang Nginx dengan sudo systemctl reload nginx.
• Metode functions.php: Hapus baris add_filter( 'xmlrpc_enabled', '__return_false' ) dan simpan.

Setelah mengaktifkan kembali, verifikasi bahwa endpoint merespons dengan benar:

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>'

Respons XML yang valid yang mencantumkan metode yang tersedia mengonfirmasi bahwa endpoint aktif.

Memperkuat xmlrpc.php Tanpa Menonaktifkannya

Jika menonaktifkan bukan pilihan, terapkan mitigasi ini untuk mengurangi permukaan serangan:

Terapkan HTTPS: Pastikan situs Anda menggunakan sertifikat TLS yang valid. Jika belum, konfigurasikan melalui penyedia hosting Anda — SSL Certificates mencegah intersepsi kredensial dalam transit.

Batasi laju di tingkat firewall atau CDN: Konfigurasikan WAF Anda (Cloudflare, ModSecurity) untuk membatasi permintaan POST ke xmlrpc.php maksimum 5–10 per menit per IP.

Blokir system.multicall secara khusus:

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

Ini menghilangkan vektor amplifikasi brute force sambil mempertahankan semua fungsionalitas XML-RPC lainnya.

Batasi berdasarkan IP: Jika Anda hanya mengakses XML-RPC dari alamat IP yang diketahui (rentang IP operator aplikasi mobile Anda, atau IP kantor statis), masukkan alamat tersebut ke daftar putih di .htaccess atau Nginx dan tolak semua yang lain.

Pantau log akses: Audit secara rutin log server Anda untuk permintaan POST berulang ke xmlrpc.php. Lonjakan permintaan POST dengan status 200 ke file ini adalah indikator yang dapat diandalkan dari kampanye brute force yang sedang berlangsung.

Pada VPS dengan cPanel atau lingkungan panel terkelola lainnya, Anda dapat mengonfigurasi aturan ModSecurity langsung dari panel kontrol untuk menerapkan pembatasan ini tanpa pengeditan file manual.

Memilih Metode yang Tepat: Matriks Keputusan

Untuk situs produksi yang dihosting di Dedicated Servers, blok tingkat server Nginx atau Apache selalu lebih disukai daripada solusi berbasis plugin karena mencegah eksekusi PHP sepenuhnya untuk permintaan berbahaya, menghilangkan overhead CPU yang diakibatkan pemblokiran berbasis plugin di bawah serangan berkelanjutan.

Daftar Periksa Poin Penting Praktis

• Audit apakah plugin atau layanan aktif apa pun dalam tumpukan Anda benar-benar memerlukan XML-RPC sebelum menonaktifkannya — periksa Jetpack, aplikasi mobile, dan alat otomasi penerbitan apa pun.
• Jika tidak ada ketergantungan, terapkan blok tingkat server (.htaccess atau Nginx) daripada plugin — ini lebih efisien dan bertahan dari penonaktifan plugin.
• Jika Anda harus tetap mengaktifkan XML-RPC, hapus tanpa syarat system.multicall dan pingback.ping melalui filter xmlrpc_methods — kedua metode ini menyumbang sebagian besar penyalahgunaan XML-RPC.
• Selalu terapkan HTTPS pada situs WordPress mana pun yang menerima permintaan terautentikasi, termasuk XML-RPC.
• Setelah menerapkan blok apa pun, verifikasi dengan curl bahwa endpoint mengembalikan 403 atau memutus koneksi — jangan asumsikan konfigurasi sudah benar tanpa pengujian.
• Di lingkungan VPS atau server dedicated berbasis Nginx, gunakan return 444 daripada deny all untuk menghindari memberikan umpan balik tingkat HTTP kepada penyerang.
• Catat dan pantau permintaan POST ke xmlrpc.php — lonjakan mendadak adalah peringatan dini kampanye credential-stuffing atau amplifikasi DDoS.
• Jika Anda mengelola beberapa situs WordPress, pertimbangkan untuk memusatkan konfigurasi ini di tingkat server atau CDN daripada menerapkan aturan plugin per situs.

Untuk situs yang memerlukan manajemen jarak jauh yang kuat tanpa permukaan risiko XML-RPC, memigrasikan integrasi ke WordPress REST API dengan application passwords adalah jalur jangka panjang yang tepat. REST API menyediakan pencabutan per token, izin yang dibatasi cakupannya, dan semantik HTTP standar yang jauh lebih mudah diamankan dan diaudit.

Jika Anda menyiapkan lingkungan WordPress baru dan menginginkan dasar yang bersih dan aman dari awal, VPS Control Panels dengan ModSecurity yang telah dikonfigurasi sebelumnya memberi Anda perlindungan WAF tingkat server tanpa memerlukan penulisan aturan manual.

—

Pertanyaan yang Sering Diajukan

Apakah menonaktifkan xmlrpc.php merusak WordPress REST API?

Tidak. REST API (/wp-json/) adalah endpoint yang sepenuhnya terpisah dengan autentikasi dan peruteannya sendiri. Memblokir xmlrpc.php tidak berpengaruh sama sekali pada fungsionalitas REST API. Kedua sistem secara arsitektur independen.

Apakah menonaktifkan xmlrpc.php akan merusak Jetpack?

Tergantung pada modul Jetpack mana yang Anda gunakan. Jetpack telah secara bertahap memigrasikan fitur ke REST API, tetapi beberapa modul lama — termasuk fitur publicize dan notifikasi tertentu — masih berkomunikasi melalui XML-RPC. Periksa halaman debug Jetpack di Jetpack > Dashboard > Debug untuk melihat apakah konektivitas XML-RPC terdaftar sebagai persyaratan sebelum menonaktifkannya.

Apakah metode .htaccess atau metode functions.php lebih aman?

Metode .htaccess jauh lebih aman dalam kondisi serangan. Ini memblokir permintaan di lapisan web server sebelum PHP dimuat, mengonsumsi sumber daya minimal. Filter functions.php berjalan di dalam konteks eksekusi PHP WordPress, yang berarti server tetap mem-bootstrap WordPress untuk setiap permintaan yang diblokir — yang mahal di bawah serangan volume tinggi.

Dapatkah penyerang tetap mengeksploitasi xmlrpc.php jika saya hanya menonaktifkannya melalui filter WordPress?

Sebagian. Filter xmlrpc_enabled mencegah pemanggilan metode terautentikasi, tetapi file tetap dapat diakses secara publik dan server tetap memproses permintaan masuk. Endpoint pingback mungkin tetap sebagian fungsional tergantung pada versi WordPress. Untuk perlindungan lengkap, padukan filter dengan blok tingkat server.

Bagaimana cara memeriksa apakah xmlrpc.php saat ini dapat diakses di situs saya?

Jalankan perintah berikut dari terminal lokal Anda, ganti domain dengan domain Anda sendiri:

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

Respons 200 berarti endpoint terbuka. Respons 403 atau koneksi terputus (000) mengonfirmasi bahwa endpoint diblokir. Anda juga dapat menggunakan alat online di xmlrpc.eritreo.it untuk menguji kerentanan pingback secara khusus.