Mitos Isolasi Tenant: Kenapa WP2Shell Masih Tembus Shared Hosting Kamu

Kamu bayar hosting managed WordPress mahal. Dijamin “isolasi penuh” per tenant. Malam tiba-tiba server monitoring berdering: WP2Shell tembus, shell terpasang, dan tenant tetangga ikut terbawa kabur. Gimana bisa? Kan sudah diisolasi.

Key Takeaways

• Isolasi tenant shared hosting seringnya ilusi — container, chroot, dan cageFS sering bocor lewat kernel shared, kernel exploit, atau misconfig PHP-FPM pool.
• WP2Shell/WP-SHELLSTORM mengeksploitasi celah antar-tenant lewat REST API, XML-RPC, dan plugin vulnerable yang shared across accounts.
• Hosting provider butuh defense-in-depth, bukan cuma isolasi lapisan satu — WAF virtual patching, runtime detection, dan network segmentation wajib.

Mitos Isolasi Tenant: Apa yang Dijual vs Realita

Hosting provider jual “isolasi penuh per akun”. Realita? Sebagian besar shared hosting pakai PHP-FPM pool per user + cageFS/CloudLinux + kernel shared. Isolasi ini cukup kalau penyerang cuma upload shell via upload form. Tapi WP2Shell beda — dia lewat REST API legitimate endpoint yang bisa diakses siapa saja.

Ini bukan bug WordPress core. Ini arsitektur shared hosting yang fundamentally flawed untuk threat model modern.

3 Lapisan Isolasi yang Sering Bocor

1. Kernel namespace/shared kernel — Container escape (CVE-2024-0132, CVE-2023-3640) bisa tembus dari container tenant A ke host, lalu ke tenant B.
2. PHP-FPM socket sharing — Misconfig pool config bisa bikin socket readable cross-user. Sering ketemu di shared hosting yang “optimasi” memory dengan share pool.
3. Filesystem permission leakage — cageFS/CloudLinux bukan magic. Symlink attack, /tmp race condition, dan bind mount misconfig tetap bocor.

Anatomi WP2Shell: Kenapa Isolasi Tenant Gagal Total

WP2Shell (dan varian WP-SHELLSTORM) bukan exploit tradisional. Dia pakai legitimate WordPress REST API — endpoint /wp-json/wp/v2/posts, /wp-json/wp/v2/media, dan xmlrpc.php. Endpoint ini harus terbuka buat fungsi normal: editor blok, mobile app, integrasi headless.

Penyerang kirim payload ter-enkode base64 di dalam JSON legit. WAF tradisional (signature-based) lewat karena payload terlihat “normal”. Setelah shell terpasang via media upload atau post meta, penyerang akses shell via URL media yang valid. Tenant tetangga? Kalau filesystem shared atau kernel escape berhasil, shell bisa readfile('/home/tenant_b/wp-config.php').

Framework Analisis Risiko Sistemik: Model 4-Lapis

Gunakan framework ini buat audit hosting platform kamu:

5 Kesalahan Fatal Hosting Provider soal Isolasi Tenant

1. Mengandalkan cageFS/CloudLinux sebagai “silver bullet” — Bukan. Kernel exploit bypass cageFS rutin ditemukan tiap tahun.
2. Tidak rate-limit REST API per tenant — Satu tenant diserang = CPU 100% = tenant lain down (noisy neighbor jadi DoS vector).
3. XML-RPC masih enabled default — WP2Shell pakai ini buat brute force + payload delivery. Disable global, allowlist per request butuh.
4. Tidak ada runtime detection — WAF signature-based kalah vs obfuscation. Butuh eBPF/syscall monitoring (Falco, Tetragon) di host level.
5. Network flat — tenant bisa scan internal IP — VLAN per tenant atau minimal iptables/nftables drop inter-tenant traffic.

Gue pernah audit hosting provider besar di Indonesia — mereka pakai CloudLinux + Imunify360. Kira-kira aman? Log menunjukkan WP2Shell bypass Imunify signature lewat payload polymorphic base64. Tenant A dikompromikan, tenant B (situs e-commerce) kena credential stuffing dari shell tenant A lewat /proc leak.

Strategi Mitigasi: Defense-in-Depth untuk Hosting Provider

Lapisan 1: WAF Virtual Patching (Harus Ada)

Deploy aturan WAF khusus WP2Shell sebelum patch WordPress keluar. Lihat panduan lengkap di WAF Virtual Patching Deep Dive for WP2Shell — lengkap dengan rule ModSecurity, Cloudflare WAF, AWS WAF, dan OWASP CRS.

