PHP2Shell: penyebab dan panduan remediasi

Sumber diperiksa pada 22 Oktober 2026. APemirsa: Operator aplikasi PHP, responden keamanan, dan teknisi yang memelihara build PHP khusus.

Artikel ini merangkum penyebab, cakupan dampak, proses perbaikan formal, tindakan mitigasi sementara, dan implementasi patch resmi dari kerentanan PHP2Shell. Teks utama dikutip menggunakan angka seperti S1; semua tautan sumber tercantum dalam lampiran di akhir teks. Fragmen konfigurasi adalah templat penerapan, yang perlu disesuaikan berdasarkan versi aktual, kapasitas bisnis, dan hubungan warisan konfigurasi.

TL;DR: Langkah-langkah perbaikan dan saran

Tingkatkan runtime PHP: tingkatkan cabang yang relevan ke setidaknya 8.2.35, 8.3.36, 8.4.27 atau 8.5.12. Untuk paket distribusi, gunakan versi paket lengkap yang dikonfirmasi oleh vendor untuk memperbaiki kedua CVE. S1 S10
Ganti semua proses lama: restart atau roll over setiap PHP worker, layanan hosting, dan container setelah peningkatan, dan konfirmasikan bahwa instance lama telah keluar.
Verifikasi melalui jalur permintaan Web yang sebenarnya: periksa Web SAPI, versi paket lengkap, dan instance yang sedang berjalan. Memeriksa php -v saja tidak membuktikan bahwa layanan langsung sudah diperbaiki.
Jalankan pemeriksaan regresi bisnis dan pulihkan anggaran sumber daya normal: uji login, penanganan sesi, unggahan, impor, dan penanganan kesalahan. Jika batas memori PHP dihapus untuk sementara, pulihkan anggaran terbatas yang sesuai setelah melakukan patching.
Jika peningkatan segera tidak mungkin dilakukan: batasi lalu lintas yang tidak tepercaya sebelum mencapai PHP. Evaluasi penonaktifan kemajuan unggahan dan penelusuran balik fatal PHP 8.5 seperti dijelaskan di Bagian 5. Mitigasi konfigurasi dan aturan WAF memiliki cakupan terbatas dan tidak dapat menggantikan peningkatan. S1 S2 S3

1. Tinjauan Kerentanan dan Penilaian Risiko

PHP2Shell dalam artikel ini mengacu pada dua kerentanan tingkat Critical yang secara resmi diungkapkan oleh PHP pada 21 Oktober 2026. Keduanya terkait dengan memori dan meminta manajemen siklus hidup mesin PHP, sehingga menimbulkan risiko eksekusi kode jarak jauh yang tidak diautentikasi. S1 S2 S3

Proyek	CVE-2026-109618	CVE-2026-109619
nama resmi	RCE via OOM corruption	RCE via stale global state
masalah inti	Memori yang tidak mencukupi menyebabkan lompatan yang tidak normal, meninggalkan keadaan yang belum menyelesaikan inisialisasi.	Status global yang tersisa di pekerja menunjuk ke memori permintaan yang dirilis.
Waktu kejadian yang khas	Proses inisialisasi, eksekusi, atau pembersihan permintaan saat ini	Permintaan sebelumnya meninggalkan status, dan permintaan berikutnya mengkonsumsinya terlebih dahulu.
Apakah OOM merupakan kondisi yang diperlukan?	Termasuk dalam mekanisme pemicu inti kerentanan	Tidak; kesalahan fatal lainnya dan pembersihan pasca diagnosis juga mungkin terlibat
Arah perbaikan mendasar	Tangani Kegagalan Alokasi dan Penghentian Permintaan dengan Aman	Perbaiki kepemilikan negara, waktu pembersihan, dan inisialisasi awal
Persyaratan pembuangan	harus diperbaiki	harus diperbaiki secara bersamaan

Dasar: Dua buletin keamanan resmi dan pengiriman perbaikan. S2 S3 S4

1.1 Memahami penerapan yang terpengaruh

PHP secara resmi menganggap semua penerapan PHP yang menangani permintaan Web berisiko, termasuk PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, dan LiteSpeed. Serangan mod_php yang ditunjukkan dapat terjadi sebelum kode aplikasi dijalankan, sehingga pemeriksaan login, middleware kerangka kerja, dan validasi unggahan aplikasi tidak dapat mencakup jalur tersebut. S1

Penting untuk membedakan antara “penyebaran perlu diperbaiki” dan “rantai serangan tertentu telah terbukti sepenuhnya”. Pengumuman CVE-2026-109618: FPM akan keluar dari proses anak setelah startup permintaan gagal, memblokir jalur pembersihan mod_php yang sesuai setelah kegagalan startup; namun, jalur OOM setelah startup berhasil masih berisiko. Pengumuman tersebut juga mencatat bahwa eksploitasi penuh FPM untuk CVE ini belum ditunjukkan. Pembatasan ini tidak dapat digunakan untuk menyimpulkan bahwa FPM aman, apalagi CVE-2026-109619 tidak dapat diabaikan. S2 S3

Batasan izin langsung untuk keberhasilan eksploitasi bergantung pada identitas proses yang menghosting PHP dan sumber daya yang dapat diaksesnya. Secara umum, perhatian harus diberikan pada kode situs web, direktori unggahan, kredensial basis data, token layanan, dan kemampuan akses jaringan internal; “eksekusi kode jarak jauh” tidak berarti mendapatkan izin root secara alami. Penilaian konsekuensi di sini didasarkan pada model izin proses, dan dampak sebenarnya perlu dievaluasi bersama dengan izin penerapan.

Skrip CLI satu kali biasa tidak memiliki entri HTTP yang sama; tetapi proses yang menangani tugas eksternal untuk waktu yang lama dalam mode CLI atau tertanam harus tetap disertakan dalam inventaris runtime dan siklus hidup. Hanya dependensi CMS, kerangka kerja, atau Composer yang diperbarui dan mesin PHP yang mendasarinya tidak diganti secara otomatis.

2. Analisis penyebab

2.1 Pertama-tama pahami dua siklus hidup

PHP worker sering menangani banyak permintaan secara berurutan. Memori yang dialokasikan selama permintaan dapat dilepaskan secara seragam di akhir permintaan, sementara pekerja itu sendiri dan beberapa bidang globalnya tetap ada.

Oleh karena itu, mesin harus mempertahankan dua batasan:

