Ash 3.37.2 แก้ CVE-2026-96581: upsert อาจย้ายข้อมูลข้าม tenant

Ash 3.37.2 แก้ CVE-2026-96581: upsert อาจอ่านและย้ายข้อมูลข้าม tenant

โครงการ Ash Framework ออก ash รุ่น 3.37.2 เพื่อแก้ CVE-2026-96581 ซึ่งเกี่ยวกับการสร้างข้อมูลแบบ upsert ในแอปที่ใช้ multitenancy ชนิด strategy :attribute ภายใต้การตั้งค่าที่เข้าข่าย ผู้ใช้ของ tenant หนึ่งอาจส่ง primary key ของระเบียนอีก tenant ให้ create action แล้วได้รับข้อมูลกลับมา แก้ไขฟิลด์ หรือทำให้ระเบียนถูกย้ายมาอยู่ใน tenant ของตนได้ ผู้ดูแลแอป Elixir ที่ให้ผู้ใช้สร้างหรืออัปเดตข้อมูลผ่าน Ash ควรตรวจเส้นทางนี้เป็นพิเศษ

ประกาศของผู้พัฒนาระบุช่วงที่ได้รับผลกระทบเป็น ash ตั้งแต่ 1.22.0 ถึงก่อน 3.37.2 และให้ระดับความรุนแรง High ความเสี่ยงไม่ครอบคลุมทุกแอปที่ติดตั้ง Ash แต่ต้องมี resource ที่ใช้ attribute multitenancy, เปิด create action แบบ upsert? true ที่ผู้เรียกส่งคีย์ชนกับระเบียนของ tenant อื่นได้ และเข้าเงื่อนไขการ upsert ด้วย primary key หรือ identity ที่ตั้ง all_tenants? การมีคีย์ที่เดาได้หรือรั่วจากลิงก์และข้อมูลส่งออกทำให้เส้นทางนี้เข้าถึงได้ง่ายขึ้น

ลำดับการเปิดเผยและแพตช์

commit แก้ไขของโครงการ ปรากฏวันที่ 26 ตุลาคม 2026 เวลา 05:12 UTC โดยระบุว่าจำกัด upsert ให้อยู่ใน tenant ของคำขอ Ash 3.37.2 เผยแพร่เวลา 05:30 UTC ในวันเดียวกัน จากนั้นผู้พัฒนาเผยแพร่ ประกาศความปลอดภัย GHSA-vw7c-67pf-gh96 เวลา 05:32 UTC และ ระเบียน CVE-2026-96581 ถูกเผยแพร่ครั้งแรกเวลา 07:20 UTC เวลาทั้งหมดเป็น UTC

วันดังกล่าวสำคัญต่อการเลือกแพตช์: ash 3.37.1 ที่ออกก่อนหน้านี้แก้ช่องโหว่คนละชุด แต่ยังอยู่ในช่วงที่ได้รับผลกระทบของ CVE-2026-96581 หากระบบเพิ่งอัปเดตเป็น 3.37.1 ต้องอัปเดตต่อเป็น 3.37.2 หรือใหม่กว่า ไม่ควรถือว่าการอัปเดตครั้งก่อนครอบคลุมช่องโหว่นี้แล้ว

กลไกที่ทำให้ข้อมูลข้าม tenant

ใน Ash การทำ upsert คือการสร้างระเบียนใหม่หรือปรับระเบียนเดิมเมื่อพบคีย์ชนกัน ประกาศของโครงการระบุว่า Ash.Actions.Create และ Ash.Actions.Create.Bulk รุ่นก่อนแก้ไขไม่ได้จำกัดระเบียนที่ชนคีย์ให้อยู่ใน tenant ของคำขอ เมื่อแอปใช้ attribute multitenancy แล้วให้ caller ส่ง primary key เข้า create action ได้ ผู้โจมตีที่รู้คีย์ของระเบียนอีก tenant สามารถส่ง create/upsert ด้วยคีย์นั้น การชนคีย์ทำให้โค้ดเข้าเส้นทางอัปเดตระเบียนเดิม ทั้งที่ระเบียนนั้นเป็นของ tenant อื่น

ผลไม่ได้มีแค่การตอบว่าคีย์มีอยู่หรือไม่ ประกาศระบุว่า upsert อาจคืน ทุก attribute ของระเบียน ให้ผู้เรียกและเขียนฟิลด์ที่เปิดให้อัปเดตลงระเบียนเดิม หากแอปใช้ค่าเริ่มต้นของฟิลด์ upsert การเขียนอาจรวม tenant attribute ทำให้ความเป็นเจ้าของระเบียนเปลี่ยนไปยัง tenant ของผู้เรียก จึงมีทั้งความเสี่ยงด้านความลับและความถูกต้องของข้อมูล ขอบเขตจริงขึ้นกับ action, identity, field ที่อนุญาต และ data layer ที่ใช้งาน

