คำนวณคะแนน CVSS 4.0 ตาม FIRST v4.0 specification. Engine ใช้ FIRST reference calculator (BSD-2-Clause).
เหมือน CVSS 3.1 — ช่องทางที่ผู้โจมตีต้องใช้เพื่อเข้าถึงระบบ
AV:N
เลือกเมื่อ: ระบบเปิดให้ผู้ใช้อินเทอร์เน็ตส่ง traffic เข้าถึงได้
อย่าเลือกเพียงเพราะ: ระบบมี IP สาธารณะ — ต้องยืนยันว่าช่องโหว่โดนจากภายนอกจริง
ตัวอย่าง: SQL injection ใน login page ที่เข้าใช้ได้จากอินเทอร์เน็ต
ที่มา: CVSS v4.0 §2.1.1 · อ่านเพิ่ม
AV:A
เลือกเมื่อ: โจมตีต้องผ่าน L2 broadcast domain, Wi-Fi, Bluetooth, CAN bus
อย่าเลือกเพียงเพราะ: 'อยู่ใน internal network' อาจ Route ได้ ให้ใช้ Network
ตัวอย่าง: Blueborne, ARP spoofing
AV:L
เลือกเมื่อ: โจมตีต้อง execute code local หรือหลอกให้ user เปิดไฟล์
อย่าเลือกเพียงเพราะ: app เป็น local — ถ้ามี remote path ใช้ Network
ตัวอย่าง: Privilege escalation ผ่าน setuid
AV:P
เลือกเมื่อ: ต้องเสียบ USB, ถอด case, เข้าถึง console
อย่าเลือกเพียงเพราะ: อุปกรณ์อยู่ในที่ล็อค — ถ้ายิงผ่าน network ได้ ใช้ Network
ตัวอย่าง: Cold boot attack
⚠️ ข้อควรระวัง: ต่างจาก 3.1 ตรงที่ 'ใกล้เคียง (A)' ครอบคลุมทั้ง L2 network + local IPC ไม่จำเป็นต้องเป็น wireless
**เปลี่ยนจาก 3.1** — ตอนนี้วัดเฉพาะ 'มาตรการป้องกันในระบบ' ที่ต้องเอาชนะ ไม่รวมเงื่อนไข environmental (ย้ายไป AT)
AC:L
เลือกเมื่อ: exploit ทำงานได้โดยไม่ต้อง bypass ASLR/CSP/CFI
อย่าเลือกเพียงเพราะ: exploit ง่าย — ถ้ามี mitigations ต้องประเมิน
ตัวอย่าง: SQL injection ใน endpoint ที่ไม่มี prepared statement
ที่มา: CVSS v4.0 §2.1.2 · อ่านเพิ่ม
AC:H
เลือกเมื่อ: exploit ต้องมี heap grooming, ASLR bypass, sandbox escape
อย่าเลือกเพียงเพราะ: 'exploit ยาก' — ต้องเจาะจงว่า bypass mitigation อะไร
ตัวอย่าง: Chromium exploit ที่ต้อง bypass V8 sandbox + site isolation
⚠️ ข้อควรระวัง: ผู้ใช้จำนวนมากยังคิดแบบ 3.1 — High ใน 4.0 หมายถึงต้อง bypass mitigations เช่น ASLR/PIE/CSP
**NEW ใน CVSS 4.0** — วัด condition นอกเหนือระบบเป้าหมาย (เช่น race window, MITM position, target config)
AT:N
เลือกเมื่อ: attacker ไม่ต้องอาศัย condition ภายนอก
อย่าเลือกเพียงเพราะ: ระบบเป็น default install — ต้องพิจารณา user context
ตัวอย่าง: Public endpoint ที่รับ input ตลอด
ที่มา: CVSS v4.0 §2.1.3 · อ่านเพิ่ม
AT:P
เลือกเมื่อ: ต้องรอ user login, ต้องอยู่ใน MITM position, ต้องชนะ race
อย่าเลือกเพียงเพราะ: 'exploit ทำครั้งเดียวสำเร็จ' — ต้องมีเงื่อนไข objective
ตัวอย่าง: TOCTOU race, MITM ที่ต้องอยู่ใน same LAN
⚠️ ข้อควรระวัง: อย่าสับสนกับ AC — AT วัด 'สิ่งที่ต้องเกิดในโลก', AC วัด 'สิ่งที่ระบบต้าน'
เหมือน CVSS 3.1 — สิทธิ์ที่ผู้โจมตีต้องมี 'ก่อน' ไม่ใช่ 'หลัง'
PR:N
เลือกเมื่อ: unauthenticated attack
อย่าเลือกเพียงเพราะ: endpoint /public — ยืนยันว่าไม่มี auth check
ตัวอย่าง: SQL injection ที่ login page
ที่มา: CVSS v4.0 §2.1.4 · อ่านเพิ่ม
PR:L
เลือกเมื่อ: ต้อง login แต่ไม่ต้องเป็น admin
อย่าเลือกเพียงเพราะ: signup ได้ — ก็ยัง Low
ตัวอย่าง: IDOR
PR:H
เลือกเมื่อ: สิทธิ์ระดับ root/DBA
อย่าเลือกเพียงเพราะ: ต้อง 'สิทธิ์เพิ่ม' — ถ้าให้ผ่าน signup ใช้ Low
ตัวอย่าง: Command injection ที่ต้องมีสิทธิ์ config server
**เพิ่มค่า A (Active) ใน 4.0** — เดิมมีแค่ N/R
UI:N
เลือกเมื่อ: exploit ทำงานเองได้
อย่าเลือกเพียงเพราะ: attacker เป็นคนกด — ผู้พิจารณาคือ user อื่น
ตัวอย่าง: RCE ผ่าน network service
ที่มา: CVSS v4.0 §2.1.5 · อ่านเพิ่ม
UI:P
เลือกเมื่อ: phishing ที่ user คลิกลิงก์เดียว, DOM XSS
อย่าเลือกเพียงเพราะ: user ต้อง approve prompt — ถ้าต้อง multi-step ใช้ Active
ตัวอย่าง: Stored XSS ที่ผู้ใช้แค่เห็นหน้า
UI:A
เลือกเมื่อ: ต้องมี login + click + submit form
อย่าเลือกเพียงเพราะ: user ต้องทำ 2 อย่าง — ต้องเป็น distinct interaction
ตัวอย่าง: CSRF ที่ต้อง login ก่อน
⚠️ ข้อควรระวัง: UI:P = passive คลิกลิงก์, UI:A = active ทำ multi-step (เช่น login + edit)
**Vulnerable System = ระบบที่โดนช่องโหว่ตรง ๆ** — แยกจาก Subsequent (ระบบอื่นที่ได้รับผลกระทบต่อ)
VC:H
เลือกเมื่อ: ได้ credentials, secrets, PII, database dump ของ VS
อย่าเลือกเพียงเพราะ: ข้อมูลมาก — ดู sensitivity
ตัวอย่าง: Dump SQL database
ที่มา: CVSS v4.0 §2.2.1 · อ่านเพิ่ม
VC:L
เลือกเมื่อ: อ่านได้แต่เลือกไม่ได้ / ข้อมูลไม่สำคัญ
อย่าเลือกเพียงเพราะ: ปริมาณน้อย — ดู sensitivity
ตัวอย่าง: Stack trace, verbose error
VC:N
เลือกเมื่อ: ช่องโหว่ไม่ให้ read access
อย่าเลือกเพียงเพราะ: ยังไม่เจอ leak — ถ้ามี read path ต้องประเมิน
ตัวอย่าง: DoS อย่างเดียว
attacker แก้ไข VS ได้แค่ไหน
VI:H
เลือกเมื่อ: แก้ config, code, สำคัญได้
อย่าเลือกเพียงเพราะ: แก้จำนวนมาก — ดู criticality
ตัวอย่าง: Overwrite backend code
ที่มา: CVSS v4.0 §2.2.2 · อ่านเพิ่ม
VI:L
เลือกเมื่อ: เขียนได้บางส่วน
อย่าเลือกเพียงเพราะ: แก้ 1 field
ตัวอย่าง: แก้ preference
VI:N
เลือกเมื่อ: read-only
อย่าเลือกเพียงเพราะ: ยังไม่เจอ write path
ตัวอย่าง: Information disclosure
ช่องโหว่ทำให้ VS ล่มได้แค่ไหน
VA:H
เลือกเมื่อ: complete DoS
อย่าเลือกเพียงเพราะ: crash ครั้งเดียว — ต้อง repeatable
ตัวอย่าง: Amplification DDoS
ที่มา: CVSS v4.0 §2.2.3 · อ่านเพิ่ม
VA:L
เลือกเมื่อ: performance degradation
อย่าเลือกเพียงเพราะ: response ช้า — ดู SLA
ตัวอย่าง: Slowloris
VA:N
เลือกเมื่อ: ไม่กระทบ availability
อย่าเลือกเพียงเพราะ: ยังไม่เจอ crash
ตัวอย่าง: Info leak
**Subsequent System = ระบบอื่นที่ได้รับผลกระทบต่อจาก VS** — คล้าย Scope Changed ใน 3.1 แต่แยกออกเป็น 3 impact metrics
SC:H
เลือกเมื่อ: VM escape นำไป host, container escape นำไปข้อมูล admin
อย่าเลือกเพียงเพราะ: 'อาจกระทบ'
ตัวอย่าง: Guest→Host data leak
ที่มา: CVSS v4.0 §2.3.1 · อ่านเพิ่ม
SC:L
เลือกเมื่อ: รั่วเฉพาะ metadata
อย่าเลือกเพียงเพราะ: ไม่ได้ระบุ
ตัวอย่าง: Container escape เห็นแค่ hostname
SC:N
เลือกเมื่อ: self-contained
อย่าเลือกเพียงเพราะ: ไม่รู้ — ให้พิจารณา architecture
ตัวอย่าง: In-process bug
⚠️ ข้อควรระวัง: SC/SI/SA เป็น None ถ้าไม่มีระบบอื่นเกี่ยวข้อง — ไม่ต้อง 'เดา' ว่ามีผลกระทบต่อ
แก้ไขระบบอื่นที่เกี่ยวข้องได้แค่ไหน
SI:H
เลือกเมื่อ: Guest→Host code, cross-tenant
อย่าเลือกเพียงเพราะ: 'อาจแก้ได้'
ตัวอย่าง: Guest ทำ Host code execution
ที่มา: CVSS v4.0 §2.3.2 · อ่านเพิ่ม
SI:L
เลือกเมื่อ: เขียน metadata ได้
อย่าเลือกเพียงเพราะ: ไม่รู้
ตัวอย่าง: Log injection ข้าม tenant
SI:N
อย่าเลือกเพียงเพราะ: 'ไม่รู้'
ตัวอย่าง: Read-only bug
ระบบอื่นล่มได้แค่ไหน
SA:H
เลือกเมื่อ: Guest→Host crash
อย่าเลือกเพียงเพราะ: 'อาจล่ม'
ตัวอย่าง: Hypervisor crash
ที่มา: CVSS v4.0 §2.3.3 · อ่านเพิ่ม
SA:L
เลือกเมื่อ: resource exhaustion cross-tenant
ตัวอย่าง: Noisy neighbor
SA:N
**เปลี่ยนชื่อจาก 3.1 (Exploit Code Maturity)** และเป็น Threat metric เดียวใน 4.0
E:X
เลือกเมื่อ: ยังไม่ประเมิน
อย่าเลือกเพียงเพราะ: อยากลด score
ตัวอย่าง: ช่องโหว่เพิ่งเปิดเผย
ที่มา: CVSS v4.0 §3.1 · อ่านเพิ่ม
E:A
เลือกเมื่อ: มีในข่าว, มี Metasploit module, commodity malware
อย่าเลือกเพียงเพราะ: 'มี PoC ใน GitHub'
ตัวอย่าง: Log4Shell หลังปล่อยหลายเดือน
E:P
เลือกเมื่อ: มี PoC บน GitHub แต่ยังไม่มี report attack
อย่าเลือกเพียงเพราะ: 'PoC ทำได้'
ตัวอย่าง: PoC จาก researcher สาธารณะ
E:U
เลือกเมื่อ: vendor advisory ที่ไม่มี exploit detail
อย่าเลือกเพียงเพราะ: 'ไม่มีข่าว'
ตัวอย่าง: Vendor advisory ก่อน PoC เผยแพร่
⚠️ ข้อควรระวัง: X ใน 4.0 = worst case (Attacked) เหมือน 3.1 — ไม่ได้ลด score
เหมือน CVSS 3.1
CR:X
เลือกเมื่อ: ไม่ทราบ
อย่าเลือกเพียงเพราะ: ขี้เกียจ
ตัวอย่าง: ระบบใหม่
ที่มา: CVSS v4.0 §4.1 · อ่านเพิ่ม
CR:H
เลือกเมื่อ: PII, secrets, credentials
อย่าเลือกเพียงเพราะ: 'องค์กรใหญ่'
ตัวอย่าง: Credit card DB
CR:M
เลือกเมื่อ: ข้อมูลภายในไม่ลับ
อย่าเลือกเพียงเพราะ: default
ตัวอย่าง: Employee list
CR:L
เลือกเมื่อ: ข้อมูลเปิดเผยได้
อย่าเลือกเพียงเพราะ: 'อยากลด score'
ตัวอย่าง: Marketing content
IR:X
IR:H
เลือกเมื่อ: financial, medical, critical config
อย่าเลือกเพียงเพราะ: 'ระบบใหญ่'
ตัวอย่าง: Bank ledger
IR:M
เลือกเมื่อ: user profile
ตัวอย่าง: Profile page
IR:L
เลือกเมื่อ: logging system
ตัวอย่าง: Verbose log
AR:X
AR:H
เลือกเมื่อ: core banking, EMR
อย่าเลือกเพียงเพราะ: '24/7 ต้องออนไลน์'
ตัวอย่าง: ATM
AR:M
เลือกเมื่อ: internal tool
ตัวอย่าง: HR system
AR:L
เลือกเมื่อ: monthly report
ตัวอย่าง: Batch report
MSI:S และ MSA:S ใช้เมื่อ Subsequent System เป็นระบบที่กระทบต่อความปลอดภัยทางกายภาพของมนุษย์ (เช่น medical device, industrial control). เลือก S เมื่อ integrity/availability ของระบบต่อเนื่องหมายถึงความปลอดภัย ไม่ใช่แค่ข้อมูล.