Batasan inisialisasi: Data yang terlihat oleh kode lain harus berada dalam keadaan yang dapat dibaca, dilintasi, dan dimusnahkan dengan aman.
Keterbatasan siklus hidup: setelah memori permintaan telah dibebaskan, bidang yang berumur lebih lama tidak boleh terus memperlakukan alamat dalam memori tersebut sebagai status valid.

Kedua kendala ini sesuai dengan mode kegagalan utama dari dua kelompok kerentanan. Proses berikut adalah deskripsi mekanisme yang menggabungkan pengumuman dan kompilasi patch. Hal ini tidak berarti bahwa setiap penerapan memiliki jalur yang dapat dijangkau secara persis sama. S2 S3 S5

2.2 CVE-2026-109618: OOM mengganggu pembaruan status yang belum selesai

Implementasi lama menggunakan lompatan non-lokal tipe longjmp() untuk menangani OOM, dan jalur terkait keluar dari konteks eksekusi saat ini melalui zend_bailout(). Bahayanya adalah bahwa sepotong kode C mungkin telah menerbitkan objek, array, atau status permintaan baru ke kode lain, namun belum menyelesaikan semua inisialisasi bidang; saat ini, kegagalan alokasi apa pun pada waktu yang relevan dapat menyebabkan langkah penutupan normal dilewati. S2

Proses kegagalan dapat dipecah menjadi empat langkah:

Buat atau perbarui struktur internal permintaan dan buat agar dapat diakses.
Alokasi memori berikutnya gagal dan OOM terpicu.
Alur eksekusi berpindah dari fungsi saat ini, dan kode yang awalnya digunakan untuk menyelesaikan inisialisasi atau pemulihan status tidak dijalankan.
Permintaan pembersihan terus memproses struktur ini dan memperlakukan konten yang tidak valid sebagai bidang atau alamat yang valid.

Masalahnya bukan kehabisan memori selalu menyebabkan RCE. Sebaliknya, kelelahan memori mengubah aliran kontrol dan melanggar asumsi mesin tentang struktur yang valid. Alokasi yang gagal tidak perlu secara langsung melibatkan struktur yang pada akhirnya salah terbaca. S2

Mengapa permintaan yang lebih kecil juga bisa kehabisan memori

Jumlah byte di badan permintaan dan penggunaan heap setelah penguraian bukanlah hal yang sama. Bidang A mungkin berhubungan dengan beberapa string, elemen array, dan objek metadata di dalam PHP; kompleksitas struktural masukan akan mempengaruhi tingkat amplifikasi memori.

Masalah dengan multipart yang tercantum dalam pengumuman resmi meliputi: kesenjangan pemeriksaan ukuran awal ketika panjang deklarasi yang tersedia tidak ada, jumlah header untuk satu bagian tidak cukup terbatas, dan kontrol file kosong masih menghasilkan metadata, dengan nama yang disarangkan semakin meningkatkan beban kerja array. Pelepasan, penguraian kode, atau penugasan ulang masukan oleh aplikasi juga dapat menjadi sumber OOM. S2

Dua kesimpulan protektif dapat ditarik dari sini:

Pembatasan isi permintaan harus diterapkan sebanyak mungkin sebelum memasuki PHP, dan panjang pembacaan aktual serta kompleksitas struktural harus dipertimbangkan.
Membatasi ukuran file, jumlah file, atau menutup satu portal unggahan saja tidak dapat mencakup semua sumber OOM.

Mengapa otentikasi aplikasi mungkin terlambat

Di mod_php, isi permintaan dapat diurai secara otomatis selama fase inisialisasi permintaan; bahkan jika startup gagal, pembersihan permintaan terkait akan tetap dilakukan. Oleh karena itu, jalur serangan yang dikonfirmasi dapat terjadi sebelum kode aplikasi. Untuk mengurangi paparan pada tahap ini, pembatasan perlu ditempatkan pada proksi terbalik, server Web, atau batas lain yang mendahului pemrosesan permintaan PHP. S1 S2

2.3 CVE-2026-109619: Memori permintaan telah dilepaskan, referensi global masih hidup

Masalah ini melibatkan status kesalahan, sesi, objek, atau ekstensi: bidang disimpan di lokasi akses jangka panjang pekerja, namun data yang direferensikan oleh bidang tersebut termasuk dalam satu permintaan. Selama referensi tidak dibersihkan dengan benar sebelum tumpukan permintaan dilepaskan, permintaan berikutnya mungkin mengalami status menggantung, membentuk penggunaan setelah bebas. S3

Analisis resmi membagi kondisi eksploitasi menjadi “produsen” dan “konsumen”:

peran atau kondisi	artinya	Implikasinya terhadap perlindungan
produsen negara	Tempatkan milik negara atas permintaan ini ke dalam lokasi yang masih bisa diakses nantinya	Untuk memeriksa apakah pembersihan terkait telah selesai setelah keluar secara tidak normal
Statusnya tetap ada	Itu tidak dibersihkan, atau dibersihkan dan kemudian diisi ulang karena operasi yang terlambat.	Menghapus sekali saja pada tahap penutupan awal mungkin tidak cukup
penggunaan kembali pekerja	Pekerja yang sama terus memproses permintaan berikutnya	Banyak pekerja hanyalah perbedaan penjadwalan, bukan jaminan keamanan memori
memajukan konsumen	Membaca, melepaskan atau menentukan nilai sisa sebelum keadaan terkait diinisialisasi secara normal.	Harus memeriksa INI, sesi dan jalur lainnya sebelum inisialisasi

Kondisi-kondisi ini perlu dipenuhi secara bersamaan; log kesalahan apa pun tidak membuktikan bahwa kerentanan telah berhasil dieksploitasi. S3

Itu tidak memerlukan OOM sebagai prasyarat yang diperlukan

Kesalahan fatal dapat mengganggu publikasi dan pemulihan status berpasangan. Kegagalan kompilasi atau penguraian, kesalahan yang tidak tertangkap, kegagalan require, dan waktu tunggu eksekusi dapat meninggalkan status tertentu. Diagnostik non-fatal yang terlambat dibersihkan juga dapat mengisi kembali informasi kesalahan yang telah dihapus. S3

Oleh karena itu, mengubah memory_limit menjadi tidak terbatas tidak mencakup serangkaian kerentanan ini.

”Sebelum inisialisasi” perlu ditangani secara terpisah

