ช่องโหว่ Security Vulnerability — CVE-2026-102940 (CVSS 9.6)
📋 สรุปช่องโหว่
ช่องโหว่ Security Vulnerability ถูกค้นพบและรายงานใน NVD โดยมี CVSS Score 9.6 ระดับ "วิกฤต"
รายละเอียดต้นฉบับ (EN): OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.4.0, controllers/C_Document.class.php write actions, including move_action_process(), do not verify the caller's access to the source document, current patient and category, or destina
ผู้ดูแลระบบที่ใช้ซอฟต์แวร์ที่ได้รับผลกระทบควรตรวจสอบและอัพเดตโดยเร็ว
💥 ผลกระทบที่อาจเกิดขึ้น
ผลกระทบขึ้นอยู่กับประเภทและบริบทการใช้งาน:
• ระดับความรุนแรง CVSS 9.6 (วิกฤต) บ่งชี้ว่าช่องโหว่นี้อาจส่งผลต่อความปลอดภัยของระบบในระดับสูง
• ผู้โจมตีอาจใช้ประโยชน์จากช่องโหว่นี้เพื่อเข้าถึง แก้ไข หรือทำลายข้อมูลในระบบ
• ดูรายละเอียดผลกระทบเฉพาะที่ https://nvd.nist.gov/vuln/detail/CVE-2026-102940
🖥️ ซอฟต์แวร์และระบบที่ได้รับผลกระทบ
ตรวจสอบเวอร์ชันที่ได้รับผลกระทบและข้อมูลเพิ่มเติมที่ https://nvd.nist.gov/vuln/detail/CVE-2026-102940
🔧 แนวทางการแก้ไขและป้องกัน
- ขั้นตอนแก้ไขทั่วไป:
- 1. ตรวจสอบ Vendor Advisory: เข้าไปที่เว็บไซต์ vendor หรือ https://nvd.nist.gov/vuln/detail/CVE-2026-102940 เพื่อดู patch อย่างเป็นทางการ
- 2. อัพเดตเป็นเวอร์ชันล่าสุด: ติดตั้งเวอร์ชันที่แก้ไขช่องโหว่แล้วทันที
- 3. ตรวจสอบ Logs: ดู system log และ access log หาร่องรอยการโจมตีที่อาจเกิดขึ้นแล้ว
- 4. ติดตั้ง Security Monitoring: ใช้ WAF หรือ IDS เพื่อ monitor การโจมตี
- 5. Backup ข้อมูล: สำรองข้อมูลสำคัญก่อนทำการเปลี่ยนแปลงใดๆ
- 6. แจ้งทีมงาน: แจ้งให้ทีม IT security ทราบเพื่อวางแผนรับมือ
📄 รายละเอียดต้นฉบับ (ภาษาอังกฤษ)
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.4.0, controllers/C_Document.class.php write actions, including move_action_process(), do not verify the caller's access to the source document, current patient and category, or destination patient and category before Document::change_patient() performs the mutation. A low-privilege authenticated user can reassign an arbitrary document to a patient or category the user can access and then retrieve it through the normally protected read path. The reassignment occurs before a later list rendering check, so a final HTTP 403 response does not mean the unauthorized write was blocked. This issue is fixed in version 8.4.0.