Atlassian เตือน CVE-2026-21589 ระดับ Critical: รู้ path ก็อ่านไฟล์ใต้ web root ได้โดยไม่ล็อกอิน

Atlassian ออกประกาศฉุกเฉิน CVE-2026-21589 ระดับ Critical คะแนน CVSS 4.0 เท่ากับ 9.3 กระทบผลิตภัณฑ์ Data Center แปดกลุ่ม ได้แก่ Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo, Crowd, Crucible และ Fisheye ครับ ผู้โจมตีที่ไม่ต้องล็อกอินสามารถเข้าถึงไฟล์บางไฟล์ใต้ web application root ได้ หากรู้ชื่อและ path ที่ตรงเป๊ะ

ประโยค “ต้องรู้ exact path” ไม่ควรถูกแปลว่าเสี่ยงต่ำ เพราะชื่อไฟล์มาตรฐาน, artifact จาก build, คู่มือติดตั้ง, error message หรือข้อมูลจากระบบอื่นอาจช่วยเดา path ได้ Atlassian แนะนำ patch ไป fixed version ทันที; หากยังทำไม่ได้ให้ตัด public access และใช้ WAF/proxy หรือ product-specific rewrite mitigation ชั่วคราว

สรุป 30 วินาที

ช่องโหว่กระทบ Data Center ของ Atlassian 8 กลุ่ม และ advisory ระบุว่า affected versions ก่อนรายการ fix ทั้งหมดต้องได้รับการแก้ไข
ไม่ต้องมีบัญชี ไม่ต้องให้ผู้ใช้กด และ network-accessible instance คือพื้นผิวหลัก
ผู้โจมตีต้องรู้ชื่อกับ path ของไฟล์ และช่องโหว่ไม่ให้ list directory แต่ไฟล์ที่อ่านได้อาจมีข้อมูลสำคัญตาม configuration
Atlassian Cloud ถูก patch แล้วและบริษัทบอกว่ายังไม่พบหลักฐาน exploitation ในการสืบสวนของตน Cloud customer ไม่ต้องทำอะไรกับ advisory นี้
Data Center admin ต้อง inventory ทุก node, mirror และ instance แล้วอัปเดตตาม branch ที่รองรับ ไม่ใช่ patch เพียง node เดียวใน cluster
Mitigation แบบ WAF/rewrite เป็นสะพานชั่วคราว ต้องทดสอบ encoding/normalization และไม่แทนการอัปเดต

ทำไมเรื่องนี้เกี่ยวกับคุณ

Atlassian Data Center มักอยู่ใกล้ source code, ticket, runbook, deployment detail และ identity integration ต่อให้ช่องโหว่ “อ่านไฟล์” ไม่ได้เขียนหรือรันคำสั่งโดยตรง ไฟล์หนึ่งอาจมี secret, internal URL, signing configuration หรือข้อมูลที่ช่วยโจมตีขั้นถัดไป ผลกระทบจึงไม่ควรวัดจากชนิด primitive เพียงคำเดียว

ลองนึกถึงห้องเอกสารที่ผู้บุกรุกมองไม่เห็นรายชื่อแฟ้ม แต่ถ้ารู้ว่าตู้มาตรฐานเก็บแฟ้มสำคัญช่องไหน เขาสามารถขอแฟ้มนั้นผ่านช่องรับเอกสารได้ การปิดป้ายรายการแฟ้มช่วยนิดเดียว แต่ไม่แก้ประตูที่ไม่ตรวจสิทธิ์

ทีมไทยที่ใช้ reverse proxy, WAF หรือ load balancer หลายชั้นต้องระวังว่าแต่ละชั้น decode URL ไม่เหมือนกัน Rule ที่บล็อกข้อความดิบอาจพลาด double encoding ขณะที่ rule กว้างเกินไปทำให้ path ปกติใช้ไม่ได้ การทดสอบ mitigation ต้องทำกับ staging และเก็บ access log ทั้งก่อน/หลัง normalization

ทำงานยังไง: path ที่หลุดจากรั้ว web application

