สิบนาทีหลังเปิด PR แก้บั๊ก เซิร์ฟเวอร์ก็โดนยิงด้วยเพย์โหลดตรงรูปแบบ — เมนเทนเนอร์ OCaml สรุปว่า security embargo แบบเดิมไม่ซื้อเวลาให้ใครอีกแล้ว

(หมายเหตุ: โพสต์ต้นทางลงวันที่ 22 ส.ค. 2026 เรานำมาเขียนช้ากว่านั้น — มันกลับมาเป็นที่ถกเถียงรอบใหญ่เมื่อ 28 ส.ค. หลัง Simon Willison หยิบไปเขียนต่อและมีเมนเทนเนอร์โครงการอื่นเข้ามายืนยันว่าเจอเหมือนกัน)

Anil Madhavapeddy ศาสตราจารย์ด้านวิทยาการคอมพิวเตอร์ที่เคมบริดจ์และเมนเทนเนอร์หลักของคอมไพเลอร์ OCaml เขียนบันทึกสั้น ๆ แต่หนักมากชิ้นหนึ่ง หลังปล่อยแพตช์ความปลอดภัยของ cohttp 6.3.0 ซึ่งแก้ช่องโหว่ path traversal (advisory OSEC-2026-16)

ตามขั้นตอนปกติของโลกโอเพนซอร์ส บั๊กแบบนี้จะถูก embargo ไว้ — แก้เงียบ ๆ แจ้งผู้ได้รับผลกระทบก่อน แล้วค่อยออกประกาศสาธารณะ แต่รอบนี้เขาเจอสิ่งที่ทำให้ขั้นตอนทั้งชุดดูไร้ความหมาย: “I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue”

ไทม์ไลน์จริง วัดเป็นนาที

รายงานบั๊กเดินทางมาถึงเขาแบบส่วนตัวผ่านช่อง Slack ทาง Jane Street เมื่อสัปดาห์ก่อนหน้า และตัวบั๊กเองก็ ถูกค้นพบด้วย Claude Fable ตั้งแต่ต้นทาง — ไทม์ไลน์ทั้งเส้นถูกบีบสั้นลงตั้งแต่จุดนั้นแล้ว

ก่อนจะดูแพตช์อย่างละเอียด เขาชี้เอเจนต์ของตัวเองไปที่โค้ดส่วนที่มีปัญหาเพื่อดูว่ายังมีอะไรซ่อนอยู่อีก โดยสั่งให้ไปสำรวจปัญหา path normalisation:

• Claude Fable ปฏิเสธงานนี้ตรง ๆ เพราะติดบล็อกด้านความปลอดภัย เนื่องจากเขาไม่มีสิทธิ์เข้าถึง Project Glasswing
• DeepSeek V4 Pro ทำให้ และพบปัญหาที่เกี่ยวข้องเพิ่มอีกหลายจุดด้วยตัวเอง
• เอเจนต์ของเขา สร้างเพย์โหลดโจมตีเพื่อยิงเซิร์ฟเวอร์ทดสอบในเครื่องได้ในเวลาไม่ถึงหนึ่งนาที

จากนั้นเขาเปิด cohttp#1145 สู่สาธารณะแบบเงียบ ๆ เพื่อขอสายตาช่วยรีวิว งานแบบนี้ปกติใช้เวลาไม่กี่วันและออกรีลีสภายในหนึ่งถึงสองสัปดาห์ก็ถือว่าเหมาะสม แต่ “Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories.”

ประโยคที่ตามมาคือส่วนที่น่ากลัวที่สุดของโพสต์ทั้งชิ้น: “If it took me just a minute to create my own exploit locally, then ten minutes actually seems quite long for an automated attack window to start!”

ทำไม embargo ถึงหมดฤทธิ์

ตรรกะของ embargo ตั้งอยู่บนสมมติฐานว่า ความลับของรายละเอียดคือสิ่งที่ปกป้องผู้ใช้ — แต่วันนี้เอเจนต์ต้องการแค่ “ทิศทางกว้าง ๆ” ว่าให้ไปหาอะไรแถวไหน แล้วมันวิจัยต่อเองได้