Waktu kedua jenis konsumen yang dikonfirmasi berbeda:

EDiagnostik INI awal: Beberapa konfigurasi yang diterapkan berdasarkan permintaan mengeluarkan peringatan, pemberitahuan, atau penghentian sebelum inisialisasi pelaksana normal, dan pemrosesan diagnostik dapat mengakses status kesalahan lama.
kemajuan unggahan sesi: sesi dapat diproses terlebih dahulu selama proses penguraian isi permintaan, tetapi modul reguler RINIT belum selesai; tidak dapat disimpulkan bahwa jalur tersebut tidak ada karena aplikasi tidak memanggil session_start() secara eksplisit. S3

Tidak semua konfigurasi INI memiliki waktu risiko yang sama. Konfigurasi tingkat direktori mod_php dan PHP_VALUE / PHP_ADMIN_VALUE yang diteruskan oleh front-end FPM perlu dibedakan dari konfigurasi startup php.ini, FPM pool dan FPM .user.ini biasa. Yang terakhir memiliki waktu konfigurasi yang berbeda dan tidak dapat secara kolektif disebut sebagai konsumen awal yang sama. S3

Mematikan display_errors, log_errors, mengurangi error_reporting, atau menggunakan @ hanya memengaruhi visibilitas diagnosis; keadaan internal yang relevan mungkin telah diakses sebelum memutuskan apakah akan mengeluarkan log. S3

3. Perbaikan versi dan pemilihan patch

3.1 Garis dasar perbaikan upstream resmi

Cabang PHP saat ini	Versi pertama yang menyertakan perbaikan resmi ini	Saran
8.2	8.2.35	Tingkatkan ke versi ini atau versi berikutnya yang berisi perbaikan yang sama
8.3	8.3.36	Sama seperti di atas
8.4	8.4.27	Sama seperti di atas
8.5	8.5.12	Sama seperti di atas
8.1 dan versi sebelumnya	Dukungan umum di hulu telah berakhir	Prioritaskan migrasi ke cabang yang didukung; rilis cek jangka pendek atau backport pabrikan LTS

Versi dan status dukungan didasarkan pada pengumuman resmi PHP, dan batas waktu adalah 22 Oktober 2026. S1

Ini adalah ambang batas perbaikan khusus cabang. Hal ini tidak dapat digantikan dengan pernyataan bahwa setiap versi di bawah 8.5.12 rentan: versi seperti 8.2.35 dan 8.4.27 di cabang lain sudah berisi perbaikan.

3.2 Periksa versi paket distribusi lengkap

Distro sering kali menambahkan perbaikan keamanan berdasarkan versi upstream yang lebih lama. Penerimaan juga harus memeriksa versi rilis, sumber repositori, versi paket lengkap, dan buletin keamanan.

Misalnya, versi paket perbaikan Ubuntu 24.04 LTS yang terdaftar untuk Ubuntu USN-8948-1 adalah:

8.3.6-0ubuntu0.24.04.13

Bagian hulunya masih 8.3.6, tetapi versi paket lengkap dari distribusi tersebut disertakan dalam pengumuman perbaikan ini. Kesimpulan ini hanya berlaku untuk distribusi dan sumber paket yang sesuai, dan tidak dapat digeneralisasikan ke build mana pun yang juga menampilkan 8.3.6. S10

3.3 Memilih patch yang tepat

adegan	Rencana prioritas	Poin-poin penting untuk penerimaan
Menggunakan paket distribusi PHP	Instal pembaruan keamanan yang dirilis oleh produsen	Pengumuman ini mencakup CVE; versi paket lengkap sudah benar
Gunakan wadah PHP resmi atau gambar buatan sendiri	Perbarui runtime dasar, bangun kembali, dan terapkan	Instance yang berjalan menggunakan image baru; semua salinan lama sudah keluar
Cabang yang didukung yang dikompilasi sendiri	Gunakan versi keamanan resmi dari cabang ini atau set patch resmi lengkap	Pencocokan cabang, penyelesaian ketergantungan, kompatibilitas ekstensi, dan penerusan regresi
Tunduk pada 7.4, 8.0, 8.1	Prioritaskan backport vendor; evaluasi cabang kode sumber darurat resmi jika perlu	Identifikasi perubahan perilaku dan jadwalkan migrasi ke versi yang didukung

Patch resmi telah dirilis, dan perbaikan sebenarnya harus dimulai dari patch ini. Cuplikan kode di Bagian 6 dimaksudkan untuk mengilustrasikan sorotan desain dan tinjauan dan bukan merupakan tambalan lengkap yang dapat diterapkan secara independen. S1 S4 S6

4. Proses perbaikan formal

4.1 Inventaris runtime yang benar-benar menangani permintaan

Disarankan untuk membentuk buku besar singkat untuk mencatat setidaknya:

Masukkan nama atau layanan domain, backend proksi terbalik, PHP SAPI.
Cabang PHP, versi paket lengkap atau intisari gambar, sumber pembuatan.
FPM pool, unit layanan aktual, kontainer atau Pod, jumlah replika.
Ekstensi, konfigurasi utama, dan file konfigurasi tambahan telah dimuat.
Apakah ada versi PHP lain, salinan penerapan lama, atau portal asal yang dapat diakses secara langsung?

Ini adalah saran penerapan sehingga “yang ditingkatkan” dapat sesuai dengan setiap entri lalu lintas yang sebenarnya. Terutama periksa apakah baris perintah PHP dan Web PHP menggunakan versi yang berbeda, gambar dibuat tetapi wadah lama masih berjalan, bagian dari kumpulan atau salinannya tidak diganti, dll.

4.2 Pilih dan sebarkan pembaruan yang benar

Konfirmasikan versi perbaikan sesuai Bagian 3, sebaiknya gunakan sumber paket tepercaya yang ada atau rantai build terkontrol. Cakupan pembaruan harus mencakup komponen yang benar-benar menghosting permintaan, seperti paket FPM, modul Apache PHP, biner CGI, atau build layanan di mana PHP tertanam.

Sebelum memutakhirkan, simpan konfigurasi dan daftar paket, serta verifikasi startup dan layanan utama di lingkungan yang mirip dengan produksi. Untuk ekstensi yang dikelola sendiri, periksa kompatibilitas build dan jalankan yang sesuai dengan versi PHP. Hanya memilih komitmen yang tampaknya relevan dari cabang lain tidak menjamin bahwa seluruh rangkaian perbaikan telah diterapkan.

