Ilustrasi konseptual pengamanan layanan digital kampus. Bukan dokumentasi insiden.

Fakultas Ilmu Komputer UPN Veteran Jakarta
Pembaruan informasi 22 Oktober 2026

Fakultas Ilmu Komputer UPN Veteran Jakarta dengan koordinasi bersama Tim CNC Research Group (Computer Network and Cybersecurity) yang dipimpin oleh Prof. Dr. Ir. Supriyanto, ST., M.Sc., IPM mengimbau seluruh pengelola website dan aplikasi berbasis PHP untuk segera memeriksa sistem serta menerapkan pembaruan keamanan PHP. Prioritaskan layanan yang dapat diakses dari internet dan layanan yang mengelola akun atau data pengguna.

PHP2Shell merupakan sebutan untuk dua kerentanan kritis PHP, yaitu CVE-2026-109618 dan CVE-2026-109619, dengan nilai CVSS v4.0 sebesar 9,2. PHP telah menerbitkan rilis perbaikan pada 21 Oktober 2026. Kerentanan ini dapat memungkinkan penyerang menjalankan kode pada server tanpa autentikasi. [1][2][3]

Apa yang perlu diketahui

Masalah berada pada runtime atau mesin PHP yang menjalankan aplikasi. Dampaknya dapat menjangkau berbagai website, termasuk CMS dan aplikasi yang dikembangkan sendiri, apabila menggunakan PHP yang rentan. Penelitian juga menunjukkan potensi terbukanya informasi sensitif dari memori proses, seperti token dan kredensial. Pembaruan CMS, tema, plugin, atau kode aplikasi saja belum menyelesaikan kerentanan pada runtime PHP. [4]

Cloudflare melaporkan telah mengamati trafik serangan yang menargetkan kerentanan ini. Situasi tersebut perlu ditindaklanjuti segera, tetapi tidak membuktikan bahwa website tertentu telah berhasil disusupi. Penetapan insiden pada suatu sistem memerlukan pemeriksaan oleh pengelola dan tim keamanan. [5]

Website yang perlu diperiksa

Periksa portal fakultas dan program studi, website laboratorium, layanan pembelajaran, jurnal, formulir daring, serta aplikasi administrasi yang menggunakan PHP. Cakupan pemeriksaan meliputi hosting bersama, VPS, mesin virtual, container, dan produk pihak ketiga yang menyertakan PHP. Jangan melewatkan subdomain lama, lingkungan pengujian yang terbuka ke internet, maupun replika di belakang load balancer. [6]

Versi PHP yang menerima perbaikan

Tabel menunjukkan rilis perbaikan untuk kedua CVE tersebut dalam masing-masing cabang, berdasarkan informasi per 22 Oktober 2026. Gunakan rilis terbarui yang didukung dan kompatibel dengan aplikasi. Untuk paket distribusi atau vendor yang menerapkan backport, pastikan advisory vendor menyatakan kedua CVE telah diperbaiki; nomor versi dasar saja belum cukup untuk menilai statusnya. PHP 8.1 dan versi lebih lama memerlukan penanganan vendor atau migrasi ke cabang yang didukung. [1][3]

Tindakan segera bagi pengelola website

1 Tetapkan penanggung jawab dan inventarisasi layanan

Catat URL, pemilik layanan, penyedia hosting, cara PHP dijalankan, versi atau paket runtime yang aktif, serta status akses publik. Hubungi penyedia hosting bila pengelola website tidak memiliki akses ke pembaruan PHP. Minta bukti versi atau paket perbaikan dan konfirmasi waktu penerapannya. [6]

2 Perbarui PHP yang benar-benar melayani website

Terapkan paket resmi yang memperbaiki kedua CVE. Pada container, perbarui image dan buat ulang container; perubahan PHP di host belum tentu memperbaiki PHP di dalam container. Terapkan perbaikan pada seluruh node dan replika. Pastikan worker atau layanan yang relevan dimulai ulang sesuai petunjuk paket agar proses lama tidak terus berjalan. [1][6]

