Oracle HCM มีช่องโหว่ CVSS 8.2: Playbook 72 ชั่วโมงสำหรับ HRIS และ IT

CVE-2026-70773 คืออะไรและใครอยู่ในขอบเขต?

Oracle เผยแพร่ Critical Security Patch Update วันที่ 18 สิงหาคม 2026 และแก้ revision วันที่ 20 สิงหาคม รายการ Oracle E-Business Suite ระบุ CVE-2026-70773 ใน HCM Common Architecture ส่วน Knowledge Integration กระทบ version 12.2.3 ถึง 12.2.15

Risk matrix ของ Oracle ให้ CVSS 3.1 base score 8.2, attack vector แบบ Network, complexity ต่ำ, ไม่ต้องมี privilege และไม่ต้องให้ผู้ใช้คลิก ผลกระทบที่ระบุคือ confidentiality สูงและ integrity ต่ำ โดย availability ไม่มีผลตาม vector นี้ กล่าวง่าย ๆ คือผู้โจมตีที่เข้าถึง endpoint ผ่าน HTTP อาจอ่านข้อมูลที่ไม่ควรเห็นและแก้บางข้อมูลได้

อย่าสับสนกับ Oracle Fusion Cloud HCM ข่าวนี้ชี้ Oracle E-Business Suite HCM Common Architecture หากเป็น SaaS หรือเวอร์ชันอื่นต้องตรวจเอกสารของผลิตภัณฑ์นั้น ไม่ควร patch จากชื่อ HCM อย่างเดียว

ชั่วโมง 0-4 ต้องทำ Triage อะไร?

เปิด incident หรือ emergency change record ทันที แล้วให้ System Owner, DBA/Application Owner, Security, Network, HRIS และ Privacy/Data Owner เข้าห้องเดียวกัน เป้าหมายสี่ชั่วโมงแรกคือรู้ว่ามีระบบใดตรง version, endpoint ใดเข้าถึงได้, ข้อมูลใดอยู่ในขอบเขต และใครมีอำนาจหยุดบริการ

• ยืนยัน inventory และ exact version จากระบบจริง ไม่ใช้ CMDB อย่างเดียวถ้าอัปเดตไม่ทัน

• เปิด Oracle advisory และ MOS patch document จากบัญชี support ที่ได้รับอนุญาต ตรวจ prerequisite และ patch conflict

• ตรวจ network path, reverse proxy, WAF และ internet exposure ของ Knowledge Integration endpoint

• รักษา log, configuration, access evidence และเวลาระบบก่อนเปลี่ยนอะไรเพื่อรองรับ forensic review

• กำหนด severity, business owner, maintenance window, decision time และช่องทางสื่อสารที่ไม่เปิดรายละเอียดโจมตีเกินจำเป็น

ชั่วโมง 4-24 ควร Contain และเตรียม Patch อย่างไร?

ถ้ายัง patch ไม่ได้ทันที ให้จำกัด network access ตามสถาปัตยกรรมจริง เช่น allowlist แหล่งที่จำเป็น ปิด route ที่ไม่ใช้ หรือเพิ่ม monitoring โดยต้องทดสอบว่า payroll, integration และ self-service ที่สำคัญไม่หยุดแบบเงียบ การ containment เป็นมาตรการชั่วคราว ไม่ใช่เหตุผลเลื่อน patch ไม่มีกำหนด

ทำ backup ตาม vendor support path และพิสูจน์ว่า restore ได้ เตรียม clone หรือ lower environment ที่ใกล้ production รวม integration สำคัญ เช่น identity, payroll, time, reporting และ downstream data warehouse อย่าทดสอบเฉพาะหน้า login เพราะช่องโหว่อยู่ใน shared architecture

Oracle ระบุว่าลูกค้าควรอยู่บน version ที่ยัง support และใช้ patch โดยไม่ชักช้า พร้อมเตือนว่ามีกรณีโจมตีสำเร็จเพราะไม่ได้ลง patch ที่ออกแล้ว ข้อความนี้เป็นคำแนะนำทั่วไปของ Oracle ไม่ได้ยืนยันว่า CVE รายการนี้ถูก exploit แล้ว

ชั่วโมง 24-48 จะทดสอบและติดตั้งอย่างไร?

