wp2shell: ช่องโหว่ RCE ใน WordPress เวอร์ชันมาตรฐาน ที่ถูกค้นพบภายในสิบชั่วโมงด้วยเงินเพียง $25

เมื่อวันที่ 17 กรกฎาคม 2026 Searchlight Cyber ได้เผยแพร่ wp2shell ซึ่งเป็นเชนการรันโค้ดจากระยะไกลแบบไม่ต้องยืนยันตัวตนในแกนหลักของ WordPress ที่ไม่ต้องใช้ปลั๊กอิน ธีม หรือการเข้าสู่ระบบ คำขอแบบไม่ระบุตัวตนต่อการติดตั้งมาตรฐานก็เพียงพอ: “การโจมตีนี้ไม่มีเงื่อนไขเบื้องต้น และผู้ใช้แบบไม่ระบุตัวตนสามารถใช้ช่องโหว่นี้ได้ในการติดตั้ง WordPress แบบมาตรฐานที่ไม่มีปลั๊กอิน” คำแนะนำของบริษัทระบุ เชนนี้รวมช่องโหว่สองรายการ ได้แก่ CVE-2026-63030 ซึ่งเป็นข้อบกพร่องการสับสนเส้นทางในปลายทางแบบแบตช์ของ WordPress REST API ที่คำแนะนำของโครงการจัดระดับเป็นวิกฤต และ CVE-2026-60137 ซึ่งเป็นการแทรก SQL ใน author__not_in พารามิเตอร์ของ WP_Query ที่คำแนะนำจัดระดับเป็นปานกลาง WordPress ได้เผยแพร่ WordPress 7.0.2 ในวันเดียวกัน และคำแนะนำของโครงการระบุว่า WordPress 6.9.5, WordPress 6.8.6 และ WordPress 7.1 beta2 มีการแก้ไขเดียวกัน Searchlight อ้างถึงการประมาณการว่ามีเว็บไซต์ WordPress มากกว่า 500 ล้านแห่ง นักวิจัยที่อยู่เบื้องหลังเชนนี้ Adam Kues กล่าวว่าเชนนี้เกิดจากการรัน GPT-5.6 Sol Ultra ที่สร้างขึ้นจากพรอมป์ต์ที่ OpenAI เคยเผยแพร่สำหรับปัญหาทางคณิตศาสตร์ โดยมีเอเจนต์สูงสุดสี่ตัว ใช้เวลาอย่างน้อยหกชั่วโมงในการตามล่า และอีกประมาณสี่ชั่วโมงในการยกระดับ โดยมีการใช้โมเดลคิดเป็นมูลค่าประมาณ $25 บันทึกนี้ถูกจัดเก็บเป็นผลการวิจัย — ความรุนแรงสูงตามมาตราส่วนของคลังข้อมูลเอง ความมั่นใจระดับ A ไม่มีการบันทึกความเสียหายในโลกจริง ระบุวันที่เป็นวันเดียว — และ the Orca AI Incident Archiveเผยแพร่บันทึกนี้พร้อมลิงก์เอกสารต้นฉบับไว้ด้านล่าง

การเปิดเผยข้อมูลครั้งนี้เป็นความร่วมมือที่ประสานกันไว้ Searchlight ไม่เปิดเผยรายละเอียดทางกลไกเมื่อวันที่ 17 กรกฎาคม และให้เวลาฝ่ายป้องกันตลอดช่วงสุดสัปดาห์เพื่ออัปเกรดระบบ Kues เผยแพร่รายงานทางเทคนิคฉบับเต็มเมื่อวันที่ 20 กรกฎาคม เมื่อถึงตอนนั้น ช่องโหว่แบบลูกโซ่นี้ได้ถูกจำลองขึ้นใหม่ได้อย่างอิสระแล้ว Searchlight ระบุว่า Calif และ Hacktron ได้ประกอบห่วงโซ่การโจมตีครบทั้งสายขึ้นมาใหม่ได้ก่อนที่หลักฐานแนวคิด (proof of concept) อื่น ๆ จะปรากฏบน GitHub ทั้งนี้ ประกาศด้านความปลอดภัยสองฉบับของ WordPress เองระบุเวอร์ชันที่ได้รับการแก้ไขแล้วเป็นเวอร์ชันเดียวกัน และ CISA ได้เพิ่ม CVE ทั้งสองรายการเข้าสู่แค็ตตาล็อก Known Exploited Vulnerabilities ของตนเมื่อวันที่ 21 กรกฎาคม

สองบั๊ก และอาร์เรย์ที่หลุดจังหวะกัน

