ช่องโหว่ WordPress core ตอนอัปเดต (CVE-2026-119977) ถูกยิงจริงแล้ว

พอดีเห็นข่าวว่าเมื่อ 3 พ.ย. CISA เพิ่ม CVE-2026-119977 ของ WordPress core เข้ารายการ Known Exploited Vulnerabilities (KEV) ซึ่งแปลว่ามีหลักฐานว่าถูกโจมตีจริงแล้ว ไม่ใช่แค่ช่องโหว่บนกระดาษ ผมเลยนั่งไล่เว็บ WordPress ที่ดูแลอยู่ก่อน แล้วค่อยมาสรุปให้เพื่อนๆ ที่มีเว็บ WordPress อยู่ในมือ เพราะรอบนี้มีจุดที่ต่างจากทุกครั้ง คือถ้ากดอัปเดตไปตรงๆ ตามความเคยชิน จังหวะที่กดอัปเดตนั่นแหละคือจังหวะที่เปิดช่องให้ยิงพอดี

ตัวช่องโหว่อยู่ใน core ไม่ใช่ปลั๊กอินหรือธีม และกระทบตั้งแต่รุ่น 4.7 ขึ้นมาจนถึง 7.1.3 ทีม WordPress ออก 7.1.4 แก้ไว้ตั้งแต่ 28 ต.ค. 2026 พร้อม backport ลงทุกสายย้อนไปถึง 4.7 ส่วน CISA ตั้งกำหนดให้หน่วยงานรัฐของสหรัฐแก้ให้เสร็จภายใน 6 พ.ย. เส้นตายนี้ไม่ได้บังคับเรา แต่บอกได้ดีว่าเขามองความเร่งด่วนไว้ระดับไหน

ช่องโหว่นี้ทำงานยังไง

เวลา WordPress อัปเดต core แบบเต็มแพ็กเกจ มันไม่ได้เขียนทับไฟล์ของเว็บทันที ขั้นตอนจริงคือโหลดไฟล์ zip ของรุ่นใหม่มา แตกไฟล์ทั้งชุดลงโฟลเดอร์ทำงานชั่วคราวใต้ wp-content/upgrade/ ก่อน แล้วค่อยคัดลอกไฟล์จากตรงนั้นไปทับของเดิม สุดท้ายค่อยลบโฟลเดอร์ชั่วคราวทิ้ง

ปัญหามีสามข้อซ้อนกันอยู่

1. ก่อน 7.1.4 ชื่อโฟลเดอร์ชั่วคราวนี้ตั้งจากชื่อแพ็กเกจ เลยเดาได้ล่วงหน้า
2. ในช่วงที่แตกไฟล์เสร็จแต่ยังไม่ลบ โฟลเดอร์นั้นมี WordPress ครบทั้งชุด รวมถึงตัวติดตั้ง wp-admin/setup-config.php ซึ่งรายงานของ Patchstack บอกว่าสำเนาที่ถูกแตกไว้นี้รันได้โดยไม่ต้องมีค่า config ของเว็บ
3. ขั้นเก็บกวาดเดิมยังลบไฟล์ index.php ที่กันการเปิดดูรายชื่อไฟล์ในโฟลเดอร์ upgrade ทิ้งไปด้วย

พอสามข้อนี้มารวมกัน ถ้า web server ยอมเสิร์ฟไฟล์ใต้ wp-content/upgrade/ ผู้โจมตีที่ไม่ต้องล็อกอินเลยแค่ยิง request ไปที่ตัวติดตั้งในโฟลเดอร์ชั่วคราวให้ทันช่วงที่ไฟล์ยังอยู่ ก็เปิดตัวติดตั้งได้ และพาไปถึงการรันโค้ดบนเครื่องได้ ชื่อทางเทคนิคคือ time-of-check time-of-use race condition (CWE-367)