4.3 Mulai ulang atau roll over instance yang sedang berjalan

Menginstal file dan memuat kode baru ke dalam suatu proses adalah dua hal yang berbeda. Layanan terkait harus dimulai kembali, atau penggantian bergulir harus diselesaikan, dan pekerja lama serta kontainer lama harus dipastikan telah keluar.

Untuk mod_php, mulai ulang proses Apache yang menghosting modul. Layanan yang menyematkan PHP memerlukan proses hostingnya diganti. Untuk FPM, menghapus OPcache tidak menggantikan memperbarui runtime dan menghentikan pekerja lama.

Saat menggunakan peralihan yang anggun, Anda perlu memeriksa apakah proses generasi lama masih menangani koneksi panjang atau permintaan yang belum terselesaikan. Catatan penerimaan harus mencakup layanan aktual, versi penerapan, waktu penyelesaian perubahan, dan hasil keluar dari instans lama.

4.4 Verifikasi melalui permintaan Web yang sebenarnya

Disarankan untuk menggabungkan bukti-bukti berikut daripada hanya mengandalkan satu perintah versi:

bukti	Apa yang bisa dibuktikan	Tidak bisa membuktikan apa pun sendirian
Manajer paket atau metadata gambar	Sumber instalasi dan versi lengkap	Lalu lintas telah dialihkan ke contoh ini
Status proses dan penerapan	pekerja atau kontainer menyelesaikan penggantian	Pintu masuk luar harus diarahkan ke sana
Hasil diagnostik terbatas diakses melalui portal nyata	Web SAPI aktual dan konfigurasi yang berjalan	Apakah backport rilis mencakup dua CVE
Pengumuman vendor atau catatan patch lengkap	Perbaikan bug ini disertakan dalam build ini	Semua replika dikerahkan

PHP_VERSION, PHP_SAPI, file konfigurasi yang dimuat, dan konfigurasi darurat dapat diperiksa melalui kemampuan diagnostik internal yang ada, atau portal diagnostik sementara dan dikontrol akses. Pastikan permintaan tidak dikembalikan secara langsung oleh CDN atau cache halaman; hapus entri diagnostik sementara setelah selesai.

php -v biasanya hanya menunjukkan biner CLI yang saat ini dipilih oleh shell; perintah seperti php-fpm -i tidak setara dengan memverifikasi pekerja yang ada yang menerima lalu lintas. Jangan memaparkan halaman lengkap phpinfo() ke jaringan publik untuk waktu yang lama.

4.5 Pemeriksaan regresi bisnis dan penghapusan pengaturan darurat

Verifikasi login normal, sesi membaca dan menulis, formulir dan pengunggahan, impor, penanganan kesalahan, dan stabilitas pekerja seputar fungsi yang terpengaruh oleh perubahan ini. Periksa apakah tingkat kesalahan, penundaan respons, puncak memori, proses keluar dan frekuensi pembangunan kembali tidak normal.

Jika memory_limit=-1 ditetapkan untuk sementara, anggaran terbatas yang sesuai dengan kapasitas bisnis akan dipulihkan setelah patch resmi berlaku; jika pm.max_requests=1 diatur, konfigurasi siklus hidup yang dievaluasi kapasitas akan dipulihkan setelah perbaikan dikonfirmasi. Batasan ukuran input dan kontrol akses sumber dapat dipertahankan sesuai kebutuhan bisnis.

Jika masalah kompatibilitas muncul selama pemutakhiran, prioritas harus diberikan untuk menangguhkan portal yang terpengaruh, membatasi akses eksternalnya, atau menyesuaikan aplikasi sebelum melakukan roll back. Mengizinkan kembali runtime yang belum diperbaiki untuk melayani jaringan publik secara langsung akan membuka kembali risiko aslinya.

5. Langkah-langkah mitigasi ketika peningkatan segera tidak memungkinkan

Bagian ini dimaksudkan untuk pengurangan paparan jangka pendek atau peningkatan ketersediaan. Setiap tindakan hanya mencakup jalur tertentu, dan kombinasi beberapa tindakan tidak setara dengan perbaikan menyeluruh. S1 S2 S3

5.1 Prioritaskan kontrol lalu lintas sebelum PHP

Jika layanan mengizinkannya, batasi sementara titik akhir sensitif ke sumber tepercaya atau terapkan kontrol akses sebelum PHP. Untuk beban kerja unggahan, batasi ukuran isi permintaan, jumlah bidang, jumlah komponen, header per bagian, dan kedalaman penumpukan. Layanan yang tidak memerlukan multipart dapat menolaknya di frontend. S2

Pembatasan ini mencakup semua pintu masuk ke PHP. Hanya mencegat URL bernama “unggah” yang akan melewatkan entri lain yang masih diuraikan secara otomatis oleh PHP di badan permintaan. Untuk kasus seperti transfer terpotong, kurangnya panjang yang dinyatakan, dll., batasnya harus didasarkan pada ukuran baca sebenarnya; aplikasi juga harus memiliki anggaran ukuran keluarannya sendiri ketika mendekompresi atau memperluas konten lagi.

Templat konfigurasi 5.2 FPM pool

Tempatkan pengaturan berikut di bagian konfigurasi FPM pool yang sebenarnya melayani permintaan, bukan kata demi kata di php.ini. Nilai 8M dan 4M adalah contoh penyesuaian beban kerja. Berikan ruang untuk bidang formulir dan batas multibagian saat membatasi seluruh permintaan POST. S11 S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

PHP 8.5 saja, ditambah:

php_admin_flag[fatal_error_backtraces] = off

Fungsi dan batasannya masing-masing adalah sebagai berikut:

Konfigurasi	efek yang diharapkan	Deskripsi batasan yang harus dipertahankan
`memory_limit=-1`	Hapus kondisi pemicu batas atas memori permintaan PHP yang dapat diprediksi	Hal ini tidak mencegah kegagalan alokasi yang mendasar; membatalkan anggaran awal dapat meningkatkan risiko kehabisan memori dan gangguan layanan.
`post_max_size` lebih kecil	Mengurangi ukuran data yang masuk ke proses parsing	Parser yang tidak diperbaiki memiliki celah yang diketahui; amplifikasi memori tidak dapat dicegah secara mandiri
`upload_max_filesize < post_max_size`	Batasi ukuran file tunggal dan cadangan ruang overhead permintaan	Tidak membatasi semua kolom, metadata, atau alokasi dalam aplikasi
Tutup kemajuan unggahan	Blokir jalur terkait sesi yang dikonfirmasi	Tidak mencakup varian negara global lainnya
PHP 8.5 menutup penelusuran balik yang fatal	Blokir konfirmasi status terkait produsen	Tidak mencakup jalur lain seperti sesi

