ถ้าเซิร์ฟเวอร์ของเราใช้ Apache อยู่ ล่าสุดนี้ควรรีบอัปเกรดกันหน่อย เพราะเพิ่งมีช่องโหว่ RCE ระดับ critical ใน Apache HTTP Server ที่เปิดโดยไม่ต้องยืนยันตัวตน และที่แย่กว่านั้นคือ คนที่เจอช่องโหว่นี้คือ Anthropic กับ Google Cloud Vulnerability Research Team — ทั้งสองทีมที่กำลังเอา AI ไปหาบั๊กในซอฟต์แวร์จริง ๆ

CVE-2026-119618 เป็น race condition ใน HTTP/2 module (mod_http2) ของ Apache HTTP Server โดยเจาะลึกลงไปคืออยู่ในฟังก์ชัน assign_headers()
กลไกคือ: เมื่อมีหลาย thread ทำงานพร้อมกันแล้วแชร์ resource กัน การ sync ไม่ถูกต้องทำให้เกิด heap corruption ซึ่งตามมาด้วยการรันโค้ดแบบ arbitrary บนเซิร์ฟเวอร์ได้ โดยผู้โจมตี ไม่ต้องยืนยันตัวตน ด้วยซ้ำ
พอ heap เสียหาย นั่นแปลว่าผู้โจมตีเข้าถึงโค้ดที่รันอยู่ด้วยสิทธิ์ของ process เว็บเซิร์ฟเวอร์ได้ ซึ่งแย่มากถ้าเป็น production
สถานะตอนที่เขียนบทความนี้: ยังไม่มี exploit ที่เผยแพร่ และยังไม่มีรายงานการโจมตีจริงในโลก ก็ยังเป็นข่าวดี เพราะแปลว่ามีเวลาอัปเกรด
- Apache HTTP Server: เวอร์ชัน 2.4.55 ถึง 2.4.70
- mod_h2 แบบ standalone จาก GitHub: เวอร์ชัน 2.0.8 ถึง 2.0.42
เวอร์ชันที่แก้แล้วคือ Apache HTTP Server 2.4.71 ขึ้นไป และ mod_h2 2.0.42 ขึ้นไป (ถ้าจัดการ standalone module แยก)
จุดที่ทำให้เรื่องนี้ไม่ใช่แค่ของเซิร์ฟเวอร์เก่า คือ 64% ของ cloud environment มี resource ที่เปราะ และ 51% ของ cloud environment มี instance ที่เปิดออกสู่อินเทอร์เน็ตสาธารณะ โดยตัวเลขนี้ยังไม่ได้คิด config ด้วย
นั่นแปลว่าใน cloud สถานการณ์หนึ่งที่เปราะจริง ๆ คือ: Apache instance ที่รันอยู่ใน container หรือ VM ถูกเข้าถึงได้จากภายนอก → เข้า process ของเว็บเซิร์ฟเวอร์ → ใช้เป็นจุดเริ่มต้นของ lateral movement → ไปแตะ microservice ข้างเคียงหรือ cloud metadata endpoint ได้
อัปเกรด Apache HTTP Server เป็น 2.4.71 ขึ้นไป ซึ่งแก้ race condition ใน assign_headers() ไปแล้ว ถ้าจัดการ mod_h2 แยกจาก GitHub ให้อัปเกรดเป็น 2.0.42 ขึ้นไป
ถ้าอัปเกรดทันไม่ได้เพราะติดขัดตอน operational ให้ปิด HTTP/2 ซึ่งตัด attack vector ทิ้งทั้งหมด โดยแก้ในไฟล์ config (เช่น httpd.conf):
apache# Restrict protocols to HTTP/1.1
Protocols http/1.1
ต้องเอา h2 และ h2c ออกให้หมด ไม่ใช่แค่เพิ่มบรรทัดข้างบน
ผมอยากย้ำว่าการปิด HTTP/2 เป็น workaround ไม่ใช่การแก้ปัญหา เพราะมันไปลด capability ของเว็บเซิร์ฟเวอร์ทั้งตัว HTTP/2 ยังมีประโยชน์จริง ๆ อย่าง multiplexing และ header compression
- ถ้าใช้ container image ที่มี Apache เวอร์ชันเก่า ต้อง rebuild image ใหม่ ไม่ใช่แค่ restart container
- ถ้าใช้ Kubernetes กับ
Ingress ที่ terminate TLS ด้วย Apache ต้องเช็ค ingress controller version ด้วย เพราะเวอร์ชัน Apache ข้างในอาจไม่ใช่ตัวที่คุณคิด
- ถ้าใช้ reverse proxy หน้า Apache ด้วย (nginx, Cloudflare) ก็ยังต้องอัปเกรด เพราะช่องโหว่อยู่ใน process ของ Apache ไม่ใช่ที่ request แรกเข้ามา
ที่น่าสนใจกว่าตัวบั๊กคือ ใครเจอ — Anthropic และ Google Cloud Vulnerability Research Team หาเจออิสระ ๆ ทั้งสองทีม
นี่เป็นสัญญาณที่ชัดเจนว่า agent กำลังเข้ามาในกระบวนการ security research จริงจัง ไม่ใช่แค่เขียนโค้ด แต่หาช่องโหว่ที่ซับซ้อนระดับ race condition ใน C ซึ่งเป็นงานที่คนอ่านโค้ดด้วยตาล้วน ๆ ทำยากมาก
แล้วมันก็สอดคล้องกับข่าวอีกเรื่องในช่วงเดียวกัน — Google ใช้ AI ช่วย verify security property ของซอฟต์แวร์ภายในราวสี่สัปดาห์ และมีรายงานว่า DeepMind กำลังสำรวจว่าจะเอาเทคโนโลยีนี้เข้าไปใน coding agent ได้อย่างไร
64% ของ cloud environment เปราะ กับ 51% ที่เปิดสู่สาธารณะ เป็นตัวเลขที่ทำให้ต้องคิด: ใน cloud สมัยนี้ เราไม่ได้แค่ "เปิดเว็บ" แต่เราเปิด HTTP/2 อัตโนมัติโดยไม่ได้รู้ตัว ค่า default ของ reverse proxy และ ingress controller หลายตัวเปิด HTTP/2 ไว้เสมอ และ patch ช่องโหว่นี้ไม่ใช่เรื่องของแอปที่เราเขียน แต่เป็นเรื่องของ image ที่เรา pull มา
- เช็คว่าเครื่องไหนในระบบรัน Apache และรุ่นเท่าไร
- อัปเกรดเป็น 2.4.71 ขึ้นไป (หรือ mod_h2 2.0.42 ขึ้นไป)
- ถ้าอัปเกรดทันไม่ได้ทันที ให้ปิด HTTP/2 ด้วย
Protocols http/1.1 เป็นมาตรการชั่วคราว
- อย่าลืม container image ที่ build ไว้ — patch ที่ registry ไม่ได้ช่วย ต้อง rebuild
- ถ้ามี cloud resource ที่เปิดสู่สาธารณะ ให้ดูว่ามี Apache ตัวไหนบ้างโดยเฉพาะ
ถ้าคุณใช้ Wiz อยู่จะมี query กับ advisory ให้ใช้ (wiz-threat-center → wiz-adv-2026-191) ส่วนคนที่ไม่มีก็ลอง grep รุ่น Apache ในระบบก่อน แล้วค่อยตัดสินใจว่าจะอัปเกรดหรือปิด HTTP/2