ฟังดูเหมือนต้องโชคดีมากถึงจะยิงทัน เพราะในการทดสอบของ Wordfence ช่วงเวลานั้นปกติเหลือแค่ไม่กี่วินาที แต่ผู้โจมตีไม่ได้ยิงครั้งเดียวแล้วเลิก Wordfence เห็นการยิงวนซ้ำไปที่ path ของตัวติดตั้งในโฟลเดอร์ upgrade มากกว่า 18,500 request ใน 21 ชั่วโมงแรกหลังเปิดเผยข้อมูล และบางแหล่งยิงวนซ้ำไปที่กลุ่มเว็บเดิมต่อเนื่องราว 14.5 ชั่วโมง วันไหนเว็บที่ถูกยิงวนอยู่อัปเดตตรงจังหวะพอดีก็โดน

ข้อสำคัญคือ การกดอัปเดตขึ้น 7.1.4 ครั้งนี้เองก็ยังเสี่ยง เพราะตอนกด โค้ดที่ทำหน้าที่แตกไฟล์ยังเป็นของรุ่นเดิมที่มีช่องโหว่อยู่ เว็บที่เปิดอัปเดตอัตโนมัติไว้ก็หนีไม่พ้น เพราะ auto update ใช้โฟลเดอร์เดียวกัน เลยต้องปิดทางเข้าโฟลเดอร์นี้ก่อนอัปเดตทุกครั้ง

ระดับความรุนแรง ทำไมแต่ละที่ให้คะแนนไม่เท่ากัน

รอบนี้ป้ายความรุนแรงจากแต่ละแหล่งไม่ตรงกัน ใครอ่านแค่ประกาศของ WordPress อาจเข้าใจว่าไม่ต้องรีบ

ที่คะแนนไม่ถึงระดับ Critical เป็นเพราะค่า AC:H (ความยากในการโจมตีสูง) ต้องมีหลายเงื่อนไขพร้อมกัน คือเว็บต้องกำลังอัปเดตแบบเต็มแพ็กเกจ web server ต้องยอมเสิร์ฟโฟลเดอร์ upgrade และผู้โจมตีต้องยิงทันช่วงที่ไฟล์ยังอยู่ แต่ถ้ายิงทัน ผลที่ได้คือ C:H/I:H/A:H คือรันโค้ดด้วยสิทธิ์ของ user เจ้าของเว็บนั้นได้เต็มที่ และไม่ต้องมีบัญชีผู้ใช้เลย

ณ วันที่เขียน ยังไม่เห็นรายงานสาธารณะว่ามีเว็บถูกเจาะสำเร็จด้วยช่องโหว่นี้ ตัวเลขของ Wordfence คือจำนวน request ที่เห็น ไม่ใช่จำนวนเว็บที่โดนเจาะ แต่ CISA ไม่ใส่อะไรเข้า KEV ถ้าไม่มีหลักฐานการโจมตีจริง แม้ยังไม่เปิดเผยรายละเอียดของหลักฐานนั้น

รุ่นไหนต้องอัปเดตเป็นอะไร

ไม่จำเป็นต้องกระโดดขึ้น 7.1 ทุกเว็บ ทีม WordPress backport การแก้ลงทุกสายที่ยังได้รับ security update ย้อนไปถึง 4.7 เว็บเก่าที่ยังขึ้นสายใหม่ไม่ได้ อัปเดตในสายเดิมก็พอ

สิ่งที่ 7.1.4 แก้มีสามข้อ คือตั้งชื่อโฟลเดอร์ชั่วคราวเป็นตัวอักษรสุ่ม 16 ตัว เก็บไฟล์ index.php ในโฟลเดอร์ upgrade ไว้ และสร้างใหม่ถ้าหายไป และไม่คัดลอก wp-config.php ออกมาในขั้นคัดลอกไฟล์ ข้อสุดท้ายนี้ Patchstack ตั้งข้อสังเกตว่าไม่ได้เขียนไว้ในประกาศของ WordPress

ขั้นที่ 1 ปิด wp-content/upgrade ก่อนอัปเดต