Batasan ukuran berasal dari pengumuman resmi; untuk sintaks kumpulan dan semantik konfigurasi tingkat manajemen, lihat manual PHP. S1 S2 S3 S11

Pengaturan php_admin_* tingkat manajemen tidak dapat ditimpa oleh aplikasi melalui ini_set(). Semua konfigurasi masuk kumpulan, tingkat direktori, dan front-end masih harus ditinjau untuk mengonfirmasi bahwa nilai pada permintaan sebenarnya sesuai dengan yang diharapkan. Setelah modifikasi, bangun kembali semua pekerja untuk mencegah proses yang ada terus mempertahankan keadaan lama.

Jika Anda memilih untuk memodifikasi php.ini secara langsung, sintaksnya harus diubah menjadi:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

Tidak seperti php_admin_value di kumpulan, hanya mengatur memory_limit=-1 di php.ini tidak mencegah aplikasi memodifikasinya lagi. Kerangka kerja, kode aplikasi, dan konfigurasi lainnya harus diperiksa untuk melihat apakah mereka telah menyetel ulang nilai terbatas; ketika penerapan diperlukan, gunakan pengaturan tingkat manajemen yang sesuai untuk SAPI saat ini dan periksa nilai efektif sebenarnya. S11 S12

Tambahkan fatal_error_backtraces = Off hanya untuk PHP 8.5. Jangan gunakan ini_set() tingkat aplikasi sebagai solusi untuk menonaktifkan kemajuan unggahan, dan jangan mengandalkan FPM .user.ini untuk membuatnya efektif sebelum penguraian permintaan. S1 S3

5.3 Kelola biaya penghapusan batas memori PHP

memory_limit=-1 adalah mitigasi jalur sementara untuk lingkungan yang tidak diperbaiki dan tidak boleh disalin sebagai konfigurasi default jangka panjang. Ketika aplikasi atau permintaan menjadi tidak terkendali, maka dapat menggunakan lebih banyak memori host. Oleh karena itu, sebelum digunakan, Anda harus mengevaluasi jumlah konkurensi, puncak pekerja tunggal, dan total kapasitas layanan, serta menerapkan batas input front-end. S2

Batas memori kontainer atau cgroup dapat memberikan batasan ketersediaan namun tidak menjamin bahwa alokasi tidak akan pernah gagal; seluruh kontainer, master, dan seluruh pekerja juga dapat dihentikan ketika batas tersebut dipicu. Granularitas isolasi dan strategi terminasi perlu dievaluasi bersamaan dengan penerapan dan tidak dapat disebut sebagai perlindungan lengkap untuk kedua CVE ini. S2

Jangan mengganti strategi di atas dengan RLIMIT_AS, RLIMIT_DATA, atau batasan ruang alamat proses terkait; hal ini dapat secara langsung menyebabkan alokasi yang mendasarinya gagal pada jalur OOM yang masih bermasalah. S2

Contoh Konfigurasi 5.4 Nginx

Berlaku untuk penerapan di mana Nginx meneruskan permintaan ke PHP-FPM. Ini dapat diatur pada tingkat konfigurasi layanan hosting sebenarnya:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size membatasi ukuran isi permintaan; fastcgi_request_buffering on memungkinkan Nginx membaca isi permintaan lengkap terlebih dahulu dan kemudian mengirimkannya ke backend FastCGI. Apakah ini berlaku di server atau location tertentu perlu diperiksa sehubungan dengan hubungan pewarisan dan cakupan yang ada. S13 S14

Hanya ketika bisnis tidak memerlukan multipart, Anda dapat menambahkan aturan penolakan ke pintu masuk layanan yang sesuai:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Ini adalah templat pembatasan entri sederhana yang menggunakan if dan return, bukan aturan pemfilteran umum untuk kerentanan parser. Verifikasi sintaks konfigurasi dan permintaan normal sebelum penerapan, dan periksa apakah error_page khusus mengalihkan 403 permintaan ke PHP. Pencocokan string tidak memberikan jaminan lengkap atas semua perbedaan penguraian. S15

Selain itu, konfigurasi ini tidak secara otomatis membatasi jumlah data, jumlah bidang, atau jumlah objek PHP yang dapat didekompresi oleh aplikasi; bisnis yang perlu mengunggah harus menggunakan batasan tambahan yang memahami struktur permintaan mereka.

5.5 Mitigasi opsional: satu permintaan per pekerja FPM

Untuk penerapan FPM yang mampu menanggung biaya overhead, penyiapan jangka pendek dapat dievaluasi:

pm.max_requests = 1

Dan membangun kembali pekerja yang ada. Ini memblokir rantai permintaan silang yang dijelaskan di tingkat penggunaan kembali pekerja, tetapi akan meningkatkan overhead pembuatan dan inisialisasi proses; pada saat yang sama, ia tidak dapat memperbaiki permintaan yang sama OOM dan masalah pembersihan CVE-2026-109618. Ketika nilainya lebih kecil tetapi lebih besar dari 1, masih ada jendela permintaan penggunaan kembali. S3 S11

5.6 WAF dan Cloudflare batas cakupan

Cloudflare telah mengumumkan pengaturan penerapan untuk perlindungan terhadap PHP2Shell, termasuk paket Free. Saat menggunakan layanannya, Anda harus memeriksa apakah lalu lintas sebenarnya melewati proxy, apakah aturan perlindungan berlaku, dan apakah situs asal dapat dilewati secara langsung; untuk paket berbayar, Anda juga perlu memeriksa konfigurasi dan pengecualian Aturan Terkelola terkait. S16

Beberapa deteksi yang dijelaskan oleh vendor menggunakan sinyal respons, sehingga semua perlindungan tidak dapat diartikan sebagai “setiap serangan diblokir sebelum mencapai PHP”. WAF dapat membantu mengurangi paparan dan memberikan informasi pengamatan, namun peningkatan lanjutan ke PHP masih diperlukan. S16