Advisory อธิบายว่า request ที่สร้างมาเฉพาะสามารถเข้าถึงไฟล์ใต้ web application root โดยไม่ authenticate และต้องรู้ exact name/path มันไม่ใช่ directory browser ที่เปิดแล้วเห็นรายการทั้งหมด แต่เป็นเหมือนช่องบริการที่รับพิกัด หากพิกัดถูกก็ส่งเอกสารออกมา

Atlassian ให้ regex mitigation ที่ตั้งใจบล็อก .. ซึ่งอยู่ติดกับ slash, backslash หรือ double-colon รวมรูปแบบ URL-encoded หลายชั้น และมีคำแนะนำต่างกันตามผลิตภัณฑ์: WAF/proxy ใช้ได้กว้าง, Tomcat RewriteValve สำหรับ Confluence/Jira/JSM/Bamboo/Crowd และ urlrewrite.xml สำหรับ Bitbucket

Mitigation เหล่านี้สะท้อนว่าปัญหาเกี่ยวกับ path traversal/normalization แต่เราไม่ควรประดิษฐ์ payload ทดสอบกับ production หรือเผย path สำคัญใน ticket สาธารณะ ใช้ health check ที่ vendor แนะนำและ staging clone ที่ไม่มีข้อมูลจริง

การมีหลาย node ทำให้ความเสี่ยงซับซ้อน หาก load balancer ยังส่ง traffic ไป node เก่า แม้ node ส่วนใหญ่ patch แล้วก็ยังมีช่องเปิด Mirrors และ mirror farm ของ Bitbucket ต้องอยู่ใน inventory ด้วย ไม่ใช่ดูเฉพาะ URL ที่ผู้ใช้เข้าเป็นประจำ

เวอร์ชันแก้ที่ Atlassian ระบุ

รายการ fixed versions ใน ประกาศต้นทาง คือ Bitbucket 9.4.26, 10.2.8 หรือ 10.5.1; Confluence 9.2.26 หรือ 10.2.19; Jira Service Management 5.12.40, 10.3.26 หรือ 11.3.12; Jira Software 9.12.40, 10.3.26 หรือ 11.3.12

Bamboo ต้อง 10.2.24 หรือ 12.1.12; Crowd ต้อง 6.3.7, 7.0.3, 7.1.7 หรือ 7.2.4; Crucible และ Fisheye ต้อง 4.9.15 ทีมควรเลือก fixed LTS branch ที่ตรง compatibility ของตนหรือใหม่กว่า ไม่เลือกเลขสุ่มข้าม major โดยไม่อ่าน migration notes

หลังอัปเดตให้ยืนยัน version จาก runtime ทุก node ตรวจว่า node เก่าถูกถอดจาก pool และรัน smoke test authentication, search, repository hook, plugin กับ backup/restore ตามขอบเขตผลิตภัณฑ์ อย่าถือว่า installer จบเท่ากับ rollout จบ

เงินและผลกระทบ

Downtime เพื่อ patch มีต้นทุน แต่การอ่านไฟล์ลับอาจนำไปสู่การหมุน credential, forensic, notification และหยุดระบบยาวกว่า วางลำดับจาก internet-facing instance, ระบบที่มีไฟล์ลับใต้ web root, shared identity และ repository ที่มี deployment secrets ก่อน

องค์กรที่ใช้ plugin จำนวนมากอาจกลัว compatibility จนชะลอ patch ให้แยกสองงาน: ลด exposure ทันทีด้วย network/WAF และทำ compatibility test เร่งด่วน ไม่ใช้ข้อกังวล plugin เป็นเหตุผลให้ระบบเปิดสู่ internet แบบเดิม

เก็บหลักฐานก่อนเปลี่ยนระบบเท่าที่ incident process กำหนด เช่น version, topology, WAF config, access log hash และเวลา อย่าลบ log เพราะต้องการพื้นที่ระหว่าง upgrade และอย่าส่ง raw log ที่มี token ไปห้องแชตทั่วไป

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