Madhavapeddy อ้างงานของ Fang et al. (2024) ที่พบว่าเอเจนต์ GPT-4 เจาะช่องโหว่ได้ 87% จากชุดทดสอบ 15 รายการเมื่อได้รับคำอธิบาย CVE แต่ทำได้แค่ 7% เมื่อไม่ได้รับ — ส่วนต่าง 80 จุดนี้คือมูลค่าทั้งหมดที่ embargo เคยซื้อไว้ให้ และสองปีต่อมาตัวเลข mean time to exploit ติดลบ 7 วัน แล้ว หมายความว่าโดยเฉลี่ย การโจมตีเกิดขึ้นก่อนแพตช์ ตัวเลขเดียวกันนี้เคยอยู่ที่ราว 63 วันในช่วงปี 2018–19 และข้ามศูนย์ไปเมื่อปี 2024

ตัวอย่างล่าสุดที่เขายกมา:

ช่องโหว่	จากประกาศ → ความพยายามโจมตีครั้งแรก
marimo — CVE-2026-39987	9 ชั่วโมง (โดยไม่มี proof-of-concept สาธารณะเลย)
Langflow — CVE-2026-33017	20 ชั่วโมง

สิ่งที่กลับด้านคือ ตอนนี้แค่มีคนหนึ่งคนกำลังค้นหาเรื่องคลาสของบั๊กนั้นอยู่ ก็เพียงพอแล้ว — ไม่ว่าจะเป็นคำถามในเมลลิงลิสต์ คอมมิตแปลก ๆ ในบรานช์กำพร้า หรือบริบทที่หลุดออกมา ก็พอจะปลุกเอเจนต์ของอีกฝ่ายให้ไปสร้างโค้ดโจมตีได้

งานปี 2026 ของ Pesoli et al. บัญญัติคำว่า “bugonomics” ขึ้นมาอธิบายภาวะนี้ และเสนอว่าคอขวดได้ย้ายไปอยู่ที่ defender remediation throughput — LLM ผลิตเอ็กซ์พลอยต์ออกมาเรื่อย ๆ แต่ความสามารถในการตรวจสอบ จัดลำดับ และปล่อยรีลีสของเมนเทนเนอร์ยังเท่าเดิม

และไม่ใช่แค่ OCaml — Nick Craig-Wood เมนเทนเนอร์ rclone ยืนยันในความเห็นบน Hacker News ว่า “In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month!” โดยอัตราที่รายงานเหล่านั้นมีเนื้ออยู่จริงสูงถึงราว 75% (คือไม่ใช่ขยะ แต่คือภาระจริง) และเสริมว่า GitHub เคยออก CVE ให้ภายใน 2–3 วัน ตอนนี้ใช้เวลา 3–4 สัปดาห์ จนเขาต้องปล่อย point release พร้อมคำว่า CVE-PENDING ใน changelog

สามทางที่เขาเสนอ และข้อจำกัดของแต่ละทาง

1. พัฒนาแพตช์ในที่ที่ลับจริง ๆ — temporary private forks ของ GitHub ตั้งใจทำเพื่อการนี้ แต่ใช้จริงแล้วไม่เวิร์ก: GitHub ตัด CI ออกจาก fork ประเภทนี้เพื่อกันข้อมูลรั่ว ซึ่งเท่ากับตัดเมนเทนเนอร์ออกจากผลเทสต์, merge เข้า fork ได้แค่ PR เดียวทั้งที่ปัญหาจริงมักคร่อมหลาย repo, และผู้รีวิวต้องถูกแอดมินเพิ่มเข้าทีละคน ทั้งที่โลกโอเพนซอร์สคนรีวิวคือใครก็ได้ที่ว่างในตอนนั้น เขาสรุปว่านี่คือ การอุดรูผิดรู อยู่ดี — สิ่งที่สำคัญกว่าการเก็บแพตช์เป็นความลับ คือการทำให้ คำอธิบายปัญหา ไปถึงคนที่ควรรู้โดยไม่รั่ว ซึ่งต้องการโครงสร้าง web-of-trust ที่โอเพนซอร์สยังไม่มี (ทุกวันนี้กระจายอยู่บน Matrix, Discord, Slack ที่รั่วง่ายมาก)