5.7 Mengapa tindakan umum saja tidak cukup

tindakan atau penilaian	kekurangan
Tutup saja `file_uploads`	Tidak dapat mencakup semua pemrosesan multibagian dan menerapkan jalur OOM-nya sendiri
Pengaturan `enable_post_data_reading=Off`	Ubah perilaku pengisian POST/FILES secara otomatis; isi permintaan masih dapat dibaca oleh aplikasi dan dapat mengganggu bisnis normal
Matikan tampilan kesalahan, log atau gunakan `@`	Pemrosesan diagnostik internal mungkin masih mengakses status menggantung
Meningkatkan jumlah pekerja	Jangan membuat mekanisme pembersihan kondisi aman, atau menghilangkan penggunaan kembali pekerja tunggal
Konfigurasikan hanya `disable_functions` atau `open_basedir`	Batasan ini tidak memperbaiki kerusakan memori lapisan mesin C
Hanya periksa satu versi atau satu salinan satu kali	Tidak dapat dibuktikan bahwa semua pintu masuk dan instance yang berjalan telah diganti
Tidak ada log pengecualian yang terlihat	Hal ini tidak dapat membuktikan bahwa kerentanan tersebut tidak ada atau belum pernah dieksploitasi sebelumnya.

Diantaranya, konfigurasi dan dasar mekanisme kerentanan PHP dapat ditemukan di S2 S3 S12; penilaian mengenai cakupan, penerimaan dan batasan izin didasarkan pada saran implementasi yang diajukan oleh mekanisme ini.

6. Ide implementasi dan poin tinjauan patch resmi

6.1 Gunakan perbaikan lengkap untuk cabang yang benar

Pengajuan resmi perwakilan untuk PHP 8.5 adalah:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

Komit secara eksplisit mengaitkan dua CVE, keduanya untuk menyesuaikan mekanisme keluar OOM dan untuk memperbaiki status global yang dapat diakses selama fase inisialisasi. Kirim halaman dengan perbedaan penuh lihat S4 S5. Cabang lain harus menggunakan rilis keamanan resminya sendiri atau patch yang cocok, dan tidak dapat diasumsikan bahwa perubahan pada 8.5 dapat langsung diterapkan ke versi yang lebih lama.

6.2 OOM Perbaikan: pulihkan status yang dapat diproses terlebih dahulu, lalu akhiri permintaan

Implementasi formal memperkenalkan dua tingkat pemrosesan OOM lunak dan keras: ketika batas lunak tercapai, status tertunda dicatat, dan keluar terkontrol dilakukan di lokasi aman seperti VM; antarmuka alokasi yang dapat gagal memungkinkan pemanggil untuk menangani kegagalan secara eksplisit. Untuk alokasi yang tidak dapat secara langsung mengembalikan kegagalan, jika ambang batas yang lebih tinggi diperkirakan terlampaui, proses akan langsung dihentikan untuk menghindari terus memproses permintaan dalam keadaan peralihan yang tidak aman. S2 S5

Berikut cuplikan kode kunci pada diff 8.5 yang digunakan untuk menandai pending OOM:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

Penanganan interupsi VM dan lokasi aman lainnya selanjutnya disebut zend_handle_delayed_oom(). Konteks eksekusi kode penggunanya menggunakan jalur pelepasan yang terkontrol; jalur keras OOM memanggil _exit(137). S5

Dari perspektif desain, perubahan penting adalah: menghindari melintasi tumpukan panggilan C secara sewenang-wenang ketika struktur berada dalam keadaan perantara, dan menempatkan pintu keluar di lokasi yang dapat mempertahankan batasan keadaan. Setelah batas lunak dipicu, memori tambahan mungkin diperlukan untuk menyelesaikan proses, sehingga ambang batas lunak yang baru tidak dapat dipahami sebagai batas atas absolut untuk total memori proses.

Juga tidak dapat diringkas sebagai “PHP telah menghapus semua zend_bailout()”. Patch ini masih menggunakan mekanisme yang relevan dalam konteks tertentu; yang diperbaiki adalah waktu keluar yang berbahaya dan pengelolaan negara yang menyertainya. S5

6.3 Perbarui pemanggil alokasi dan penguraian multibagian secara bersamaan

Jika Anda hanya mengubah fungsi alokasi menjadi “mengembalikan NULL jika gagal” dan pemanggil asli masih berasumsi bahwa penunjuk yang valid selalu dikembalikan, Anda akan memperkenalkan akses penunjuk nol baru atau pembersihan tidak lengkap. Antarmuka alokasi yang gagal dalam patch perlu ditinjau bersama dengan pemeriksaan pemanggil dan propagasi pengecualian. S5

perbaikan terkait multibagian juga mencakup melakukan pemeriksaan kumulatif berdasarkan volume baca aktual, mengurangi pemrosesan header yang tidak berguna atau duplikat, dan mengadopsi logika keluar dan pembersihan yang konsisten ketika OOM tertunda. Perubahan ini mengurangi amplifikasi sumber daya dan membuat parser mematuhi protokol OOM yang baru. S5

Untuk tim yang mengelola cabangnya sendiri, disarankan agar isu-isu berikut menjadi fokus tinjauan kode:

Apakah negara terlihat oleh dunia luar sebelum diinisialisasi sepenuhnya?
Setelah kegagalan alokasi atau pengecualian panggilan balik, apakah kepemilikan masih unik dan tidak ambigu?
Bisakah Anda mencapai pintu keluar pembersihan terpadu jika Anda gagal di tengah jalan?
Bisakah fungsi pembersihan mengenali bidang yang tidak diinisialisasi atau dibebaskan?
Apakah penguraian anggaran didasarkan pada volume pemrosesan aktual, bukan hanya klaim permintaan kepercayaan?
Apakah nilai pengembalian kegagalan yang baru telah ditangani oleh semua penelepon?

Ini adalah pertanyaan tinjauan yang dirangkum berdasarkan mekanisme perbaikan, dan bukan merupakan kesimpulan dari audit yang telah diselesaikan untuk basis kode yang tidak disediakan.

6.4 Perbaikan permintaan silang: inisialisasi lebih awal, pembersihan akhir nanti

Sesuai dengan CVE-2026-109619, patch ini menyesuaikan beberapa batasan siklus hidup secara bersamaan. File dan operasi yang tercantum di bawah ini mengambil perbedaan resmi PHP 8.5 sebagai contoh. S5

