PHP2Shell: NACSA Desak Tampal PHP Segera

PHP2Shell: NACSA Desak Tampal PHP Segera

Pada 21 Oktober 2026, projek PHP mengeluarkan versi kecemasan untuk dua bug peringkat enjin yang kini dipasarkan sebagai PHP2Shell. Bug ini membenarkan remote code execution tanpa pengesahan dalam PHP itu sendiri, bukan dalam aplikasi yang dibina dengannya. Dua hari kemudian, National Cyber Coordination and Command Centre (NC4) di bawah NACSA menerbitkan advisory NC4-ALR-2026-000011 yang meminta organisasi Malaysia yang mempunyai PHP terdedah ke internet supaya menampal segera, dan mengasingkan atau menutup sistem jika tidak mampu.

Angka yang menjelaskan keterdesakan datang daripada Wiz: kod terjejas berada dalam runtime yang, menurut anggaran mereka, menggerakkan kira-kira 70% internet. Angka yang patut merisaukan pasukan Malaysia berbeza: kebanyakan anda bukan pemilik PHP yang melayani laman web anda.

Apa sebenarnya PHP2Shell

Advisory itu menjejaki CVE-2026-109618 (remote code execution melalui corrupt out-of-memory) dan CVE-2026-109619 (remote code execution melalui stale global state). Kedua-duanya bug enjin, dan itu mengubah cara kita bertindak balas. WordPress, Laravel, borang hubungi yang ditulis sendiri dan alat dalaman berusia sedekad terdedah sama rata, kerana kelemahan itu berada di bawah semuanya. Audit plugin atau framework untuk bug ini membuang masa.

Skor CVSS v4.0 ialah 9.2, tetapi vektor itu membawa attack complexity tinggi dan attack requirements yang perlu dipenuhi. Ini belum lagi menjadi worm yang cukup dengan satu permintaan. Ia bug memory-safety dalam runtime web paling meluas di dunia, dengan analisis awam dan demonstrasi yang sudah tersebar. Wiz menyebutnya seperti Heartbleed kerana laluan corruption boleh membocorkan memori proses sebelum code execution dicapai.

Server API mengubah pendedahan anda. mod_php ialah kes paling teruk: enjin berjalan dalam worker Apache, dan request shutdown dipanggil walaupun startup gagal, jadi permintaan yang mati semasa initialization masih sampai ke laluan teardown yang terjejas. PHP-FPM menamatkan child worker apabila startup gagal, sebab itu exploit penuh yang disahkan hanya ditunjukkan pada model embedded. Itu bukan lesen untuk skip FPM. FrankenPHP membenamkan PHP dengan cara sama dan patut dianggap terdedah; LSAPI LiteSpeed lebih menyerupai FPM.

Di Malaysia, kerja tampal ini kerja host

Kebanyakan laman SME Malaysia duduk di shared hosting di mana panel kawalan menetapkan PHP mengikut domain: cPanel dengan EasyApache 4 dan MultiPHP Manager, CloudLinux PHP Selector, Plesk, DirectAdmin. Penyewa memilih 7.4 atau 8.1 daripada dropdown. Penyewa tidak boleh rebuild pakej.

Jika itu anda, repositori aplikasi anda tiada apa-apa untuk dibaiki. Unit tampalan ialah set pakej host dan setiap build PHP per pool yang panel masih tawarkan. Tanya tiga soalan:

• Versi PHP dan SAPI tepat mana yang melayani domain ini, per pool, bukan "yang terkini"?
• Adakah build itu sudah dikemas kini ke 8.5.12, 8.4.27, 8.3.36 atau 8.2.35, dan bila?
• Adakah branch lama masih boleh dipilih, dan mod_php masih dihidupkan di mana-mana?

"Kami guna versi terkini" bukan jawapan. 8.3.35 ialah versi terkini semalam, dan ia terdedah. Minta string itu, kemudian sahkan sendiri. Kelemahan cPanel EmailTrack pada September sudah menunjukkan betapa besar kuasa lapisan hosting ke atas semua penyewa sekali gus: bug panel kawalan ialah masalah fleet, dan begitu juga bug runtime.

Jika penyedia anda tidak boleh tampal dalam tempoh yang anda perlukan, nasihat NC4 ialah asingkan atau tutup perkhidmatan. Di shared hosting keputusan itu milik operator, jadi pilihan realistik anda ialah berpindah. Lebih baik tahu minggu ini daripada semasa insiden.

Sahkan PHP yang benar-benar menjawab permintaan

php -v di shell memberitahu anda tentang binari CLI. Itu jarang runtime yang melayani trafik. Pada server Ubuntu biasa, /usr/bin/php boleh berada pada satu versi, tiga FPM pool pada versi lain, dan modul Apache daripada pakej keempat. Periksa SAPI, bukan mesin.

Semakan terpantas ialah fail sementara yang mencetak runtime web:

<?php
// drop as /tmp/version.php behind your vhost, fetch it, then delete it
header('Content-Type: text/plain');
echo PHP_VERSION, ' ', PHP_SAPI, PHP_EOL;

Response header ialah isyarat kedua, walaupun banyak setup menyembunyikannya. Kedua-duanya tidak menggantikan inventori di pihak host.

Untuk server milik anda, skrip read-only ini menyenaraikan binari, mengesan mod_php, menyenaraikan FPM pool dan menandakan pool tanpa siling memori:

#!/usr/bin/env bash
# php-sapi-audit.sh - read-only inventory of PHP runtimes and FPM pool limits
set -u

patched() { # $1 = version; 0 patched, 1 vulnerable, 2 unsupported branch
  local v=$1 major minor patch
  IFS=. read -r major minor patch <<<"${v%%-*}"
  case "${major}.${minor:-0}" in
    8.5) [ "${patch:-0}" -ge 12 ] ;;
    8.4) [ "${patch:-0}" -ge 27 ] ;;
    8.3) [ "${patch:-0}" -ge 36 ] ;;
    8.2) [ "${patch:-0}" -ge 35 ] ;;
    7.4|8.0|8.1) return 2 ;;
    *) return 1 ;;
  esac
}

echo "== PHP binaries =="
for bin in /usr/bin/php /usr/bin/php[0-9]*; do
  [ -x "$bin" ] || continue
  ver=$("$bin" -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  sapi=$("$bin" -r 'echo PHP_SAPI;' 2>/dev/null)
  patched "$ver"
  case $? in
    0) verdict="patched" ;;
    2) verdict="unsupported branch - backport or migrate" ;;
    *) verdict="VULNERABLE - patch now" ;;
  esac
  printf '%-26s %-9s %-10s %s\n' "$bin" "$ver" "$sapi" "$verdict"
done

echo
echo "== Apache PHP module =="
if command -v apache2ctl >/dev/null 2>&1; then
  if apache2ctl -M 2>/dev/null | grep -q 'php'; then
    echo "mod_php loaded: highest-risk SAPI, patch this first"
  else
    echo "no mod_php module loaded"
  fi
fi

echo
echo "== FPM pools =="
shopt -s nullglob
for conf in /etc/php/*/fpm/pool.d/*.conf; do
  pool=$(grep -m1 '^\[' "$conf" | tr -d '[]')
  limit=$(grep -E '^[[:space:]]*php_(admin_)?value\[memory_limit\]' "$conf" \
          | tail -1 | sed 's/.*=//; s/^[[:space:]]*//')
  [ -n "$limit" ] || limit="(inherited from php.ini)"
  case "$limit" in
    -1) flag="  <-- no ceiling, see below" ;;
    *)  flag="" ;;
  esac
  printf '%-14s %-46s %s%s\n' "$pool" "$conf" "$limit" "$flag"
done

Jalankan di kotak dan tampal output ke dalam tiket apabila penyedia mendakwa sesuatu pool elok sedangkan ia melaporkan 8.2.34.

Jalan pintas yang didokumenkan ialah pertukaran ketersediaan

Advisory PHP sendiri jelas menyatakan tiada mitigation bersih. Langkah sementara yang mula tersebar ialah membuang siling memori dalam pool terjejas: php_admin_value[memory_limit] = -1.

Peruntukan memori yang direka untuk mencetuskan OOM biasanya melanggar memory_limit dan membunuh permintaan, yang memang kita mahu semasa cubaan exploit. Tanpa siling, peruntukan yang sama pergi ke sistem operasi dan OOM killer memilih mangsa mengikut logiknya sendiri: pangkalan data, panel kawalan, atau FPM master. Tetapkan per pool, jangan sekali-kali global dalam php.ini, dan hanya untuk beberapa jam sehingga pakej siap dibina.

Dua kesilapan berkaitan. Jangan guna RLIMIT_AS atau RLIMIT_DATA dalam pool atau unit file; advisory memberi amaran bahawa had address-space menolak kegagalan peruntukan ke dalam laluan terdedah. Dan had memori container bukan pengganti: cgroup membunuh container, bukan permintaan, jadi satu muat naik hasad menjadi gelung restart.

WAF atau reverse proxy membeli masa dengan mengehadkan bentuk yang diperlukan oleh exploit: hadkan bilangan multipart part dan header setiap part, hadkan bilangan input variable dan kedalaman nesting, dan tolak body multipart tanpa Content-Length yang boleh digunakan. Mematikan session.upload_progress.enabled membuang ciri yang sebahagian helah multipart bergantung padanya, dengan kos kehilangan bar kemajuan upload. Semua ini bukan pembaikan. Ia perbezaan antara tampal pada 14:00 dan tampal pada 14:00 sementara sesuatu mengimbas anda.

Exploit boleh senyap, jadi rotate semula rahsia