3 Batasi akses publik apabila perbaikan belum dapat diterapkan

Koordinasikan pembatasan akses dengan pengelola infrastruktur. Gunakan aturan jaringan atau reverse proxy untuk membatasi seluruh layanan PHP yang rentan, lalu tampilkan informasi pemeliharaan melalui halaman statis yang terpisah dari runtime tersebut. Menutup halaman login saja dapat menyisakan endpoint PHP lain yang tetap terbuka. CERT-EU merekomendasikan pertimbangan isolasi dari jaringan publik sampai perbaikan diterapkan dan diverifikasi. [3]

4 Pertahankan perlindungan tambahan sambil menyelesaikan patch

Jika menggunakan WAF atau CDN, ikuti petunjuk penyedia dan pastikan perlindungan PHP2Shell aktif. Tinjau akses langsung ke origin agar pembatasan tidak dilewati. Sesuaikan batas ukuran permintaan dan fasilitas unggah menurut kebutuhan layanan. WAF dan perubahan konfigurasi hanya mengurangi paparan serta tidak menggantikan pembaruan PHP. [1][5]

5 Periksa indikasi kompromi dan lindungi bukti

Minta tim teknis meninjau log akses dan error, peringatan keamanan, perubahan berkas atau akun tanpa izin, proses turunan PHP yang tidak diharapkan, serta koneksi keluar yang mencurigakan. Temuan tersebut adalah petunjuk untuk diteliti, bukan bukti tunggal eksploitasi PHP2Shell. Bila ada dugaan kompromi, isolasi sistem dan koordinasikan pengamanan log serta snapshot sebelum pembersihan menghilangkan bukti. Eskalasikan kepada unit TIK atau tim respons insiden yang berwenang. [6][7]

6 Verifikasi perbaikan sebelum memulihkan akses

Periksa runtime yang digunakan oleh request website pada setiap node; pemeriksaan PHP melalui terminal saja dapat menunjukkan instalasi yang berbeda. Konfirmasikan paket perbaikan, jalankan uji fungsi penting, dan tinjau kembali temuan keamanan. Jika kompromi terindikasi, pemulihan perlu mencakup pemeriksaan persistensi, penggunaan lingkungan bersih, serta pencabutan sesi dan rotasi rahasia yang berpotensi terekspos dari lingkungan tepercaya. Jangan menganggap patch otomatis membersihkan sistem yang sudah disusupi. [6][7]

Alur keputusan mitigasi

Komunikasi yang perlu disampaikan kepada pengguna

Pengelola diminta menyampaikan informasi melalui kanal resmi ketika pembatasan akses, pemeliharaan, atau pemeriksaan memengaruhi pengguna. Pesan perlu menjelaskan layanan yang terpengaruh, waktu mulai beserta zona waktu WIB, tindakan yang sedang dilakukan, pilihan layanan sementara, dan waktu pembaruan informasi berikutnya.

Gunakan status sesuai fakta: pemeliharaan preventif, pemeriksaan atas indikasi insiden, atau insiden yang telah terkonfirmasi. Pernyataan tentang kebocoran data dan cakupannya harus mengikuti hasil pemeriksaan. Jika dampak pada data pengguna terkonfirmasi, koordinasikan pemberitahuan khusus dengan unit yang berwenang. Komunikasi pemulihan juga perlu menjelaskan layanan yang telah tersedia dan batasan yang masih berlaku. [7]

Sampaikan bahwa petugas tidak meminta kata sandi atau kode OTP melalui pesan. Berikan tautan resmi yang dapat diperiksa pengguna, dan arahkan laporan ke kanal yang dikelola institusi.

Arahan bagi pengguna layanan