lokasi	mengubah arah	Masalah terpecahkan
`Zend/zend_execute_API.c` dll.	Setel ulang status pelaksana seperti kesalahan, pengecualian, penangan, objek, dll.	Setelah permintaan berakhir, masih ada referensi lama yang dapat diakses pada permintaan berikutnya.
Jalur permulaan `main/main.c`	Hubungi `php_basic_early_rinit()` sebelum SAPI diaktifkan	Ketika konsumen awal terjadi, keadaan dasar yang relevan belum diinisialisasi.
Tutup jalur `main/main.c`	Hancurkan HTTP globals dan tandai sebagai tidak terdefinisi	Nilai yang dilepaskan masih dianggap sebagai objek yang valid
sebelum tumpukan permintaan akhirnya dibebaskan	Bersihkan kembali pesan kesalahan terakhir	Diagnostik pembersihan yang terlambat mengisi kembali status kesalahan
`ext/session/session.c`	kemajuan unggahan Jalur awal diinisialisasi sesi global pertama	Modul reguler RINIT sebelumnya mengakses status lama
Kode terkait serialisasi	Batasi penguraian kelas dan panggilan balik pengguna pada pemrosesan awal	Jalankan kode pengguna tambahan ketika inisialisasi belum selesai

Misalnya, urutan startup meliputi:

zend_activate();
php_basic_early_rinit();
sapi_activate();

Setelah HTTP globals dimusnahkan, tambahkan tanda status kegagalan:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Kutipan ini mengilustrasikan dua prinsip: Inisialisasi sebelum konsumen sedini mungkin, dan lakukan pembersihan akhir setelah operasi terakhir yang mungkin membuat ulang status. Menyetel ulang penunjuk hanya selama RINIT normal atau tahap penonaktifan sebelumnya mungkin melewatkan akses lebih awal atau lebih lambat. S5

6.5 Mengapa tidak disarankan untuk melakukan “perbaikan satu jalur” sendiri?

Mengganti semua zend_bailout() dengan _exit(), atau hanya menambahkan tanda centang null pada entri tertentu, akan mencakup sejumlah besar konteks eksekusi yang berbeda. Mereka mungkin menghilangkan bidang status lainnya, atau mereka mungkin mengubah penghancuran, panggilan balik yang diperluas, hosting proses, dan semantik akhir permintaan.

Untuk versi yang didukung, perbaikan lengkap yang telah dirilis akan diutamakan. Migrasi cabang sendiri harus mencatat sumber tambalan, garis dasar yang berlaku, penanganan konflik dan perubahan perilaku, serta menggunakan kasus penggunaan regresi hulu yang sesuai dan verifikasi proses bisnis ini. Saran di sini berasal dari analisis cakupan patch di seluruh pengalokasi, VM, sesi, dan perubahan siklus hidup permintaan. S4 S5

7. Backport darurat PHP 7.4, 8.0, 8.1

PHP secara resmi menyediakan backport kode sumber minimum dari tiga cabang lama berdasarkan tingkat keparahannya. Nama cabangnya adalah:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Untuk tautan cabang, lihat S7 S8 S9. Ini adalah pengiriman darurat untuk kerentanan ini dan tidak mewakili kembalinya dukungan upstream reguler untuk cabang lama, juga tidak menggantikan pembaruan keamanan lainnya. S1

7.1 Ambil backport PHP 8.1 sebagai contoh

Pengiriman yang relevan untuk PHP 8.1 adalah:

1d7dec178a094e6e75b229ce22754045f8c6070a

Strateginya lebih mengutamakan kegagalan cepat: memanggil _exit(1) setelah mengeluarkan diagnostik di jalur OOM yang sesuai, dan termasuk status global dan koreksi relevan lainnya; sambil menonaktifkan secara internal pemrosesan terkait kemajuan pengunggahan sesi. Untuk pengiriman kode sumber yang relevan, lihat S6.

Ini adalah perbedaan perilaku dari desain OOM tertunda yang lebih lengkap di cabang yang didukung. Hanya karena konfigurasi masih menunjukkan bahwa kemajuan unggahan aktif, bukan berarti perilaku pemrosesan internal setelah backport ini tidak akan berubah.

7.2 Harga yang harus Anda terima saat menerapkan

Keluar dari proses secara langsung dapat menyebabkan permintaan saat ini gagal, melewatkan callback shutdown normal PHP dan sebagian penutupan aplikasi; jika host mengadopsi model thread, penting juga untuk mengevaluasi dampak keluarnya seluruh proses host pada pekerjaan bersamaan lainnya. Apakah manajer proses dapat menyelesaikan proses penggantian tepat waktu juga harus disertakan dalam verifikasi.

Oleh karena itu, pengguna versi lama harus mempertimbangkan secara berurutan:

Bermigrasi ke cabang PHP yang didukung dan versi tetapnya.
Gunakan rilis yang secara eksplisit mencakup pembaruan pabrikan CVE atau LTS.
Jika memang tunduk pada kode sumber versi lama, gunakan backport darurat resmi dari versi yang cocok untuk memverifikasi perubahan lengkap dan kompatibilitas, dan mengatur migrasi berikutnya.

“Backport minimum” di sini menjelaskan cakupan kompatibilitas dan implementasi yang dipilih oleh pejabat, dan tidak boleh secara otomatis ditafsirkan sebagai “perbaikan kerentanan yang diketahui tidak lengkap”. Anda harus menilai berdasarkan kode sumber dari cabang terkait dan pengumuman pabrikan, dan jangan menghapus sendiri perubahan pendukung. S1 S6

8. Kriteria penerimaan dan pemeriksaan lanjutan

Disarankan agar hasil berikut digunakan sebagai dasar untuk menyelesaikan perbaikan ini:

Barang penerimaan	Standar penyelesaian
cakupan kerentanan	Pengumuman build atau vendor secara eksplisit memperbaiki CVE-2026-109618 dan CVE-2026-109619
Cakupan penerapan	Semua portal, kumpulan, layanan, dan replika menggunakan runtime yang diperbaiki
Proses mulai berlaku	Pekerja lama, proses host lama, dan container lama semuanya keluar
Verifikasi permintaan otentik	SAPI yang dikonfirmasi, dibuat dan dikonfigurasi dengan tautan Web yang sebenarnya untuk menghilangkan penyesatan cache
ketersediaan bisnis	Fungsi-fungsi utama seperti sesi, pengunggahan, impor, dan penanganan kesalahan telah kembali normal.
Mengakhiri tindakan sementara	Memori tak terbatas dan konfigurasi daur ulang pekerja ekstrem telah dipulihkan sesuai dengan rencana kapasitas atau memiliki alasan penyimpanan yang jelas
Bukti perubahan	Catat versi paket atau intisari gambar, cakupan pembaruan, waktu penyelesaian, dan hasil verifikasi