จุดเข้าใช้งานนี้เป็นฟีเจอร์ ไม่ใช่ความผิดพลาด WordPress 5.6 เปิดตัว endpoint แบบแบตช์ในปี 2020 เพื่อให้ไคลเอนต์สามารถส่งคำขอ REST เสมือนหลายรายการภายในคำขอ HTTP เดียว เช่น เพื่อเปลี่ยนชื่อโพสต์หลายรายการพร้อมกัน endpoint นี้เข้าถึงได้ไม่ว่าผู้เรียกจะได้รับการพิสูจน์ตัวตนหรือไม่ และคำขอย่อยแต่ละรายการจะพาการพิสูจน์ตัวตนใดก็ตามที่ผู้เรียกส่งมา คำขอโดยตรงไปยังเส้นทาง REST ของ WordPress จะทำงานผ่านไปป์ไลน์สี่ขั้นตอน: ตรวจสอบพารามิเตอร์ที่จำเป็นและถูกต้อง ทำความสะอาดข้อมูลเหล่านั้น เรียกใช้คอลแบ็กการอนุญาต แล้วจึงเรียกใช้คอลแบ็กของ endpoint endpoint ต่างๆ พึ่งพาไปป์ไลน์นั้นสำหรับสมมติฐานเกี่ยวกับชนิดข้อมูล — ว่า ID ของโพสต์เป็นจำนวนเต็ม และชื่อเรื่องเป็นสตริง

API แบบแบตช์แยกไปป์ไลน์ออกเป็นสองส่วน โดยตรวจสอบคำขอย่อยทุกตัวในลูปหนึ่ง และดำเนินการคำขอเหล่านั้นในลูปที่สอง และเก็บอาร์เรย์ไว้สองตัว คือ $matches และ $validation ซึ่งรายการต่าง ๆ ถูกออกแบบให้เรียงตรงกันทีละดัชนี ใน class-wp-rest-server.php ตามที่ Kues อธิบาย คำขอย่อยที่ตัวมันเองเป็น WordPress error จะถูกเพิ่มต่อท้ายเข้าไปใน $validation แล้วก็ไปเจอคำสั่ง continue โดยข้ามบรรทัดที่ต่อท้ายค่าเข้าไปใน $matches นับจากจุดนั้น ทุกแมตช์จะถูกเลื่อนถอยหลังไปหนึ่งตำแหน่ง ลูปการทำงานจะจับคู่คำขอย่อย ณ ดัชนีหนึ่งกับข้อมูลการตรวจสอบที่บันทึกไว้ ณ ดัชนีนั้น แต่ handler ที่จับคู่อยู่กลับเป็นของเส้นทางอื่น — ดังนั้นพารามิเตอร์ตัวหนึ่งจึงถูกตรวจสอบกับกฎของปลายทางหนึ่ง แล้วจึงถูกดำเนินการด้วยโค้ดของอีกปลายทางหนึ่ง

นี่คือสิ่งที่ทำให้พารามิเตอร์แบบลิสต์ที่ดูธรรมดากลายเป็นการฉีดโค้ด เส้นทางคอลเลกชันโพสต์แมปพารามิเตอร์สาธารณะของตน author_excludeอาร์กิวเมนต์ไปยังauthor__not_in. เมื่อค่าเป็นอาร์เรย์ WordPress จะรัน absintกับทุกองค์ประกอบและเรียงลำดับ它們; เมื่อค่าเป็นสเกลาร์ ค่านั้นจะถูกต่อโดยไม่ถูกแตะต้องเข้าไปในส่วน SQL ที่กลายเป็น NOT IN ($author__not_in). สตริงอย่างเช่น 0) OR 1=1 --จึงไปอยู่ในข้อความคิวรี เมื่อเรียกตามปกติ เส้นทางจะปฏิเสธมัน เพราะ author_excludeต้องเป็นอาร์เรย์ของจำนวนเต็ม; การเรียกแบบแบตช์ที่ไม่ซิงโครไนซ์นี่เองที่ทำให้สตริงหลุดผ่านไปได้

ยังมีอุปสรรคสองข้อเหลืออยู่ และทั้งสองข้อก็ได้รับการแก้ไขด้วยการซ้อนกลเม็ดนี้เข้าไป API แบบแบตช์ปฏิเสธคำขอ GET ขณะที่ช่องโหว่การฉีดนั้นอยู่ในเส้นทาง GET และการตรวจสอบเมธอดของคำขอก็ถูกนำไปใช้ในรูปของการตรวจสอบพารามิเตอร์ ซึ่งการทำให้สถานะไม่ตรงกันแบบเดียวกันนี้สามารถข้ามผ่านได้ เพย์โหลดที่ Kues เผยแพร่จะส่งคำขอซับชั้นนอกที่ผิดรูปแบบเพื่อทำให้การตรวจสอบเมธอดไม่ตรงกัน จากนั้นจึงส่งแบตช์ชั้นในซึ่งคำขอซับที่สองนำ author_exclude ที่เป็นอันตรายไปยังแฮนด์เลอร์ที่ไม่ตรวจสอบพารามิเตอร์นี้ แล้วตามด้วยคำขอ GET ที่รันการฉีดนั้น การฉีดแบบ UNION จะคืนค่าฐานข้อมูลตามอำเภอใจภายในแถวที่มีรูปร่างเหมือนโพสต์ธรรมดา