• Pantau pengumuman melalui website dan kanal resmi FIK atau UPNVJ. Gunakan layanan alternatif hanya melalui tautan yang telah diumumkan secara resmi.
• Waspadai pesan yang mengatasnamakan tim perbaikan dan meminta kata sandi, OTP, pembayaran, atau pemasangan aplikasi. Jangan memasukkan kredensial melalui tautan yang tidak dapat diverifikasi.
• Laporkan perubahan halaman yang mencurigakan, pengalihan alamat, atau aktivitas akun yang tidak dikenal. Jika menerima pemberitahuan resmi bahwa akun mungkin terdampak, ikuti arahan pengamanan akun melalui kanal resmi.

Pelaporan dan pemantauan perkembangan

Pengelola website diminta melaporkan status pemeriksaan dan mitigasi melalui https://servicedesk.upnvj.ac.id/id/portal atau hubungi via Whatsapp. Cantumkan nama layanan, URL, penanggung jawab, status perbaikan, kendala, dan dampak terhadap layanan. Kirim detail teknis sensitif melalui kanal internal yang ditentukan.

Pengguna dapat memantau perkembangan melalui https://upatik.upnvj.ac.id/ atau https://new-fik.upnvj.ac.id. Informasi akan diperbarui mengikuti perkembangan advisory dan hasil pemeriksaan layanan terkait.

Referensi resmi dan bacaan teknis

Informasi rilis dan rekomendasi diperiksa pada 22 Oktober 2026. Periksa kembali advisory sebelum menerbitkan pembaruan berikutnya.

[1] PHP  Security advisory dan rilis perbaikan 21 Oktober 2026
[2] PHP Security  Advisory teknis kedua CVE
[2b] PHP Security  RCE via stale global state
[3] CERT-EU  Security Advisory 2026-018 Critical Vulnerabilities in PHP
[4] Wiz Research  PHP2Shell
[5] Cloudflare  Cloudflare deploys protections against php2shell vulnerability
[6] NCSC-NL  Operational information regarding php2shell
[7] NIST  SP 800-61 Revision 3

Contoh pemberitahuan kepada pengguna

Pilih contoh sesuai kondisi layanan dan ganti seluruh bagian berwarna kuning sebelum digunakan. Contoh ini dipakai sebagai pesan tersendiri sesuai kebutuhan komunikasi.

Pemberitahuan pemeliharaan preventif

Kami sedang melakukan pemeliharaan keamanan pada [NAMA LAYANAN] untuk menerapkan pembaruan PHP terkait PHP2Shell. Akses [DIBATASI ATAU DIHENTIKAN SEMENTARA] sejak [TANGGAL DAN JAM WIB].

Selama pemeliharaan, [LAYANAN ALTERNATIF ATAU PETUNJUK PENGGUNA]. Pembaruan berikutnya akan disampaikan pada [TANGGAL DAN JAM WIB] melalui [KANAL RESMI]. Kontak bantuan [KONTAK RESMI]. Petugas tidak meminta kata sandi atau OTP.

Pemberitahuan pemeriksaan indikasi insiden

Kami menemukan indikasi aktivitas tidak wajar pada [NAMA LAYANAN] dan sedang melakukan pemeriksaan. Akses layanan [STATUS AKSES] sejak [TANGGAL DAN JAM WIB] untuk mendukung penanganan.

Cakupan dan dampaknya terhadap data pengguna masih diperiksa. [TINDAKAN PENGGUNA YANG SUDAH DITETAPKAN TIM]. Pembaruan berikutnya disampaikan pada [TANGGAL DAN JAM WIB] melalui [KANAL RESMI]. Bantuan tersedia di [KONTAK RESMI].

Pemberitahuan pemulihan layanan

Akses [NAMA LAYANAN] telah dipulihkan pada [TANGGAL DAN JAM WIB] setelah [TINDAKAN DAN VERIFIKASI YANG BENAR-BENAR SELESAI]. Tim melanjutkan pemantauan terhadap layanan.

[BATASAN LAYANAN ATAU ARAHAN PENGGUNA YANG MASIH BERLAKU]. Informasi mengenai dampak terhadap data disampaikan berdasarkan hasil pemeriksaan melalui [KANAL RESMI]. Hubungi [KONTAK RESMI] bila masih mengalami gangguan.