Hal di atas adalah saran untuk implementasi. Jika Anda perlu memverifikasi perilaku OOM, keluar abnormal, atau patch khusus, Anda harus menggunakan pengujian regresi upstream atau injeksi kesalahan terkontrol di lingkungan terisolasi untuk menghindari berulang kali kehabisan memori di lingkungan produksi sebagai metode penerimaan.

Periksa juga PHP fatal, crash pekerja, restart abnormal, tingkat kesalahan permintaan, dan kejadian WAF sebelum dan sesudah pembaruan. Log hanya dapat memberikan petunjuk investigasi: kemunculan OOM tidak berarti telah dieksploitasi, dan tidak adanya alarm tidak membuktikan bahwa tidak ada eksploitasi yang terjadi. Peningkatan ini memperbaiki jalur kerentanan yang dapat dicapai di masa depan; jika ditemukan anomali seperti perusakan file atau kebocoran kredensial, investigasi insiden terpisah harus dilakukan.

Lampiran: Sumber dan tautan yang dikutip

Semua tautan sumber dikumpulkan di bawah ini. Saran, patch, dan panduan vendor mencerminkan pemeriksaan pada 22 Oktober 2026; penerapan selanjutnya harus memeriksa pembaruan vendor. Kutipan bernomor dalam teks mengacu pada entri ini.

S1 — Buletin keamanan resmi dan versi perbaikan PHP

Sumber: Proyek PHP, 21 Oktober 2026.
Tujuan: Cakupan risiko, empat versi perbaikan resmi, tindakan sementara resmi, dan instruksi backport darurat untuk cabang lama.
Referensi: PHP 2026 This security bulletin ada di arsip buletin tahunan

S2 — Buletin Teknis Resmi CVE-2026-109618

Sumber: php/php-src GitHub Security Advisory, 21 Oktober 2026.
Identifikasi: GHSA-w8hw-w9fx-j79w.
Tujuan: Batas cakupan untuk OOM, amplifikasi multibagian, perbedaan dan mitigasi SAPI.
Referensi: RCE via OOM corruption

S3 — Buletin Teknis Resmi CVE-2026-109619

Sumber: php/php-src GitHub Security Advisory, 21 Oktober 2026.
Identifikasi: GHSA-6wmf-4rv5-p3rp.
Tujuan: Permintaan silang negara yang menggantung, produsen dan konsumen, inisialisasi awal, mitigasi konfigurasi.
Referensi: RCE via stale global state

S4 — Pengiriman perbaikan resmi PHP 8.5

Sumber: php/php-src.
Kirim: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
Tujuan: Mengonfirmasi pengajuan formal untuk memperbaiki dua kerentanan secara bersamaan, dan menjelaskan arah perubahan secara keseluruhan.
Referensi: Avoid state corruption via bailout

S5 — PHP 8.5 Secara resmi dipulihkan dan menyelesaikan perbedaan

Sumber: berbeda dari pengajuan resmi yang sama.
Tujuan: Periksa implementasi spesifik pengalokasi, VM, HTTP globals, sesi, serialisasi, dan siklus hidup permintaan.
Referensi: official complete diff

S6 — PHP 8.1 pengiriman backport darurat resmi

Sumber: php/php-src.
Kirim: 1d7dec178a094e6e75b229ce22754045f8c6070a.
Tujuan: Periksa keluarnya cabang lama dengan cepat dan unggah perubahan perilaku kemajuan.
Referensi: PHP 8.1 Emergency backport submission
Referensi: corresponds to complete diff

S7 — PHP 7.4 cabang backport darurat resmi

Sumber: Cabang kode sumber php/php-src, PHP tercantum dalam buletin keamanan resmi.
Referensi: PHP-7.4-CVE-2026-109618-109619

S8 — PHP 8.0 cabang backport darurat resmi

Sumber: Cabang kode sumber php/php-src, PHP tercantum dalam buletin keamanan resmi.
Referensi: PHP-8.0-CVE-2026-109618-109619

S9 — PHP 8.1 cabang backport darurat resmi

Sumber: Cabang kode sumber php/php-src, PHP tercantum dalam buletin keamanan resmi.
Referensi: PHP-8.1-CVE-2026-109618-109619

S10 — Buletin Keamanan Ubuntu USN-8948-1

Sumber: Canonical / Ubuntu, 21 Oktober 2026.
Tujuan: Melepaskan backport dan melengkapi contoh versi paket.
Referensi: USN-8948-1: PHP vulnerabilities

S11 — Panduan PHP-FPM Configuration

Sumber: dokumen resmi PHP.
Tujuan: Semantik konfigurasi seperti php_admin_value, php_admin_flag, pm.max_requests, dll.
Referensi: PHP-FPM Configuration

S12 — Panduan Konfigurasi PHP Core INI

Sumber: dokumen resmi PHP.
Tujuan: Definisi dan cakupan isi permintaan, unggahan, memori, dan konfigurasi baca POST otomatis.
Referensi: Description of core php.ini directives

S13 — Nginx meminta batas ukuran badan

Sumber: dokumen resmi Nginx.
Tujuan: Arti client_max_body_size dan tingkat konfigurasi yang tersedia.
Referensi: ngx_http_core_module / client_max_body_size

S14 — penyangga permintaan Nginx FastCGI

Sumber: dokumen resmi Nginx.
Tujuan: Urutan pemrosesan dan fungsi fastcgi_request_buffering.
Referensi: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx Kondisi dan instruksi pengembalian

Sumber: dokumen resmi Nginx.
Tujuan: Sintaks konfigurasi if dan return.
Referensi: ngx_http_rewrite_module

S16 — Petunjuk Perlindungan Cloudflare PHP2Shell

Sumber: blog resmi Cloudflare.
Tujuan: Deskripsi cakupan penerapan WAF, pengaturan rencana Free, dan mekanisme deteksi.
Referensi: Cloudflare deploys protections against php2shell vulnerability