Rincian kerentanan PHP kritis telah diungkapkan dan tambalan (patch) telah diterbitkan.

Rilis perbaikan untuk PHP 8.5.12, 8.4.27, 8.3.36, dan 8.2.35 telah diterbitkan, bersama dengan patch untuk cabang PHP 7.4, PHP 8.0, dan PHP 8.1 yang sudah tidak lagi didukung (versi rentan 5.4 hingga 7.3 tetap belum ditambal), yang memperbaiki dua kerentanan kritis:

  • CVE-2026-109618 — Eksekusi kode jarak jauh adalah kerentanan yang disebabkan oleh penanganan kehabisan memori yang mengeksekusi fungsi longjmp() ketika proses kehabisan memori. Kerentanan ini dapat menyebabkan interpreter PHP berhenti ketika hanya beberapa struktur internal yang terkait dengan pemrosesan permintaan yang diinisialisasi. Fungsi penyelesaian permintaan kemudian mengakses struktur ini seolah-olah sudah diinisialisasi, meskipun belum ada memori yang dialokasikan untuknya.

    Vektor serangan utama adalah memanipulasi permintaan multipart untuk menghabiskan memori yang tersedia pada proses. Untuk melewati batas post_max_size, header Content-Length dapat dihilangkan dan sejumlah besar header HTTP dapat dikirimkan. Serangan yang ditargetkan pada operasi spesifik dalam aplikasi PHP yang mengonsumsi memori berlebihan juga dimungkinkan. Eksploitasi ini telah dikonfirmasi untuk mod_php, karena memanggil fungsi shutdown() bahkan saat terjadi kegagalan. PHP-FPM akan menghentikan proses anak saat terjadi kegagalan, sehingga serangan menjadi lebih sulit tetapi secara teoritis tidak mustahil.

  • CVE-2026-109619 – Eksekusi kode jarak jauh akibat kerentanan use-after-free karena penghapusan status global yang tidak tepat terkait dengan permintaan tertentu. Jika suatu permintaan terinterupsi karena kesalahan fatal, batas waktu habis, atau kondisi kehabisan memori, status global mungkin tidak direset, dan pointer mungkin tetap aktif meskipun memori yang dirujuknya telah dibebaskan. Saat memproses permintaan berikutnya dalam proses yang sama, pointer yang tersisa dapat diakses ke status global lama.

    Eksploitasi dapat dicapai dengan menciptakan kondisi kehabisan memori selama pemrosesan permintaan multipart dalam kode indikator kemajuan unggahan (session.upload_progress). Vektor serangan utama dan terkonfirmasi adalah handler fatal_error_backtraces di PHP 8.5, yang tidak mengatur ulang status pelacakan setelah selesai. Dalam kasus pertama, serangan dimungkinkan pada mod_php dan PHP-FPM, sedangkan dalam kasus kedua, hanya dimungkinkan pada mod_php. Serangan yang belum terkonfirmasi juga disebutkan dalam konfigurasi yang berisi arahan yang memicu peringatan di awal pemrosesan permintaan (misalnya, peringatan tentang penggunaan parameter yang sudah usang).

Telah dinyatakan bahwa pemblokiran kerentanan secara total hanya dimungkinkan dengan menginstal pembaruan. Langkah-langkah berikut mengurangi kemungkinan serangan yang berhasil, tetapi tidak membuat sistem sepenuhnya aman:

  • Menyetel parameter "memory_limit=-1" di php.ini mempersulit penyerang untuk mengontrol habisnya batas memori.
  • Atur parameter "post_max_size = 8M" jika Anda tidak perlu mengunggah file berukuran besar. Parameter "upload_max_filesize" harus lebih kecil dari parameter "post_max_size".
  • Menetapkan batasan konsumsi memori yang dapat diterima pada tingkat sistem, melalui parameter cgroup memory.max atau konsumsi memori kontainer, tetapi bukan melalui batasan sistem RLIMIT_AS dan RLIMIT_DATA, yang hanya memicu panggilan longjmp() yang bermasalah.
  • Jika performa bukan hal penting, Anda dapat membatasi jumlah permintaan yang diproses oleh satu proses pekerja menggunakan pm.max_requests=1 di PHP-FPM dan MaxRequestsPerChild di Apache httpd.
  • Pengaturan pada file php.ini atau tingkat konfigurasi. server (bukan melalui ini_set() atau FPM .user.ini, karena parameter harus berlaku sebelum permintaan diproses) parameter "session.upload_progress.enabled=0.
  • Saat menggunakan PHP 8.5, parameter "fatal_error_backtraces=0" harus diatur.
  • Menghapus pengaturan usang atau salah per permintaan (seperti assert.* dan jalur yang salah di open_basedir) yang menyebabkan pesan diagnostik ditampilkan sebelum inisialisasi.
  • Memperbaiki masalah kode PHP yang dapat menyebabkan waktu habis (timeout) dan kesalahan fatal, seperti yang terkait dengan penanganan callback dan kegagalan pemrosesan unduhan.
  • Untuk memblokir kerentanan pertama dalam kode versi PHP yang lebih lama, Anda dapat mengganti panggilan longjmp() dalam penanganan kehabisan memori dengan _exit().
  • Selain itu, Anda dapat mengurangi nilai parameter max_input_nesting_level di php.ini dan memblokir permintaan multipart, seperti yang ditunjukkan dalam pengumuman awal.

Status perbaikan kerentanan pada distribusi dapat dinilai di halaman-halaman ini: Debian, UbuntuSUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

Lampiran 1: Kerentanan diidentifikasi menggunakan model AI GPT-5.6 dan Gemini 4 Argon. OpenAI telah menerbitkan utilitas php2shell-checker untuk menguji situs web dan program yang dapat dieksekusi secara lokal terhadap kerentanan, tetapi utilitas ini hanya memeriksa nomor versi PHP yang dikembalikan oleh server HTTP atau perintah "php -v", tanpa memberikan analisis terperinci.

Update 2: Penulis prototipe eksploitasi yang memanfaatkan kerentanan double-free melaporkan bahwa masalah tersebut masih belum ditambal di PHP 8.5.12 dan eksploitasi tersebut terus berfungsi. Perwakilan PHP sebelumnya menyatakan bahwa kerentanan ini tidak terkait dengan patch yang akan datang dan bukan masalah nyata. Namun, penulis eksploitasi tersebut mengklaim bahwa itu adalah kerentanan yang sama sekali berbeda.

Sumber: opennet.ru

Beli hosting yang andal untuk situs dengan perlindungan DDoS, server VPS VDS 🔥 Beli hosting website andal dengan perlindungan DDoS, server VPS VDS | ProHoster