การรันโมเดล: พรอมต์คณิตศาสตร์ที่ชี้ไปยังโค้ดเบส

คูสไม่ได้เขียนพรอมต์นั้นขึ้นมาเองตั้งแต่แรก OpenAI ได้เผยแพร่พรอมต์ที่ใช้ขณะทำงานเกี่ยวกับข้อคาดการณ์ Cycle Double Cover และคูสเขียนว่าเขาได้อ่านพบว่าโมเดลดังกล่าวเพิ่งแก้ข้อคาดการณ์นั้นได้ และดูเหมือนว่าจะไม่มีใครในชุมชนความมั่นคงปลอดภัยพูดถึงพรอมต์นี้ เหตุผลของเขาคือถ้ามันดีพอสำหรับคณิตศาสตร์ยาก ๆ มันก็คงดีพอสำหรับการวิจัยด้านความมั่นคงปลอดภัยเช่นกัน เขาจึงดัดแปลงมันและนำไปใช้กับ WordPress

การตั้งค่าถูกจำกัดให้แคบอย่างตั้งใจ เขาคลอนรีลีส WordPress เวอร์ชันเสถียรล่าสุดลงในไดเรกทอรีชื่อ main/ และลบ .git ไดเรกทอรีของมันออก โดยสั่งโมเดลไม่ให้ใช้บันทึกการเปลี่ยนแปลง ประวัติ git หรืออินเทอร์เน็ตแบบเปิดเพื่อ diff โค้ดเทียบกับเวอร์ชันที่แพตช์แล้ว — เหตุผลที่เขาระบุคือ สำหรับการค้นพบช่องโหว่แบบใหม่ การตรวจดูประวัติหรือเว็บนั้นเป็นการสิ้นเปลืองโทเค็น มีไดเรกทอรี third_party/ ที่ว่างเปล่าให้ไว้ เพื่อให้โมเดลสามารถโคลนดีเพนเดนซี เช่นซอร์สโค้ด PHP หรือ MySQL ได้ หากโมเดลตัดสินว่าห่วงโซ่นั้นจำเป็นต้องมีบั๊กในไลบรารีที่อยู่ใต้ WordPress งานนี้ถูกกำหนดให้เป็น pre-authentication RCE ในการติดตั้งใช้งานจริงแบบทั่วไปบน MySQL โดยมีเอเจนต์ได้สูงสุดสี่ตัวและอย่างน้อยหกชั่วโมง Kues เขียนว่าเขาระบุข้อกำหนดด้านการกำหนดค่าไว้อย่างชัดเจน เพราะไม่เช่นนั้นโมเดลจะ "โกง" — ด้วยการเลือกตัวเลือกการกำหนดค่าที่เป็นไปได้ยากสุด ๆ หรือด้วยการกุเงื่อนไขเบื้องต้นที่ผู้โจมตีไม่มีทางบรรลุได้

สิ่งที่ได้กลับมาในเอาต์พุตขณะรันคือข้อกล่าวอ้างเรื่องช่องโหว่ SQL injection ก่อนการยืนยันตัวตน Kues ไม่เชื่อเรื่องนี้ เขาเขียนว่า WordPress เป็นหนึ่งในเป้าหมายที่ถูกตรวจสอบอย่างหนักที่สุดตลอดกาล และในทศวรรษนั้นก็ยังไม่มีช่องโหว่ก่อนการยืนยันตัวตนที่มีนัยสำคัญ เขาติดตั้ง WordPress เวอร์ชันมาตรฐานบนเซิร์ฟเวอร์ระยะไกล และขอให้โมเดลขโมยอีเมลของผู้ดูแลระบบ ภายในไม่กี่นาทีมันก็พิมพ์ที่อยู่ที่เขาใช้ตั้งค่าอินสแตนซ์นั้นออกมา จากนั้นเขาถามว่าการฉีดแบบอ่านอย่างเดียวสามารถยกระดับสิทธิ์ได้หรือไม่ และประมาณสี่ชั่วโมงต่อมา โมเดลตอบว่าทำได้ — ถึงระดับผู้ดูแลระบบ โดยไม่ต้อง crack รหัสผ่านใด ๆ และไม่ต้องคำนวณแบบออฟไลน์