2. เลิก embargo แล้วปล่อยต่อเนื่อง — Chrome พิสูจน์ว่าทำได้ด้วยอัปเดตความปลอดภัยรายสัปดาห์ ปล่อยสองรีลีสต่อสัปดาห์ และ dynamic patching ที่สลับโปรเซสเบื้องหลังเป็นไบนารีใหม่โดยไม่ต้องรีสตาร์ต ส่วนเคอร์เนล Linux ก็ปล่อยแก้เร็วที่สุดเท่าที่ทำได้ โดยเลื่อนได้ไม่เกินเจ็ดวันและกรณียกเว้นสิบสี่วัน แต่อุปสรรคของ OSS คือแพ็กเกจจิ้ง — Chrome ส่งไบนารีก้อนเดียว ส่วนไลบรารีโอเพนซอร์สฝังอยู่ในผลิตภัณฑ์ปลายน้ำสารพัด สิ่งที่ต้องมีก่อนคือระบบจัดการแพ็กเกจข้ามอีโคซิสเต็มที่บอกได้ว่าไลบรารีตัวหนึ่งไปโผล่อยู่ที่ไหนบ้าง เครื่องมือสแกนช่วย triage และ CI ที่ครอบคลุมแพลตฟอร์มจริง ไม่ใช่แค่ Linux (OpenBSD, FreeBSD, macOS และสถาปัตยกรรมอย่าง RISC-V)

3. ป้องกันเชิงรุกที่ชั้นโปรโตคอล — ถ้ายอมรับว่าแพตช์ต้นน้ำจะตามหลังเอ็กซ์พลอยต์เสมอ ก็ต้องมีอะไรที่เร็วกว่ามาขวางก่อน บั๊ก cohttp ตัวนี้มีมาตรการบรรเทาที่ง่ายมาก — แค่ normalise ตัวคั่นพาธที่ถูก percent-encode — และกฎข้อนี้ เขียนได้ตั้งแต่นาทีที่รายงานมาถึง พร้อมดีพลอยระหว่างที่แพตช์เต็มยังอยู่ในขั้นรีวิวและแพ็กเกจ virtual patching เป็นเรื่องปกติบนคลาวด์อยู่แล้ว (Cloudflare ปล่อย managed rules อุด Log4Shell ตั้งแต่ปี 2021) แต่ โอเพนซอร์สไม่มีกลไกกระจายกฎแบบนี้นอกเหนือจาก CDN เชิงพาณิชย์

มีอีกประเด็นที่เขาพูดตรง ๆ และเจ็บ: Project Glasswing ขยายเป็น 150 องค์กรใน 15 ประเทศแล้ว ครอบคลุมผู้ให้บริการโครงสร้างพื้นฐานสำคัญ คลาวด์ สถาบันการเงิน และ Linux Foundation แต่เมนเทนเนอร์ระดับ “mom and pop” ยังเข้าไม่ถึง เขาบอกว่าเมื่อเดือนเมษายนเขายัง ambivalent ว่าเรื่องนี้เป็นผลเสียหรือไม่ “but it’s pretty obvious today that it’s turning out pretty terribly” — เพราะฝั่งโจมตีใช้โมเดลน้ำหนักเปิดที่ไม่มีการ์ดเรลได้อยู่แล้ว ขณะที่ฝั่งป้องกันโดนโมเดลเชิงพาณิชย์ปฏิเสธงาน

มุมมอง AI Curator

โพสต์นี้มีค่ามากเพราะมันไม่ใช่บทวิเคราะห์ แต่เป็น เทเลเมทรี — คนเดียวกันเป็นทั้งคนแก้บั๊ก คนเปิด PR และคนที่อ่านล็อกเว็บเซิร์ฟเวอร์ตัวเอง เลข “สิบนาที” จึงมีน้ำหนักต่างจากสถิติรวมของบริษัทความปลอดภัยที่ขายของอยู่ด้วย

