File PHP Asing di Upload WordPress: Periksa Sebelum Menghapus

Anda menemukan something.php di wp-content/uploads, padahal folder itu seharusnya berisi gambar dan dokumen. File tersebut bisa menjadi web shell atau loader yang mempertahankan akses penyerang. Namun menghapus semua file PHP di folder uploads tanpa pemeriksaan juga berisiko menghapus komponen sah dari plugin atau aplikasi khusus, merusak fungsi website, dan menghilangkan bukti yang dibutuhkan untuk mengetahui cara file itu dibuat.

Jawaban cepat: perlakukan file PHP yang tidak dikenal sebagai indikator berisiko, bukan diagnosis lengkap. Simpan path, metadata, hash, dan log terkait; jangan membuka URL file di browser; minta host membatasi eksekusi atau akses jika bahaya nyata; lalu bandingkan file dengan backup serta telusuri akun, endpoint upload, plugin, theme, dan job yang dapat menulis. Setelah sumbernya diketahui, karantina atau hapus melalui rencana yang dapat dibalik, tutup celah, dan uji konfigurasi server yang benar-benar digunakan.

Mengapa file di uploads perlu diperiksa dengan hati-hati?

wp-content/uploads biasanya menyimpan media yang diunggah dan dapat diakses melalui web. Jika PHP-FPM atau Apache mengeksekusi file script di direktori itu, file yang seharusnya menjadi data dapat berubah menjadi kode server. Penyerang dapat menyisipkan file melalui akun yang dibajak, plugin upload yang lemah, kredensial FTP, atau kerentanan lain. Tetapi fungsi plugin tertentu mungkin membuat subdirektori atau file bantu; lokasi dan pola nama memberi petunjuk, bukan kepastian.

OWASP merekomendasikan daftar tipe file yang diizinkan, validasi konten alih-alih mempercayai Content-Type dari browser, nama yang dikendalikan aplikasi, pembatasan ukuran, dan penyimpanan upload yang tidak dapat dieksekusi (File Upload Cheat Sheet). WordPress juga menyarankan permission minimum dan memperingatkan agar direktori tidak dibuat world-writable seperti 777 (file permissions). Kedua panduan mendukung pemeriksaan berlapis—bukan satu aturan ekstensi.

Hentikan paparan tanpa menghilangkan jejak

Jika file berada di URL publik dan ada indikasi script dieksekusi, segera hubungi hosting. Minta mereka membatasi akses ke path atau menonaktifkan handler script pada lokasi tersebut sesuai stack yang digunakan. Jangan mengetik URL langsung, memakai curl yang mengikuti redirect, atau meminta pengunjung “cek apakah file terbuka”. Status akses dapat dicek oleh provider melalui log atau uji yang terkendali pada salinan terisolasi.

Sebelum perubahan, catat:

• Path lengkap relatif terhadap root, nama file, ekstensi dan huruf besar/kecil, ukuran, owner/group, permission, inode bila tersedia, serta waktu create/modify yang dilaporkan filesystem.
• Hash SHA-256 dan salinan bukti yang disimpan di luar webroot dengan akses terbatas. Simpan juga salinan kerja yang dapat dipindai di lingkungan terisolasi.
• URL terkait, response status, Content-Type, request ID, waktu, IP yang disamarkan sesuai kebijakan, dan potongan access/error log yang relevan.
• Versi backup terakhir yang diketahui bersih, plugin/theme yang mengelola upload, akun yang bisa menulis ke directory, dan perubahan sebelumnya.

Jangan mengubah timestamp atau membuka file untuk menjalankannya. Jika isi perlu dianalisis, minta analis melakukannya di lingkungan terisolasi. File dapat menyimpan password, data pelanggan, atau kode yang berbahaya; jangan menempelkan isi mentah ke forum publik.

Inventarisasi file tanpa mengeksekusinya

Pada salinan filesystem atau sesi shell read-only yang disetujui host, inventarisasi tipe script yang umum dan variasinya:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' -o -iname '*.php5' -o -iname '*.php7' \) -print

Jalankan dari root instalasi yang benar; multisite, folder uploads kustom, symlink, dan mount hosting dapat mengubah cakupan. Perintah itu hanya mencetak nama file, bukan menyatakan semuanya berbahaya. Catat pula file tersembunyi, nama ganda seperti image.php.jpg, subfolder baru, serta file konfigurasi seperti .htaccess atau .user.ini yang mengubah cara server menangani konten.

