SAP Cloud SDK ได้คะแนน CVSS 10.0—อัปเกรดก่อนคีย์ OAuth2 รั่ว

ประกาศ Security Patch Day ของ SAP วันที่ 13 ตุลาคม 2026 ระบุว่า CVE-2026-89111 ใน SAP Cloud SDK for Python กระทบรุ่นต่ำกว่า 0.45.2 และได้คะแนนความรุนแรง CVSS 10.0 สำหรับทีมที่ดูแลแอปบน SAP Business Technology Platform หรือ BTP งานเร่งด่วนคือระบุว่าแอปใดใช้แพ็กเกจรุ่นดังกล่าวและส่งค่าผู้เช่าเข้า SDK ระหว่างขอโทเค็น การอัปเกรดต้องเกิดในแอปที่ติดตั้งไลบรารี ไม่ใช่รอให้การแพตช์บริการบนแพลตฟอร์มเปลี่ยนแพ็กเกจในอิมเมจของแอปเอง

คำแนะนำด้านความปลอดภัยของโครงการ อธิบายว่าในแอป BTP แบบหลายผู้เช่า ผู้ที่ควบคุมค่า tenant_subdomain อาจเปลี่ยนปลายทางคำขอโทเค็น OAuth2 ให้เป็นเซิร์ฟเวอร์ของตน ทำให้ client credentials ของแอปถูกส่งออกไป รุ่น 0.45.2 เพิ่มการตรวจค่าก่อนนำไปแทนใน URL ของโทเค็น ส่วนการเทียบค่ากับรายชื่อผู้เช่าที่ลงทะเบียนเป็นวิธีลดความเสี่ยงระหว่างรออัปเกรด คะแนนความรุนแรงบอกถึงผลกระทบที่เป็นไปได้ภายใต้เงื่อนไขการโจมตีนี้ ไม่ได้หมายความว่าทุกแอปที่ติดตั้งแพ็กเกจมีคีย์รั่วแล้ว

เหตุใดค่าผู้เช่าจึงพาคำขอโทเค็นออกนอกปลายทาง

แอปหลายผู้เช่าต้องขอโทเค็นให้ตรงกับผู้เช่าที่กำลังเรียกบริการ SDK จึงรับค่า tenant_subdomain แล้วนำไปประกอบกับ URL ของบริการยืนยันตัวตน จุดเสี่ยงเกิดเมื่อค่าที่ผู้โจมตีมีอิทธิพลถูกใช้ในขั้นตอนประกอบ URL โดยไม่มีการตรวจที่เพียงพอ ผลคือคำขอที่ควรไปยังปลายทางโทเค็นตามการตั้งค่าอาจถูกส่งไปยังปลายทางอื่น การเปลี่ยนเส้นทางนี้เป็นช่องโหว่แบบ server-side request forgery หรือ SSRF ซึ่งเกิดจากฝั่งเซิร์ฟเวอร์ของแอปเป็นผู้ส่งคำขอเอง

ข้อมูลที่อาจไปกับคำขอคือ OAuth2 client credentials ของแอป โดยเฉพาะ client ID และ client secret ที่ใช้ยืนยันตัวตนกับบริการ หากปลายทางที่รับคำขออยู่ภายใต้การควบคุมของผู้โจมตี ความลับอาจถูกเปิดเผยก่อนแอปจะพบว่าขอโทเค็นไม่สำเร็จ ผลกระทบหลังจากนั้นขึ้นอยู่กับสิทธิ์ของ client ชุดนั้นและวิธีที่แอปแบ่ง credentials ระหว่างผู้เช่า จึงต้องระบุให้ได้ว่าคำขอที่ผิดปลายทางอาจพาความลับชุดใดออกไป ไม่ควรอนุมานจากคะแนน CVSS เพียงอย่างเดียวว่าผู้โจมตีเข้าถึงข้อมูลทั้งหมดของระบบได้

