phpMyAdmin dan PHP2Shell: Tidak Ada CVE Baru phpMyAdmin, tapi Instalasi Anda Tetap Terancam

Sejak PHP2Shell diumumkan pada 21 Oktober, kami beberapa kali mendapat pertanyaan yang sama: apakah ada CVE phpMyAdmin, dan versi berapa yang sudah aman? Jawaban singkatnya, keduanya tidak ada. phpMyAdmin belum menerbitkan pengumuman keamanan apa pun di 2026, dan versi 5.2.3 dari Oktober 2025 masih menjadi rilis terbaru. Tapi itu bukan berarti phpMyAdmin aman. Calif mendemonstrasikan eksekusi kode tanpa login terhadap beberapa aplikasi PHP, dan phpMyAdmin 5.2.3 ada di daftarnya. Celahnya ada di PHP, bukan di phpMyAdmin, jadi perbaikannya adalah meng-update PHP yang menjalankan phpMyAdmin. Kedengarannya sederhana, sampai Anda sadar bahwa phpMyAdmin sering berjalan di PHP yang berbeda dari situs-situs Anda yang lain.

Apa yang Sudah Pasti

• PHP2Shell adalah CVE-2026-109618 dan CVE-2026-109619, dua bug use-after-free di engine PHP dengan skor 9.2 di CVSS 4.0. Versi perbaikannya PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35, dirilis 21 Oktober 2026.
• CISA memasukkan kedua CVE ke katalog Known Exploited Vulnerabilities pada 26 Oktober. Honeypot milik Amazon mencatat percobaan serangan pada 17 Oktober, empat hari sebelum patch keluar.
• Menurut Sansec, Calif melaporkan bahwa penyerang tanpa login bisa menjalankan kode di phpMyAdmin 5.2.3, bersama aplikasi PHP populer lainnya. Synology juga memasukkan phpMyAdmin ke daftar paketnya yang terdampak PHP2Shell.
• phpMyAdmin sendiri tidak punya advisory terkait. Pengumuman terakhirnya, PMASA-2025-1 sampai PMASA-2025-3, sudah diperbaiki di 5.2.2 pada Januari 2025: dua celah XSS tingkat sedang (CVE-2025-24530 dan CVE-2025-24529) dan penguatan untuk bug iconv glibc CVE-2024-2961.

Jadi kalau scanner atau penyedia hosting melaporkan "phpMyAdmin rentan", yang dimaksud adalah PHP di bawahnya. Meng-install ulang phpMyAdmin 5.2.3 tidak mengubah apa pun. Perbaikannya adalah update PHP lalu restart proses yang menjalankan phpMyAdmin.

Kenapa phpMyAdmin Harus Didahulukan

Semua situs PHP di server yang belum di-patch memang terpapar, tapi instalasi phpMyAdmin adalah target yang sangat berharga:

• Mudah ditemukan. Bot sudah dua puluh tahun mengakses /phpmyadmin, /pma, dan /phpMyAdmin di setiap alamat IP di internet, jadi phpMyAdmin yang terbuka hampir pasti sudah ada di daftar seseorang.
• Login-nya tidak menolong. Halaman login phpMyAdmin, two-factor authentication, dan pembatasan percobaan login semuanya berjalan di dalam PHP. Bug di PHP itu sendiri tidak bisa dihentikan oleh kode yang baru dijalankan PHP setelahnya.
• Shell di server itu biasanya berarti akses ke database. Prosesnya bisa membaca config.inc.php, password controluser kalau dikonfigurasi, dan sering kali file .env aplikasi lain di mesin yang sama. Dari situ penyerang bisa langsung terhubung ke MySQL atau MariaDB.
• Sering terlupakan. phpMyAdmin di-install sekali untuk migrasi atau permintaan support, lalu dibiarkan berjalan di server lama, container Docker lama, atau NAS lama, jauh setelah tidak ada yang ingat keberadaannya.

Cek PHP Mana yang Menjalankan phpMyAdmin Anda

Menjalankan php -v di server belum cukup. Perintah itu menampilkan PHP command line, yang bisa berbeda dari pool PHP-FPM atau modul Apache yang melayani phpMyAdmin, dan di control panel bahkan PHP-nya lain sama sekali. Cara paling pasti adalah lewat phpMyAdmin sendiri: setelah login, halaman utamanya punya panel Web server yang menampilkan versi PHP yang sedang melayani halaman itu. Ingat juga bahwa Debian, Ubuntu, dan RHEL memasang perbaikan tanpa mengubah nomor versi, jadi untuk paket distribusi cek changelog paketnya, bukan angkanya.

Baris control panel adalah tempat kesalahan paling sering terjadi. Di cPanel, update ea-php83 memperbaiki situs pelanggan, tapi tidak memperbaiki phpMyAdmin yang dibuka dari antarmuka cPanel, karena phpMyAdmin itu berjalan di PHP bawaan cPanel sendiri. cPanel merilis build cPanel & WHM baru (11.110.0.153, 11.134.0.66, 11.136.0.50, dan 11.138.0.18) bersamaan dengan perbaikan EasyApache, jadi jalankan juga /scripts/upcp. Di Plesk, phpMyAdmin berjalan di PHP sw-engine milik panel, yang di-update lewat installer Plesk, bukan lewat apt atau dnf. Plesk menyatakan semua versi PHP yang mereka sediakan terdampak, jadi pasang update Plesk terbaru untuk rilis yang Anda pakai.

Untuk Docker, image yang Anda pull bulan lalu masih berisi PHP lama. Image resmi phpMyAdmin dibangun di atas base image php:8.3 dan sudah di-build ulang; per 28 Oktober, tag latest, 5.2.3, apache, dan fpm-alpine sudah berisi PHP 8.3.36. Lakukan pull, buat ulang container (bukan sekadar restart), lalu pastikan dengan docker exec <container> php -v.

Kalau Masih Memakai phpMyAdmin 4.9

phpMyAdmin 4.9 hanya mendukung PHP 5.5 sampai 7.4, dan rilis terakhirnya, 4.9.11, keluar pada Februari 2023. Ini penting karena proyek PHP hanya merilis perbaikan untuk versi 8.2 ke atas. PHP 7.4 hanya diperbaiki lewat build vendor seperti Debian, Ubuntu Pro, cPanel, Plesk, atau layanan long-term support berbayar, dan PHP 7.3 ke bawah sama sekali tidak mendapat perbaikan kecuali Anda membayar. Server yang menjalankan phpMyAdmin 4.9 kemungkinan besar memakai PHP yang tidak akan pernah di-patch. Solusi yang realistis adalah memindahkannya ke phpMyAdmin 5.2.3 di PHP 8.2.35 atau 8.3.36, yang masih masuk rentang PHP yang didukung resmi oleh phpMyAdmin 5.2.

Langkah Darurat yang Hampir Tanpa Biaya

Berbeda dengan situs publik, phpMyAdmin biasanya hanya dipakai segelintir orang. Karena itu mudah dilindungi di level web server, tempat request ditolak sebelum sampai ke PHP. Lakukan ini hari ini, bahkan kalau PHP sudah di-patch:

1. 1Batasi akses berdasarkan alamat IP. Di nginx, tambahkan baris allow untuk alamat kantor atau VPN lalu deny all di dalam blok location phpMyAdmin. Di Apache, pakai Require ip dengan alamat yang sama. Selain itu semua akan mendapat 403 dari web server, bukan dari PHP.
2. 2Kalau tim Anda tidak punya IP tetap, pasang HTTP basic authentication di depan phpMyAdmin di level web server (auth_basic di nginx, AuthType Basic di Apache). Ini pemeriksaan terpisah dari login phpMyAdmin, dan berjalan sebelum request diteruskan ke PHP.
3. 3Kalau keduanya belum bisa dilakukan sekarang, blokir request multipart/form-data ke path phpMyAdmin. Sansec melaporkan semua pemicu PHP2Shell yang diketahui memakai content type itu. Form login phpMyAdmin tidak memakainya, jadi yang hilang hanya halaman Import dan upload file ke kolom BLOB.
4. 4Lebih baik lagi, keluarkan phpMyAdmin dari internet sepenuhnya. Akses lewat VPN atau SSH tunnel, atau pakai aplikasi desktop seperti DBeaver, HeidiSQL, atau TablePlus lewat SSH. Mengganti /phpmyadmin menjadi path yang aneh memang mengurangi noise di log, tapi bukan perlindungan.

Cek Apakah Sudah Dimasuki

Percobaan serangan sudah dimulai sebelum patch tersedia, jadi server yang di-patch pada 22 Oktober pun mungkin sudah sempat didatangi. Periksa mundur setidaknya sampai 17 Oktober:

• File: cari file PHP yang berubah belakangan ini di direktori phpMyAdmin dan web root, misalnya find /usr/share/phpmyadmin /var/www -name "*.php" -newermt 2026-10-17. Cek juga direktori temporary phpMyAdmin serta UploadDir atau SaveDir kalau Anda mengaturnya.
• Log: cari request POST ke path phpMyAdmin dari alamat yang bukan milik tim Anda, dan worker PHP-FPM atau proses Apache yang mati dengan signal 11 (segmentation fault). Percobaan eksploitasi bug memori yang gagal sering membuat worker crash.
• Database: jalankan SELECT user, host FROM mysql.user dan cari akun yang tidak pernah dibuat siapa pun, lalu cek trigger, event, atau stored procedure yang tidak dikenal. Kalau privilege FILE diberikan dan secure_file_priv kosong, cek apakah ada file yang ditulis lewat SELECT INTO OUTFILE.
• Sistem: cek crontab milik user web server (www-data, apache, atau nginx), dan cari proses serta koneksi keluar milik user itu yang tidak bisa dijelaskan.

Kalau Anda menemukan sesuatu, anggap kredensial database di server itu sudah diketahui penyerang. Ganti password semua akun database yang bisa dijangkau dari server tersebut, termasuk controluser phpMyAdmin, ubah blowfish_secret, dan ganti secret aplikasi yang tersimpan di file .env di mesin yang sama. Kalau database berisi data pribadi warga Indonesia, UU PDP mewajibkan pemberitahuan tertulis kepada subjek data dan lembaga pengawas paling lambat 3 x 24 jam sejak terjadi kegagalan pelindungan data, jadi libatkan penanggung jawab prosesnya sejak awal.

Mulai dari Mana

Buat daftar semua phpMyAdmin yang Anda punya, termasuk yang ada di server staging, VPS lama, perangkat NAS, dan di dalam file Docker Compose. Untuk masing-masing, catat PHP yang benar-benar menjalankannya, update, lalu batasi aksesnya di web server. Bagi kebanyakan tim, ini pekerjaan sekitar satu jam per server, dan pembatasan akses itu akan tetap berguna saat celah PHP berikutnya diumumkan. Kalau Anda butuh bantuan untuk mengecek banyak server sekaligus, ini pekerjaan rutin bagi tim managed service.