Bandingkan temuan dengan backup bersih dan paket plugin/theme yang tepercaya. Perhatikan owner, permission, jalur parent, waktu perubahan, referensi dari database, dan log proses upload. Timestamp bisa dipalsukan; hash yang cocok dengan file vendor atau backup memberi bukti lebih kuat, tetapi file sah tetap perlu konteks. Jika PHP memang dipakai aplikasi khusus di uploads, dokumentasikan siapa pemiliknya dan mengapa file tersebut berada di sana.

Telusuri bagaimana file tersebut dibuat

1. Audit jalur upload. Periksa formulir frontend, REST/AJAX endpoint, plugin media, plugin import, integrasi, dan akses SFTP/FTP. Pastikan upload memerlukan izin yang sesuai, tipe yang diizinkan dibatasi, nama file dibuat aman, dan konten divalidasi di server.
2. Cocokkan waktu dengan log. Cari POST ke endpoint upload, autentikasi admin/hosting, permintaan ke file baru, perubahan plugin, restore backup, dan task terjadwal pada rentang yang sama. Jangan menganggap jam file sebagai satu-satunya sumber waktu.
3. Periksa persistence di luar folder. Cari file yang memanggil path tersebut, akun asing, plugin/theme berubah, cron, database, .htaccess, .user.ini, konfigurasi PHP, backup otomatis, serta rule CDN. Satu file mungkin hanya loader; file lain bisa membuatnya kembali.
4. Periksa integrity yang relevan. wp core verify-checksums membandingkan file inti WordPress, bukan uploads. wp plugin verify-checksums --all dapat membantu untuk plugin WordPress.org yang mendukungnya; komponen premium, custom, dan data aplikasi perlu sumber pembanding lain. Lihat panduan WP-CLI security checks.
5. Tentukan dampak pada pengunjung. Minta host memastikan apakah PHP handler dapat berjalan pada path itu dan apakah permintaan publik pernah menerima output yang bukan media. Jangan membuktikannya dengan mengeksekusi file berbahaya di production.

Jangan menganggap semua uploads berada pada satu batas keamanan. Instalasi multisite dapat menyimpan media per site ID; plugin dapat memakai subfolder; symlink atau mount dapat menghubungkan path ke lokasi lain. Pastikan root yang diperiksa benar dan tanyakan kepada provider apakah beberapa website berbagi user sistem atau direktori yang dapat ditulis. Ini membantu menentukan apakah satu temuan hanya mengenai satu site atau berpotensi memengaruhi tenant lain. Catat juga apakah file muncul di backup otomatis, karena restore dapat menyalinnya lagi tanpa penyerang mengunggah ulang.

Bedakan file yang ada, file yang dapat diakses, dan kode yang dieksekusi

Keberadaan nama file di directory tidak sama dengan bukti bahwa server menjalankannya. Sebaliknya, respons 403 atau 404 dari satu browser tidak membuktikan bahwa file tidak dapat dipanggil melalui origin lain, variasi path, CDN, atau aturan handler yang berbeda. Jangan meminta pengunjung menguji URL tersebut. Minta provider mengonfirmasi pemetaan handler di server dan membandingkan log origin dengan edge; bila perlu lakukan tes pada salinan staging menggunakan prosedur canary yang disiapkan administrator, bukan dengan membuat web shell.

Pada salinan bukti read-only, perintah metadata seperti stat dan sha256sum dapat membantu mengikat temuan ke hash dan waktu tanpa mengeksekusi isi file:

stat --printf='%n %s %U:%G %a %y' -- 'wp-content/uploads/path/suspect.php'
sha256sum -- 'wp-content/uploads/path/suspect.php'

Simpan output di tiket terbatas dan tulis versi utilitas/OS bila perlu. Jika host tidak menyediakan shell, minta mereka mengekspor metadata dan log melalui kanal support resmi. Jangan mengirim salinan ke layanan analisis publik sebelum memastikan tidak ada data pribadi, rahasia, atau aturan kontrak yang melarangnya.

Hapus atau karantina hanya setelah sumber dan bukti jelas

