---
title: "Kenapa XML-RPC WordPress Sebaiknya Dimatikan"
description: "Apa itu xmlrpc.php, kenapa sering jadi pintu brute force dan pingback abuse, siapa yang masih membutuhkannya, dan cara mematikannya dengan aman."
url: "https://nivelva.com/insight/xml-rpc-wordpress-dimatikan"
category: "Keamanan/Cyber Security"
tags: ["wordpress","xml-rpc","brute force","pingback","hardening"]
author: "Theresia Candiawan"
published: "2026-11-07T10:08:00+07:00"
updated: "2026-11-07T10:08:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Kenapa XML-RPC WordPress Sebaiknya Dimatikan

> **Jawaban singkat:** XML-RPC adalah antarmuka lama WordPress untuk menerbitkan dan pingback dari luar. Kebanyakan situs sudah tidak memakainya karena ada REST API, padahal file xmlrpc.php sering dipakai untuk brute force massal dan pingback abuse. Matikan bila tidak ada plugin atau aplikasi yang bergantung padanya.

XML-RPC adalah protokol lama yang memungkinkan program lain berbicara dengan WordPress lewat satu file, `xmlrpc.php`. Lewat file itu, aplikasi luar bisa menerbitkan artikel, mengunggah gambar, atau mengirim pingback tanpa membuka wp-admin.

Masalahnya, fitur ini lahir jauh sebelum WordPress punya REST API, dan sekarang sebagian besar situs tidak lagi memakainya. Yang tersisa justru sisi buruknya: `xmlrpc.php` menjadi salah satu alamat yang paling sering dihujani permintaan otomatis. Salah langkah bisa dua arah. Membiarkannya terbuka tanpa alasan menambah permukaan serangan, sedangkan mematikannya tanpa cek dulu bisa memutus plugin yang ternyata masih bergantung padanya.

## Kenapa xmlrpc.php jadi sasaran?

Ada dua cara penyalahgunaan yang paling dikenal. Keduanya bukan bug yang bisa ditambal sekali jadi, melainkan efek samping dari cara kerja protokolnya.

### Brute force berlipat lewat system.multicall

XML-RPC punya metode `system.multicall` yang menggabungkan banyak perintah dalam satu permintaan. Penyerang memanfaatkannya untuk mencoba banyak kombinasi username dan password sekaligus dalam **satu** permintaan HTTP. Akibatnya, pembatas percobaan login yang hanya menghitung jumlah permintaan ke `wp-login.php` bisa terlewati, dan log tampak lebih sepi daripada jumlah tebakan yang sebenarnya.

