ช่องโหว่ WordPress ที่พบบ่อยที่สุด 2026 และสิ่งที่ต้องเตรียมรับปี 2027

ช่องโหว่ WordPress (WordPress vulnerability) คือจุดบกพร่องในโค้ดของ WordPress Core, Plugin หรือ Theme ที่ทำให้ผู้ไม่มีสิทธิ์อ่าน แก้ไข หรือสั่งงานเว็บไซต์ได้เกินกว่าที่ระบบตั้งใจ ช่องโหว่หนึ่งรายการมักได้รับรหัส CVE และถูกบันทึกในฐานข้อมูลช่องโหว่ เช่น Patchstack, Wordfence Intelligence และ WPScan พร้อมระบุเวอร์ชันที่ได้รับผลกระทบและเวอร์ชันที่แก้ไขแล้ว

รายงานฉบับนี้รวบรวมตัวเลขจากรายงานต้นทาง ณ ตุลาคม 2026 ได้แก่ Patchstack State of WordPress Security in 2026 (ข้อมูลปี 2025), รายงานกลางปี 2025 ของ Patchstack, สถิติของ WPScan และ OWASP Top 10:2025 เพื่อสรุปว่าช่องโหว่ประเภทใดพบบ่อย ประเภทใดถูกโจมตีจริงมากที่สุด และเจ้าของเว็บควรเตรียมอะไรสำหรับปี 2027 ตัวเลขทุกตัวมีลิงก์ไปยังหน้าที่ระบุตัวเลขนั้น

ตัวเลขสำคัญของช่องโหว่ WordPress ปี 2023–2026

ตารางด้านล่างรวบรวมตัวเลขหลักจากรายงานของ Patchstack สองฉบับ คือ ฉบับปี 2026 (เผยแพร่ 25 กุมภาพันธ์ 2026 ข้อมูลปี 2025) และ ฉบับปี 2025 (เผยแพร่ 14 มีนาคม 2025 ข้อมูลปี 2024) ตัวเลขปี 2023 มาจากกราฟเปรียบเทียบรายปีในฉบับปี 2026

ข้อสังเกตจากตาราง ช่องโหว่ระดับ High ในปี 2025 เพิ่มขึ้น 113% เมื่อเทียบกับปีก่อน และ Patchstack ระบุว่าพบช่องโหว่ร้ายแรงในปี 2025 มากกว่าสองปีก่อนหน้ารวมกัน ส่วนหนึ่งมาจากการตรวจ Plugin และ Theme แบบเสียเงินในตลาดอย่าง Envato (Patchstack, 2026) ในทางกลับกัน WordPress Core เองมีช่องโหว่น้อยมากทุกปี ความเสี่ยงหลักจึงอยู่ที่ส่วนเสริมที่เจ้าของเว็บเลือกติดตั้ง

สำหรับปี 2026 ยังไม่มีรายงานประจำปี แต่ หน้าสถิติของ WPScan ซึ่งอัปเดตตลอด แสดงจำนวนช่องโหว่ที่บันทึกในฐานข้อมูลตามปี ได้แก่ 8,368 รายการในปี 2024, 10,557 รายการในปี 2025 และ 9,055 รายการในปี 2026 (นับถึงวันที่สืบค้น 3 ตุลาคม 2026) ซึ่งหมายความว่าเพียงสามไตรมาสแรกของปี 2026 ก็ใกล้เคียงทั้งปี 2025 แล้ว

ทำไมตัวเลขแต่ละแหล่งไม่เท่ากัน

Patchstack, Wordfence และ WPScan ต่างมีฐานข้อมูลช่องโหว่ของตัวเอง แต่ละแหล่งนับจากรายงานที่ตัวเองรับหรือรวบรวม และจัดประเภทช่องโหว่ต่างกันเล็กน้อย ตัวอย่างเช่น ปี 2025 Patchstack นับได้ 11,334 รายการ ขณะที่ WPScan บันทึก 10,557 รายการ เมื่ออ้างอิงตัวเลขจึงควรระบุแหล่งและปีของข้อมูลเสมอ และไม่ควรนำตัวเลขต่างแหล่งมาบวกกัน ในรายงานของ Patchstack เองยังแยกให้เห็นว่าปี 2025 Patchstack เป็นผู้เปิดเผยช่องโหว่ 7,227 รายการ Wordfence 3,504 รายการ และ WPScan 601 รายการ (คำนวณจากกราฟ Top 3 WordPress vulnerability disclosers ใน Patchstack, 2026)

หมายเหตุ: หน้ารายงานรายไตรมาสของ Wordfence ปฏิเสธการเข้าถึงอัตโนมัติขณะจัดทำรายงานนี้ จึงไม่ได้นำตัวเลขจาก Wordfence มาใช้โดยตรง