การแก้ไขในรุ่นที่ประกาศตรวจ tenant_subdomain ตามกฎ DNS label ก่อนนำค่าไปแทนใน URL ค่าที่มีตัวคั่น URL หรือรูปแบบที่ไม่ใช่ชื่อย่อยตามกฎจะถูกปฏิเสธก่อนส่งคำขอโทเค็น อย่างไรก็ตาม ชื่อที่มีรูปแบบถูกต้องยังอาจเป็นชื่อผู้เช่าที่แอปไม่รู้จัก การตรวจรูปแบบใน SDK และการตรวจสิทธิ์ว่าผู้เช่านั้นลงทะเบียนกับแอปจริงจึงตอบคนละคำถาม ทีมพัฒนาต้องรักษาการผูกคำขอกับผู้เช่าที่ถูกต้องไว้ แม้หลังอัปเกรดแล้ว

หาขอบเขตจากแพ็กเกจ ค่าที่รับ และ credentials ที่ใช้

จุดเริ่มต้นคือรายการแอปที่ติดตั้งแพ็กเกจ Python ชื่อ sap-cloud-sdk ทั้งในบริการหลัก งานเบื้องหลัง และอิมเมจที่เผยแพร่แยกกัน ชื่อผลิตภัณฑ์ในเอกสารสถาปัตยกรรมอาจไม่ตรงกับชื่อแพ็กเกจที่ระบบติดตั้ง จึงควรตรวจทั้งไฟล์กำหนด dependencies ไฟล์ล็อก และสภาพแวดล้อมที่รันจริง หากไลบรารีเข้ามาผ่าน dependency ของแพ็กเกจอื่น การดูเฉพาะรายการที่นักพัฒนาประกาศไว้โดยตรงอาจพลาดแอปที่ต้องประเมิน

ในอิมเมจหรือสภาพแวดล้อม Python ที่แอปใช้จริง คำสั่ง python -m pip show sap-cloud-sdk ช่วยแสดงรุ่นที่ติดตั้ง จากนั้นเทียบผลกับไฟล์ล็อกและข้อมูลการเผยแพร่อิมเมจ การแก้ข้อกำหนดเวอร์ชันในซอร์สโค้ดไม่ได้ยืนยันว่าอิมเมจที่รับคำขออยู่ถูกสร้างและเผยแพร่ใหม่แล้ว หากมีหลาย replica หรือหลายบริการที่อาศัยอิมเมจคนละชุด ให้ตรวจรุ่นของชุดที่ยังให้บริการด้วย การยืนยันรุ่นหลังเผยแพร่ช่วยแยกการแพตช์ที่เสร็จในระบบจริงออกจากงานที่เสร็จเพียงใน repository

ขั้นต่อมาคือไล่เส้นทางของ tenant_subdomain จากข้อมูลที่แอปรับไปจนถึงการเรียก SDK ค่านี้อาจมาจากโฮสต์ของคำขอ ข้อมูล routing หรือระเบียนผู้เช่าที่แอปเก็บไว้ แต่แหล่งที่มาจริงต้องตรวจจากโค้ดและการตั้งค่าของแต่ละระบบ ประเด็นสำคัญคือผู้เรียกจากภายนอกเปลี่ยนค่านั้นได้หรือไม่ และมีการผูกค่ากับผู้เช่าที่ลงทะเบียนก่อนส่งเข้า SDK หรือเปล่า แอปที่ติดตั้งแพ็กเกจแต่ไม่ส่งค่าผู้เช่าเข้าสู่เส้นทางขอโทเค็นดังกล่าวมีลักษณะการเปิดรับต่างจากแอปที่ใช้เส้นทางนี้กับทุกคำขอ

พร้อมกันนั้นให้ทำแผนที่ว่าแต่ละเส้นทางอ่าน client ID และ client secret จาก service binding ตัวแปรสภาพแวดล้อม หรือระบบจัดการความลับใด และ credentials หนึ่งชุดใช้กับผู้เช่ากี่ราย แผนที่นี้ช่วยจำกัดขอบเขตการตรวจเหตุการณ์และการเปลี่ยนคีย์หากพบการส่งคำขอผิดปลายทาง บันทึกเพียงตำแหน่งอ้างอิงและเจ้าของความลับในรายการงานแก้ไข ไม่คัดลอกค่า secret ลงในตั๋วงาน ผลทดสอบ หรือบันทึกข้อผิดพลาด เพราะเอกสารที่ใช้ประสานงานอาจกลายเป็นแหล่งเปิดเผยข้อมูลอีกแห่ง

เลือกเวอร์ชันโดยดูเส้นทาง SDK ที่แอปเรียก

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

