มี WAF แล้ว รอดจาก PHP2Shell ไหม? WAF ช่วยได้แค่ไหนระหว่างรอแพตช์ PHP
มี WAF แล้วรอดจาก PHP2Shell ไหม? สรุปสิ่งที่ WAF ทำได้และทำไม่ได้ระหว่างรอแพตช์ PHP วิธีทดสอบ rule ใน staging และตารางตัดสินใจว่าเครื่องไหนต้องแพตช์ก่อน
มี WAF แล้ว รอดจาก PHP2Shell ไหม? WAF ช่วยได้แค่ไหนระหว่างรอแพตช์ PHP
ถ้ามี WAF อยู่หน้าเว็บแล้ว คำถามแรกหลัง PHP ออกแพตช์เมื่อ 21 ตุลาคม 2026 ก็คือ "รอแพตช์รอบหน้าได้ไหม" ตอบตรงๆ: WAF ช่วยลดโอกาสโดน PHP2Shell ได้จริงในช่วงรอแพตช์ แต่ไม่ได้ทำให้ปลอดภัย ทีม PHP กับ AWS ซึ่งขาย WAF เอง เขียนไว้ตรงกันว่าการอัปเดต PHP คือวิธีเดียวที่แก้ช่องโหว่ได้ครบถ้วน
ให้คิดว่า WAF เป็นเทปพันท่อรั่วระหว่างรอช่าง พันแล้วน้ำหยดน้อยลงจริง แต่ไม่มีใครพันทิ้งไว้ทั้งปี (รายละเอียดของช่องโหว่ทั้งสองตัว อยู่ในบทความหลักของชุดนี้) ข้างล่างคือ WAF ซื้อเวลาได้แค่ไหน และต้องเช็คอะไรก่อนจะเชื่อมัน
ทำไม WAF ถึงช่วยได้แค่ "บางส่วน"
ข่าวดีคือ PHP2Shell เข้ามาทาง HTTP request ซึ่งเป็นจุดที่ WAF ยืนเฝ้าอยู่พอดี AWS ระบุว่าช่องโหว่ทั้งสองตัวเกิดจากวิธีที่ PHP จัดการ request แบบ multipart/form-data (รูปแบบที่เบราว์เซอร์ใช้ตอนอัปโหลดไฟล์) ก่อนที่โค้ดของแอปจะเริ่มทำงาน
แต่ปัญหาจริงอยู่ในการประมวลผลภายใน PHP AWS ระบุว่า WAF ของตัวเองไม่ได้แยกโครงสร้างภายในของ multipart body และมองไม่เห็นหน่วยความจำของ PHP worker หรือ config ฝั่งเซิร์ฟเวอร์ และ AWS ยังบอกว่าหนึ่งในสองช่องโหว่ส่วนใหญ่อยู่นอกระยะของ WAF ทุกตัว Sansec ซึ่งมีระบบป้องกันชื่อ Shield ก็เตือนแบบเดียวกันว่าอย่ารอ rule
WAF ทำอะไรได้จริงในช่วงรอแพตช์
OWASP เรียกวิธีนี้ว่า virtual patching คือใช้ชั้นกรอง traffic บล็อกการโจมตีช่องโหว่ที่รู้จักโดยไม่แตะโค้ด แต่ OWASP กำกับไว้ว่ามันลดความเสี่ยงได้เฉพาะ traffic ที่ผ่านชั้นนั้น และเฉพาะรูปแบบที่ rule รู้จัก ตัวช่องโหว่ยังอยู่ที่เดิม
สำหรับ PHP2Shell สิ่งที่ WAF ทำได้มีประมาณนี้ (ตัวอย่างจากคู่มือของ AWS ซึ่งประเมินเองว่าแต่ละข้อครอบคลุมแค่ไหน):
- บล็อก
multipart/form-data ถ้าไม่มีงานจริงที่ส่งแบบนี้เลย เช็คทุก workflow ก่อน ไม่ใช่แค่ฟอร์มอัปโหลดไฟล์ แต่รวมถึงฟอร์มหรือ API client ที่ส่ง field แบบ multipart โดยไม่มีไฟล์ด้วย ถ้าไม่มีจริง ข้อนี้ตัดทางเข้าหลักของทั้งสองช่องโหว่ และทีม PHP เองก็แนะนำ
- บล็อก request ที่มีหน้าตาตรงกับตัวกระตุ้น AWS ระบุว่า custom rule ของตัวเองสำหรับ CVE-2026-109619 จะบล็อกเมื่อครบสามเงื่อนไข คือเป็น
POST, มี PHPSESSID ใน cookie หรือ body และ body มี PHP_SESSION_UPLOAD_PROGRESS (มี managed rule ให้ด้วย)
- จำกัดขนาด body AWS แนะนำเพดาน 8 KB สำหรับ CVE-2026-109618 แต่ให้คะแนนแค่ "บางส่วน" เพราะ header เล็กๆ จำนวนมากที่ไม่เกินเพดานแต่กินหน่วยความจำใน PHP มากกว่าขนาดจริงมาก ยังหลุดไปได้
- rate limit ลดจำนวนครั้งที่ลองได้ แต่ไม่หยุด request ที่สำเร็จครั้งเดียว
- เก็บ log log ของ WAF คือหลักฐานว่ามีอะไรเข้ามาบ้าง ใช้ต่อตอนไล่ล่าร่องรอย PHP2Shell ใน log
สิ่งที่ WAF มองไม่เห็น
signature ขึ้นกับรูปแบบที่รู้จักแล้ว Amazon เห็นความพยายามโจมตีใน honeypot ตั้งแต่ 17 ตุลาคม ส่วนคู่มือ WAF ของ AWS ออกวันที่ 21 ตุลาคม
traffic ที่ไม่ผ่าน WAF Tenable สรุปว่า rule ของ Cloudflare เป็นมาตรการชั่วคราว และครอบคลุมเฉพาะ traffic ที่วิ่งผ่าน Cloudflare หลักเดียวกันใช้กับทุกยี่ห้อ ถ้า origin ยังรับ request ตรงจาก IP ได้ หรือมีเว็บภายในที่ไม่อยู่หลัง WAF ก็ไม่ได้รับการป้องกัน
สถานะและ config ฝั่งเซิร์ฟเวอร์ ตารางของ AWS ตอบว่า "ไม่ได้" ตรงๆ สองชิ้น คือค่า fatal_error_backtraces ของ PHP 8.5 และคำเตือนจากค่า INI ที่ผิดหรือเลิกใช้ ทั้งคู่มีส่วนในการประมวลผล request แต่การตรวจของ WAF มองไม่เห็น
เพดานการตรวจและการหลบเลี่ยง AWS WAF ตรวจ body ได้แค่ส่วนแรก บน Application Load Balancer และ AppSync คือ 8 KB ตายตัว ส่วน integration อื่นเริ่มที่ 16 KB และปรับได้ เพดานนี้ต่างกันไปในแต่ละผลิตภัณฑ์ OWASP เตือนว่าการ match และการแปลง encoding ของ rule พลาดได้ และ rule แบบ blocklist โดนหลบง่ายกว่า ส่วน HTTP request smuggling ที่ PortSwigger อธิบายเป็นข้อจำกัดทั่วไปของชั้นหน้า คือเมื่อเซิร์ฟเวอร์ด้านหน้ากับด้านหลังตีความขอบเขต request ไม่ตรงกัน ผู้โจมตีอาจข้าม security control ด้านหน้าได้ แหล่งที่เราตรวจไม่มีรายงานว่าใช้วิธีนี้ส่ง PHP2Shell
ถ้าหน้าเว็บยังไม่มีอะไรกั้นเลย WAF ที่ป้องกันการโจมตีเว็บทั่วไปและมี rate limit เป็นชั้นเสริมที่ควรมีสำหรับเว็บและ API สาธารณะ แต่ไม่ใช่ตัวแทนการแพตช์
เช็คยังไงว่า rule ทำงานจริง (โดยไม่ยิงใส่ production)
ลำดับนี้มาจากคู่มือ AWS กับ Virtual Patching Cheat Sheet ของ OWASP ส่วนเรื่อง staging เป็นคำแนะนำของเราเอง:
- เปิด log ของ WAF ก่อนเปลี่ยนอะไร
- ตั้ง rule เป็นโหมดนับหรือบันทึกอย่างเดียวก่อน AWS เรียก Count ส่วน OWASP เรียก Log Only ในโหมดนี้ traffic ที่ match ยังวิ่งถึง origin
- ใช้ staging origin ที่แยกขาด รัน PHP ที่แพตช์แล้ว อยู่หลัง WAF ตัวเดียวกัน และไม่มีข้อมูล production AWS แนะนำให้ทดสอบด้วย multipart POST ธรรมดา, body ที่ใหญ่เกินเพดาน และ POST ที่มี cookie
PHPSESSID กับ PHP_SESSION_UPLOAD_PROGRESS ใน body ใช้ request สังเคราะห์ในจำนวนจำกัด
- กำหนดผลที่คาดหวังของแต่ละ rule rule บล็อก multipart ทั้งหมดจะ match การอัปโหลดตามที่ออกแบบไว้ และ rule เพดาน 8 KB จะ match JSON ที่ใหญ่กว่านั้นเช่นกัน ถ้างานจริงชนกับนโยบายชั่วคราว ให้บันทึกไว้แล้วเร่งแพตช์ระบบนั้นก่อน
- กำหนดเกณฑ์ rollback ก่อนเปลี่ยนเป็น Block หลังเปลี่ยนแล้วต้องเห็น HTTP 403 พร้อม log ของ rule นั้น
- ห้ามเอา PoC สาธารณะมารันกับระบบ โค้ดพวกนั้นไม่มีใครรับรอง และ OWASP เตือนว่าบล็อก request ทดสอบได้แบบเดียวไม่ได้แปลว่าป้องกันได้ครบ
อีกเรื่อง: อย่าให้ WAF เก็บ body หรือ cookie แบบเหวี่ยงแห OWASP และเอกสาร CRS เตือนว่า alert อาจบันทึกรหัสผ่านหรือข้อมูลบัตรลงไปด้วย เก็บแค่ rule ID เวลา endpoint ผลลัพธ์ และ correlation ID ตามที่ OWASP แนะนำก็พอ (ข้อสังเกตของเราเอง ไม่ใช่ของ OWASP หรือ CRS: ข้อมูลแบบนี้เข้าข่าย PDPA ด้วย)
ตารางตัดสินใจ: แพตช์ก่อน หรือพึ่ง WAF ไปก่อน
| สถานการณ์ | ทำอะไร | บทบาทของ WAF |
|---|
| เว็บเปิดสู่อินเทอร์เน็ต + PHP ยังไม่แพตช์ (เสี่ยงสุดคือ Apache mod_php) | แพตช์เลย Amazon แนะนำให้นับเวลาเป็นชั่วโมง แล้วรีสตาร์ท PHP worker ทุกตัว | มาตรการชั่วคราว มีวันหมดอายุ |
| ไม่มี traffic แบบ multipart ที่ใช้งานจริง (เช็คอัปโหลด ฟอร์ม และ API client แล้ว) | บล็อก multipart/form-data ที่หน้าเว็บเป็นมาตรการชั่วคราว ระหว่างเร่งจัดการแพตช์ด่วน | ช่วยได้มากที่สุดในทุกแถว |
| มี traffic แบบ multipart ที่ใช้งานจริง | แพตช์ก่อน ระหว่างนั้นตั้ง session.upload_progress.enabled=0 ใน php.ini, FPM pool หรือ config ของเซิร์ฟเวอร์ (ไม่ใช่ ini_set() หรือ .user.ini) แล้วรีสตาร์ท worker ทุกตัว | ลดความเสี่ยง แต่ AWS ยืนยันว่าไม่ปิดช่องโหว่ |
| ยังแพตช์ไม่ได้ (appliance ของ vendor, รอเจ้าของระบบ) | ค่าชั่วคราวของ PHP + rule WAF + change ticket พร้อมวันทบทวน ถ้าทำไม่ได้หรือช้าเกิน NCSC ของอังกฤษให้พิจารณาปิดระบบไว้ก่อน | ซื้อเวลาเท่านั้น |
| PHP 7.4, 8.0, 8.1 | ไม่มีรุ่นแก้จากต้นทาง แต่ทีม security ของ PHP ปล่อยแพตช์ระดับ source ขั้นต่ำไว้ให้ ถ้าไม่ใช้ก็หา backport จาก vendor หรืออัปเกรด | ไม่เปลี่ยนคำตอบ |
| ระบบภายในที่ไม่ผ่าน WAF | แพตช์ตามหลังระบบที่เปิดสู่อินเทอร์เน็ต แต่ต้องทำ | มองไม่เห็น traffic นี้เลย |
| แพตช์แล้ว | ยืนยันเวอร์ชันและรีสตาร์ท worker | เก็บไว้เป็นชั้นเสริมหรือถอดออก ตามที่ AWS แนะนำ |
ไม่แน่ใจว่าเครื่องไหนเข้าแถวแรกบ้าง เริ่มจากวิธีเช็คเวอร์ชัน PHP ว่าโดน PHP2Shell หรือไม่
"วันหมดอายุ" ไม่ได้แปลว่าต้องลบ rule ทิ้ง OWASP ให้บันทึก virtual patch เข้า patch management ปกติ แล้วทบทวนเป็นระยะว่าถอดได้หรือยัง ประเด็นคือ rule ต้องไม่กลายเป็นข้ออ้างให้เลื่อนแพตช์
ถ้ากำลังหา WAF มาวางหน้าเว็บที่ยังไม่มีอะไรกั้น ดูรูปแบบติดตั้งและแพ็กเกจ zcrWAF ได้ แต่แถวแรกของตารางไม่เปลี่ยน
เครื่องมือฟรีทำได้ดีแค่ไหน
ทีม PHP เองแนะนำให้จำกัดขนาด request หลัง decode, จำนวน field, part, header และความลึกของการซ้อน ที่ web server หรือ proxy เพดานขนาด body ตั้งได้ใน web server หรือ reverse proxy ที่ใช้อยู่แล้วโดยไม่ต้องซื้ออะไร ข้ออื่นทำได้ครบแค่ไหนขึ้นกับซอฟต์แวร์ของเซิร์ฟเวอร์ที่ใช้
OWASP CRS เป็น rule set แบบ open source ที่ใช้ฟรี paranoia level 1 ออกแบบให้แทบไม่มี false positive เหมาะเป็นพื้นฐาน แต่เอกสารของ CRS เองบอกว่ามันตรวจแบบทั่วไป ไม่รู้จักแอปที่อยู่ข้างหลัง อย่าเดาว่า rule ทั่วไปจะจับช่องโหว่ใหม่ได้เอง ให้ทดสอบตามขั้นตอนข้างบน
zcrWAF อยู่ตรงไหนในเรื่องนี้
zcrWAF คือไฟร์วอลล์เว็บแอปพลิเคชันที่ตรวจ traffic ของเว็บไซต์ เว็บแอป API และ origin server สำหรับ OWASP Top 10 และรูปแบบการโจมตีทั่วไป มี rate limit, CAPTCHA หรือการยืนยันตัวตนกับ session ที่น่าสงสัย, กฎ Allow, Block หรือ Challenge ที่สร้างเองได้, security log แบบ real-time พร้อม audit trail ว่าอะไรถูก challenge, block หรือ allow และแจ้งเตือนผ่าน E-Mail, Microsoft Teams, LINE และ Webhook ติดตั้งได้ทั้ง Cloud/SaaS, Virtual Appliance และ ICT Hardware Appliance ดูหน้าจอจริงได้ที่หน้า demo
ข้อมูลผลิตภัณฑ์ของ zcrWAF ไม่ได้ระบุว่าครอบคลุม PHP2Shell ถ้าสงสัยว่าโดนไปแล้วก่อนแพตช์ ไปต่อที่แนวทางรับมือเหตุ PHP2Shell
ติดต่อทีมงาน
อยากรู้ว่าเว็บ PHP ที่ดูแลอยู่ควรแพตช์ตัวไหนก่อน และ WAF ที่มีอยู่ช่วยได้แค่ไหน ทีมงานยินดีให้คำปรึกษาฟรี
แหล่งอ้างอิง
- AWS Security Blog, "Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)" (เผยแพร่ 21 ต.ค. 2026 ปรับปรุง 22 ต.ค.): https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/ (เข้าถึง 23 ตุลาคม 2026)
- Amazon Threat Intelligence, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot" (21 ต.ค. 2026): https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (เข้าถึง 23 ตุลาคม 2026)
- PHP, ประกาศ security release 21 ตุลาคม 2026: https://www.php.net/archive/2026.php และ advisory https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w กับ https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp (เข้าถึง 23 ตุลาคม 2026)
- OWASP Cheat Sheet Series, "Virtual Patching Cheat Sheet": https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html (เข้าถึง 23 ตุลาคม 2026)
- OWASP CRS Documentation, "False Positives and Tuning" และ "Paranoia Levels": https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/ (เข้าถึง 23 ตุลาคม 2026)
- PortSwigger Web Security Academy, "HTTP request smuggling": https://portswigger.net/web-security/request-smuggling (เข้าถึง 23 ตุลาคม 2026)
- Tenable, "PHP2Shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions": https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote (เข้าถึง 23 ตุลาคม 2026)
- Sansec, "PHP2Shell": https://sansec.io/research/php2shell (เข้าถึง 23 ตุลาคม 2026)
- UK NCSC, "Critical security issue affecting PHP": https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php (เข้าถึง 23 ตุลาคม 2026)
- หมายเหตุข้อมูล: บทความนี้ไม่ยกตัวเลขหรือเหตุการณ์จาก demo หรือ telemetry ของลูกค้า และไม่ได้ทดสอบ rule ของ WAF ยี่ห้อใดกับช่องโหว่นี้เอง ข้อจำกัดของ WAF ที่ยกมาเป็นการประเมินของแหล่งที่อ้างถึง