ขั้นนี้ทำก่อนกดอัปเดตเสมอ คำแนะนำที่ตรงกันคือให้ปิดการเข้าถึงโฟลเดอร์นี้ที่ web server, virtual host หรือ CDN และ อย่าพึ่งไฟล์ที่วางไว้ในโฟลเดอร์ upgrade เอง เพราะ WordPress เคลียร์ของในโฟลเดอร์นั้นตอนเก็บกวาด

การปิดตรงนี้ไม่ทำให้การอัปเดตพัง เพราะตัวอัปเดตของ WordPress เขียนและอ่านไฟล์ในโฟลเดอร์นี้ผ่าน filesystem โดยตรง ไม่ได้เรียกผ่านเว็บ ระหว่างอัปเดตปกติไม่ควรมีใครต้องเปิดไฟล์ใต้ wp-content/upgrade/ ผ่าน browser เลย

Apache (รวมถึงเครื่องที่ใช้ nginx หน้า Apache) ใส่ไว้บนสุดของ .htaccess ที่ root ของเว็บ ก่อนบล็อก # BEGIN WordPress

# ปิดโฟลเดอร์ชั่วคราวของตัวอัปเดต (CVE-2026-119977)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

ถ้าเว็บติดตั้งไว้ใน subfolder เช่น /blog/ ให้วางในไฟล์ .htaccess ของ subfolder นั้น ส่วนใครแก้ config ของ virtual host ได้ วางไว้ใน vhost จะดีกว่า เพราะปลั๊กอินที่เขียน .htaccess เองจะไม่ไปทับ

nginx ใช้ ^~ เพื่อให้ location นี้ชนะ location แบบ regex ของไฟล์ .php ที่ส่งต่อให้ PHP-FPM ถ้าลืม ^~ ไฟล์ .php ในโฟลเดอร์นี้จะไปตก location ของ PHP แทน แล้ว deny จะไม่มีผลกับไฟล์ที่สำคัญที่สุด

location ^~ /wp-content/upgrade/ {
    deny all;
}

แก้แล้วเช็ก config ก่อน reload ทุกครั้งด้วย nginx -t ส่วนเครื่อง DirectAdmin ที่ใช้ nginx อย่างเดียว ให้ใส่บล็อกนี้ผ่านหน้า Custom HTTPD Configurations ของโดเมน อย่าแก้ไฟล์ config ที่ระบบสร้างให้ตรงๆ เพราะจะถูกเขียนทับตอน rewrite config รอบถัดไป

Cloudflare ถ้าเว็บอยู่หลัง Cloudflare เพิ่ม WAF custom rule ตัวเดียวคลุมทุก hostname ใน zone นั้นได้เลย ตั้ง action เป็น Block

starts_with(http.request.uri.path, "/wp-content/upgrade/")

ชั้นนี้ช่วยกันจากขอบ แต่ใครที่รู้ IP จริงของเครื่องก็ยิงข้าม Cloudflare เข้ามาตรงๆ ได้ ผมเลยแนะนำให้ใส่ทั้ง Cloudflare และ web server ไม่เลือกอย่างใดอย่างหนึ่ง

เช็กว่าปิดได้จริงก่อนไปขั้นถัดไป ต้องได้ 403 ทั้งสองบรรทัด

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/upgrade/
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/upgrade/test/wp-admin/setup-config.php

ถ้าบรรทัดที่สองได้ 404 แปลว่า request ยังวิ่งผ่านไปถึง WordPress หรือ PHP อยู่ กฎยังไม่ทำงาน ให้กลับไปดูว่าวางกฎไว้ก่อนบล็อกของ WordPress หรือยัง และ nginx มี ^~ หรือยัง

กฎที่ใส่ไว้ไม่ต้องถอดออกหลังอัปเดตเสร็จ เก็บไว้ถาวรได้เลย เพราะระหว่างอัปเดตแต่ละรอบ โฟลเดอร์นี้มีแค่ index.php ไม่มีอะไรที่ต้องเปิดจากเว็บอยู่แล้ว