Penjelasan lebih luas tentang pola serangan ini ada di [kenapa halaman login admin jadi sasaran brute force](https://nivelva.com/insight/halaman-login-admin-sasaran-brute-force).

### Pingback yang dipakai menyerang situs lain

Pingback adalah fitur pemberitahuan otomatis saat situs lain menautkan artikelmu. Metode `pingback.ping` membuat WordPress mengambil halaman dari alamat yang disebut pengirim. Bila banyak situs WordPress disuruh melakukan itu bersamaan ke satu target, situs-situs tersebut ikut menjadi bagian dari serangan DDoS terhadap pihak lain, sekaligus membebani server milikmu sendiri.

Kedua pola itu membuat `xmlrpc.php` boros sumber daya. Di hosting dengan kuota CPU terbatas, lonjakan permintaan ke file ini cukup untuk membuat situs melambat.

## Siapa yang masih membutuhkan XML-RPC?

Sebelum mematikan, cek apakah ada yang masih memakainya:

- **Jetpack.** Koneksi Jetpack ke WordPress.com memakai XML-RPC. Bila `xmlrpc.php` diblokir penuh, fitur Jetpack bisa berhenti bekerja.
- **Aplikasi atau editor desktop lama** yang menerbitkan artikel dari luar wp-admin.
- **Integrasi buatan sendiri** dari sistem lain (misalnya skrip impor artikel) yang ditulis sebelum REST API populer.
- **Pingback dan trackback**, bila kamu memang masih ingin menerimanya.

Kalau tidak ada satu pun di daftar itu, situsmu hampir pasti tidak memerlukan XML-RPC. Integrasi baru sebaiknya memakai [REST API WordPress](https://developer.wordpress.org/rest-api/) dengan Application Passwords, yang tersedia di inti WordPress sejak versi 5.6.

## Pilihan cara mematikan, mana yang tepat?

Tidak semua cara mematikan bekerja sama. Ini yang sering membingungkan.

| Cara | Yang diblokir | Beban server | Cocok untuk |
|:--|:--|:--|:--|
| Filter `xmlrpc_enabled` | Hanya metode yang butuh login | Permintaan tetap diproses PHP | Menutup brute force, pingback tetap jalan |
| Plugin "disable XML-RPC" | Tergantung plugin | Permintaan tetap diproses PHP | Pengguna tanpa akses server |
| Blokir di `.htaccess` (Apache/LiteSpeed) | Seluruh akses ke `xmlrpc.php` | Ringan, ditolak sebelum PHP | Kebanyakan situs di shared hosting |
| Blokir di konfigurasi Nginx | Seluruh akses ke `xmlrpc.php` | Paling ringan | VPS dengan Nginx |
| Aturan WAF atau CDN | Seluruh akses atau sebagian | Ditolak sebelum sampai server | Situs di balik WAF |

### Filter xmlrpc_enabled: setengah jalan

Banyak tutorial menyarankan baris ini di plugin kecil atau `functions.php`:

```
add_filter( 'xmlrpc_enabled', '__return_false' );
```

Dokumentasi resmi WordPress menjelaskan bahwa filter ini **hanya** mematikan metode XML-RPC yang memerlukan autentikasi, seperti menerbitkan artikel. Pingback dan endpoint lain yang tidak butuh login tetap aktif. Jadi filter ini menutup jalur brute force lewat XML-RPC, tetapi tidak menghentikan penyalahgunaan pingback, dan setiap permintaan tetap memakan proses PHP.

### Memblokir di level server: tuntas

Untuk Apache 2.4 atau LiteSpeed, tambahkan ke `.htaccess` di folder utama WordPress:

```
<Files xmlrpc.php>
    Require all denied
</Files>
```

Untuk Nginx, tambahkan di dalam blok `server` situsmu, lalu uji dan muat ulang konfigurasi:

```
location = /xmlrpc.php {
    deny all;
}
```

Jalankan `nginx -t` sebelum `systemctl reload nginx` supaya kesalahan ketik tidak menjatuhkan server. Setelah itu, buka `https://domainmu/xmlrpc.php` di browser. Kalau berhasil, kamu akan melihat pesan 403 Forbidden, bukan tulisan "XML-RPC server accepts POST requests only."

> **Pakai Jetpack?:**
>
> Jangan memblokir `xmlrpc.php` sepenuhnya bila situsmu memakai Jetpack. Pilih aturan WAF yang hanya mengizinkan akses dari alamat milik layanan tersebut, atau cukup pasang pembatas laju (rate limit) dan perlindungan brute force yang kuat.

## Kapan mematikan, kapan membiarkan?

Matikan XML-RPC sepenuhnya di level server bila situsmu dikelola lewat wp-admin biasa, tidak memakai Jetpack, dan tidak ada integrasi lama. Ini kondisi sebagian besar website bisnis, toko online kecil, dan company profile. Hasilnya langsung terasa: satu jalur brute force hilang, dan permintaan sampah tidak lagi menyentuh PHP.

Biarkan aktif, tapi dengan pengaman, bila ada layanan yang memang bergantung padanya. Dalam kasus ini, pakai password kuat dan 2FA untuk semua admin, batasi laju permintaan ke `xmlrpc.php` di WAF, dan pantau log akses. Pertimbangkan juga untuk memindahkan integrasi lama ke REST API agar suatu hari XML-RPC bisa dimatikan.

Mematikan XML-RPC hanya satu bagian dari pengamanan. Langkah dasar lain seperti update rutin, akun admin minimal, dan backup terpisah dibahas di [dasar keamanan WordPress](https://nivelva.com/insight/keamanan-wordpress-dasar).

## Pertanyaan yang sering diajukan

### Apakah mematikan XML-RPC merusak SEO?

Tidak. Mesin pencari merayapi halaman biasa, bukan `xmlrpc.php`. Yang hilang hanya kemampuan menerima pingback.

### Apakah REST API juga perlu dimatikan?

Jangan dimatikan penuh. Editor blok Gutenberg dan banyak plugin bergantung pada REST API. Kalau khawatir, batasi endpoint tertentu seperti daftar pengguna, bukan seluruh API.

### Bagaimana tahu xmlrpc.php sedang diserang?

Lihat log akses server dan cari banyak permintaan POST ke `/xmlrpc.php` dari alamat yang sama atau beragam dalam waktu singkat. Lonjakan penggunaan CPU tanpa kenaikan pengunjung juga bisa menjadi tanda.

### Apakah aplikasi WordPress di HP masih butuh XML-RPC?

Tergantung versi aplikasi dan cara situs dihubungkan. Uji dulu setelah memblokir. Bila aplikasi tidak bisa login, aktifkan lagi sementara dan cari opsi koneksi lewat REST API atau Application Passwords.

## Sumber

- <https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/>
- <https://developer.wordpress.org/rest-api/>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/xml-rpc-wordpress-dimatikan
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com