สิ่งที่น่าคิดที่สุดไม่ใช่ความเร็วของฝ่ายโจมตี แต่คือ ความไม่สมมาตรที่การ์ดเรลสร้างขึ้นเอง ในไทม์ไลน์เดียวกันนี้ โมเดลเชิงพาณิชย์ตัวท็อปปฏิเสธที่จะช่วยเมนเทนเนอร์ตรวจโค้ดของตัวเอง ขณะที่โมเดลน้ำหนักเปิดยินดีทำให้ ผลลัพธ์คือ policy ที่ตั้งใจกันคนร้ายกลับไปเก็บภาษีจากคนดีเป็นหลัก เพราะคนร้ายมีทางเลือกอื่นเสมอ ส่วนเมนเทนเนอร์อาสาสมัครไม่มี — นี่คือข้อโต้แย้งเชิงประจักษ์ที่หนักที่สุดข้อหนึ่งที่เราเคยเห็นต่อการจำกัดสิทธิ์เข้าถึงความสามารถด้านความปลอดภัยไว้กับองค์กรใหญ่ และมันมาจากคนที่อยู่ในสถานะที่ควรผ่านเกณฑ์ทุกข้อของ Glasswing อยู่แล้วด้วยซ้ำ

สำหรับทีมไทย บทเรียนที่เอาไปใช้ได้ทันทีมีสามข้อ หนึ่ง ถ้าคุณดูแลโอเพนซอร์สหรือมีไลบรารีภายในที่แชร์ข้ามทีม ให้เลิกคิดว่า “ยังไม่ประกาศ = ยังปลอดภัย” — สมมติฐานที่ปลอดภัยกว่าคือ นับถอยหลังเริ่มตั้งแต่นาทีที่คอมมิตแรกโผล่ในที่สาธารณะ และวางแผนรีลีสจากตรงนั้น สอง มาตรการบรรเทาชั้น edge — กฎ WAF, การ normalise พาธที่ reverse proxy, rate limit บนเส้นทางที่ต้องสงสัย — เลิกเป็น “ของเสริม” แล้ว มันคือชั้นที่ปล่อยได้ภายในนาทีขณะที่แพตช์จริงยังใช้เวลาเป็นวัน ทีมที่ใช้ Cloudflare หรือ nginx อยู่แล้วมีกลไกนี้ในมือโดยไม่ต้องซื้ออะไรเพิ่ม สาม ถ้าโครงการของคุณเปิดรับรายงานช่องโหว่ผ่าน GitHub เตรียมรับ น้ำท่วมรายงานที่เครื่องเขียน ได้เลย — ตัวเลขของ rclone (20 ฉบับใน 10 ปี → 40+ ฉบับในเดือนเดียว) คือรูปร่างของสิ่งที่กำลังจะมาถึง และเพราะ 75% ของมันมีเนื้อจริง คุณจะทิ้งไม่ได้ด้วย ให้ตัดสินใจตั้งแต่ตอนนี้ว่าใครในทีมเป็นคน triage และจะใช้เครื่องมืออะไรช่วย ก่อนที่มันจะมาถึงจริง

ประโยคที่ควรจำจากโพสต์นี้คือคำถามที่ Pesoli et al. ตั้งไว้ ซึ่ง Madhavapeddy ยกมาเห็นด้วย: คำถามไม่ใช่ว่าโมเดล frontier โมเดลน้ำหนักเปิด หรือ program analysis ฝ่ายไหน “ชนะ” แต่คือ จะจัดวางมันอย่างไรให้ความสามารถในการตรวจสอบและปล่อยรีลีสที่มีอยู่อย่างจำกัด ถูกใช้ไปกับการแก้ที่ยั่งยืน แทนที่จะหมดไปกับการค้นหาและร่างรายงานแบบกลไก

แหล่งข่าว

• Just a rumour of a bug is enough to find a security exploit these days — Anil Madhavapeddy (22 ส.ค. 2026)
• Simon Willison — บันทึกที่หยิบเรื่องนี้มาขยายพร้อมความเห็นของเมนเทนเนอร์ rclone (28 ส.ค. 2026)
• cohttp#1145 — PR ที่เป็นจุดเริ่มของไทม์ไลน์สิบนาที
• Fang et al. (2024) — LLM Agents can Autonomously Exploit One-day Vulnerabilities (ที่มาของตัวเลข 87% vs 7%)