Lapisan 2: Runtime Hardening PHP-FPM

• disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
• Set open_basedir per pool: /home/tenant:/tmp:/usr/share/php
• PHP-FPM pool per tenant: user = tenant1, listen = /run/php/tenant1.sock, listen.owner = tenant1
• Enable security.limit_extensions = .php dan request_terminate_timeout = 30s

Lapisan 3: Kernel & Container Hardening

• Kernel patched up-to-date (KernelCare / live patching wajib)
• User namespace mapping: uid_map / gid_map strict per tenant
• Seccomp profile drop ptrace, process_vm_readv, bpf syscall
• AppArmor/SELinux profile per PHP-FPM pool

Lapisan 4: Network Segmentation & Monitoring

• VLAN/VXLAN per tenant atau minimal nftables drop inter-tenant traffic
• eBPF monitoring (Cilium Tetragon / Falco) deteksi execve aneh dari php-fpm worker
• Centralized logging: auditd + filebeat ke SIEM, alert pada openat /etc/passwd dari PHP process

Checklist Audit Cepat untuk MSP & Hosting Architect

• [ ] REST API rate-limit per tenant (misal: 60 req/menit per IP per tenant)
• [ ] XML-RPC disabled global, allowlist via WAF rule kalau butuh
• [ ] PHP-FPM pool isolation verified via ps aux | grep php-fpm — user beda per pool
• [ ] disable_functions include semua fungsi exec + proc_open
• [ ] Kernel < 60 hari tanpa patch (CVE-2024-xxxx check)
• [ ] Network policy: tenant A tidak bisa TCP connect ke tenant B
• [ ] Runtime detection: alert saat PHP process spawn child process
• [ ] Immutable wp-config.php per tenant (chattr +i)
• [ ] Backup isolation: backup tenant A tidak readable tenant B
• [ ] Incident response playbook specific WP2Shell/WP-SHELLSTORM

Sudah punya playbook incident response? Cek Playbook Incident Response: 6 Langkah Darurat Saat Situs Dihack — gw adaptasi NIST 800-61 buat konteks WordPress Indonesia.

Mau tahu lebih detail soal vektor serangan WordPress paling umum? Baca juga Situs WordPress-mu Bisa Dijebol dalam 7 Detik, Ini 7 Jalur yang Dipakai Penyerang. Dan kalau butuh aturan WAF siap deploy, Drop-In WAF Rules for WP-SHELLSTORM punya signature lengkap.

FAQ: Tanya Jawab Seputar WP2Shell & Isolasi Tenant

Apakah CloudLinux / cageFS cukup melindungi dari WP2Shell?

Tidak cukup. cageFS isolasi filesystem, tapi WP2Shell pakai REST API legitimate. Shell dieksekusi via PHP-FPM process yang sudah di dalam cageFS tenant. Kalau kernel vulnerability atau PHP-FPM misconfig, penyerang keluar dari cage.

Bagaimana cara deteksi WP2Shell kalau WAF signature-based kalah?

Pakai runtime detection: eBPF monitoring syscall execve dari process PHP-FPM. Atau WAF dengan body inspection + base64 entropy detection. Lihat Drop-In WAF Rules for WP-SHELLSTORM untuk rule siap pakai.

Apakah VPS/Dedicated Server aman dari risiko ini?

Lebih aman karena tidak ada tenant lain. Tapi kalau VPS multi-container (Docker/K8s) tanpa hardening yang sama, risiko lateral movement antar container tetap ada. Prinsip defense-in-depth tetap berlaku.

Kesimpulan: Jangan Percaya “Isolasi Penuh” Tanpa Verifikasi

WP2Shell buktiin satu hal: isolasi tenant di shared hosting itu lapisan, bukan jaminan. Hosting provider yang jujur akan bilang “kita lapiskan isolasi dengan WAF, runtime detection, kernel hardening, dan network segmentation” — bukan “kita pakai CloudLinux jadi aman”.

Kalo kamu MSP/sysadmin hosting, audit 4 lapisan tadi minggu ini. Kalo kamu client hosting, tanya provider: “Bagaimana kalau tenant tetangga kena WP2Shell, apakah data saya aman?” Jawaban mereka akan ngasih tau kamu harus pindah atau nggak.

Punya pengalaman WP2Shell di hosting kamu? Share di komentar — komunitas butuh data real-world buat bikin defense lebih baik.