Jika anda telah mengemas kini laman web syarikat kepada PHP 8.5.12, 8.4.27, 8.3.36 atau 8.2.35 selepas kelemahan PHP2Shell, tindakan anda betul, tetapi ia tidak meliputi segala-galanya. Pada 23 Oktober 2026, projek PHP menerbitkan amaran baharu tentang kelemahan ketiga, CVE-2026-115560, yang tidak dibaiki oleh kemas kini 21 Oktober. Ia memerlukan konfigurasi yang luar biasa dan PHP menganggapnya laluan serangan yang tidak mungkin berlaku, tetapi penyelesaian sementaranya mudah: minta pasukan atau syarikat hos anda hari ini untuk menetapkan session.upload_progress.enabled kepada 0 dan memulakan semula PHP, kemudian sahkan secara bertulis bahawa kemas kini 21 Oktober benar-benar telah dipasang.

Apakah yang diumumkan oleh PHP pada 23 Oktober?

Dua hari selepas keluaran kecemasan, projek itu menerbitkan amaran makluman ringkas tentang penjejakan «kemajuan muat naik» dalam sesi, iaitu ciri yang menunjukkan kepada pengguna sejauh mana fail besar telah dimuat naik. Menurut amaran itu, ciri ini boleh membuka laluan pelaksanaan kod dari jauh dalam satu keadaan tertentu, dan pembaikannya akan datang dalam keluaran berkala seterusnya, bukan sebagai kemas kini kecemasan, bersama nasihat penuh tentang kelemahan tersebut.

Bagi pemilik perniagaan, dua perkara penting. Pertama, ini kelemahan yang berasingan, jadi menjalankan salah satu daripada empat versi di atas sahaja tidak mencukupi. Kedua, langkah sementara yang sama sudah disenaraikan dalam nasihat bagi CVE-2026-109619 pada 21 Oktober. Jika pasukan anda telah melaksanakannya ketika itu, tiada apa-apa yang baharu diperlukan: kekalkan sahaja.

Adakah laman web anda terdedah?

Menurut amaran PHP, masalah ini hanya timbul apabila tiga syarat berlaku serentak:

  • Konfigurasi PHP menetapkan session.serialize_handler kepada php_binary atau php_serialize.
  • Kod aplikasi menukarnya kepada php semasa masa jalan dengan ini_set() sebelum sesi bermula.
  • Penjejakan kemajuan muat naik sesi masih aktif, seperti tetapan asalnya.

Kebanyakan laman web tidak berbuat demikian. Masalahnya, pemilik jarang tahu apa yang dilakukan oleh setiap baris dalam sistem yang dibina bertahun-tahun lalu atau dalam pemalam lama. Oleh itu pilihan paling selamat ialah: jika laman web anda tidak memaparkan bar kemajuan semasa memuat naik fail, mematikan ciri ini tidak merosakkan apa-apa dan menutup pintu itu. Jika laman web bergantung padanya, tanya pembangun anda sama ada kod mengubah tetapan itu semasa masa jalan.

Tiga hari kemudian: pastikan kemas kini 21 Oktober benar-benar dipasang

Kelemahan asal, CVE-2026-109618 dan CVE-2026-109619, masih merupakan risiko yang lebih besar. Pihak Berkuasa Keselamatan Siber Kebangsaan Arab Saudi (NCA) mengeluarkan amaran nombor 2026-7949 mengenainya, dan agensi Amerika Syarikat CISA menasihatkan agar semua sistem PHP diinventori, sistem yang terdedah kepada internet ditampal dahulu, dan sistem yang tidak dapat ditampal segera diputuskan daripada talian. CISA menyatakan ia belum melihat eksploitasi yang berjaya pada masa penerbitan, tetapi itu tidak bermakna masa menyebelahi anda.

Tiga perkara yang sering terlepas pandang:

  • Mulakan semula, bukan muat semula. Buletin Red Hat menyatakan bahawa perubahan konfigurasi memerlukan proses PHP dimulakan semula, dan muat semula sahaja tidak mencukupi.
  • Nombor versi mungkin berbeza pada pelayan Linux. Pengumuman PHP menyatakan bahawa pengedaran Linux menerima tampalan lebih awal, jadi anda mungkin melihat nombor yang berbeza daripada 8.5.12, misalnya, walaupun pembaikan sudah dipasang. Minta pengesahan bertulis daripada syarikat hos anda, bukan sekadar nombor. Red Hat menyatakan bahawa RHEL 8, 9 dan 10 semuanya terjejas.
  • Cara PHP dijalankan mengubah tahap risiko. Projek PHP menilai risiko paling tinggi bagi mod_php pada Apache, manakala Red Hat menyatakan eksploitasi lebih sukar secara praktikal dengan PHP-FPM lalai. Lebih sukar tidak bermakna mustahil, jadi kemas kini tetap diperlukan dalam kedua-dua keadaan.

5 soalan untuk dihantar hari ini kepada syarikat hos atau pasukan anda

  1. Versi PHP manakah yang berjalan pada setiap laman web dan sistem kita, dan adakah ia merangkumi pembaikan 21 Oktober 2026?
  2. Adakah proses PHP telah dimulakan semula selepas kemas kini, bukan sekadar dimuat semula?
  3. Adakah kita telah menetapkan session.upload_progress.enabled kepada 0? Jika belum, adakah kita benar-benar memerlukan ciri itu?
  4. Adakah kod laman web kita mengubah session.serialize_handler semasa masa jalan?
  5. Adakah kita mempunyai laman web pada 8.1 atau lebih lama? Cabang itu tidak lagi disokong, dan jadual versi yang disokong menunjukkan sokongan keselamatan bagi 8.2 tamat pada 31 Disember 2026.

Pandangan Origami

Tiga amaran dalam tiga hari adalah perkara biasa selepas kelemahan besar: apabila penyelidik menggali satu bahagian bahasa pengaturcaraan, mereka turut menemui apa yang berada di sebelahnya. Namun ia juga menunjukkan sesuatu tentang syarikat. Sesiapa yang menampal pada 21 haribulan lalu menutup fail akan terlepas amaran 23 haribulan. Keselamatan di sini ialah pemantauan berterusan, bukan tugas yang selesai sekali sahaja.

Apa yang kami lihat dalam syarikat Arab Saudi ialah soalan yang sukar bukanlah «apakah kelemahannya?», tetapi «siapa di pihak kita yang membaca amaran PHP pada pagi Jumaat dan tahu pelayan mana milik kita?». Di Origami, kami membina laman web dan sistem serta memantau kemas kininya sejak hari pertama. Jika anda mahu laman web anda diperiksa, atau tetapan ini dilaksanakan tanpa gangguan perkhidmatan, hubungi kami.

Kesimpulan

Kemas kini 21 Oktober adalah wajib dan masih yang paling penting; amaran baharu tidak mengubahnya. Tambah satu langkah murah hari ini: matikan penjejakan kemajuan muat naik jika anda tidak memerlukannya, mulakan semula PHP, dan dapatkan pengesahan bertulis daripada syarikat hos anda. Kemudian, perhatikan keluaran berkala PHP seterusnya yang akan membawa pembaikan muktamad bagi CVE-2026-115560.

Sumber