Jika laman web atau kedai dalam talian syarikat anda berjalan pada WordPress, Magento, Laravel atau mana-mana sistem lain berasaskan PHP, minta penyedia hos atau pasukan teknikal anda hari ini juga untuk mengemas kini PHP kepada versi 8.5.12, 8.4.27, 8.3.36 atau 8.2.35, kemudian mulakan semula pelayan. Projek PHP mengeluarkan versi ini pada 21 Oktober 2026 untuk menutup dua kelemahan kritikal yang dikenali sebagai PHP2Shell, setiap satunya bertaraf 9.2 daripada 10, yang membolehkan penyerang menjalankan arahan pada pelayan anda tanpa sebarang kata laluan. Pihak Berkuasa Keselamatan Siber Kebangsaan Arab Saudi (NCA) mengeluarkan amaran tahap «kritikal» pada hari yang sama yang mengesyorkan kemas kini, dan syarikat keselamatan mengesan cubaan eksploitasi beberapa jam sebelum pembaikan diterbitkan.

Apakah sebenarnya yang berlaku?

Dua kelemahan itu ialah CVE-2026-109618 dan CVE-2026-109619, dan kedua-duanya terletak dalam bahasa PHP itu sendiri, bukan dalam pemalam atau tema. Inilah perbezaan utamanya: dalam artikel kami sebelum ini tentang pembaikan WordPress yang menjadi peta kepada penyerang, pepijat itu berada dalam perisian yang berjalan di atas PHP. Kali ini pepijat berada pada asas tempat semua perisian itu berdiri. Jadi WordPress yang terkini atau senarai pemalam yang pendek tidak melindungi anda.

Menurut nasihat keselamatan pertama PHP, kelemahan pertama berlaku apabila sesuatu permintaan kehabisan memori semasa sedang disediakan, menyebabkan PHP meninggalkan data yang separuh dimulakan lalu menganggapnya sah. Menurut nasihat kedua, kelemahan yang lain membiarkan data daripada permintaan terdahulu tertinggal selepas ia dibebaskan, dan permintaan seterusnya pada proses yang sama menggunakannya. Hasilnya sama dalam kedua-dua kes: satu permintaan web yang direka dengan teliti sudah cukup untuk menjalankan arahan pada pelayan.

Wiz Research menemui kelemahan ini dengan bantuan model AI. Laporannya menyatakan pasukan itu menemuinya pada 19 Ogos 2026, melaporkannya kepada pasukan PHP pada 24 Ogos, dan setiap versi PHP sejak 5.4 terjejas oleh sekurang-kurangnya satu daripadanya. Wiz menganggarkan kira-kira 70% laman web berjalan pada PHP.

Adakah laman saya terjejas?

Berkemungkinan besar ya, jika ia berjalan pada PHP dan versinya lebih lama daripada nombor di atas. Wiz menunjukkan pelaksanaan kod jarak jauh tanpa pengesahan pada WordPress, Drupal dan Joomla dengan tetapan lalai. Sansec meluaskan senarai dalam analisisnya kepada 11 platform, termasuk Magento 2.4.9, WordPress 7.1.2, Laravel 13.11, Symfony 8.1, phpMyAdmin, Nextcloud dan WHMCS.

Untuk mengetahui versi PHP anda, buka panel pengehosan (cPanel, Plesk atau seumpamanya) dan cari «PHP Version», atau tanya pasukan anda. Beri perhatian kepada dua perkara:

  • Versi 8.1 dan yang lebih lama tidak lagi disokong dan tidak akan menerima pembaikan. Menurut jadual versi PHP yang disokong, cabang yang disokong sekarang hanyalah 8.2, 8.3, 8.4 dan 8.5.
  • Cabang 8.2 sendiri kehilangan sokongan keselamatan pada 31 Disember 2026, dua bulan setengah lagi. Jika anda mengemas kini sekarang, beralihlah ke 8.4 atau 8.5 supaya tidak perlu menaik taraf sekali lagi tidak lama lagi.

Apa yang perlu dilakukan hari ini: lima langkah

  1. Kenal pasti semua tempat PHP berjalan. Laman web, kedai, panel pentadbir, dan mana-mana sistem dalaman atau portal pelanggan. Banyak syarikat terlupa tentang laman lama yang masih dalam talian.
  2. Kemas kini kepada versi yang telah dibaiki. 8.5.12, 8.4.27, 8.3.36 atau 8.2.35. Bagi pengehosan kongsi, tanya penyedia anda secara bertulis: adakah anda telah menggunakan kemas kini 21 Oktober?
  3. Mulakan semula PHP selepas mengemas kini. Nasihat PHP menyatakan bahawa proses yang belum dimulakan semula kekal pada kod lama, jadi memuat turun kemas kini sahaja tidak mencukupi.
  4. Jika laman anda masih pada 8.1 atau lebih lama, rancang naik taraf minggu ini dan uji dahulu pada salinan staging, kerana sesetengah pemalam lama mungkin tidak berfungsi.
  5. Semak log. Wiz mengesyorkan mencari permintaan muat naik luar biasa yang diikuti ralat kehabisan memori, ralat HTTP 500 berulang, atau kuki sesi (PHPSESSID) yang terlalu besar atau rosak.

Jika anda tidak dapat mengemas kini hari ini

Nasihat PHP mencadangkan langkah sementara yang mengurangkan risiko tetapi tidak menggantikan kemas kini: matikan session.upload_progress.enabled dengan menetapkannya kepada 0 dan mulakan semula semua proses, dan pada versi 8.5 tetapkan fatal_error_backtraces kepada 0. Jika laman anda tidak pernah menerima muat naik fail, anda juga boleh menyekat permintaan multipart pada pelayan hadapan.

Jika laman anda berada di belakang Cloudflare, syarikat itu menyatakan dalam blognya bahawa ia telah melaksanakan peraturan tembok api untuk kelemahan ini sejak 3:02 pagi UTC pada 21 Oktober, kira-kira 9 jam sebelum pendedahan, pada semua pelan termasuk pelan percuma. Namun Cloudflare sendiri menasihatkan agar PHP tetap dikemas kini walaupun dengan perlindungan ini, kerana penyerang sentiasa mengubah serangan mereka.

Pandangan Origami

Kelemahan ini mengingatkan bahawa keselamatan laman web tidak berhenti pada kemas kini WordPress dan pemalamnya. Di bawah setiap laman ada bahasa pengaturcaraan, pelayan dan tetapan, dan semuanya memerlukan seseorang untuk memantaunya. Apa yang sering kami lihat di syarikat ialah laman yang dibina bertahun-tahun lalu, dan kini tiada siapa tahu versi PHP yang digunakannya atau siapa yang mempunyai akses untuk mengemas kininya. Jika itu keadaan anda, persoalannya bukan lagi «perlukah kita kemas kini?» tetapi «siapa yang akan mengemas kininya hari ini?». Di Origami, kami membina laman web dan sistem serta memantau kemas kininya dari hari pertama. Jika anda mahu laman anda diperiksa atau PHP dinaik taraf tanpa gangguan, hubungi kami.

Sumber