ประเภทช่องโหว่ WordPress ที่พบบ่อยที่สุด

คำถาม “ช่องโหว่ประเภทไหนพบบ่อย” มีสองมุมที่ให้คำตอบต่างกัน มุมแรกคือจำนวนที่ถูกรายงาน ซึ่ง XSS ครองอันดับหนึ่งเสมอ มุมที่สองคือจำนวนที่ถูกโจมตีจริง ซึ่ง Broken Access Control นำห่าง ตารางด้านล่างแสดงทั้งสองมุม

ที่มา: คอลัมน์แรกจาก Patchstack 2025 mid-year report ซึ่งระบุว่า 5 ประเภทแรกรวมกันราว 85% ของทั้งหมด (สัดส่วนคิดจากชุดข้อมูลที่ Patchstack ใช้ในรายงาน เช่น XSS 1,192 รายการ = 34.7%) *คอลัมน์ที่สองคำนวณจากจำนวนแยกตามประเภทใน WPScan Statistics หารด้วยจำนวนช่องโหว่ทั้งหมด 39,497 รายการ (สะสมทุกปี ณ 3 ตุลาคม 2026) **คอลัมน์ที่สามเป็นค่าจากกราฟ Most exploited vulnerabilities ใน Patchstack, 2026 ค่าทั้งหมดรวมกันได้ 100 จึงอ่านได้เป็นร้อยละของการโจมตีที่ถูกบล็อก

ช่องว่างระหว่างสองมุมมีคำอธิบายจากรายงานต้นทางบางส่วน Patchstack (2025) ระบุว่า XSS หาเจอง่าย ปี 2024 คิดเป็นเกือบครึ่งหนึ่งของรายการใหม่ และ Patchstack เองให้แรงจูงใจนักวิจัยในการหา XSS ซึ่งทำให้จำนวนรายงานสูง ส่วน Broken Access Control ถูกบล็อกด้วย WAF ทั่วไปได้ยาก (Patchstack, 2026) ในมุมของเรา ช่องโหว่ด้านสิทธิ์อย่าง Broken Access Control และ Privilege Escalation ให้ผลที่ผู้โจมตีต้องการโดยตรง เช่น สร้างบัญชีแอดมินหรือแก้ค่าระบบ จึงเหมาะกับการโจมตีอัตโนมัติ

เทียบกับ OWASP Top 10:2025

OWASP Top 10:2025 เป็นฉบับเผยแพร่ (Release) และเป็นฉบับที่ 8 ของรายการนี้ (OWASP, Introduction) ประเภทช่องโหว่ที่พบใน WordPress จับคู่กับหมวดของ OWASP ได้ดังนี้ ตามรายการ CWE ที่แต่ละหมวดระบุ

ที่มา: A01:2025, A05:2025 และ A06:2025 โดย OWASP ระบุว่าหมวด A01 มีจำนวนการพบสูงสุดในข้อมูลที่ได้รับ ซึ่งสอดคล้องกับข้อมูลการโจมตีจริงใน WordPress

1. Broken Access Control (การควบคุมสิทธิ์บกพร่อง)

คืออะไร: ฟังก์ชันของ Plugin ทำงานโดยไม่ตรวจว่าผู้เรียกมีสิทธิ์หรือไม่ ใน WordPress มักเกิดกับ AJAX handler หรือ REST API endpoint ที่ลืมตรวจ capability ทำให้ผู้ใช้ระดับ Subscriber หรือคนที่ไม่ได้ล็อกอินเรียกใช้ฟังก์ชันของแอดมินได้ Patchstack ระบุว่าการโจมตีประเภทนี้ป้องกันด้วย WAF ทั่วไปได้ยาก เพราะคำขอดูเหมือนการใช้งานปกติ ไม่มีรูปแบบการฉีดโค้ดให้จับ (Patchstack, 2026)

<?php
// โค้ดที่มีช่องโหว่: ไม่มี nonce และไม่ตรวจสิทธิ์
add_action( 'wp_ajax_nopriv_xx_save_settings', 'xx_save_settings' );
function xx_save_settings() {
    update_option( $_POST['key'], $_POST['value'] );   // ใครก็แก้ option ใดก็ได้
    wp_die();
}

// แนวทางที่ถูก: ตรวจ nonce และ capability ก่อนทำงาน
add_action( 'wp_ajax_xx_save_settings', 'xx_save_settings_safe' );
function xx_save_settings_safe() {
    check_ajax_referer( 'xx_settings' );
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( null, 403 );
    }
    // … บันทึกเฉพาะ option ที่กำหนดไว้ล่วงหน้า
}