ผลตรวจโค้ดของ The Hacker News ระบุว่ารุ่น 0.53.0 ถึง 0.55.0 ขาดการตรวจ tenant_subdomain ในเส้นทาง Destination บางกรณี และรุ่น 0.55.0 ยังมีช่องว่างในเส้นทาง Document Management Service ก่อนการตรวจกลับมาในรุ่น 0.55.1 ข้อค้นพบนี้เป็นผลทดสอบเส้นทางในรุ่นถัดมาของสื่อ ไม่ใช่การประกาศขยายช่วงเวอร์ชันที่ได้รับผลกระทบภายใต้ CVE เดิมโดย SAP สำหรับทีมที่ใช้โมดูลเหล่านี้ ความต่างดังกล่าวทำให้ต้องตรวจทั้งรุ่นและเส้นทางเรียกจริงก่อนเลือกอิมเมจใหม่

วิธีตัดสินใจคือเริ่มจากช่วงที่ผู้ผลิตระบุอย่างเป็นทางการ แล้วเพิ่มการตรวจเฉพาะทางสำหรับ Destination หรือ Document Management Service หากแอปใช้โมดูลนั้นในรุ่นที่มีข้อสังเกต ตรวจพฤติกรรมด้วยอินพุตที่ควรผ่านและอินพุตที่ควรถูกปฏิเสธในสภาพแวดล้อมทดสอบของแอปเอง การทดสอบต้องยืนยันว่าค่าผู้เช่าที่ไม่ถูกต้องหยุดก่อนเกิดคำขอขาออก ไม่ใช่ตรวจเพียงว่าปลายทางตอบกลับด้วยข้อผิดพลาด เพราะคำขอที่ส่งออกไปแล้วอาจพา credentials ไปด้วย

ลำดับแก้ไขในแอป BTP แบบหลายผู้เช่า

1. จัดลำดับบริการจากรุ่นที่ใช้งานจริง เส้นทางรับ tenant_subdomain และสิทธิ์ของ credentials ที่เกี่ยวข้องก่อน แอปที่ใช้รุ่นเข้าข่ายและรับค่าผู้เช่าจากคำขอภายนอกเข้าสู่เส้นทางขอโทเค็นควรได้รับความสำคัญสูง การแยกบริการตามเส้นทางจริงช่วยให้ทีมแพตช์จุดที่มีโอกาสส่งความลับออกไปโดยไม่เหมารวมทุกบริการบน BTP ว่าเปิดรับเหมือนกัน
2. แก้ข้อกำหนดแพ็กเกจและไฟล์ล็อก สร้างอิมเมจใหม่ แล้วเผยแพร่ตามกระบวนการของแอป หลังเผยแพร่ให้ตรวจรุ่นจากสภาพแวดล้อมที่กำลังรันอีกครั้ง พร้อมบันทึกว่า deployment ใดและ replica ใดใช้ชุดใหม่ หากแอปมีหลายกระบวนการที่สร้างจาก dependency ชุดเดียวกัน ต้องตรวจว่าทุกกระบวนการย้ายไปพร้อมกัน มิฉะนั้นคำขอบางส่วนอาจยังผ่านโค้ดเดิม
3. ทดสอบผู้เช่าที่ลงทะเบียนให้ขอโทเค็นและเรียกบริการต่อได้ตามปกติ จากนั้นทดสอบค่าที่ผิดกฎ DNS label และค่าที่มีรูปแบบถูกต้องแต่ไม่ได้ลงทะเบียนแยกกัน กรณีแรกควรถูกหยุดก่อน SDK ส่งคำขอโทเค็น ส่วนกรณีหลังควรถูกปฏิเสธด้วยกฎสิทธิ์ของแอป การแยกสองกรณีทำให้เห็นว่าการแก้ในไลบรารีกับการตรวจผู้เช่าของแอปต่างทำหน้าที่ครบหรือไม่
4. ตรวจการเชื่อมต่อขาออกในช่วงที่รุ่นเสี่ยงให้บริการ โดยเทียบโฮสต์ปลายทางของคำขอโทเค็นกับปลายทางที่กำหนดไว้ใน configuration และข้อมูลผู้เช่าที่ลงทะเบียน เชื่อมเวลาเหตุการณ์กับบันทึกการรับคำขอและบันทึกของระบบยืนยันตัวตนเท่าที่มีอยู่ ระวังไม่เปิดเผย client secret ในผลค้นหาหรือไฟล์ที่ใช้ส่งต่อให้ทีมอื่น
5. บันทึกผลการตรวจต่อบริการหนึ่งรายการให้เห็นรุ่นเดิม รุ่นที่เผยแพร่ใหม่ เส้นทางที่ทดสอบ ชุด credentials ที่อาจเกี่ยวข้อง และช่วงเวลาที่ตรวจบันทึก ข้อมูลนี้จำเป็นเมื่อพบเหตุผิดปกติภายหลัง เพราะช่วยระบุได้ว่าคำขอเกิดก่อนหรือหลังการเปลี่ยนอิมเมจ และความลับชุดใดต้องถูกจัดการต่อ