Jika file terbukti tidak sah, simpan bukti, hentikan akses publik, lalu karantina di luar webroot dengan izin terbatas atau hapus sesuai arahan host dan prosedur insiden. Jangan meninggalkan file karantina di folder yang masih dilayani web server. Setelah file dibuang, periksa kembali struktur folder, symlink, variasi ekstensi, dan akun/proses yang dapat menulis di sana. Jika file muncul lagi, hentikan penghapusan berulang dan telusuri persistence seperti yang dijelaskan pada cara menemukan backdoor WordPress; eskalasi ke tim teknis bila perlu.

Jangan memulihkan folder uploads seluruhnya dari backup lama tanpa membandingkan media bisnis yang baru diunggah dan kemungkinan bahwa backup itu sudah terinfeksi. Buat daftar aset yang harus dipertahankan, hash file penting, dan lakukan restore selektif pada salinan uji. Konten database yang merujuk file harus ditinjau sebelum file sah dipulihkan. Sebelum memutuskan restore, uji backup dan pastikan salinan yang dipilih mendahului kompromi; lihat prinsip backup website yang dapat dipulihkan.

Mencegah PHP dieksekusi dari uploads

Minta administrator server menerapkan kontrol sesuai stack—Apache, Nginx, LiteSpeed, container, atau layanan managed hosting. Tidak ada satu potongan .htaccess yang berlaku untuk semuanya; Nginx tidak membaca .htaccess, dan plugin atau multisite bisa menggunakan aturan yang berbeda. Pastikan aturan ditempatkan di konfigurasi yang benar, tidak tertimpa blok WordPress, dan tidak mematikan fungsi upload/media yang sah.

Uji di staging dengan file statis yang aman dan akun yang disetujui: media harus bisa diakses sesuai kebutuhan, sedangkan script yang tidak diizinkan tidak boleh dijalankan. Gunakan file uji yang tidak memiliki kode executable dan jangan mengunggah web shell sebagai tes. Pastikan akses melalui origin maupun CDN menghasilkan kebijakan sama; cache tidak boleh melayani salinan lama. Host juga dapat memindahkan data upload ke lokasi non-executable, membatasi izin tulis, membatasi tipe file per kebutuhan, dan mengaktifkan logging/alert terhadap file baru.

Kesalahan umum yang memperburuk kasus

• Menghapus file sebelum menyalin hash dan log, sehingga jejak jalur masuk hilang.
• Menganggap setiap file dengan ekstensi .php pasti malware, atau menganggap nama seperti image.php.jpg pasti aman.
• Mengunjungi URL untuk “memastikan PHP berjalan”; hal itu dapat menjalankan kode berbahaya atau memicu redirect.
• Menyalin aturan Apache ke Nginx, menambahkan deny rule tanpa backup, atau mengedit konfigurasi production tanpa persetujuan host.
• Hanya memindai uploads dan melewatkan database, plugin, administrator, konfigurasi server, atau cron yang menulis ulang file.
• Mengubah semua permission ke 777 atau membuat directory upload dapat ditulis oleh semua proses.
• Memasang scanner baru lalu menghapus semua temuannya tanpa membedakan false positive, file vendor, dan bukti insiden.

Apakah semua file PHP di uploads harus dihapus? Tidak otomatis. Periksa owner, fungsi, sumber plugin, hash, dan log; aplikasi khusus dapat memiliki file sah. Hapus hanya file yang terbukti tidak diperlukan atau berbahaya setelah bukti diamankan.

Apakah nama .php.jpg pasti aman? Tidak. Server, handler, plugin, atau aturan salah konfigurasi dapat menafsirkan nama dan ekstensi secara berbeda. Jangan menguji dengan mengeksekusi file; minta host memeriksa pemetaan handler dan gunakan salinan aman.

Apakah wp core verify-checksums memeriksa folder uploads? Tidak. Perintah itu membandingkan file core. Upload, plugin non-WordPress.org, theme custom, konfigurasi server, dan database perlu pemeriksaan lain.

Kapan saya harus eskalasi? Segera bila file dapat diakses publik, payment/login terpengaruh, file muncul kembali, Anda tidak memiliki akses log, atau tidak yakin cara membatasi eksekusi tanpa membuat website down.

Jika file asing muncul di uploads setelah dugaan peretasan, minta audit keamanan WordPress untuk memeriksa entry point, perubahan file, dan kontrol server tanpa menghapus bukti secara acak.