ขั้นที่ 2 อัปเดตให้ครบทุกเว็บ

กับดักบนเครื่องที่รวมหลายเว็บคือคิดว่า auto update ทำให้หมดแล้ว ความจริง WordPress เปิด auto update สำหรับรุ่นย่อยไว้เป็นค่าเริ่มต้นก็จริง แต่มีเว็บจำนวนไม่น้อยที่ปิดไว้ ทั้งที่ตั้งใจและที่ปลั๊กอินปิดให้ เลยต้องไล่เช็กเลขรุ่นจริงทุกเว็บ

ไล่รุ่นทุกเว็บในเครื่องจากไฟล์ version.php (ตัวอย่างนี้ใช้ layout ของ DirectAdmin ใครใช้ /var/www ก็เปลี่ยน path ตาม)

for f in /home/*/domains/*/public_html/wp-includes/version.php; do
  v=$(grep -o "wp_version = '[^']*'" "$f" | cut -d"'" -f2)
  echo "$v  ${f%/wp-includes/version.php}"
done | sort -V

หาเว็บที่อาจปิด auto update ไว้ ผลที่ได้เป็นแค่รายการให้เปิดไฟล์ดูต่อ ไม่ใช่ข้อสรุป เพราะบางเว็บตั้งค่าเหล่านี้เป็น false ไว้ก็ติดมาด้วย

grep -lE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE'?, *false|DISALLOW_FILE_MODS" \
  /home/*/domains/*/public_html/wp-config.php

อัปเดตด้วย WP-CLI โดยรันเป็น user เจ้าของเว็บ ไม่ใช่ root ไฟล์ที่ได้จะได้ไม่กลายเป็นของ root

WP="sudo -u webuser -- wp --path=/home/webuser/domains/example.com/public_html"

$WP core version
$WP core update --minor      # อยู่สายเดิม ได้รุ่น backport เช่น 6.8.12
# หรือ $WP core update       # ขึ้นรุ่นล่าสุด 7.1.4
$WP core verify-checksums
$WP core version

1. ทำรายการทุกเว็บ พร้อมเลขรุ่นและสาย จากสคริปต์ด้านบน รวมเว็บ staging และเว็บที่ลืมไปแล้วแต่ยังเปิดอยู่
2. ปิด wp-content/upgrade ด้วยกฎในขั้นที่ 1 แล้วเช็กด้วย curl ว่าได้ 403 ลองกับเว็บเดียวก่อน ผ่านแล้วค่อยใส่ทุกเว็บ
3. อัปเดต เป็น 7.1.4 หรือรุ่น backport ของสายที่ใช้ เว็บที่ปิด auto update ไว้ทำมือทีละเว็บ
4. ยืนยันผล ด้วย wp core version กับ wp core verify-checksums ทุกเว็บ ไม่ใช่สุ่มดูบางเว็บ
5. เว็บรุ่น 4.6 ลงไป ไม่มีแพตช์ ต้องย้ายขึ้นสายที่ยังได้รับการดูแล หรือปิดไม่ให้เข้าจากภายนอกไปก่อน

ขั้นที่ 3 เช็กว่าโดนไปแล้วหรือยัง

ตอนนี้ยังไม่มีใครเผยแพร่ IP หรือ hash ของไฟล์ที่ใช้โจมตี การเช็กเลยต้องดูจากพฤติกรรม เริ่มจาก log ของ web server ว่ามี request ไปที่ไฟล์ .php ใต้โฟลเดอร์ upgrade หรือไม่ โดยเฉพาะช่วงเวลาที่เว็บอัปเดต (เครื่อง DirectAdmin เก็บ log แยกโดเมนไว้ที่ /var/log/httpd/domains/ ระบบอื่นปรับ path ตาม ถ้าเว็บอยู่หลัง Cloudflare และไม่ได้ตั้ง mod_remoteip ไว้ คอลัมน์ IP จะเป็น IP ของ Cloudflare)

