---
title: "PHP2Shell: Cara Mengamankan Server Perusahaan"
locale: id
category: how_to
category_name: "Panduan"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide
published_at: 2026-10-24T16:09:48+09:00
---

# PHP2Shell: Cara Mengamankan Server Perusahaan

> Penanganan PHP2Shell dimulai dengan memperbarui dan memulai ulang PHP pada layanan web yang berjalan. Jika ada dugaan penyusupan, amankan bukti terlebih dahulu. Setelah patch diterapkan, log tetap perlu diperiksa dan kredensial diganti.

## Key Points

- Periksa penggunaan PHP pada server yang sedang beroperasi dan produk dengan PHP bawaan.
- Jika ada dugaan penyusupan, isolasi server dan amankan bukti sebelum memulai ulang server.
- Terapkan versi perbaikan atau gunakan langkah sementara resmi hingga pembaruan dilakukan.
- Mulai ulang layanan yang menjalankan PHP, lalu pastikan patch telah diterapkan pada layanan web yang berjalan.
- Periksa log terdahulu dan ganti kredensial server yang terekspos.

Penanganan PHP2Shell dimulai dengan memeriksa penggunaan PHP dan menerapkan versi yang telah diperbaiki. Setelah pembaruan, mulai ulang layanan yang menjalankan PHP. Jika ada dugaan peretasan, bukti harus diamankan sebelum layanan dimulai ulang. Setelah pemasangan patch, pemeriksaan log dan penggantian kredensial tetap diperlukan.

Versi dan pengaturan mengacu pada pengumuman KISA tanggal 22 Oktober 2026 dan pengumuman tambahan PHP tanggal 23 Oktober.

## Apa itu kerentanan PHP2Shell?

PHP2Shell adalah kerentanan PHP yang memungkinkan eksekusi kode di server tanpa autentikasi. Masalahnya terletak pada pengelolaan memori saat server web memproses permintaan. Keberhasilan serangan bergantung pada lingkungan eksekusi dan pengaturannya.

| Kategori | Nomor identifikasi | Sifat masalah |
| --- | --- | --- |
| Masalah penanganan kehabisan memori | CVE-2026-109618 | Memproses data internal yang tidak lengkap saat memori habis |
| Masalah status yang tertinggal antarpermintaan | CVE-2026-109619 | Menggunakan status yang menunjuk ke memori yang telah dibebaskan pada permintaan berikutnya |

KISA menyatakan bahwa kedua kerentanan memiliki tingkat keparahan CVSS 9.2. Jika serangan berhasil, penyerang dapat memasang webshell atau membocorkan informasi pelanggan. Webshell adalah berkas yang disalahgunakan untuk mengendalikan server dari jarak jauh. Serangan juga dapat berlanjut menjadi pengubahan tampilan situs dan penyusupan ke jaringan internal.