Atlassian ระบุว่ายังไม่พบหลักฐาน exploitation ในการสืบสวนของบริษัท แต่ไม่ได้แปลว่าไม่มีการโจมตีในทุกองค์กร และ advisory บอกตรง ๆ ว่าไม่สามารถยืนยันว่า instance ของลูกค้าได้รับผลกระทบหรือไม่ ต้องให้ local security team ตรวจเอง

The Register สรุปความรุนแรงและผลิตภัณฑ์กว้าง แต่รายละเอียด operational ที่ควรใช้จริง—fixed versions, regex, node/mirror instructions—ต้องยึด advisory ของ Atlassian ซึ่งอาจแก้ไขภายหลัง จึงควรบันทึกเวลาและ revision ที่ตรวจ

Advisory ไม่แจก “รายชื่อไฟล์ลับทุก configuration” ซึ่งสมเหตุผล เพราะ plugin, deployment และ custom path ต่างกัน ทีมต้อง inventory ของตน ไม่ควรสรุปว่าหากไม่มีไฟล์ตัวอย่างจากอินเทอร์เน็ตก็ปลอดภัย

ยังไม่มีคำตอบเดียวว่า WAF rule ใดเหมาะทุกเทคโนโลยี Atlassian ระบุให้ผู้ใช้ปรับตาม proxy/WAF และทดสอบ rule ดังนั้น mitigation ต้องมี owner, test cases และ expiry date ไม่ปล่อยค้างจนกลายเป็น permanent substitute

แล้วเราควรทำอะไร

ภายในชั่วโมงแรก: ตรวจว่ามีผลิตภัณฑ์แปดกลุ่มนี้หรือไม่จาก asset inventory และ network scan ที่ได้รับอนุญาต ระบุ version, node, mirror, owner, internet exposure และข้อมูลที่อาจอยู่ใต้ web root จากนั้นจำกัด external access หากยังไม่ patch

ภายในวันเดียว: สำรองตาม runbook เลือก fixed branch จากรายการต้นทาง อัปเดต staging แล้ว production ทีละ node พร้อมยืนยัน runtime version และ health หลังกลับเข้าพูล ถ้าจำเป็นต้องใช้ mitigation ให้ implement ตาม vendor, ทดสอบ encoded variants และ monitor false positive

ฝั่ง detection ให้ URL-decode access-log request สูงสุดสองรอบตามคำแนะนำ Atlassian แล้วค้นหา .. ที่ติดกับ slash, backslash หรือ double-colon รวมทั้งค้น raw encoded pattern เก็บผลภายใต้สิทธิ์จำกัด และ correlate กับ response size, source IP, requested path กับเวลาที่ secret ถูกใช้

หากพบ request น่าสงสัย อย่าหยุดที่ block IP ให้เริ่ม incident response ตรวจไฟล์ที่อาจถูกอ่าน หมุน credential ที่เกี่ยวข้องจาก clean environment ตรวจ lateral movement และเก็บ forensic image ตามนโยบาย อุปกรณ์โจมตีอาจเปลี่ยน IP ได้ง่าย

Recap

inventory ทั้ง 8 product groups ทุก node และ mirror
patch เป็น fixed LTS version หรือใหม่กว่าตาม advisory
ตัด internet access ก่อนหาก patch ยังไม่ทัน
ทดสอบ WAF/rewrite กับ encoding และ normalization
ตรวจ log ทั้ง decoded และ raw pattern โดยจำกัดสิทธิ์
ยืนยัน runtime version ทุก node หลัง rollout
หมุน secret และเข้า incident process เมื่อพบหลักฐาน ไม่ block IP อย่างเดียว

คำว่า exact path เป็นเงื่อนไข ไม่ใช่เกราะครับ ระบบที่รู้จักกันกว้างมักมีโครงสร้างที่ค้นร่องรอยได้ การ patch และลด exposure จึงควรเกิดก่อนการถกเถียงว่าผู้โจมตี “น่าจะเดาได้ไหม”