ทดสอบ install, rollback และ smoke test ใน lower environment ก่อน หากเวลาความเสี่ยงไม่พอให้ใช้ emergency change path ที่มีผู้อนุมัติชัด ไม่ตัด verification ทิ้ง แยก evidence ว่า patch binary มาจาก Oracle support, checksum ตรง และผู้ดำเนินการใช้บัญชีที่ติดตามได้

• Pre-check: version, free space, invalid objects, concurrent jobs, integration queue และ backup completion

• Install: ทำตาม MOS document บันทึก patch ID, เวลา, operator, command/result และ deviation จาก runbook

• Functional test: login, employee search, HR transaction, approval, payroll/time integration และ critical report ตามขอบเขตองค์กร

• Security test: ยืนยัน route/endpoint, access control, error response และ alert โดยไม่ทำ exploit บน production

• Rollback decision: กำหนดเวลาและเกณฑ์ก่อนเริ่ม เช่น data corruption, critical integration failure หรือ payroll impact

ชั่วโมง 48-72 ต้อง Validate และสื่อสารอะไร?

หลัง production change ให้ยืนยันทั้ง patch state และ business outcome ตรวจ version/patch inventory, service health, queue, reconciliation sample และสิทธิ์สำคัญ จากนั้น review log ย้อนหลังตาม retention และ threat window ที่ทีม Security กำหนด มองหา access หรือ data change ผิดปกติโดยไม่สมมติว่าไม่มี alert แปลว่าไม่เคยเกิดเหตุ

HR และ Privacy ต้องประเมินว่ามีหลักฐาน confidentiality หรือ integrity impact หรือไม่ หากพบ anomaly ให้เข้าสู่ incident response และ notification assessment ตามกฎหมาย สัญญา และนโยบายองค์กร อย่าสื่อว่าข้อมูลรั่วเพียงเพราะมีช่องโหว่ และอย่าสื่อว่าปลอดภัยแน่นอนเพียงเพราะ patch สำเร็จ

แจ้งผู้บริหารแบบ answer-first: ระบบใดได้รับผลกระทบ exposure เป็นอย่างไร containment/patch เสร็จเมื่อไร validation ผ่านอะไร สิ่งใดยังตรวจอยู่ และ decision ถัดไปคืออะไร แยก technical detail ไว้ใน annex

หลักฐานใดต้องเก็บไว้สำหรับ Audit?

เก็บ advisory snapshot หรือ reference, asset/version evidence, risk acceptance, approval, maintenance timeline, backup/restore proof, patch provenance, test results, log review, exception และ communication decision เชื่อมทั้งหมดด้วย incident/change ID เดียว

ใช้ NIST Cybersecurity Framework เป็นภาษากลางได้: Identify inventory และ owner; Protect ด้วย access/backup; Detect ด้วย log/alert; Respond ผ่าน triage/containment/communication; Recover ด้วย restore, validation และ lesson learned กรอบนี้ช่วยให้ HRIS คุยกับ Security โดยไม่ต้องเปลี่ยนบทความเป็นคู่มือโจมตี

ภายในเจ็ดวันทำ retrospective ว่าเหตุใด asset/version หรือ endpoint exposure จึงตอบช้า ปรับ vulnerability intake, vendor advisory subscription, dependency owner และ patch SLA เพื่อให้รอบหน้าไม่เริ่มจากค้นว่าใครถือรหัส MOS

ข้อจำกัดและสิ่งที่ Admin ต้องตรวจคืออะไร?

Playbook นี้ไม่แทน MOS patch document, vendor support, forensic investigation หรือคำปรึกษากฎหมาย ไม่ควรนำคำสั่งทั่วไปไปใช้กับ production โดยไม่ดู architecture และ change policy Admin ต้องตรวจ revision ของ Oracle advisory, affected versions, CVSS vector และสถานะ exploitation ล่าสุดก่อนเผยแพร่

ตรวจว่าบทความไม่บอกว่า Oracle Fusion Cloud HCM อยู่ในขอบเขต ไม่ยืนยัน breach และไม่เปิดรายละเอียด exploit ตรวจ internal links, HTTPS references และภาพ hero 1600×900 ว่าเปิดได้ ไม่มีข้อความ โลโก้ หรือลายน้ำ แล้วคงสถานะ draft จน HRIS/Security reviewer อนุมัติ