การคิดต้นทุนของเขาเอง: 50% ของโควตาการใช้งานรายสัปดาห์ ซึ่งเขาประเมินว่าอยู่ที่ประมาณ $25 ตามสัดส่วนจากค่าสมัครสมาชิก $200 สำหรับ exploit ที่สร้างขึ้นในเวลาเพียงสิบชั่วโมงกว่าศเล็กน้อย ต้นทุนฝั่งมนุษย์ไม่ได้ฟรี — Kues ใช้เวลาวันถัดไปแกะว่าสิ่งที่โมเดลทำนั้นคืออะไร และเขียนว่างาน post-exploitation ทำให้เขาใช้เวลานานกว่ามากในการทำความเข้าใจ เมื่อเทียบกับเวลาที่ใช้ในการสร้าง คำตัดสินของเขาคมตรงและจำกัดขอบเขตแคบอย่างผิดปกติ: "ผมไม่กล่าวอ้างทั่วไป แต่ผมพูดได้อย่างมั่นใจเต็มที่ว่าไม่มีนักวิจัยด้านความปลอดภัยคนใดจะสามารถค้นพบและทำ exploit chain นี้ให้เสร็จภายใน 10 ชั่วโมงได้โดยไม่ใช้ AI"

จาก SELECT แบบอ่านอย่างเดียวไปจนถึงผู้ดูแลระบบ

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

ขั้นแรก ทำให้แคชโพสต์ในหน่วยความจำปนเปื้อนWordPress เก็บแคชของออบเจ็กต์ WP_Post แยกตามแต่ละคำขอ เพื่อให้โพสต์เดียวกันที่ถูกอ้างถึงหลายครั้งภายในคำขอเดียวใช้การไปกลับฐานข้อมูลเพียงครั้งเดียว การฉีด SQL สามารถสร้างโพสต์ปลอมขึ้นมาได้ ดังนั้นผู้โจมตีจึงควบคุมได้อย่างแม่นยำว่าสิ่งใดจะถูกแคช — แต่โพสต์ปลอมเหล่านั้นไม่ใช่แถวในฐานข้อมูล และแคชจะสิ้นสุดไปพร้อมกับคำขอนั้น

ประการที่สอง เปลี่ยนโพสต์ที่กุขึ้นให้เป็นแถวข้อมูลจริงฟีเจอร์การฝัง (embed) ของ WordPress จะแคชการฝังที่ถูกแปลงแล้วไว้ในฐานข้อมูลในรูปแบบโพสต์ประเภท oembed_cache การฝังโพสต์ภายในเครื่องผ่านเส้นทางแบบสัมพัทธ์ เช่นใน [embed]/?p=S[/embed] จะทำให้ WordPress ข้ามการดึงข้อมูลผ่าน HTTP และไม่ตรวจสอบว่าโพสต์ที่อ้างอิงมีอยู่จริงหรือไม่ จึงมีการสร้างแถวข้อมูลขึ้นมา การฝังลักษณะนี้สามรายการซึ่งมีโทเค็นในคิวรีสตริงต่างกันจะสร้างค่าแฮชแคชที่แตกต่างกันสามค่า ซึ่งเป็นวิธีที่ผู้โจมตีได้แถวข้อมูลหลายแถวมาใช้งาน

ประการที่สาม หาทางหลบเลี่ยงฟิลด์เดียวที่ยังคงที่ เมื่อเวอร์ชันในหน่วยความจำและในฐานข้อมูลของโพสต์ไม่ตรงกัน WordPress จะทำให้ทั้งสองสอดคล้องกันด้วยการเรียกที่กำหนดอย่างชัดเจนpost_content จากเอาต์พุตของ embed ทุกอย่างเกี่ยวกับโพสต์ถูกควบคุมโดยผู้โจมตี ยกเว้นเนื้อหา ซึ่งเป็นฟิลด์ที่customize_changesetใช้เก็บ JSON ของการเปลี่ยนแปลงธีมและไซต์ที่รอดำเนินการ

ประการที่สี่ แกดเจ็ตวงวน โพสต์มีพาเรนต์ และ WordPress ปฏิเสธวงจร: wp_insert_post_parent ฟิลเตอร์จะไล่ขึ้นไปตามต้นไม้ และเมื่อพบลูป จะเรียกการอัปเดตที่ตั้งค่า post_parentให้เป็นศูนย์ การเรียกนั้นไม่เขียนทับ post_content ดังนั้นเวอร์ชันที่สร้างขึ้นในหน่วยความจำจึงรอดจากการกระทบยอด — changeset ที่ JSON ยังคงอยู่ครบ โดยมีแถวข้อมูลจริงรองรับ

ประการที่ห้า ยืมสิทธิอำนาจของผู้ดูแลระบบ ชุดการเปลี่ยนแปลงซึ่งสถานะระบุว่าถูกกำหนดเวลาไว้ในอนาคต แต่มีวันที่อยู่ในอดีตจะถูกนำไปใช้ทันที แต่ละรายการใน JSON ของชุดการเปลี่ยนแปลงนั้นระบุ user_id และรายการในเชนของ Kues ระบุ user_id 1 ซึ่งเป็นผู้ดูแลระบบ ดังนั้น WordPress จึงรับเอาตัวตนนั้นมาใช้ชั่วคราวเพื่อนำการเปลี่ยนแปลงไปใช้ การเปลี่ยนแปลงแรกคือการอัปเดตที่ดูไม่เป็นอันตรายซึ่งกระทำต่อ nav_menus_created_posts.