เจ้าของเว็บป้องกันอย่างไร: อัปเดต Plugin ทันทีที่มีแพตช์ ลดจำนวนบัญชีที่มีสิทธิ์สูง และปิดการสมัครสมาชิกถ้าไม่จำเป็น เพราะช่องโหว่จำนวนมากต้องการเพียงบัญชีระดับ Subscriber อ่านเพิ่มที่ User Admin หลายคนใน WordPress เสี่ยงอย่างไร

2. Cross-Site Scripting (XSS)

คืออะไร: ผู้โจมตีฝัง JavaScript ลงในหน้าเว็บผ่านข้อมูลที่ Plugin รับมาแล้วแสดงผลโดยไม่ escape เมื่อผู้เยี่ยมชมหรือแอดมินเปิดหน้านั้น สคริปต์จะทำงานในเบราว์เซอร์ของเขา ผลที่พบบ่อยคือเว็บเด้งไปเว็บอื่น โฆษณาแปลกปลอม หรือการสร้างบัญชีแอดมินผ่านเซสชันของแอดมินที่เปิดหน้านั้น ประเภทที่อันตรายที่สุดคือ Unauthenticated Stored XSS ซึ่งช่องโหว่สองอันดับแรกในรายการที่ถูกโจมตีมากที่สุดของปี 2025 เป็นประเภทนี้ (LiteSpeed Cache <= 5.7 และ tagDiv Composer <= 4.2) ทั้งที่เปิดเผยตั้งแต่ปี 2024 และ 2023 (Patchstack, 2026)

<?php
// Plugin ที่มีช่องโหว่: เก็บค่าจากผู้ใช้แล้วพิมพ์ออกตรงๆ
echo '<div class="note">' . get_option( 'xx_notice' ) . '</div>';

// ค่าที่ผู้โจมตีส่งเข้ามา (ตัดส่วนทำงานออกแล้ว)
// <script src="https://bad-site.example/…"></script>

// แนวทางที่ถูก: escape ตอนแสดงผล
echo '<div class="note">' . esc_html( get_option( 'xx_notice' ) ) . '</div>';

เจ้าของเว็บป้องกันอย่างไร: อัปเดต Plugin และตรวจหา <script แปลกปลอมในฐานข้อมูลเป็นระยะ ถ้าเว็บเริ่มเด้ง ให้ดูขั้นตอนใน เว็บเด้งไปเว็บอื่น เกิดจากอะไร

3. Cross-Site Request Forgery (CSRF)

คืออะไร: ผู้โจมตีหลอกให้แอดมินที่ล็อกอินอยู่เปิดลิงก์หรือหน้าเว็บที่ส่งคำขอไปยังเว็บของเหยื่อ เบราว์เซอร์ส่งคุกกี้ของแอดมินไปด้วย คำขอนั้นจึงทำงานในนามแอดมิน Patchstack อธิบายว่าปัญหาเกิดเมื่อ Plugin ไม่ตรวจ nonce ในคำขอ และจัด CSRF เป็นประเภท “ไม่ต้องล็อกอิน” เพราะตัวผู้โจมตีไม่ต้องมีบัญชี (Patchstack, 2025)

<form action="https://victim-site.example/wp-admin/admin-post.php" method="POST">
  <input type="hidden" name="action" value="xx_update_settings">
  <input type="hidden" name="admin_email" value="…">
</form>
<!-- ส่วนที่สั่งส่งฟอร์มอัตโนมัติถูกตัดออก -->

เจ้าของเว็บป้องกันอย่างไร: ล็อกเอาต์จากหลังบ้านเมื่อเลิกใช้งาน ไม่เปิดลิงก์ที่ไม่รู้จักขณะล็อกอินเป็นแอดมิน และแยกบัญชีแอดมินออกจากบัญชีที่ใช้เขียนบทความทั่วไป

4. SQL Injection

คืออะไร: ข้อมูลจากผู้ใช้ถูกนำไปต่อเป็นคำสั่ง SQL โดยตรง ผู้โจมตีจึงแก้คำสั่งให้ดึงข้อมูลที่ไม่ควรได้ เช่น ตาราง wp_users ที่เก็บ hash รหัสผ่าน OWASP ระบุว่า SQL Injection เป็นช่องโหว่ “ความถี่ต่ำ ผลกระทบสูง” มี CVE มากกว่า 14,000 รายการ (OWASP A05:2025) ใน WordPress คิดเป็น 7.2% ของรายงานครึ่งแรกปี 2025 และราว 5% ของการโจมตีที่ Patchstack บล็อกในปี 2025

<?php
global $wpdb;
// มีช่องโหว่: ค่า id จาก URL ถูกต่อเข้าคำสั่งตรงๆ
$row = $wpdb->get_row( "SELECT * FROM {$wpdb->prefix}xx_orders WHERE id = " . $_GET['id'] );

// แนวทางที่ถูก: ใช้ placeholder
$row = $wpdb->get_row( $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}xx_orders WHERE id = %d",
    absint( $_GET['id'] )
) );

เจ้าของเว็บป้องกันอย่างไร: อัปเดต Plugin ใช้ผู้ใช้ฐานข้อมูลที่มีสิทธิ์เฉพาะฐานของเว็บนั้น และสำรองฐานข้อมูลสม่ำเสมอ ดู ควรทำ Backup WordPress อย่างไรให้ปลอดภัย

5. Local File Inclusion (LFI)

คืออะไร: Plugin รับชื่อไฟล์จากผู้ใช้แล้วนำไป include โดยไม่จำกัด ผู้โจมตีจึงสั่งให้อ่านไฟล์อื่นบนเซิร์ฟเวอร์ เช่น wp-config.php หรือรันไฟล์ PHP ที่อัปโหลดไว้ OWASP จัดไว้ใน A05 Injection (CWE-98) ใน WordPress คิดเป็น 12.6% ของรายงานครึ่งแรกปี 2025 และ 10% ของการโจมตีที่ถูกบล็อกในปี 2025 ช่องโหว่อันดับ 10 ในรายการที่ถูกโจมตีมากที่สุดปี 2025 คือ LFI ใน Ads Pro <= 4.89 (Patchstack, 2026)

เจ้าของเว็บป้องกันอย่างไร: อัปเดต Plugin และตั้งสิทธิ์ไฟล์ให้ wp-config.php อ่านได้เฉพาะเจ้าของ ตามแนวทางใน File Permission ใน WordPress

6. Privilege Escalation (การยกระดับสิทธิ์)

คืออะไร: ผู้ใช้สิทธิ์ต่ำหรือคนที่ไม่ได้ล็อกอินเปลี่ยนบทบาทตัวเองเป็นแอดมินได้ เช่น ผ่านฟอร์มสมัครสมาชิกหรือฟังก์ชันแก้โปรไฟล์ที่รับค่า role จากผู้ใช้ เป็นประเภทที่ถูกโจมตีมากเป็นอันดับสอง (20% ของการโจมตีที่ถูกบล็อกปี 2025) และติดรายการ 10 อันดับถึงสามครั้ง ได้แก่ SureTriggers <= 1.0.82, LiteSpeed Cache <= 6.3.0.1 และ WooCommerce Payments <= 5.6.1 (Patchstack, 2026)

เจ้าของเว็บป้องกันอย่างไร: ตรวจรายชื่อผู้ใช้ระดับ Administrator เป็นประจำ ตั้งค่า Default Role ของสมาชิกใหม่เป็น Subscriber และเปิดการแจ้งเตือนเมื่อมีแอดมินใหม่

7. Arbitrary File Upload (อัปโหลดไฟล์ได้ทุกชนิด)

คืออะไร: ฟอร์มหรือ endpoint อัปโหลดไม่ตรวจชนิดไฟล์ ผู้โจมตีจึงอัปโหลดไฟล์ PHP (Web Shell) แล้วสั่งงานเซิร์ฟเวอร์ได้ทั้งหมด OWASP จัดไว้ใน A06 Insecure Design (CWE-434) แม้สัดส่วนการโจมตีจะราว 3% แต่ผลกระทบสูงสุดประเภทหนึ่ง ข้อมูลของ Monarx ในรายงาน Patchstack ปี 2026 ระบุว่าการอัปโหลดไฟล์อันตรายเพิ่มขึ้นเกือบสามเท่าในเดือนพฤศจิกายนและธันวาคม 2025 และสคริปต์ประเภท Uploader เพิ่มขึ้นเกือบเท่าตัวตั้งแต่มิถุนายน 2025 (Patchstack, 2026)

# โฟลเดอร์ uploads ไม่ควรมีไฟล์ PHP
find wp-content/uploads -type f -name "*.php"

# รายชื่อ Plugin ที่มีเวอร์ชันใหม่รออัปเดต (ต้องมี WP-CLI)
wp plugin list --update=available --fields=name,version,update_version

เจ้าของเว็บป้องกันอย่างไร: ปิดการรัน PHP ในโฟลเดอร์ uploads ที่ระดับเว็บเซิร์ฟเวอร์ และลบ Plugin ฟอร์มหรือแกลเลอรีที่ไม่ได้ใช้