# ใครยิงไฟล์ .php ใต้ wp-content/upgrade บ้าง: IP, เวลา, path, status
zgrep -hE '"(GET|POST) [^"]*/wp-content/upgrade/[^" ]*\.php' /var/log/httpd/domains/*.log* \
  | awk '{print $1, $4, $7, $9}' | sort | uniq -c | sort -rn | head -50

# ตัวที่ต้องตกใจ: POST ไปที่ setup-config.php แล้วได้ 200
zgrep -hE '"POST [^"]*/wp-content/upgrade/[^"]*setup-config\.php[^"]*" 200 ' /var/log/httpd/domains/*.log*

ต่อด้วยไล่ไฟล์และบัญชีในแต่ละเว็บ

# ไฟล์ .php ที่ค้างอยู่ใต้ upgrade (ปกติต้องเหลือแค่ index.php)
find /home/*/domains/*/public_html/wp-content/upgrade -type f -name '*.php' ! -name index.php -ls 2>/dev/null

# บัญชีแอดมิน ปลั๊กอินที่เปิดอยู่ และไฟล์ core ที่ไม่ตรงกับต้นฉบับ ($WP ตามที่ตั้งไว้ในขั้นที่ 2)
$WP user list --role=administrator --fields=ID,user_login,user_email,user_registered
$WP plugin list --status=active
$WP core verify-checksums

ถ้าเจอบัญชีแอดมินแปลกหรือไฟล์ core ไม่ตรง checksum ให้นับว่าเว็บนั้นโดนแล้ว ไม่ใช่แค่ลบบัญชีทิ้งแล้วจบ ต้องเปลี่ยนรหัสฐานข้อมูลกับ salt ใน wp-config.php ไล่หา webshell ทั้งเว็บ และเช็กเว็บอื่นของ user เดียวกันด้วย เพราะบน shared hosting ทุกเว็บของ user นั้นใช้สิทธิ์ชุดเดียวกัน ขั้นตอนไล่เคสแบบนี้ผมเคยเขียนไว้ใน WordPress ขึ้น 500 บางหน้า แต่ debug.log ว่าง ตรงส่วนที่ไล่ log ของ Apache ใช้วิธีเดียวกันได้

สรุปลำดับที่ผมใช้

สรุปคือรอบนี้ห้ามกดอัปเดตก่อนปิดโฟลเดอร์ upgrade ลำดับต้องเป็นปิดก่อนแล้วค่อยอัปเดต ส่วนตัวผมแนะนำให้ใส่กฎ deny ไว้ทั้งที่ web server และ CDN แล้วเก็บไว้ถาวร เพราะต้นทุนแทบไม่มี ไม่กระทบการใช้งานของเว็บ และโฟลเดอร์นี้ไม่มีเหตุผลให้เปิดจากเว็บอยู่แล้ว ใครดูแลเว็บไม่กี่เว็บก็ทำมือทีละเว็บได้ ใครมีเป็นร้อยเว็บก็ใช้สคริปต์ไล่ ตามกำลังคนกับจำนวนเว็บที่แต่ละที่ดูแล

ปล. ใครใช้ Wordfence รุ่นฟรี กฎ firewall ของช่องโหว่นี้จะไปถึงรุ่นฟรีวันที่ 27 พ.ย. 2026 (รุ่นเสียเงินได้ไปตั้งแต่ 28 ต.ค.) อย่ารอวันนั้น และทั้ง Wordfence กับ Patchstack บอกตรงกันว่าปลั๊กอิน firewall ที่ทำงานในระดับ PHP ใช้แทนการปิดที่ web server ไม่ได้

ที่มา: ประกาศ WordPress 7.1.4 Security Release (wordpress.org/news) วันที่ 28 ต.ค. 2026, รายการ Known Exploited Vulnerabilities ของ CISA วันที่ 3 พ.ย. 2026 และรายงานวิเคราะห์ของ Wordfence กับ Patchstack ถ้ามีรายงานเว็บที่ถูกเจาะสำเร็จหรือ NVD ให้คะแนนออกมา เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