ประการที่หก ให้เล่นคำขอซ้ำในฐานะตัวตนดังกล่าว การเผยแพร่โพสต์จะกระตุ้นแอ็กชันที่ตั้งชื่อแบบไดนามิก คือ {status}_{post_type} เนื่องจากโพสต์ถูกสร้างขึ้นมาเทียม สถานะและประเภทนั้นจึงเป็นอะไรก็ได้ — รวมถึง parse และ request ซึ่งจะให้ฮุก parse_request และเริ่มกระบวนการไปป์ไลน์ของคำขอใหม่ตั้งแต่ต้นในขณะที่ตัวตนผู้ดูแลระบบที่ยืมมายังคงอยู่ คำขอแบบแบตช์เดิมมีคำขอย่อยที่สร้างผู้ดูแลระบบใหม่ ซึ่งล้มเหลวในรอบแรกในฐานะผู้เยี่ยมชมและสำเร็จเมื่อเล่นซ้ำ จากจุดนั้น ผู้โจมตีจะเข้าสู่ระบบด้วยบัญชีใหม่นั้นและอัปโหลดปลั๊กอินแบ็กดอร์จากไฟล์ ZIP ซึ่งเป็นการรันโค้ด

เทคนิคนี้มีเงื่อนไขหนึ่งแนบอยู่ด้วย The Hacker News ซึ่งอ้างอิง Cloudflare รายงานว่า CVE-2026-63030 ทำให้เกิดการรันโค้ดจากระยะไกลได้เฉพาะเมื่อไม่ได้ใช้แคชออบเจ็กต์แบบเพอร์ซิสเทนต์เท่านั้น ส่วนตัวการฉีดนั้นมีอยู่ตั้งแต่ WordPress 6.8 ขณะที่ห่วงโซ่แบบเต็มต้องใช้ 6.9 หรือใหม่กว่า การติดตั้งแบบมาตรฐานไม่มีการแคชออบเจ็กต์แบบเพอร์ซิสเทนต์ ซึ่งเป็นเหตุให้ถ้อยคำ "no preconditions" ของ Searchlight และคำขยายความของ Cloudflare อธิบายกรณีเริ่มต้นเดียวกันจากคนละมุม

สิ่งที่เอกสารปฐมภูมิยืนยัน

ประกาศด้านความปลอดภัยของ WordPress เองเป็นหลักฐานยืนยันที่หนักแน่นที่สุด เพราะเป็นกรณีที่ผู้ขายยอมรับกลไกของช่องโหว่และออกแพตช์แก้ไขแล้ว GHSA-ff9f-jf42-662q ซึ่งจัดอยู่ในระดับ critical อธิบายถึงจุดอ่อนด้านความสับสนของเส้นทางแบบ batch ใน REST API ของ WordPress 6.9 ขึ้นไป ซึ่งเมื่อใช้ร่วมกับการโจมตีแบบ injection แล้วนำไปสู่การรันโค้ดได้ และให้เครดิตแก่ Adam Kues จาก Assetnote และ Searchlight Cyber GHSA-fpp7-x2x2-2mjf ซึ่งจัดอยู่ในระดับ moderate อธิบายถึงช่องโหว่ injection ที่เกิดจาก author__not_in ใน WordPress 6.8 ขึ้นไป และระบุว่าปัญหาทั้งสองได้รับการแก้ไขใน WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 และ WordPress 7.1 beta2 บันทึกของ NVD สำหรับ CVE ทั้งสองรายการ ซึ่งให้คะแนนโดย WPScan CNA ไม่ใช่ NIST มีคะแนน 9.8 สำหรับ CVE-2026-63030 พร้อมเวกเตอร์ AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H และ 5.9 สำหรับ CVE-2026-60137 พร้อม AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — กรณีแรกเป็นบั๊กที่เข้าถึงได้ผ่านเครือข่ายและไม่ต้องมีสิทธิ์ใด ๆ ส่วนกรณีที่สองต้องใช้ความซับซ้อนในการโจมตีสูงและส่งผลกระทบเฉพาะด้านความลับ ฟิลด์ระดับความรุนแรงของคลังข้อมูลเองสำหรับรายการนี้ระบุว่า high ขณะที่ WordPress ระบุว่าช่องโหว่แบบ batch เป็น critical ทั้งสองเป็นมาตราส่วนที่แยกจากกันซึ่งใช้กับห่วงโซ่ทั้งหมดและกับองค์ประกอบเดียว ไม่ใช่ความขัดแย้งเกี่ยวกับตัวบั๊กเอง

