kritsana.devpassing
runartifactsdocsworkhistorydispatch

© 2026 Kritsana Prasit — built from source on a self-hosted runner

resume.pdfrssdispatch

back to artifacts
category: securitydate: 13 Nov 2026read: 3 min readsource: posts/apache-http2-rce-cve-2026-119618.mdxtrending

CVE-2026-119618: RCE ระดับ critical ใน Apache HTTP Server เจาะผ่าน mod_http2 ได้ยังไง และต้องแก้อะไร

ช่องโหว่ race condition ในฟังก์ชัน assign_headers() ของ mod_http2 ทำให้ผู้โจมตีระยะไกลไม่ต้องยืนยันตัวตนเขียนโค้ดบนเซิร์ฟเวอร์ได้ พบโดย Anthropic และ Google Cloud VRT มี 64% ของ cloud environment ที่มี resource เปราะ

CVE-2026-119618: RCE ระดับ critical ใน Apache HTTP Server เจาะผ่าน mod_http2 ได้ยังไง และต้องแก้อะไร

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

บทวิเคราะห์ CVE-2026-119618 โดยทีม Wiz ลงวันที่ 11 พ.ย. 2026


ช่องโหว่อยู่ตรงไหน

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 ขึ้นไป

ทางเลือกที่ชั่วคราว: ปิด HTTP/2

ถ้าอัปเกรดทันไม่ได้เพราะติดขัดตอน 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 แรกเข้ามา

สองเรื่องที่น่าสนใจกว่าตัว CVE

1. AI กำลังหาช่องโหว่จริง

ที่น่าสนใจกว่าตัวบั๊กคือ ใครเจอ — Anthropic และ Google Cloud Vulnerability Research Team หาเจออิสระ ๆ ทั้งสองทีม

นี่เป็นสัญญาณที่ชัดเจนว่า agent กำลังเข้ามาในกระบวนการ security research จริงจัง ไม่ใช่แค่เขียนโค้ด แต่หาช่องโหว่ที่ซับซ้อนระดับ race condition ใน C ซึ่งเป็นงานที่คนอ่านโค้ดด้วยตาล้วน ๆ ทำยากมาก

แล้วมันก็สอดคล้องกับข่าวอีกเรื่องในช่วงเดียวกัน — Google ใช้ AI ช่วย verify security property ของซอฟต์แวร์ภายในราวสี่สัปดาห์ และมีรายงานว่า DeepMind กำลังสำรวจว่าจะเอาเทคโนโลยีนี้เข้าไปใน coding agent ได้อย่างไร

2. ตัวเลข 64% บอกอะไรมากกว่าที่คิด

64% ของ cloud environment เปราะ กับ 51% ที่เปิดสู่สาธารณะ เป็นตัวเลขที่ทำให้ต้องคิด: ใน cloud สมัยนี้ เราไม่ได้แค่ "เปิดเว็บ" แต่เราเปิด HTTP/2 อัตโนมัติโดยไม่ได้รู้ตัว ค่า default ของ reverse proxy และ ingress controller หลายตัวเปิด HTTP/2 ไว้เสมอ และ patch ช่องโหว่นี้ไม่ใช่เรื่องของแอปที่เราเขียน แต่เป็นเรื่องของ image ที่เรา pull มา


สรุปที่ต้องทำ

  1. เช็คว่าเครื่องไหนในระบบรัน Apache และรุ่นเท่าไร
  2. อัปเกรดเป็น 2.4.71 ขึ้นไป (หรือ mod_h2 2.0.42 ขึ้นไป)
  3. ถ้าอัปเกรดทันไม่ได้ทันที ให้ปิด HTTP/2 ด้วย Protocols http/1.1 เป็นมาตรการชั่วคราว
  4. อย่าลืม container image ที่ build ไว้ — patch ที่ registry ไม่ได้ช่วย ต้อง rebuild
  5. ถ้ามี cloud resource ที่เปิดสู่สาธารณะ ให้ดูว่ามี Apache ตัวไหนบ้างโดยเฉพาะ

ถ้าคุณใช้ Wiz อยู่จะมี query กับ advisory ให้ใช้ (wiz-threat-center → wiz-adv-2026-191) ส่วนคนที่ไม่มีก็ลอง grep รุ่น Apache ในระบบก่อน แล้วค่อยตัดสินใจว่าจะอัปเกรดหรือปิด HTTP/2

contents

  • ช่องโหว่อยู่ตรงไหน
  • ใครเปราะบ้าง
  • ต้องแก้ยังไง
  • ทางเลือกที่ถูก: อัปเกรด
  • ทางเลือกที่ชั่วคราว: ปิด HTTP/2
  • เช็คว่าตัวเองโดนไหม
  • สองเรื่องที่น่าสนใจกว่าตัว CVE
  • 1. AI กำลังหาช่องโหว่จริง
  • 2. ตัวเลข 64% บอกอะไรมากกว่าที่คิด
  • สรุปที่ต้องทำ

related documents

security · 3
  • Lock your GitHub Actions: กัน Supply-chain Attack ด้วย lockfile แทนการ pin SHA ไปมีอีกทาง

    13 Nov 2026 · 3 min read

  • Security Best Practices for OpenClaw: Hardening Your Self-Hosted AI Agent

    06 Apr 2026 · 5 min read

  • Axios ถูกฝังมัลแวร์: บทเรียนด้านความปลอดภัยสำหรับนักพัฒนา

    06 Apr 2025 · 3 min read

comments