เหตุที่ policy ทั่วไปอาจไม่กันกรณีนี้ได้ คือประกาศระบุว่า read และ update policies ไม่ได้ทำงานบนเส้นทาง upsert ขณะที่ create policy ที่จำกัด tenant ผ่านได้เพราะคำขอมี tenant ของผู้เรียกเอง ผู้ดูแลจึงไม่ควรประเมินว่า read/update policy ปัจจุบันเพียงอย่างเดียวปิดช่องนี้แล้ว แม้ resource จะมีการกำหนดนโยบายหลายชั้นก็ตาม

แอปแบบใดควรตรวจเป็นอันดับแรก

ตรวจ resource ที่ใช้ strategy :attribute และ action ที่ประกาศ upsert? true โดยเฉพาะ action ที่ upsert จาก primary key เมื่อไม่ได้ระบุ upsert_identity และยอมรับ primary key จาก input ผู้ใช้ รวมถึง identity ที่ตั้ง all_tenants? ให้ตรวจ API, GraphQL และ background job ที่อาจส่งค่า id จากภายนอกไปถึง action นี้ด้วย สำหรับ primary key แบบเลขลำดับ ผู้เรียกอาจเดาค่าที่มีอยู่ได้ ส่วนคีย์ที่คาดเดายากก็ยังมีความเสี่ยงหากเคยปรากฏในลิงก์ รายงาน หรือข้อมูล export

การตรวจควรแยกจากช่องโหว่ Ash และ AshPostgres สามรายการที่ออกประกาศก่อนหน้านี้: บทความชุดก่อน กล่าวถึงการอ่าน relationship และการคืน skipped upsert ข้าม tenant ส่วน CVE-2026-96581 นี้เกี่ยวกับ การ upsert ที่ชนระเบียนเดิมแล้วแก้ไขหรือย้ายความเป็นเจ้าของ แม้ใช้โครงการเดียวกัน แต่จุดเรียกและผลกระทบต่างกัน

วิธีแก้และมาตรการระหว่างรออัปเดต

วิธีหลักคืออัปเดตแพ็กเกจ ash เป็น 3.37.2 หรือใหม่กว่า ตรวจ mix.lock และเวอร์ชันที่ process โหลดจริงหลัง deploy จากนั้นทดสอบ create/upsert ในสภาพแวดล้อมที่มีอย่างน้อยสอง tenant ใช้ account ของ tenant A ส่งคีย์ของระเบียน tenant B แล้วตรวจว่าคำขอไม่คืนข้อมูล ไม่เขียนฟิลด์ และไม่เปลี่ยน tenant ของระเบียน B ควรทดสอบทั้ง action เดี่ยวและ bulk หากแอปเปิดใช้ทั้งสองแบบ

ผู้พัฒนาเสนอวิธีลดความเสี่ยงชั่วคราวโดยเพิ่ม upsert_condition expr(<tenant attribute> == ^tenant()) ให้ทุก create action ที่ upsert จาก primary key หรือ identity แบบ all_tenants? และ อย่าใช้ร่วมกับ return_skipped_upsert? เงื่อนไขนี้ทำให้การชนระเบียนต่าง tenant ไม่แก้ไขระเบียนนั้น แต่ประกาศเตือนชัดว่า workaround นี้ ใช้ไม่ได้กับ Mnesia data layer ในรุ่นที่ได้รับผลกระทบ เพราะ Mnesia ไม่บังคับ upsert condition ดังกล่าว สำหรับระบบที่ใช้ Mnesia หรือยังตรวจเส้นทางการ upsert ไม่ครบ ควรจำกัดการเข้าถึง action ที่เข้าข่ายจนกว่าจะอัปเดตได้

ประกาศไม่ได้ระบุว่ามีการโจมตีจริงเกิดขึ้นแล้ว หากพบว่าระบบเปิด action ตามเงื่อนไข ควรตรวจ log คำขอที่ส่ง primary key ซ้ำ การเปลี่ยน tenant attribute และการแก้ไขระเบียนข้าม tenant โดยใช้หลักฐานภายในของระบบ การไม่มี log ไม่ใช่หลักฐานว่าไม่เคยถูกใช้ช่องโหว่ แต่ไม่ควรสรุปว่าข้อมูลรั่วไหลโดยไม่มีการตรวจสอบ

แหล่งต้นทาง: ประกาศความปลอดภัยของ Ash, commit แก้ไข, รุ่น Ash 3.37.2 และ ระเบียน CVE-2026-96581