รายการแค็ตตาล็อกของ CISA ซึ่งปรากฏอยู่ในฟิลด์ข้อมูลเสริมของ NVD ถูกเพิ่มเมื่อวันที่ 21 กรกฎาคม 2026 โดยมีกำหนดเส้นตายในการแก้ไขคือวันที่ 24 กรกฎาคม สำหรับ CVE-2026-63030 และวันที่ 4 สิงหาคม สำหรับ CVE-2026-60137 CISA ตั้งชื่อรายการแรกว่า "WordPress Core Interpretation Conflict Vulnerability" และรายการที่สองว่า "WordPress Core SQL Injection Vulnerability" นอกจากนี้ Searchlight ยังได้เผยแพร่เครื่องมือตรวจสอบสาธารณะที่ wp2shell.com เพื่อให้ผู้ดูแลระบบสามารถทดสอบอินสแตนซ์ได้โดยไม่ต้องรอซิกเนเจอร์จากสแกนเนอร์

Searchlight เองเป็นผู้บันทึกการทำซ้ำอย่างอิสระไว้ จึงเป็นคำกล่าวอ้างเกี่ยวกับบุคคลที่สามมากกว่าจะเป็นรายงานจากบุคคลที่สาม: ตามบทความเมื่อวันที่ 20 กรกฎาคม Calif และ Hacktron ได้สร้างห่วงโซ่การโจมตีเต็มรูปแบบขึ้นใหม่ก่อนที่หลักฐานเชิงแนวคิดอื่นจะปรากฏบน GitHub สิ่งที่ตรวจสอบได้อย่างอิสระคือผลที่เกิดขึ้น — หลักฐานเชิงแนวคิด ทราฟฟิกการใช้ประโยชน์ช่องโหว่ และข้อมูลเทเลเมทรีจากผู้จำหน่าย ภายในไม่กี่วัน ซึ่งมีรายละเอียดด้านล่าง

อะไรที่ถูกกล่าวอ้างแต่ยังไม่ได้รับการยืนยัน

การให้เครดิตสองรายการสำหรับช่องโหว่ injection หนึ่งรายการไม่สอดคล้องกันในบันทึกสาธารณะ คำแนะนำของ WordPress สำหรับ CVE-2026-60137 ระบุว่าช่องโหว่นี้ "ถูกค้นพบและเปิดเผยอย่างมีความรับผิดชอบในฐานะทีมโดย TF1T, dtro และ haongo" บันทึกของ Searchlight นำเสนอช่องโหว่ injection ก่อนการยืนยันตัวตนรายการเดียวกันว่าเป็นสิ่งที่การรันโมเดลของตนตรวจพบ และไม่ได้กล่าวถึงทีมนั้น คำแนะนำของ WordPress ให้เครดิต Kues เฉพาะในส่วนของความสับสนของเส้นทางแบบแบตช์ และไม่ได้กล่าวถึงโมเดล ไม่มีเอกสารใดอธิบายความทับซ้อนนี้ และไม่มีสิ่งใดที่บทความนี้ค้นพบจะคลี่คลายเรื่องนี้ได้ — ความเป็นไปได้ที่ทั้งสองจะเป็นการค้นพบช่องโหว่เดียวกันโดยแยกจากกันยังไม่ถูกตัดออก และความเป็นไปได้ที่รายงานหนึ่งเป็นการค้นพบซ้ำในภายหลังก็ยังไม่ได้รับการยืนยันเช่นกัน บันทึกไม่ได้ชี้ขาดเรื่องนี้ และบทความนี้ก็ไม่ได้ชี้ขาดเช่นกัน

ตัวเลขในพาดหัวของโพสต์วันที่ 20 กรกฎาคมของ Searchlight ไม่ได้รับการสนับสนุนจากเนื้อความในโพสต์เอง พาดหัวระบุว่า “นายหน้าค้าช่องโหว่จ่าย $500,000 สำหรับ WordPress RCE ฉันพบหนึ่งรายการด้วย GPT5.6 Sol Ultra และ $25” เนื้อความในโพสต์ระบุ $25 และสิบชั่วโมงไว้อย่างเจาะจง โดยไม่มีชื่อนายหน้า ไม่มีข้อเสนอ ไม่มีการติดต่อ และไม่มีแหล่งที่มาของตัวเลข $500,000 สำหรับชิ้นงานนี้ ไม่พบรายงานอิสระใดที่ยืนยันราคาที่จ่ายหรือที่เสนอสำหรับ wp2shell ควรตีความ $500,000 ว่าเป็นกรอบการนำเสนอของพาดหัว ไม่ใช่ราคาตลาดที่ยอมรับกันทั่วไป

