Ash และ AshPostgres แก้ CVE-2026-114214, CVE-2026-115627 และ CVE-2026-115635

Ash และ AshPostgres ออกแพตช์ 3 CVE ที่อาจทำให้ข้อมูลข้ามขอบเขตสิทธิ์

ผู้พัฒนาแอป Elixir ที่ใช้ Ash Framework และ AshPostgres ควรตรวจรุ่นของทั้งสองแพ็กเกจ หลังโครงการเผยแพร่คำแนะนำความปลอดภัยสามรายการเกี่ยวกับการอ่านข้อมูลผิดขอบเขต ความเสี่ยงไม่เกิดกับทุกแอปที่ติดตั้งแพ็กเกจ: แต่ละรายการต้องมีรูปแบบ relationship, นโยบายสิทธิ์ หรือการตั้งค่า multitenancy ตามที่ระบุไว้ ผู้ดูแลจึงควรตรวจทั้ง dependency ที่ใช้งานจริงและเส้นทางเรียกข้อมูลที่เปิดให้ผู้ใช้เข้าถึง

รายการที่เกี่ยวข้องคือ CVE-2026-114214 ใน ash และ CVE-2026-115627 กับ CVE-2026-115635 ใน ash_postgres โครงการระบุรุ่นแก้ไขเป็น ash 3.37.1 และ ash_postgres 2.15.2 ทั้งสามรายการเป็นปัญหาการรักษาขอบเขตการอ่านข้อมูล ไม่ใช่การยืนยันว่าผู้โจมตีสั่งรันโค้ดบนเซิร์ฟเวอร์ได้

วันเปิดเผยและรุ่นที่ต้องตรวจ

หลักฐานสาธารณะในคลังโครงการแสดงการแก้ไขวันที่ 25 ตุลาคม 2026: commit ของ Ash เวลา 03:07 UTC, commit แก้ lateral join ของ AshPostgres เวลา 03:19 UTC และ commit แก้ skipped upsert เวลา 03:42 UTC ต่อมา Ash 3.37.1 เผยแพร่เวลา 16:53 UTC และ AshPostgres 2.15.2 เผยแพร่เวลา 18:01 UTC ในวันเดียวกัน

ประกาศความปลอดภัยจากผู้พัฒนาเผยแพร่วันที่ 25 ตุลาคม 2026 โดย ประกาศของ CVE-2026-114214 เวลา 17:25 UTC และประกาศของ CVE-2026-115627 กับ CVE-2026-115635 เวลา 18:01 UTC ผู้ประสานงาน CVE ของระบบนิเวศ Erlang/Elixir เผยแพร่ระเบียน CVE ครั้งแรกวันที่ 25 ตุลาคม 2026 เวลา 19:47 UTC, 19:49 UTC และ 19:48 UTC ตามลำดับ เวลาทั้งหมดในบทความนี้เป็น UTC

CVE-2026-114214: ความสัมพันธ์ through อาจข้ามต้นทาง

ประกาศของ Ash ระบุว่ากระทบ ash ตั้งแต่ 3.24.0 ถึงก่อน 3.37.1 เมื่อแอปโหลด has_many ที่ประกาศ through: สำหรับระเบียนต้นทางเพียงรายการเดียวและกำหนด limit: 1 หรือโหลด has_one through ที่ไม่ได้จัดเรียงโดยใช้ limit: 1 เส้นทาง lateral_join?/4 อาจเลือกอ่านระเบียนปลายทางโดยไม่ผูกเงื่อนไขกับระเบียนต้นทาง ผลลัพธ์จึงอาจเป็นปลายทางรายการแรกตามการเรียง หรือรายการอื่นเมื่อมี offset

จุดสำคัญคือการอ่านปลายทางยังผ่าน policy ของปลายทาง แต่ถูกส่งบริบทว่าเข้าถึงผ่าน relationship (accessing_from) หาก policy อนุญาตข้อมูลเฉพาะเมื่อมาจากความสัมพันธ์ดังกล่าว ผู้ใช้ที่ควบคุม limit และ offset ผ่าน API เช่นฟิลด์ relationship ของ AshGraphql อาจไล่อ่านระเบียนที่ไม่ได้สัมพันธ์กับต้นทางของตนได้ ผลกระทบขึ้นอยู่กับ policy และรูปแบบการเปิด API จริง ไม่ควรสรุปว่าแอป Ash ทุกแห่งเปิดเผยข้อมูลทั้งหมด การแก้ไขใน 3.37.1 บังคับให้การอ่าน through ใช้เส้นทาง join ที่รักษาความสัมพันธ์ของต้นทาง

CVE-2026-115627: lateral join อาจใช้แถวเชื่อมของ tenant อื่น