8. Sensitive Data Disclosure (ข้อมูลสำคัญรั่วไหล)

คืออะไร: Plugin เปิดเผยข้อมูลที่ไม่ควรเปิด เช่น ไฟล์ log ที่มีอีเมลลูกค้า ไฟล์สำรองที่เข้าถึงได้จาก URL หรือ REST endpoint ที่คืนข้อมูลผู้ใช้ทั้งหมด คิดเป็น 3.0% ของฐานข้อมูล WPScan (WPScan) และ OWASP จัด CWE-200 ไว้ในหมวด A01 Broken Access Control

เจ้าของเว็บป้องกันอย่างไร: อย่าเก็บไฟล์สำรองหรือไฟล์ export ไว้ในโฟลเดอร์ที่เปิดผ่านเว็บได้ และปิด debug log บนเว็บจริง

ช่องโหว่ที่ยังไม่มีแพตช์ และ Virtual Patching

ปี 2025 ช่องโหว่ 46% ยังไม่ได้รับการแก้จากผู้พัฒนาเมื่อถึงวันที่เปิดเผยต่อสาธารณะ เพิ่มจาก 33% ในปี 2024 (Patchstack, 2026; Patchstack, 2025) หลายรายการอยู่ใน Plugin ที่ผู้พัฒนาเลิกดูแลแล้วและอาจไม่มีวันได้แพตช์ ปี 2024 มี Plugin และ Theme 1,614 รายการถูกนำออกจาก WordPress.org เพราะช่องโหว่ที่ไม่ได้แก้ และ Patchstack ชี้ว่า WordPress ไม่ได้แจ้งเตือนผู้ใช้เมื่อ Plugin ที่ติดตั้งอยู่ถูกปิดด้วยเหตุผลด้านความปลอดภัย

ปัญหาที่สองคือความเร็ว Patchstack วัดเวลาตั้งแต่เปิดเผยช่องโหว่จนถึงความพยายามโจมตีครั้งแรก ในกลุ่มช่องโหว่ที่ถูกโจมตีหนักซึ่งครอบคลุมราว 95% ของการโจมตีที่สังเกตได้ ผลเป็นดังนี้

ที่มา: กราฟ Time from vulnerability disclosure to active exploitation ใน Patchstack, 2026 เมื่อถ่วงน้ำหนักตามความหนาแน่นของการโจมตี ค่ามัธยฐานถึงการโจมตีครั้งแรกคือ 5 ชั่วโมง

เมื่อยังไม่มีแพตช์หรือยังอัปเดตไม่ทัน ทางเลือกที่ใช้กันคือ Virtual Patching หมายถึงกฎใน Web Application Firewall ที่บล็อกคำขอซึ่งตรงกับวิธีโจมตีช่องโหว่หนึ่งๆ โดยไม่แก้โค้ดของ Plugin เปรียบเหมือนปิดประตูบานนั้นไว้ชั่วคราวจนกว่าจะมีแพตช์จริง ข้อจำกัดที่ควรรู้มีสามข้อ

• ไม่ใช่การแก้ที่ต้นเหตุ: โค้ดที่มีช่องโหว่ยังอยู่ ถ้ากฎไม่ครอบคลุมรูปแบบการโจมตีใหม่ก็ยังโดนได้ เมื่อมีแพตช์จริงต้องอัปเดตเสมอ
• WAF ทั่วไปจับได้ไม่ครบ: การทดสอบเจาะระบบของ Patchstack ในปี 2025 พบว่าระบบป้องกันของผู้ให้บริการโฮสติ้งบล็อกการโจมตีช่องโหว่เฉพาะของ WordPress ได้เพียง 12% และเมื่อขยายขอบเขตการทดสอบ บล็อกได้ 26% (ผลการทดสอบนี้จัดทำโดยผู้ขายบริการ Virtual Patching เอง ควรอ่านโดยคำนึงถึงข้อนี้)
• ต้องอาศัยข้อมูลช่องโหว่ที่ทันเวลา: ผู้ให้บริการ Virtual Patching หลายรายใช้ฐานข้อมูลช่องโหว่ของตัวเอง ความครอบคลุมจึงต่างกัน ควรเลือกจากความถี่ในการออกกฎ และดูว่ารองรับ Plugin ที่เว็บคุณใช้หรือไม่

สำหรับ Plugin ที่ถูกปิดหรือเลิกพัฒนา การแก้ที่ยั่งยืนที่สุดคือหา Plugin ทดแทนแล้วลบตัวเดิมออก ไม่ใช่พึ่ง Virtual Patching ไปตลอด เหตุผลเพิ่มเติมอยู่ใน ทำไมต้องอัปเดต Plugin และ Theme ใน WordPress

Plugin แบบไหนเสี่ยงกว่า

รายงานต้นทางให้ข้อมูลเรื่องนี้ 3 ประเด็น

1. Plugin และ Theme แบบเสียเงิน (Premium): ปี 2025 Patchstack ได้รับรายงานช่องโหว่ที่ถูกต้องใน Premium หรือ Freemium 1,983 รายการ (29% ของรายงานทั้งหมด) ในจำนวนนี้ 59% เป็นระดับ High และรวม Medium แล้ว 76% โจมตีได้จริง โปรแกรม Zero Day ของ Patchstack พบช่องโหว่ร้ายแรงมากใน Premium 33 รายการ เทียบกับ 12 รายการในแบบฟรี และ Premium มี Known Exploited Vulnerabilities มากกว่าแบบฟรีสามเท่า สาเหตุที่รายงานให้ไว้คือโค้ดของ Premium เข้าถึงยากสำหรับนักวิจัย จึงถูกตรวจน้อยกว่า (Patchstack, 2026)
2. Theme มีสัดส่วนช่องโหว่ร้ายแรงสูง: จากกราฟแยกตามส่วนประกอบในรายงานเดียวกัน ช่องโหว่ใน Theme ปี 2025 มี 971 รายการ เป็นระดับ High 558 รายการ หรือราว 57% ขณะที่ Plugin มีระดับ High 1,408 จาก 10,359 รายการ หรือราว 14% (คำนวณจากกราฟ)
3. ยอดติดตั้งสูงไม่ได้แปลว่าปลอดภัย: ปี 2024 พบช่องโหว่ 1,018 รายการใน Plugin ที่มีผู้ติดตั้งอย่างน้อย 100,000 เว็บ Patchstack สรุปว่ายอดติดตั้งไม่ใช่ตัวชี้วัดความปลอดภัย และยอดติดตั้งสูงยิ่งทำให้เป็นเป้าหมาย (Patchstack, 2025)

รายงานไม่ได้ระบุว่า Plugin ประเภทการใช้งานใด เช่น ฟอร์ม แคช หรือร้านค้า เสี่ยงกว่ากันในเชิงสถิติ แต่รายการ 10 อันดับที่ถูกโจมตีมากที่สุดมีทั้ง Plugin แคช (LiteSpeed Cache) ระบบอัตโนมัติ (SureTriggers, FunnelKit Automations) รับบริจาค (GiveWP) ชำระเงิน (WooCommerce Payments) และส่วนเสริมของ Page Builder จากเคสที่เราแก้ จุดร่วมของเว็บที่โดนคือ Plugin เวอร์ชันเก่าที่ไม่ได้อัปเดต มากกว่าประเภทของ Plugin

สิ่งที่ต้องเตรียมรับปี 2027 (แนวโน้ม)

หัวข้อนี้เป็นแนวโน้มที่อ้างอิงจากกฎหมาย ตารางการสนับสนุน และประกาศที่ตรวจสอบได้ ไม่ใช่การคาดการณ์ตัวเลข

ที่มา: European Commission, Cyber Resilience Act, European Commission, CRA Reporting obligations และ PHP Supported Versions

1. กฎหมาย CRA ทำให้ผู้ขาย Plugin ต้องรับเรื่องช่องโหว่อย่างเป็นระบบ

ตั้งแต่ 11 กันยายน 2026 ผู้ผลิตต้องส่งการแจ้งเตือนเบื้องต้นภายใน 24 ชั่วโมงหลังทราบว่ามีช่องโหว่ถูกโจมตีจริง ส่งรายงานเต็มภายใน 72 ชั่วโมง และส่งรายงานฉบับสุดท้ายไม่เกิน 14 วันหลังมีมาตรการแก้ไข (European Commission) Patchstack มองว่าในปี 2026 Plugin เชิงพาณิชย์ทุกตัวจะต้องมีช่องทางรับแจ้งช่องโหว่ (Vulnerability Disclosure Program) จึงจะจำหน่ายให้ผู้ใช้ใน EU ได้ (Patchstack, 2026) แม้เว็บไซต์ในไทยไม่ได้อยู่ในข่ายโดยตรง แต่ Plugin ที่เราใช้ส่วนใหญ่มาจากผู้ขายที่ขายในตลาด EU ผลที่คาดได้คือแพตช์และประกาศช่องโหว่จะออกถี่และเป็นระบบขึ้น เจ้าของเว็บจึงต้องอัปเดตตามให้ทัน

2. PHP 8.2 หมดอายุการแก้ช่องโหว่ 31 ธันวาคม 2026

ตาม php.net PHP 8.2 ได้รับเฉพาะแพตช์ความปลอดภัยจนถึง 31 ธันวาคม 2026 ส่วน PHP 8.3 ถึง 31 ธันวาคม 2027, PHP 8.4 ถึง 31 ธันวาคม 2028 และ PHP 8.5 ถึง 31 ธันวาคม 2029 ขณะที่ WordPress.org แนะนำ PHP 8.3 ขึ้นไป และระบุว่าแม้ WordPress ยังทำงานบน PHP 7.4 ได้ แต่เวอร์ชันเหล่านั้นหมดอายุแล้วและอาจทำให้เว็บเสี่ยงต่อช่องโหว่ ก่อนเปลี่ยนเวอร์ชันควรทดสอบบนเว็บสำรอง เพราะ Plugin เก่าอาจไม่รองรับ อ่านเพิ่มที่ PHP Version ไม่รองรับ ทำให้ WordPress Error ได้อย่างไร

3. WordPress.org เพิ่มการตรวจก่อนปล่อยอัปเดต

วันที่ 5 มิถุนายน 2026 Matt Mullenweg ประกาศโครงการ Protect The Shire โดยทุกเวอร์ชันใหม่ของ Plugin จะรอได้นานสูงสุด 24 ชั่วโมงก่อนถูกส่งผ่านระบบอัปเดตอัตโนมัติ เพื่อให้ระบบรีวิวด้วย AI ตรวจการเปลี่ยนแปลงก่อน ประกาศระบุว่าเป็นมาตรการชั่วคราว และคาดว่าระยะรอจะสั้นลงเหลือระดับนาทีเมื่อกระบวนการพัฒนาขึ้น ก่อนหน้านั้น ตั้งแต่ 1 ตุลาคม 2024 WordPress.org บังคับใช้ 2FA กับบัญชีเจ้าของและผู้มีสิทธิ์ commit Plugin และ Plugin ใหม่ต้องผ่าน Plugin Check ก่อนเข้ารีวิว (Make WordPress Plugins) รวมถึงใช้ SVN password แยกจากรหัสผ่านบัญชี (Make WordPress Plugins) มาตรการเหล่านี้ลดความเสี่ยงจากการที่บัญชีผู้พัฒนาถูกยึดแล้วปล่อยโค้ดอันตราย แต่ครอบคลุมเฉพาะ Plugin ใน WordPress.org ไม่รวม Plugin Premium ที่ดาวน์โหลดจากที่อื่น

4. AI ทำให้ทั้งการหาและการโจมตีช่องโหว่เร็วขึ้น

Patchstack ระบุว่าผู้โจมตีใช้ AI ที่หาและโจมตีช่องโหว่ได้เองมากขึ้น ขณะเดียวกันรายงานช่องโหว่คุณภาพต่ำที่สร้างด้วย AI ก็เพิ่มภาระให้ทีมพัฒนา และพื้นผิวการโจมตีของเว็บ WordPress จะกว้างกว่า Core, Plugin และ Theme เพราะมี Plugin ที่เขียนเฉพาะเว็บและแพ็กเกจ JavaScript/PHP เพิ่มเข้ามา (Patchstack, 2026) สำหรับเจ้าของเว็บ ผลในทางปฏิบัติคือช่วงเวลาระหว่างประกาศช่องโหว่จนถึงการโจมตีจะไม่ยาวขึ้น การอัปเดตจึงต้องเป็นงานประจำ ไม่ใช่งานที่ทำเมื่อว่าง

Checklist 10 ข้อสำหรับเจ้าของเว็บ

1. ทำรายการ Plugin และ Theme ทั้งหมด พร้อมเวอร์ชันและแหล่งที่มา (WordPress.org หรือ Premium) เพื่อรู้ว่าต้องติดตามอะไร
2. ลบ Plugin และ Theme ที่ไม่ใช้ รวมถึงที่ปิดใช้งานไว้ เพราะไฟล์ยังเรียกได้จากภายนอก
3. อัปเดตภายใน 24 ชั่วโมงเมื่อเป็นแพตช์ความปลอดภัย ตามข้อมูลว่าช่องโหว่ราว 45% ถูกโจมตีภายในวันแรก หรือเปิด Auto-update สำหรับ Plugin ที่ไม่กระทบการทำงานหลัก
4. ตรวจว่า Plugin ยังมีการพัฒนา ถ้าหน้า Plugin ใน WordPress.org ถูกปิด หรือไม่ได้อัปเดตนาน ให้หา Plugin ทดแทน
5. ติดตามข่าวช่องโหว่ ด้วยการแจ้งเตือนจากฐานข้อมูลช่องโหว่หรือ Security Plugin ที่ใช้อยู่ ดู Security Plugin จำเป็นไหม
6. ลดบัญชีสิทธิ์สูง ให้ Administrator เฉพาะคนที่จำเป็น และตั้งบทบาทเริ่มต้นของสมาชิกใหม่เป็น Subscriber
7. เปิด 2FA และจำกัดการเดารหัสผ่าน ตามแนวทางใน Brute Force Attack คืออะไร และพิจารณาปิด XML-RPC ถ้าไม่ได้ใช้ (XML-RPC คืออะไร ควรปิดไหม)
8. ใช้ PHP เวอร์ชันที่ยังได้รับแพตช์ และวางแผนย้ายออกจาก PHP 8.2 ก่อน 31 ธันวาคม 2026
9. ตั้งค่า Hardening ระดับเซิร์ฟเวอร์ เช่น สิทธิ์ไฟล์ที่ถูกต้อง ปิดการแก้ไฟล์จากหลังบ้าน และปิดการรัน PHP ใน uploads ตาม Hardening WordPress และ Website Security Hardening คืออะไร
10. สำรองข้อมูลนอกเซิร์ฟเวอร์และทดสอบกู้คืน เพื่อให้กลับมาได้เร็วถ้าช่องโหว่ถูกใช้ก่อนอัปเดตทัน

รายการตรวจที่ละเอียดกว่านี้อยู่ใน WordPress Security Checklist สำหรับเจ้าของเว็บไซต์ ถ้าต้องการให้ทีมงานตรวจและปิดจุดเสี่ยงทั้งระบบ ดูรายละเอียดบริการ WordPress Security Hardening

คำถามที่พบบ่อย

แหล่งอ้างอิง

1. Patchstack. (2026). State of WordPress Security in 2026. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
2. Patchstack. (2025). State of WordPress Security 2025. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://patchstack.com/whitepaper/state-of-wordpress-security-in-2025/
3. Patchstack. (2025). Patchstack’s 2025 WordPress Security Report: Mid-Year Vulnerability Breakdown. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://patchstack.com/whitepaper/2025-mid-year-vulnerability-report/
4. WPScan. (ม.ป.ป.). WordPress Vulnerability Statistics. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wpscan.com/statistics/
5. OWASP Foundation. (2025). OWASP Top 10:2025. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://top10.owasp.org/2025/
6. OWASP Foundation. (2025). Introduction – OWASP Top 10:2025. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://top10.owasp.org/2025/0x00_2025-Introduction/
7. OWASP Foundation. (2025). A01:2025 – Broken Access Control. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/
8. OWASP Foundation. (2025). A05:2025 – Injection. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://top10.owasp.org/2025/A05_2025-Injection/
9. OWASP Foundation. (2025). A06:2025 – Insecure Design. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://top10.owasp.org/2025/A06_2025-Insecure_Design/
10. European Commission. (ม.ป.ป.). Cyber Resilience Act. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
11. European Commission. (ม.ป.ป.). Cyber Resilience Act – Reporting obligations. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
12. The PHP Group. (ม.ป.ป.). Supported Versions. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://www.php.net/supported-versions.php
13. WordPress.org. (ม.ป.ป.). Requirements. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/about/requirements/
14. Mullenweg, M. (2026). Protect The Shire. WordPress News. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/news/2026/06/pts/
15. WordPress Plugins Team. (2024). Plugin Check and 2FA Now Mandatory For New Plugin Submissions. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://make.wordpress.org/plugins/2024/10/01/plugin-check-and-2fa-now-mandatory-for-new-plugin-submissions/
16. WordPress Plugins Team. (2024). Upcoming Security Changes for Plugin and Theme Authors on WordPress.org. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://make.wordpress.org/plugins/2024/09/04/upcoming-security-changes-for-plugin-and-theme-authors-on-wordpress-org/
17. WordPress.org. (ม.ป.ป.). Checking User Capabilities – Plugin Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/plugins/security/checking-user-capabilities/
18. WordPress.org. (ม.ป.ป.). Escaping Data – Common APIs Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/apis/security/escaping/
19. WordPress.org. (ม.ป.ป.). Sanitizing Data – Common APIs Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/apis/security/sanitizing/
20. WordPress.org. (ม.ป.ป.). Nonces – Common APIs Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/apis/security/nonces/
21. WordPress.org. (ม.ป.ป.). wpdb::prepare() – Code Reference. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wpdb/prepare/
22. WordPress.org. (ม.ป.ป.). Plugins and Themes Auto-Updates. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/plugins-themes-auto-updates/
23. WordPress.org. (ม.ป.ป.). Hardening WordPress – Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/hardening/