Oleh sebab bug berada dalam enjin, log framework anda mungkin merekodkan 500 dan tidak lebih. Isyarat lemah yang patut di-grep: permintaan multipart dengan bilangan part luar biasa, baris out-of-memory dalam log FPM, 500 berulang diikuti restart worker, nilai PHPSESSID yang tidak sepadan dengan format aplikasi anda, dan sambungan keluar baharu milik pengguna web.

grep -Ei 'allowed memory size|out of memory|segfault' /var/log/php*-fpm.log

Jika ada host yang terdedah ke internet, belum ditampal dan menjalankan mod_php antara 21 Oktober dan sekarang, rotate semula apa yang proses itu boleh capai: pengguna pangkalan data, credentials SMTP dan API, secret tandatangan sesi, mana-mana token dalam fail environment. Memory disclosure boleh mendedahkan semua itu tanpa code execution, dan "kami tidak nampak apa-apa dalam log" bukan bukti tiada apa berlaku.

Anggap pembangunan exploit sudah bermula

Proses keluaran itu sendiri tidak kemas. Garis masa Wiz merekodkan data CVE muncul pada 20 Oktober dengan CVSS 10.0 yang terlalu tinggi, keluaran ditarik ke hadapan sebagai tindak balas, dan vendor container menerbitkan image yang ditampal beberapa jam lebih awal; seorang penyelidik menyiarkan video demonstrasi secara tidak sengaja. Jurang antara "advisory diterbitkan" dan "exploit berfungsi di awam" kini diukur dalam jam.

Wiz memberi kredit kepada analisis berbantukan AI kerana menemui bug itu dengan pantas, menamakan Gemini 4 Argon dan GPT-5.6 Sol serta kira-kira seminggu kerja. Sama ada kisah itu boleh dipertahankan atau tidak, ekonominya jelas: mencari bug memory-corruption dalam codebase C dahulunya projek berbulan-bulan bagi seorang pakar; kini ia sprint yang boleh dijalankan atas permintaan oleh pasukan yang cukup sumber. Sasarkan tetingkap tampalan anda dalam hari, bukan suku tahun.

Lowyat memetik data Censys yang meletakkan kira-kira 2.6 juta host PHP di internet awam, dengan kira-kira 1.5 juta masih melaporkan versi yang tiada keluaran tetap. Setiap satu calon untuk pengimbasan automatik minggu ini.

Apa yang saya akan buat minggu ini

1. Inventori per SAPI, bukan per mesin: CLI, FPM pool dan mod_php semua boleh berbeza.
2. Tampal ke 8.5.12, 8.4.27, 8.3.36 atau 8.2.35, kemudian restart FPM dan kosongkan opcache. Fail yang ditampal tetapi opcache masih hangat akan terus melayani kod lama.
3. Rebuild image container, jangan sekadar tarik. php:8.2-apache dan wordpress:latest ialah tag, bukan versi, dan layer cache menyimpan build terdedah.
4. Pada 8.2, 8.2.35 ialah keluaran terakhir sebelum end of life pada 31 Disember 2026, jadi rancang naik taraf. Pada 8.1 atau lebih lama anda sudah tidak disokong; 7.4, 8.0 dan 8.1 hanya menerima backport sumber yang perlu dibina sendiri.
5. Pada RHEL, AlmaLinux atau Rocky dengan repo Remi, sahkan pakej benar-benar tiba; PHP Foundation memberi amaran pakej itu tidak akan tiba pada hari keluaran.
6. Jika tidak boleh tampal hari ini, asingkan perkhidmatan, hadkan multipart di proxy, dan anggap host sudah terjejas.
7. Rotate semula rahsia pada mana-mana host yang terdedah semasa belum ditampal, sama ada RCE berlaku atau tidak.

Dua hari selepas advisory, soalannya bukan sama ada PHP2Shell boleh dieksploitasi. Soalannya sama ada PHP yang menjawab domain anda ialah versi yang anda boleh namakan, pada server yang anda kawal, dengan tarikh tampalan yang anda boleh buktikan.

Masih memetakan pendedahan? Tulisan forensik Citrix NetScaler merangkumi urutan operasi pada peranti edge yang dieksploitasi; kisah cPanel EmailTrack ialah analog terdekat untuk bug lapisan hosting.

Sumber

• Lowyat.NET: NACSA Urges Local Organisations To Immediately Patch Internet-Facing PHP Systems
• National Cyber Coordination and Command Centre (NC4), NACSA: NC4-ALR-2026-000011 — Critical Vulnerabilities in PHP (PHP2Shell)
• The PHP Group: Security advisory — Critical remote code execution vulnerabilities, update now
• The PHP Foundation: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released
• Wiz: PHP2Shell — Critical RCE in PHP affecting 70% of the Internet
• GitHub Advisory Database: GHSA-w8hw-w9fx-j79w — PHP RCE via OOM corruption