รายการนี้กระทบ ash_postgres ตั้งแต่ 0.38.0 ถึงก่อน 2.15.2 เฉพาะรูปแบบที่ resource สำหรับแถวเชื่อมของ many_to_many หรือ resource ในเส้นทาง through ใช้ multitenancy แบบ strategy :attribute และมีข้อมูลหลาย tenant ในตารางเดียว เมื่อโหลด relationship ผ่าน lateral join เช่นมี limit, offset หรือ sort ต่อความสัมพันธ์ โค้ดก่อนแก้ไขสร้าง query ของแถวเชื่อมโดยไม่ได้เรียก read action ที่เพิ่มเงื่อนไข tenant ให้ resource นั้น

ผลคือ query อาจนำแถวเชื่อมของ tenant อื่นมาผูกกับข้อมูลปลายทางและคืนระเบียนที่ผู้ใช้ tenant ปัจจุบันไม่ได้มีความสัมพันธ์อยู่ ผู้ดูแลควรตรวจ endpoint ที่คืนความสัมพันธ์หลายต่อหลายหรือ through โดยเฉพาะกรณีให้ client ระบุการแบ่งหน้าและการเรียงลำดับได้ การเห็นข้อมูลผิด tenant ในกรณีนี้เป็นความเสี่ยงด้านความลับของข้อมูล ไม่ได้หมายความว่าเกิดการแก้ไขข้อมูลข้าม tenant เสมอไป แพตช์ 2.15.2 เพิ่มการใช้เงื่อนไข attribute multitenancy ใน resource ที่ lateral join เดินผ่าน

CVE-2026-115635: upsert ที่ข้ามการเขียนอาจคืนระเบียนอีก tenant

รายการที่สามกระทบ ash_postgres ตั้งแต่ 2.6.22 ถึงก่อน 2.15.2 ใน resource ที่ใช้ attribute multitenancy และมีการเรียก create/upsert พร้อม return_skipped_upsert?: true หากเงื่อนไข upsert_condition ทำให้การเขียนถูกข้าม โค้ดก่อนแก้จะค้นระเบียนเดิมจากค่า identity เพื่อส่งกลับ แต่การค้นนั้นไม่จำกัด tenant ผู้เรียกที่ส่ง identity ตรงกับระเบียนของ tenant อื่นจึงอาจได้รับฟิลด์ของระเบียนนั้นกลับมา

เงื่อนไขการเกิดปัญหาค่อนข้างเฉพาะ: แอปต้องเปิด action ดังกล่าวให้ผู้เรียกควบคุมค่า identity ได้ และค่าต้องตรงกับระเบียนที่มีอยู่ใน tenant อื่น ผู้ดูแลควรค้นการใช้ Ash.bulk_create/4 และการสร้างระเบียนแบบ upsert ที่คืน skipped upsert รวมถึงตรวจว่า identity และ policy ของ resource ถูกกำหนดอย่างไร รุ่น 2.15.2 เพิ่มตัวกรอง tenant ให้การอ่านระเบียนเดิมหลังการ upsert ถูกข้าม

วิธีรับมือและตรวจระบบ

ตรวจ mix.lock ควบคู่กับรุ่นที่ process ใช้จริง แล้วอัปเดต ash เป็น 3.37.1 หรือใหม่กว่า และ ash_postgres เป็น 2.15.2 หรือใหม่กว่า ตามแพ็กเกจที่แอปติดตั้ง การอัปเดตเพียงแพ็กเกจหนึ่งไม่ครอบคลุม CVE ของอีกแพ็กเกจ หลัง deploy ให้ทดสอบข้อมูลตัวอย่างแยกหลาย tenant โดยใช้ผู้ใช้ที่มีสิทธิ์เท่ากับ client จริง ทดสอบการโหลด through ที่ limit: 1 และ offset, การโหลด many_to_many ด้วย lateral join และกรณี skipped upsert ที่ identity ซ้ำข้าม tenant ผลลัพธ์ไม่ควรมีระเบียนที่ไม่สัมพันธ์กับต้นทางหรืออยู่คนละ tenant

หากยังอัปเดตไม่ได้ทันที ให้จำกัดไม่ให้ client กำหนด limit/offset/sort ใน relationship ที่เข้าข่าย และระงับ action upsert ที่คืน skipped upsert เมื่อ caller ควบคุม identity ได้ พร้อมตรวจนโยบายการอ่านปลายทาง มาตรการเหล่านี้ขึ้นกับโครงสร้างแอปและไม่แทนแพตช์ โครงการไม่ได้ระบุหลักฐานการโจมตีจริงในประกาศทั้งสาม ดังนั้นควรแยกความเสี่ยงตามเงื่อนไขที่ยืนยันได้ออกจากการสรุปว่ามีการรั่วไหลเกิดขึ้นแล้ว

แหล่งข้อมูลต้นทาง: ประกาศ Ash CVE-2026-114214, ประกาศ AshPostgres CVE-2026-115627, ประกาศ AshPostgres CVE-2026-115635, ระเบียน CVE-2026-114214, ระเบียน CVE-2026-115627, ระเบียน CVE-2026-115635 และหน้ารุ่นแก้ไขที่ลิงก์ไว้ข้างต้น