ขอบเขตของรายการในคลังข้อมูลเองแคบกว่าเรื่องราวที่อยู่รอบ ๆ รายการนั้น บันทึกผลการวิจัยในวันเปิดเผยข้อมูล ไม่ได้ระบุถึงความเสียหายในโลกจริง และระบุวันที่เป็นวันเดียวคือ 17 กรกฎาคม 2026 นั่นไม่ใช่การอ้างว่าไม่มีอะไรเกิดขึ้นหลังจากนั้น มีรายงานทราฟฟิกการโจมตีภายในไม่กี่ชั่วโมงหลังประกาศคำเตือน และ CISA จัดทำแคตตาล็อก CVE ทั้งสองรายการในอีกสี่วันต่อมา การทำเครื่องหมายนี้ครอบคลุมสิ่งที่รายการอธิบายไว้ ซึ่งได้แก่การค้นพบและการเปิดเผยข้อมูลแบบประสานงาน ส่วนการโจมตีที่เกิดขึ้นหลังจากนั้นมีฝ่ายอื่นบันทึกไว้โดยอาศัยหลักฐานของ mereka เองด้านล่าง

การใช้ช่องโหว่หลังประกาศเตือน

Jake Knott นักวิจัยด้านความปลอดภัยหลักที่ watchTowr กล่าวกับ The Hacker News ว่า "ภายในช่วงเช้ามืดของวันเสาร์ (UTC) การโจมตีที่ประสบความสำเร็จได้ดำเนินไปอย่างเต็มที่แล้ว โดยเริ่มแรกใช้โค้ดเอ็กซ์พลอยต์ที่เปิดเผยต่อสาธารณะเพื่อขโมยข้อมูลรับรองที่ผ่านการแฮช จากนั้นจึงตามมาด้วยการรันโค้ดจากระยะไกลเมื่อมีการเปิดเผยรายละเอียดเพิ่มเติม" รายงานเดียวกันอ้างถึงข้อมูลโทรมาตรของ KEVIntel ที่เชื่อมโยงที่อยู่ IP ที่ไม่ซ้ำกัน 13 รายการ จากสวิตเซอร์แลนด์ เยอรมนี สหราชอาณาจักร อินโดนีเซีย ลิทัวเนีย เนเธอร์แลนด์ และสิงคโปร์ กับการโจมตีช่องโหว่ CVE-2026-63030 และอ้างคำกล่าวของ Ryan Dewhurst ผู้ก่อตั้ง KEVIntel ที่กล่าวว่าคำขอเหล่านั้นตรงกับ proof of concept ที่เปิดเผยต่อสาธารณะ และมีการใช้เพย์โหลดแบบ blind, UNION-based และ boolean-based ทั้งหมด

นักวิจัยของ Wiz ได้แก่ Shahar Dorfman และ Gili Tikochinski ซึ่งเผยแพร่ผลงานเมื่อวันที่ 20 กรกฎาคม ได้ประเมินขนาดของปัญหาไว้ดังนี้: 60% ขององค์กรที่ใช้ WordPress มีอินสแตนซ์ที่มีช่องโหว่อย่างน้อยหนึ่งรายการ ณ เวลาที่เผยแพร่ CVE และ 25% เปิดเซิร์ฟเวอร์ที่มีช่องโหว่ให้เข้าถึงได้จากอินเทอร์เน็ต โดยลดลงเหลือ 50% และ 10% ภายใน 24 ชั่วโมงเมื่อเริ่มมีการแพตช์ พวกเขาบันทึกการอัปโหลดปลั๊กอินที่เป็นอันตรายผ่านตัวติดตั้งในหน้าผู้ดูแลระบบ การแจกแจงผู้ใช้ผ่าน endpoint users ความพยายาม local file inclusion ต่อ wp-config และการเข้าถึงแผงผู้ดูแลระบบที่ตอบกลับ HTTP 200 — ซึ่งเป็นลักษณะบ่งชี้ของการเข้าสู่ระบบสำเร็จมากกว่าการหยั่งเชิง มัลแวร์ที่พวกเขาพบมีตั้งแต่ PHP backdoor แบบหนึ่งบรรทัดที่เรียบง่าย ไปจนถึง webshell ขนาด 150 KB ที่ปลอมตัวเป็นปลั๊กอินความปลอดภัย WordPress ที่ถูกต้องตามกฎหมายชื่อ CMSmap พร้อมโมดูลจัดการไฟล์ การเข้าถึงฐานข้อมูล การสแกนพอร์ต และการยกระดับสิทธิ์

Wiz ยังบันทึกข้อจำกัดเกี่ยวกับสิ่งที่สามารถสรุปได้ การสแกนปริมาณมากโดยไม่มีการใช้ประโยชน์หลังการบุกรุก (post-exploitation) เป็นสิ่งที่พบได้บ่อย ซึ่งสอดคล้องกับการสแกนจำนวนมากแบบฉวยโอกาสและการสแกนด้านความปลอดภัยที่ชอบด้วยกฎหมาย และบริษัทระบุว่ายังไม่พบการเคลื่อนที่ในแนวนอน (lateral movement) หรือการนำข้อมูลออก (data exfiltration) นั่นเป็นข้อความเกี่ยวกับสิ่งที่เทเลเมทรีของผู้ขายรายหนึ่งแสดงให้เห็น ไม่ใช่ข้อค้นพบว่าไม่มีข้อมูลใดถูกนำไป

อะไรเปลี่ยนแปลงไปหลังจากนั้น และอะไรที่ยังคงเปิดอยู่

สำหรับผู้ดูแลระบบ แนวทางตอบสนองนั้นสั้น การอัปเดตเป็น WordPress 7.0.2, WordPress 6.9.5 หรือ WordPress 6.8.6 คือวิธีแก้ไข ทางเลือกฉุกเฉินของ Searchlight สำหรับเว็บไซต์ที่ไม่สามารถอัปเดตได้ทันที คือการบล็อกการเข้าถึง batch API โดยไม่ระบุตัวตน — ไม่ว่าจะเป็นการติดตั้งปลั๊กอินที่บล็อกการเข้าถึง REST API โดยไม่ระบุตัวตนโดยสิ้นเชิง หรือโดยการบล็อก /wp-json/batch/v1 และ ?rest_route=/batch/v1 ที่ไฟร์วอลล์เว็บแอปพลิเคชัน บริษัทเตือนว่าทั้งสองวิธีอาจส่งผลกระทบต่อการใช้งานเว็บไซต์ตามปกติ และควรถือเป็นมาตรการชั่วคราวจนกว่าการอัปเดตจะออก เครื่องมือตรวจสอบสาธารณะที่ wp2shell.com ทดสอบอินสแตนซ์โดยตรง รายการในแคตตาล็อกของ CISA ได้เพิ่มกรอบเวลาการปฏิบัติตามข้อกำหนด: ต้องแก้ไขภายในวันที่ 24 กรกฎาคมสำหรับ CVE-2026-63030 และภายในวันที่ 4 สิงหาคมสำหรับ CVE-2026-60137

สำหรับคำถามวิจัย ส่วนที่ยังไม่ได้ข้อสรุปคือโมเดลมีส่วนสนับสนุนอะไรจริง ๆ เมื่อเทียบกับผู้ดำเนินการของมัน Kues พูดชัดเจนเกี่ยวกับการแบ่งงาน: โมเดลสร้างเชนขึ้นในเวลาประมาณสิบชั่วโมง และการทำความเข้าใจมันใช้เวลานานกว่าการสร้างมันเสียอีก เขาปฏิเสธที่จะกล่าวอ้างแบบทั่วไป และกล่าวเพียงว่าผลลัพธ์สิบชั่วโมงนั้นมนุษย์ไม่สามารถทำได้โดยลำพัง พรอมต์เองไม่ใช่ความลับ — มันมาจากพรอมต์ที่ OpenAI เผยแพร่ และ Searchlight ได้จำลองโครงสร้างของมันไว้ในรายงาน รวมถึงคำสั่งให้เพิกเฉยต่อประวัติเวอร์ชัน และข้อกำหนดที่ว่าเอ็กซ์พลอยต์ต้องทำงานได้ในการกำหนดค่าการผลิตทั่วไป การที่สูตรนั้นจะถ่ายทอดไปยังฐานโค้ดอื่นได้หรือไม่นั้นคือคำถามที่ Kues บอกว่าเขาจะไม่ตอบอย่างแท้จริง และยังไม่มีการเผยแพร่การรันครั้งที่สอง

สิ่งที่บันทึกไม่สามารถยืนยันได้จึงแคบแต่มีนัยสำคัญ นั่นคือฝ่ายใดในสองฝ่ายที่ได้รับเครดิตเป็นผู้พบการโจมตีแบบ injection ก่อน ว่ามีนายหน้าคนใดเคยจ่ายเงินตามตัวเลขในพาดหัวข่าวหรือไม่ และเว็บเชลล์ที่ Wiz สังเกตเห็นนั้นได้ขโมยอะไรไปจากเว็บไซต์ที่มันเข้าไปฝังตัวอยู่จริงหรือไม่ หากมีอะไรก็ตาม ในประเด็นสุดท้ายนี้ คำแถลงต่อสาธารณะมีเพียงของ Wiz ที่ระบุว่าไม่พบการเคลื่อนที่ในแนวนอนหรือการขโมยข้อมูลใด ๆ ซึ่งเป็นการปราศจากหลักฐานจากมุมมองเดียว และเสนอไว้ในฐานะเช่นนั้น