เมื่อใดควรหมุน OAuth2 client credentials

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

หากพบว่าคำขอซึ่งมี credentials ไปถึงปลายทางที่ไม่รู้จัก หรือมีหลักฐานอื่นว่าค่า secret ถูกเปิดเผย ควรเปลี่ยน credentials ของ client ที่เกี่ยวข้องและปรับค่าที่ทุกแอปผู้ใช้งานอ่านอยู่ ประสานการเปลี่ยนกับผู้ดูแลระบบยืนยันตัวตนเพื่อหลีกเลี่ยงช่วงที่แอปหนึ่งใช้ค่าใหม่แต่อีกแอปยังใช้ค่าเก่า หาก credentials ชุดเดียวใช้ร่วมกันหลายผู้เช่า การตรวจและการเปลี่ยนต้องครอบคลุมผู้ใช้ชุดนั้นทั้งหมด; หากแยกชุดต่อผู้เช่า ขอบเขตอาจจำกัดตามหลักฐานที่พบ

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

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

allowlist ใช้คั่นเวลาระหว่างรออัปเกรด

หากยังเผยแพร่อิมเมจใหม่ไม่ได้ แอปสามารถรับเฉพาะ tenant_subdomain ที่อยู่ในรายการผู้เช่าซึ่งลงทะเบียนแล้ว และต้องตรวจค่าก่อนส่งให้ SDK ในทุกเส้นทางที่เรียกใช้งาน รายการนี้ต้องอิงข้อมูลผู้เช่าที่แอปให้บริการจริง ไม่ใช่เพียงตรวจว่าค่าดูเหมือนชื่อ DNS ที่ถูกต้อง เพราะชื่อที่ถูกต้องตามรูปแบบอาจไม่อยู่ในความรับผิดชอบของแอป การบังคับใช้ที่จุดเดียวแต่มีเส้นทางอื่นข้ามจุดนั้นได้ยังเปิดช่องให้เกิดคำขอแบบเดิม

ทีมที่ใช้ allowlist ต้องรักษารายการให้ตรงกับการเพิ่มและยกเลิกผู้เช่า รวมถึงทดสอบเส้นทางเบื้องหลังที่ไม่ได้รับคำขอผ่านทางเข้าเดียวกับเว็บแอป วิธีนี้ลดโอกาสที่ผู้โจมตีจะส่งค่าตามอำเภอใจเข้า SDK แต่ไม่ได้เปลี่ยนโค้ดไลบรารีที่ติดตั้งอยู่ จึงควรกำหนดให้เป็นมาตรการชั่วคราวพร้อมงานเผยแพร่รุ่นแก้ไข เมื่อ deployment ใหม่ผ่านการทดสอบแล้ว บันทึกปลายทางคำขอโทเค็นและผลตรวจ credentials จะกำหนดได้ว่างานตอบสนองจบที่การอัปเกรด หรือยังต้องเปลี่ยนความลับของ client บางชุดต่อไป

อ่านเพิ่มเติม:

• CVE-2026-21589 กระทบ Jira และ Confluence แบบติดตั้งเอง—Cloud ไม่โดน
• Radware เปิดศูนย์ Cloud Security ในไทย ลดระยะทางข้อมูลสู่องค์กร
• SAP ซื้อ TechWolf เพื่อมองเห็นทักษะจริง ไม่ใช่แค่ชื่อตำแหน่ง