KISA menginformasikan adanya kebocoran informasi dan upaya serangan sebelum patch dirilis. Para peneliti memublikasikan proses penemuan kerentanan dengan bantuan AI. Masalah ini terdapat pada PHP itu sendiri, sehingga tidak terbatas pada produk situs web tertentu. [Panduan penanganan untuk perusahaan dari KISA](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230), [Penjelasan PHP2Shell dari para peneliti](https://www.php2shell.com/)

## Urutan penanganan berdasarkan kondisi

Urutan pembaruan dan pengamanan bukti bergantung pada ada tidaknya dugaan peretasan. Dalam pemasangan patch rutin, lakukan pembaruan dan mulai ulang setelah pengujian. Isolasi terlebih dahulu server yang diduga telah diretas.

| Kondisi saat ini | Tindakan pertama | Tindakan berikutnya |
| --- | --- | --- |
| Server yang terbuka ke internet tanpa indikasi peretasan | Tinjau kompatibilitas dan terapkan versi yang telah diperbaiki | Mulai ulang, pastikan versi yang benar-benar berjalan, dan periksa log |
| Ditemukan webshell atau koneksi mencurigakan | Isolasi jaringan dan laporkan | Lakukan pemulihan setelah bukti diamankan |
| Server yang sulit diperbarui segera | Terapkan pengaturan sementara resmi dan pembatasan permintaan di lapisan depan | Susun jadwal pemasangan patch dan terapkan |
| Server yang sulit menerapkan tindakan sementara sekalipun | Pertimbangkan pemblokiran akses eksternal atau penghentian sementara | Tentukan apakah layanan dapat dilanjutkan setelah pemasangan patch |
| Lingkungan yang dikelola penyedia hosting atau produsen | Konfirmasikan penerapannya kepada pihak pengelola | Dapatkan bukti bahwa perubahan telah diterapkan pada lingkungan eksekusi |

Memulai ulang setelah pembaruan diperlukan agar kode yang telah diperbaiki dapat dijalankan. Dalam penanganan insiden, proses mulai ulang ditunda untuk mengamankan bukti. Bahkan pada server yang sama, ikuti urutan kedua jika ada dugaan peretasan.

## Cara memeriksa penggunaan PHP

Periksa daftar aset sekaligus server yang benar-benar beroperasi. Jika hanya memeriksa situs utama, server yang luput dari pengelolaan bisa terlewat. Perangkat dan kontainer yang menyertakan PHP juga harus diperiksa.

1. Buat daftar situs web dan sistem yang terbuka ke internet.
2. Periksa situs yang dibuat oleh pihak luar dan situs lama.
3. Periksa server acara, server pengujian, dan halaman administrator.
4. Periksa apakah antarmuka pengelolaan perangkat dan solusi menyertakan PHP.
5. Periksa image kontainer dan kontainer yang sedang berjalan.
6. Catat versi PHP dan penanggung jawab pengelolaan setiap lingkungan.

Jika menggunakan hosting, mintalah penyedia mengonfirmasi apakah patch telah diterapkan. Untuk PHP yang disertakan dalam perangkat, periksa pembaruan dari produsen. Periksa juga sistem internal, tetapi tangani server yang terbuka ke internet terlebih dahulu.

## Versi PHP yang telah diperbaiki dan ketentuan berakhirnya dukungan

Versi perbaikan untuk seri 8.5 dalam pengumuman resmi PHP adalah **8.5.12**. Pengumuman asli KISA juga menyebutkan versi yang sama. Ini bukan berarti Anda harus menunggu 8.5.13 untuk memasang patch.

| Seri yang digunakan | Versi yang memperbaiki kedua kerentanan | Acuan penanganan |
| --- | --- | --- |
| PHP 8.5 | 8.5.13 atau lebih baru | Periksa rilis keamanan terbaru untuk seri tersebut |
| PHP 8.4 | 8.4.27 atau lebih baru | Periksa rilis keamanan terbaru untuk seri tersebut |
| PHP 8.3 | 8.3.36 atau lebih baru | Periksa rilis keamanan terbaru untuk seri tersebut |
| PHP 8.2 | 8.2.35 atau lebih baru | Siapkan peralihan ke seri yang lebih baru bersamaan dengan pemasangan patch |
| PHP 8.1 atau lebih lama | Dukungan keamanan reguler telah berakhir | Beralih ke seri yang didukung atau periksa patch dari pemasok |

Tabel ini mengacu pada versi perbaikan yang diumumkan pada 21 Oktober 2026. Nomor versi yang ditampilkan pada paket distribusi mungkin tetap sama. Dalam hal ini, periksa riwayat perubahan untuk memastikan apakah kedua CVE telah diperbaiki. [Pengumuman rilis keamanan PHP](https://www.php.net/archive/2026.php)

Dukungan keamanan PHP 8.2 berakhir pada 31 Desember 2026. KISA menyarankan peralihan ke PHP 8.3 atau lebih baru. Uji kompatibilitas aplikasi sebelum beralih. [Jadwal dukungan PHP](https://www.php.net/supported-versions.php)

Dukungan keamanan reguler untuk PHP 8.1 atau lebih lama telah berakhir. Patch dari distribusi atau penyedia dukungan jangka panjang harus diperiksa secara terpisah. Patch kode sumber untuk versi lama yang dirilis kali ini juga tidak berarti dukungan reguler dilanjutkan.

## Cara memperbarui dan memulai ulang

Setelah berkas instalasi diganti, layanan yang menjalankan PHP perlu dimulai ulang. Proses yang sudah berjalan dapat terus menjalankan kode yang masih tersimpan di memori. Jika ada dugaan peretasan, amankan bukti sebelum melakukan langkah-langkah berikut.

1. Tinjau dampak patch terhadap fungsi yang sudah ada.
2. Periksa kompatibilitas layanan di lingkungan pengujian.
3. Terapkan paket perbaikan mulai dari server yang terbuka ke internet.
4. Mulai ulang semua layanan yang menjalankan PHP.
5. Untuk lingkungan kontainer, lakukan deployment ulang menggunakan image yang telah diperbaiki.
6. Pastikan pembaruan telah diterapkan pada PHP yang benar-benar memproses permintaan web.

Layanan yang perlu dimulai ulang mencakup PHP-FPM dan Apache mod_php. Periksa juga php-cgi, FrankenPHP, dan LiteSpeed. Jika terdapat beberapa lingkungan PHP dalam satu server, masing-masing harus diperiksa.

`php -v` menampilkan versi PHP yang dijalankan melalui baris perintah. Versi ini bisa berbeda dari PHP yang digunakan layanan web. Jangan menyimpulkan bahwa pembaruan telah selesai hanya berdasarkan keluaran baris perintah.

## Ketentuan pengaturan sementara sebelum pembaruan

Tindakan sementara merupakan cara untuk mengurangi sebagian jalur serangan. Tindakan ini tidak menyelesaikan seluruh kerentanan. Jika pengaturan sulit diterapkan, pertimbangkan pemblokiran akses eksternal.

### Bagaimana cara menerapkan pengaturan memory_limit?

Rekomendasi sementara resmi untuk kerentanan ini adalah `memory_limit=-1`. Nilai ini menghapus batas penggunaan memori yang ditetapkan oleh PHP sendiri. Jangan menganggapnya sebagai pengaturan operasional biasa.

Penghapusan batas mengurangi jalur tertentu yang memicu kondisi kehabisan memori. Pengaturan ini tidak mencegah kegagalan alokasi memori yang sesungguhnya. Pembatasan ukuran permintaan dan langkah pengelolaan sumber daya harus dipertimbangkan bersamaan. [Rekomendasi untuk kerentanan kehabisan memori PHP](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

| Item | Tindakan sementara resmi | Hal yang perlu diperiksa saat penerapan |
| --- | --- | --- |
| `memory_limit` | Tetapkan ke `-1` | Terapkan pengaturan administrator agar tidak dapat diubah oleh aplikasi |
| `session.upload_progress.enabled` | Tetapkan ke `0` | Gunakan lokasi pengaturan yang diterapkan sebelum pemrosesan permintaan |
| `post_max_size` | Contoh `8M` jika unggahan tidak diperlukan | Tinjau kebutuhan layanan yang sebenarnya sekaligus pembatasan di lapisan depan |
| `upload_max_filesize` | Tetapkan lebih kecil daripada `post_max_size` | Periksa dampaknya terhadap fungsi unggah berkas |
| `fatal_error_backtraces` | Tetapkan ke `0` pada PHP 8.5 | Jangan terapkan secara seragam pada seri lain |

Nilai pengaturan dalam tabel mengacu pada pengumuman penanganan resmi Oktober 2026. `8M` adalah contoh yang diberikan untuk layanan yang tidak memerlukan unggahan. Nilai ini bukan standar ukuran yang harus diterapkan pada semua layanan.

1. Batasi ukuran permintaan pada firewall aplikasi web, server web, dan proksi.
2. Pastikan pembatasan juga berlaku pada permintaan tanpa informasi ukuran.
3. Jika unggahan tidak diperlukan, blokir permintaan multipart di lapisan depan.
4. Periksa aturan pemblokiran terbaru pada firewall aplikasi web.
5. Terapkan pengaturan melalui `php.ini`, pool PHP-FPM, atau lokasi serupa.
6. Mulai ulang proses PHP setelah memastikan apakah pengamanan bukti diperlukan.

Jangan menerapkan pengaturan sementara hanya melalui `ini_set()`. Pengaturan yang diperlukan sebelum pemrosesan permintaan dapat diterapkan terlambat. Jangan mengharapkan `.user.ini` pada PHP-FPM menjalankan peran yang sama. [Tindakan sementara resmi PHP](https://www.php.net/archive/2026.php)

### Hal yang perlu diperiksa dalam pengumuman tambahan 23 Oktober

Dalam pengumuman tambahan, PHP menyarankan agar fitur progres unggahan dinonaktifkan. Pengumuman ini membahas jalur eksekusi terpisah yang masih tersisa pada beberapa kombinasi pengaturan. Jika fitur tersebut sudah dinonaktifkan, PHP menyarankan agar kondisi itu dipertahankan hingga rilis perbaikan reguler berikutnya.

Kondisi tersebut mencakup perubahan metode serialisasi sesi saat program berjalan. Kondisi yang sama tidak berlaku pada semua instalasi PHP. Periksa pengumuman tambahan sebelum memutuskan apakah pengaturan akan dikembalikan setelah pemasangan patch. (Nilai yang dikonfirmasi: session.upload_progress.enabled=0 disarankan tetap dipertahankan hingga rilis perbaikan bug reguler berikutnya · Sumber php.net · Dikonfirmasi pada 2026-10-23) [Pengumuman tambahan PHP Session upload progress](https://www.php.net/archive/2026.php)

## Cara memeriksa log dan mengganti kredensial

KISA menyarankan pemeriksaan catatan **setidaknya sejak 20 Oktober 2026**. Jika memungkinkan, periksa juga catatan sebelum tanggal tersebut. Patch tidak dapat membatalkan peretasan atau kebocoran informasi yang sudah terjadi.

| Sasaran pemeriksaan | Jejak yang perlu diperiksa |
| --- | --- |
| Log server web | Kesalahan HTTP 500 yang berulang |
| Catatan eksekusi PHP | Penghentian tidak normal dan segfault |
| Folder web, unggahan, dan sementara | Berkas PHP yang baru dibuat atau diubah |
| Catatan eksekusi proses | Eksekusi sh, bash, atau alat pengunduhan oleh server web |
| Koneksi jaringan | Jejak koneksi baru ke alamat eksternal yang tidak dikenal |
| Situs web dan halaman pengelolaan | Skrip eksternal yang ditambahkan diam-diam |

Adanya kesalahan saja tidak cukup untuk memastikan bahwa peretasan telah terjadi. Sebaliknya, tidak adanya catatan abnormal juga tidak dapat memastikan keamanan. KISA memberikan arahan berikut.

> Tidak adanya kejanggalan dalam catatan tidak menjamin keamanan, sehingga pembaruan dan penggantian kredensial perlu dilakukan bersamaan
>
> KISA, “Panduan penanganan keamanan perusahaan terkait kerentanan keamanan PHP (PHP2Shell)”

Penggantian kredensial disarankan untuk server yang terekspos ke internet sebelum pemasangan patch. Kredensial pada server yang menunjukkan jejak peretasan wajib diganti. Ini mencakup kata sandi DB dan kata sandi administrator. Periksa juga kemungkinan tereksposnya kunci API dan token akses.

Untuk layanan yang terhubung ke DB data pribadi, periksa juga catatan DB. Jejak kueri dan pengambilan data dalam jumlah besar perlu diperiksa. Batasi juga akses langsung ke phpMyAdmin dari internet. Kurangi hak akses DB milik akun layanan web hingga sebatas yang diperlukan. [Panduan tindakan pencegahan dari 개인정보보호위원회](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Urutan penanganan jika ada dugaan peretasan

Jika ada dugaan peretasan, jangan mematikan atau langsung memulai ulang server. Memulai ulang dapat menghilangkan jejak serangan yang masih tersimpan di memori. Isolasi jaringan terlebih dahulu, lalu amankan bukti.

1. Blokir akses eksternal server melalui jaringan.
2. Perusahaan di Korea Selatan harus melapor melalui menu pelaporan insiden keamanan di 보호나라.
3. Simpan log dan daftar program yang sedang berjalan.
4. Simpan juga informasi koneksi jaringan saat ini.
5. Lakukan pembaruan dan mulai ulang setelah bukti diamankan.
6. Hapus webshell dan ganti kredensial.

Saluran konsultasi di Korea Selatan adalah KISA 118. Jalur menu pelaporan adalah 보호나라 > Pelaporan insiden keamanan > Laporkan. Jika beroperasi di luar Korea Selatan, periksa saluran pelaporan setempat.

## Perbandingan kesalahan umum

Untuk memastikan patch telah diterapkan, status eksekusi dan riwayat perubahan juga harus diperiksa. Pesan bahwa instalasi telah selesai belum cukup untuk menuntaskan pemeriksaan. Masukkan penilaian berikut ke dalam daftar periksa.

| Penilaian yang umum | Hal yang harus diperiksa |
| --- | --- |
| Selesai jika keluaran `php -v` sudah berubah | Periksa PHP yang benar-benar digunakan layanan web |
| Selesai hanya dengan memasang paket | Pastikan layanan yang menjalankan PHP telah dimulai ulang |
| Belum ditangani jika nomor versi tetap sama | Periksa perbaikan CVE dalam riwayat perubahan distribusi |
| Patch dapat dilewati jika ada firewall aplikasi web | Periksa aturan terbaru sekaligus lakukan pembaruan PHP |
| Tidak ada kebocoran jika log bersih | Tinjau juga kemungkinan tereksposnya kredensial |
| Situs yang dibuat pihak luar akan ditangani sendiri oleh penyedia | Minta bukti penerapan untuk setiap layanan |

Jangan menjalankan kode pembuktian yang ditemukan di internet pada server produksi. KISA memperingatkan adanya PoC palsu yang mengandung malware. PoC adalah kode pembuktian yang menunjukkan kemungkinan eksploitasi kerentanan. Untuk menentukan apakah sistem rentan, periksa versi dan riwayat patch terlebih dahulu.

## Daftar periksa penyelesaian tindakan untuk lingkungan alih daya dan hosting

Sebaiknya laporan penyelesaian tindakan menyertakan bukti pemeriksaan untuk setiap layanan. Tabel berikut mengelompokkan panduan penanganan KISA menjadi item pemeriksaan kerja. Ini bukan formulir resmi tersendiri untuk diserahkan.

| Item pemeriksaan | Hal yang perlu diminta kepada penyedia atau penanggung jawab |
| --- | --- |
| Ada tidaknya sasaran yang terlewat | Daftar pemeriksaan situs web, halaman pengelolaan, dan server pengujian |
| Perbaikan kerentanan | Versi yang diterapkan atau riwayat perubahan paket yang mencantumkan kedua CVE |
| Status eksekusi | Catatan mulai ulang layanan atau deployment ulang kontainer |
| Penerapan aktual | Lingkungan eksekusi PHP yang diperiksa melalui layanan web |
| Pemeriksaan peretasan | Periode log yang diperiksa dan temuan |
| Kredensial | Kredensial yang harus diganti dan status penyelesaiannya |
| Pekerjaan yang tersisa | Server yang baru menerapkan tindakan sementara dan rencana pemasangan patch lanjutan |

Sebagai contoh, anggap penyedia hanya melaporkan bahwa pemasangan paket telah selesai. Dalam hal ini, mintalah hasil konfirmasi mulai ulang dan pemeriksaan lingkungan eksekusi web. Pemeriksaan log dan penggantian kredensial dapat dikonfirmasi sebagai item terpisah.

## FAQ

### Apakah PHP2Shell dapat dicegah dengan mengganti kata sandi login?
Kerentanan ini dapat dieksploitasi tanpa login, sehingga mengganti kata sandi saja tidak menyelesaikan masalah. Pembaruan keamanan PHP diperlukan. Penggantian kredensial merupakan langkah terpisah untuk mengantisipasi kemungkinan kebocoran.

### Untuk PHP 8.5, apakah harus menunggu hingga 8.5.13?
Dokumen asli PHP dan KISA mencantumkan 8.5.13 sebagai versi perbaikan untuk kedua kerentanan. Ini tidak berarti Anda harus menunggu 8.5.13. Saat menerapkan perbaikan, periksa juga rilis resmi terbaru untuk seri tersebut.

### Jika menggunakan PHP-FPM, apakah pemeriksaan tidak diperlukan?
PHP-FPM juga perlu diperiksa. Kondisi yang memungkinkan serangan dapat berbeda tergantung pada cara PHP dijalankan. Jangan menentukan keamanan hanya berdasarkan nama lingkungan.

### Jika hasil php -v menunjukkan versi yang sudah diperbaiki, apakah penanganannya sudah selesai?
PHP di baris perintah dapat berbeda dari PHP yang digunakan layanan web. Periksa lingkungan yang benar-benar memproses permintaan web. Periksa juga apakah layanan yang berjalan sudah dimulai ulang.

### Jika nomor versi tetap sama setelah pemasangan patch, apakah itu berarti gagal?
Paket dari distribusi atau vendor dapat menyertakan perbaikan pada versi yang sudah ada. Periksa riwayat perubahan paket untuk memastikan apakah perbaikan bagi kedua CVE sudah disertakan.

### Apakah memory_limit=-1 merupakan pengaturan yang dilarang dalam penanganan kali ini?
Pengaturan tersebut tercakup dalam rekomendasi sementara resmi untuk kerentanan ini. Rekomendasi ini harus dibedakan dari rekomendasi operasional umum. Tinjau juga langkah pembatasan permintaan dan pengelolaan sumber daya.

### Apakah situs tanpa fitur unggah berkas juga perlu ditangani?
Situs tidak dapat dikecualikan hanya karena tidak memiliki fitur unggah. Karena ini merupakan kerentanan pada PHP itu sendiri, periksa versi yang digunakan dan status patchnya. Pemblokiran permintaan multipart yang tidak diperlukan merupakan langkah sementara.

### Apakah PHP 8.1 atau versi yang lebih lama boleh tetap digunakan jika tersedia patch dari vendor?
Patch dari vendor perlu diperiksa secara terpisah dari berakhirnya dukungan reguler. Meskipun patch tersebut diterapkan untuk sementara, susun rencana untuk beralih ke versi yang masih didukung.

### Jika tidak ada kejanggalan dalam log, apakah kredensial boleh tetap dipertahankan?
Log saja tidak cukup untuk menyimpulkan bahwa tidak terjadi kebocoran informasi. KISA menyarankan penggantian kredensial pada server yang terekspos ke internet sebelum dipasangi patch. Jika ada jejak penyusupan, kredensial wajib diganti.

### Jika dicurigai terjadi penyusupan, apakah pembaruan harus dilakukan terlebih dahulu?
Isolasi dari jaringan terlebih dahulu. Lakukan pembaruan setelah melaporkan insiden dan mengamankan bukti. Memulai ulang dapat menghilangkan jejak serangan yang tersisa di memori.

### Apa yang perlu diperiksa oleh pengguna hosting?
Minta bukti penerapan patch untuk setiap layanan kepada penyedia layanan. Minta juga hasil verifikasi mulai ulang layanan dan lingkungan eksekusi web yang sebenarnya. Periksa secara terpisah apakah log telah diperiksa dan kredensial telah diganti.

### Apakah pengaturan progres unggahan boleh diaktifkan kembali setelah pemasangan patch?
Periksa pengumuman tambahan PHP tertanggal 23 Oktober 2026. Karena ada masalah tambahan pada beberapa kombinasi pengaturan, disarankan agar fitur tetap dinonaktifkan. Putuskan apakah akan memulihkan pengaturan setelah memeriksa perbaikan lanjutan.

## Sources

- [KISA 보호나라: Pedoman respons keamanan bagi perusahaan terkait kerentanan keamanan PHP (PHP2Shell), 22 Oktober 2026](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)
- [Pengumuman PHP tahun 2026: Pembaruan keamanan 21 Oktober dan informasi tambahan tentang Session upload progress pada 23 Oktober](https://www.php.net/archive/2026.php)
- [Peringatan keamanan PHP: RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [Peringatan keamanan PHP: RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [PHP Supported Versions: Periode dukungan resmi](https://www.php.net/supported-versions.php)
- [PHP2Shell: Penjelasan peneliti mengenai kerentanan dan cakupan dampaknya](https://www.php2shell.com/)
- [개인정보보호위원회: Imbauan untuk mengambil langkah pencegahan kebocoran data pribadi terkait kerentanan keamanan PHP, 22 Oktober 2026](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Images

![Seorang perempuan memegang konektor kabel Ethernet biru di dekat port jaringan server rak di ruang server.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp)
![Teknisi senior memeriksa layar status tablet di samping kabinet perangkat jaringan yang terbuka di pabrik.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp)