มีคนซื้อปลั๊กอิน WordPress 30 ตัว แล้วฝังแบ็กดอร์ไว้ในปลั๊กอินทั้งหมด

• ผู้โจมตีรายเดียวกันเข้าซื้อ ปลั๊กอิน WordPress มากกว่า 30 ตัว แล้ว แทรกโค้ดแบ็กดอร์ ตั้งแต่คอมมิตแรก ทำให้เกิดการโจมตีห่วงโซ่อุปทาน
• มัลแวร์ ซ่อนตัวนานราว 8 เดือน ก่อนจะเริ่มทำงานในช่วงต้นเดือนเมษายน 2026 และฉีด ลิงก์สแปมกับการรีไดเร็กต์ ลงในหลายเว็บไซต์
• WordPress.org ปิด 31 ปลั๊กอินที่เกี่ยวข้องแบบถาวร และปล่อย forced update ภายในวันเดียวเมื่อ 7 เมษายน 2026
• ผู้โจมตีเข้าซื้อพอร์ตโฟลิโอ ‘Essential Plugin’ บน Flippa ด้วยเงิน ระดับหกหลัก แล้วใช้ Ethereum smart contract เพื่อซ่อนโดเมน C2
• เหตุการณ์นี้เป็นการกลับมาของ การโจมตีห่วงโซ่อุปทานขนาดใหญ่ คล้ายกรณี ‘Display Widgets’ ปี 2017 และเผยให้เห็น การขาดกลไกจัดการความน่าเชื่อถือ ในระบบนิเวศปลั๊กอิน WordPress

---

กรณีการโจมตีห่วงโซ่อุปทานของปลั๊กอิน WordPress

• เกิดเหตุ ปลั๊กอิน WordPress มากกว่า 30 ตัวถูกผู้โจมตีรายเดียวกันเข้าซื้อกิจการแล้ว ฝังแบ็กดอร์
• ผู้โจมตีซื้อพอร์ตโฟลิโอ ‘Essential Plugin’ บน Flippa ด้วยเงิน ระดับหกหลัก แล้วเพิ่มโค้ดอันตรายตั้งแต่คอมมิตแรก
• แบ็กดอร์ซ่อนตัวแบบไม่ทำงานอยู่ 8 เดือน ก่อนจะถูกเปิดใช้งานในช่วงต้นเดือนเมษายน 2026 และแพร่เชื้อไปยังเว็บไซต์จำนวนมาก
• WordPress.org ปิด 31 ปลั๊กอินที่เกี่ยวข้องแบบถาวร ภายในวันเดียวเมื่อ 7 เมษายน 2026
• เหตุการณ์นี้ถูกมองว่าเป็น การเกิดซ้ำของรูปแบบการโจมตีห่วงโซ่อุปทาน คล้ายกรณี ‘Display Widgets’ ในปี 2017

การค้นพบการโจมตีและการตอบสนองระยะแรก

• การติดเชื้อครั้งแรกถูกยืนยันผ่าน คำเตือนด้านความปลอดภัยใน wp-admin ของเว็บไซต์ลูกค้ารายหนึ่ง
  • ทีมปลั๊กอินของ WordPress.org เตือนว่าปลั๊กอิน “Countdown Timer Ultimate” มี โค้ดที่เปิดให้เข้าถึงโดยไม่ได้รับอนุญาต
  • WordPress.org ปล่อย forced update (v2.6.9.1) แต่บางเว็บไซต์ก็ถูกเจาะไปแล้ว
• จากการตรวจสอบด้านความปลอดภัยพบว่าโมดูล wpos-analytics ของปลั๊กอินเชื่อมต่อไปยัง analytics.essentialplugin.com เพื่อดาวน์โหลดไฟล์ wp-comments-posts.php และจากนั้นจึงเกิดการ ฉีดโค้ด PHP จำนวนมากเข้าไปใน wp-config.php

วิธีการทำงานของมัลแวร์

• โค้ดที่ถูกฉีดจะดึง ลิงก์สแปม การรีไดเร็กต์ และหน้าเว็บปลอม จากเซิร์ฟเวอร์ C2 แล้วแสดงเฉพาะกับ Googlebot
• ผู้โจมตีใช้ Ethereum smart contract ในการจัดการโดเมน C2 แบบไดนามิก
  • เนื่องจากโดเมนถูกดึงผ่าน blockchain RPC endpoint จึงไม่สามารถบล็อกได้ด้วยการบล็อกโดเมนทั่วไป
• forced update ของ WordPress.org หยุดได้เพียงฟังก์ชัน phone-home ของปลั๊กอินเท่านั้น ส่วน โค้ดอันตรายใน wp-config.php ยังอยู่ครบ

การไล่หาช่วงเวลาติดเชื้อผ่านการวิเคราะห์แบ็กอัป

• ใช้ restic backup ของ CaptainCore เพื่อเปรียบเทียบขนาดไฟล์ wp-config.php จำนวน 8 ช่วงเวลา
  • ระหว่าง 6 เมษายน 2026 เวลา 04:22~11:06 UTC ขนาดไฟล์เพิ่มจาก 3,345 ไบต์เป็น 9,540 ไบต์
  • ยืนยันได้ว่าการติดเชื้อเกิดขึ้นภายในช่วง 6 ชั่วโมง 44 นาทีนี้

ช่วงเวลาที่ฝังแบ็กดอร์และโครงสร้างโค้ด

• ในปลั๊กอินเวอร์ชัน 2.6.7 (8 สิงหาคม 2025) มีการเพิ่ม โค้ดใหม่ 191 บรรทัด และเป็นจุดที่ฝังแบ็กดอร์
  • ใน changelog ระบุไว้ว่า “WordPress 6.8.2 compatibility checked”
• ความสามารถหลักของโค้ดที่ถูกเพิ่มเข้ามา
  1. fetch_ver_info() ประมวลผลข้อมูลจากเซิร์ฟเวอร์ผู้โจมตีด้วย @unserialize()
  2. version_info_clean() เรียกใช้ชื่อฟังก์ชันที่ได้รับมาจากข้อมูลระยะไกล
  3. สร้าง REST API endpoint ที่เรียกใช้ได้โดยไม่ต้องยืนยันตัวตน (permission_callback: __return_true)
• โครงสร้างนี้เปิดทางให้เกิด การรันฟังก์ชันตามอำเภอใจ (RCE) และซ่อนตัวแบบไม่ทำงานอยู่นาน 8 เดือน ก่อนถูกเปิดใช้งานในวันที่ 5~6 เมษายน 2026

กระบวนการเข้าซื้อปลั๊กอิน

• ทีมพัฒนาเดิมคือ WP Online Support จากอินเดีย ซึ่งพัฒนาปลั๊กอินมาตั้งแต่ปี 2015
  • ต่อมารีแบรนด์เป็น Essential Plugin และดูแลปลั๊กอินฟรีและเสียเงินมากกว่า 30 ตัว
• เมื่อปลายปี 2024 รายได้ลดลง 35~45% จึงนำธุรกิจทั้งหมดไปลงขายบน Flippa
• ต้นปี 2025 บุคคลชื่อ ‘Kris’ ซึ่งมีประวัติด้าน SEO, คริปโต และการตลาดพนันออนไลน์ เข้าซื้อกิจการ
  • Flippa นำดีลนี้ไปลงบล็อกในเดือนกรกฎาคม 2025 ในฐานะ กรณีความสำเร็จ
• หลังการเข้าซื้อ SVN คอมมิตแรก (8 สิงหาคม 2025) ก็มีการเพิ่มโค้ดแบ็กดอร์ทันที
• วันที่ 5~6 เมษายน 2026 analytics.essentialplugin.com เริ่มแจกจ่ายเพย์โหลดอันตรายไปยังทุกเว็บไซต์
• วันที่ 7 เมษายน 2026 WordPress.org ปิดปลั๊กอินทั้งหมดของ Essential Plugin (31 ตัว) แบบถาวร

รายชื่อปลั๊กอินที่ถูกปิด

• Accordion and Accordion Slider, Countdown Timer Ultimate, Popup Anything on Click, WP Blog and Widgets, WP Team Showcase and Slider และปลั๊กอินอื่น ๆ มากกว่า 30 ตัว
• เมื่อค้นหาผู้เขียนดังกล่าวบน WordPress.org จะไม่พบผลลัพธ์
• ตอนนี้ analytics.essentialplugin.com ตอบกลับด้วย {"message":"closed"}

กรณีคล้ายกันในอดีต

• ปี 2017 บุคคลชื่อ ‘Daley Tias’ ซื้อปลั๊กอิน Display Widgets (ติดตั้ง 200,000 ครั้ง) ในราคา $15,000 แล้วแทรกโค้ดสแปม
• หลังจากนั้นยังทำให้ปลั๊กอินอีกมากกว่า 9 ตัวติดเชื้อด้วยวิธีเดียวกัน
• เหตุการณ์ครั้งนี้ยืนยันว่ามีการใช้วิธีเดิมซ้ำใน สเกลที่ใหญ่กว่าเดิม (มากกว่า 30 ตัว)

การกู้คืนความเสียหายและงานแพตช์

• forced update ของ WordPress.org เป็นเพียงมาตรการชั่วคราว
  • โมดูล wpos-analytics เองยังคงอยู่
• มีการสร้าง แพตช์เวอร์ชันที่ลบโมดูลแบ็กดอร์ออกทั้งหมด ด้วยตนเอง
  • จากเว็บไซต์ลูกค้า 22 แห่ง พบปลั๊กอินของ Essential Plugin ใน 12 แห่ง และแพตช์เอง 10 แห่ง
  • เวอร์ชันแพตช์ลบไดเรกทอรี wpos-analytics, เอาฟังก์ชันตัวโหลดออก และเติม -patched ในชื่อเวอร์ชัน
• ตัวอย่างเช่น Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget เป็นต้น

วิธีแพตช์ด้วยตนเอง

• ลบไดเรกทอรี wpos-analytics/
• ลบบล็อก “Plugin Wpos Analytics Data Starts” หรือบล็อก wpos_analytics_anl ออกจากไฟล์ปลั๊กอินหลัก
• เติม -patched ในเฮดเดอร์ Version: แล้วบีบอัดใหม่
• ติดตั้งด้วย wp plugin install your-plugin-patched.zip --force
• หากขนาดไฟล์ wp-config.php เพิ่มขึ้นราว 6KB ให้ถือว่าอยู่ใน สถานะติดเชื้อแบบ active และต้องกู้คืนทั้งระบบ

ปัญหาความน่าเชื่อถือของระบบนิเวศปลั๊กอิน WordPress

• ในช่วง 2 สัปดาห์ที่ผ่านมาเกิด การโจมตีห่วงโซ่อุปทานต่อเนื่อง
  • เข้าซื้อปลั๊กอินที่ผู้ใช้เชื่อถือแล้วแทรกโค้ดอันตราย
  • รับช่วงสิทธิ์ commit บน WordPress.org ต่อทันทีและปล่อยอัปเดตได้โดยไม่ต้องผ่านการตรวจสอบ
• WordPress.org ไม่มี กระบวนการเฝ้าระวังการเปลี่ยนเจ้าของหรือทบทวนโค้ดใหม่
  • เมื่อมี committer ใหม่เข้ามา ไม่มีทั้งการแจ้งเตือนผู้ใช้และระบบรีวิวอัตโนมัติ
• แม้ทีมปลั๊กอินจะตอบสนองได้รวดเร็ว แต่ก็ ไม่สามารถตรวจพบการฝังแบ็กดอร์ได้นานถึง 8 เดือน
• ผู้ดูแลเว็บไซต์ WordPress ควรตรวจสอบรายการปลั๊กอินของตน และ ลบหรือแพตช์ปลั๊กอินตระกูล Essential Plugin ทันที พร้อมตรวจสอบไฟล์ wp-config.php ด้วย

[tebica]

ใช้ WordPress มาหลายสิบปีแล้ว..
แม้จะใช้แค่ปลั๊กอินเท่าที่จำเป็นจริง ๆ แต่ก็ยังกังวลอยู่เสมอ
ถึงอย่างนั้นมันก็ยังสะดวกกว่าแบบสแตติกอยู่ดี เลยยังไม่อยากย้ายไปไหน!

[turastory]

ช่วงนี้มีข่าวเกี่ยวกับการโจมตีแบบ supply chain เยอะจริง ๆ นะ ฮือ

[tangokorea]

ก็ประมาณนั้นแหละ มีเพิ่มขึ้นอย่างรวดเร็วมาก

[xguru]

WordPress นี่มีปัญหาออกมาเรื่อย ๆ จริง ๆ ครับ ถ้าใช้งานอยู่แล้วลองดูโพสต์ที่เกี่ยวข้องและอ้างอิงอย่าง EmDash ดูนะครับ
ผมเลิกใช้ไปแล้วและย้ายไปเป็นหน้าเว็บแบบสแตติกแทนเรียบร้อยแล้ว

[colus001]

ลองติดตั้ง EmDash แล้ว แต่ตอนนี้ช้ามาก ค่า TTFB ขั้นต่ำก็ออกมาราว ๆ 3 วินาที เลยทำให้นึกว่าเขาสร้างสิ่งนี้มาให้ใช้งานจริงหรือเปล่า

[xguru]

อ้อ เข้าใจแล้วครับ งั้นผมขอพอใจกับแบบสแตติกก็แล้วกัน 555

[tangokorea]

ดูเหมือนว่าสิ่งนี้ทำให้เราคิดได้ว่า AI สำหรับจัดการหน้าเว็บแบบสแตติกอาจเข้ามาแทนที่ CMS ที่ถูกปกคลุมไปด้วยโค้ดเลกาซีได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ปฏิกิริยาที่เวอร์เกินจริงต่อ Mythos นี่ชวนขำเสมอ
  เทคโนโลยี การตรวจจับช่องโหว่อัตโนมัติ อาจสั่นคลอนวงการความปลอดภัยได้ก็จริง แต่สิ่งที่ควรกังวลจริงๆ ไม่ใช่นั่น
  สแตกเทคโนโลยีและธรรมาภิบาลองค์กรในตอนนี้ล้าหลังยุคไปแล้ว
  ถ้าจะชี้ตัวการที่ทำให้สถานการณ์แย่ลง คริปโตเคอร์เรนซี คือคำตอบ มันทำให้การแฮ็กกลายเป็นอุตสาหกรรมมูลค่าหลายพันล้านดอลลาร์ และดึงแม้แต่รัฐอย่างเกาหลีเหนือเข้ามาด้วย
  ตอนนี้มันเป็นโลกที่แค่ซื้อ dependency หรือจ่ายเงินให้พนักงานเพื่อชักจูงให้ “ทำพลาด” ก็ได้แล้ว
  เราสามารถเขียนซอฟต์แวร์ที่แทบไม่มีบั๊กได้ แต่ไม่มี แผนการ ที่จะทำให้องค์กรขนาดใหญ่ปลอดภัยในสภาพแวดล้อมแบบนี้
  เอเจนต์ LLM แบบอัตโนมัติคงถูกใช้โดยแก๊งแรนซัมแวร์ แต่ไม่จำเป็นต้องใช้ FreeBSD exploit

  • ผมสงสัยกับคำพูดที่ว่า “เราสามารถใช้ซอฟต์แวร์ที่แทบไม่มีบั๊กได้”
    ในความเป็นจริง ทุกสัปดาห์ก็ยังเจอบั๊กใน PrimeVue, Vue, Spring Boot, Oracle driver, Ansible, Nvidia driver และอื่นๆ
    ในทางปฏิบัติ โค้ดที่ไร้ข้อผิดพลาดจริงๆ น่าจะเป็นไปได้แค่ในเครื่องบินหรือยานอวกาศระดับนั้น
    นักพัฒนาส่วนใหญ่ไม่ได้ไม่อยากเขียนโค้ดไร้บั๊ก แต่บ่อยครั้งมันเป็นไปไม่ได้เพราะ ข้อจำกัดของสภาพแวดล้อม
  • อย่างกรณีของ LAPSUS$ ก็มีแก๊งแฮ็กที่ได้สิทธิ์เข้าถึงภายในเพียงแค่ติดสินบนพนักงาน
    เรื่องแบบนี้ไม่ใช่ทฤษฎี แต่เป็นความจริง และถ้าเป็นระดับรัฐที่มีเงินทุน การซื้อคนในก็ยิ่งง่ายกว่าเดิมมาก
  • ผมมองว่านี่เป็นปัญหาเรื่อง วัฒนธรรมองค์กร มากกว่าเรื่องเทคโนโลยี
    โปรเจ็กต์ OSS มี “WTF bug” น้อยกว่าซอฟต์แวร์องค์กรขนาดใหญ่อีก
    ในสภาพแวดล้อมที่พัฒนาคนเดียว คงไม่ทำพลาดแบบที่องค์กรกลับปล่อยขึ้น production เพราะขั้นตอนอนุมัติหรือธรรมเนียมปฏิบัติ
    วัฒนธรรมที่ผิดเพี้ยนซึ่งทำให้ตั้งคำถามว่า “นี่ดีที่สุดแล้วหรือ?” ไม่ได้ คือแหล่งผลิตบั๊กชั้นดี
    ทีมเล็กแก้ได้ง่าย แต่ในองค์กรใหญ่ต้นทุนสูง
  • ถ้าผู้โจมตีสามารถอัปเดตโดเมน C2 ผ่าน Ethereum smart contract ได้ ก็สงสัยว่าไฟร์วอลล์ควรบล็อกทุก Ethereum endpoint เลยหรือไม่
  • อย่างที่ บทความของ The Register บอก การที่ผู้โจมตีมองซัพพลายเชนเป็นเป้าหมายแบบ วิเคราะห์ต้นทุน-ความเสี่ยง ถือเป็นกลยุทธ์ที่สมเหตุสมผล

• เวลาดูโปรเจ็กต์เว็บ มักเริ่มด้วย “npm install” เสมอ แล้วก็มีไลบรารีนับสิบถูกติดตั้งอัตโนมัติ
  บ่อยครั้งแม้แต่คนเขียนเองก็ไม่รู้ว่ามี dependency แบบ transitive อะไรถูกรวมเข้ามาบ้าง
  โครงสร้างแบบนี้แทบไม่มีทางตรวจสอบการโจมตีซัพพลายเชนได้เลย

  • ด้วยเหตุนี้ผมจึงหลีกเลี่ยงแพ็กเกจภายนอกให้มากที่สุด
    ไม่นานมานี้ผมเขียน เครื่องมือซิงก์สภาพอากาศ โดยใช้แค่ Python standard library
    ไม่ต้องใช้แพ็กเกจภายนอกอย่าง requests ก็เพียงพอ และได้ ความสบายใจจากการไม่มี dependency
  • แม้จะมีคำพูดว่า “อย่าสร้างล้อขึ้นใหม่” แต่เราก็ต้องมี จุดกึ่งกลางที่เหมาะสม
    โลจิกสำคัญอย่างการเข้ารหัสไม่ควรเขียนเอง แต่การพึ่งไลบรารีแม้แต่กับฟังก์ชันง่ายๆ ก็เกินไป
  • นี่ไม่ใช่ปัญหาของเว็บอย่างเดียว แต่เป็นปัญหาร่วมของทุก ecosystem ไม่ว่าจะ maven, Python, Ruby ฯลฯ
  • Lockfile ช่วยได้มากกว่าที่คิด
    ถ้าตรึงเวอร์ชันไว้ ต่อให้แพ็กเกจถูกขายต่อแล้วฝัง backdoor ก็จะยังไม่กระทบจนกว่าจะอัปเดตเอง
    กลับกัน สิ่งที่น่ากลัวยิ่งกว่าคือ Dependabot ที่ส่ง PR “patch version” อัตโนมัติแล้วก่อความเสี่ยง
  • ที่แย่กว่านั้นคือพฤติกรรมแบบ sudo curl URL | bash

• ผมคิดว่าตัว อุดมการณ์เรื่องการอัปเดตซอฟต์แวร์ เองต่างหากที่เป็นปัญหา
  การอัปเดตมีข้อดีคือแพตช์ความปลอดภัย แต่ในขณะเดียวกันก็เสี่ยงที่จะบังคับการเปลี่ยนแปลงที่นักพัฒนาไม่ต้องการ หรือแม้แต่กลายเป็นอันตรายโดยเจตนา
  โดยเฉพาะ ส่วนขยาย WordPress จากนักพัฒนาเดี่ยว ผมมองว่าไม่ควรเปิดให้อัปเดตอัตโนมัติเด็ดขาด
  marketplace ของ wordpress.org ไม่รองรับโครงสร้างแบบนี้ จึงยิ่งเสี่ยง
  ก่อนหน้านี้ผมเคยเขียน คอมเมนต์เกี่ยวกับส่วนขยาย Chrome ไว้ และถ้าเปลี่ยนจาก Chrome เป็น WordPress ก็ยังใช้ได้เหมือนเดิม

• พื้นที่โจมตีซัพพลายเชนของ ปลั๊กอิน WordPress เป็นเรื่องอันตรายมานานแล้ว
  เพราะเป็น ecosystem ที่กระตุ้นให้ติดตั้งปลั๊กอินจำนวนมากจากนักพัฒนาเดี่ยวรายเล็ก
  การ ซื้อกิจการแล้วนำไปใช้ในทางที่ผิด กับปลั๊กอินที่ได้รับความเชื่อถืออยู่แล้ว เป็นวิธีโจมตีที่มีประสิทธิภาพมาก
  เพราะ “การแจ้งเตือนให้อัปเดต” ทำหน้าที่เป็นสัญญาณความน่าเชื่อถือ ผู้ใช้จึงไม่รู้ด้วยซ้ำว่าผู้เขียนเปลี่ยนไปแล้ว
  จำเป็นต้องมี ระบบลายเซ็นแพ็กเกจและความโปร่งใส แต่ WordPress ปรับปรุงโครงสร้างพื้นฐานด้านความปลอดภัยช้ามาก

  • ผู้ใช้ส่วนใหญ่ต้องการใช้แต่ปลั๊กอินฟรี ทำให้เว็บไซต์เต็มไปด้วย ปลั๊กอินพรีเมียม+โฆษณา
    หน้าแอดมินดูเหมือน มีม toolbar ของ IE6 เลยทีเดียว
  • นี่ก็เป็นเหตุผลว่าทำไมผมถึงเลิกทำเว็บไซต์ WordPress ให้ลูกค้า
    หลายคนติดตั้ง Securi หรือ Wordfence เวอร์ชันฟรีไว้เฉยๆ โดยไม่ตั้งค่าอะไร แต่กลับคาดหวังว่าจะปลอดภัยสมบูรณ์
  • wp.org ใจดีกับผู้ไม่หวังดีมากเกินไป
    มัลแวร์โจ่งแจ้งอาจถูกบล็อก แต่พฤติกรรม bait-and-switch อย่างการแทรกวิดเจ็ตโฆษณาจากโดเมนบุคคลที่สามกลับถูกปล่อยผ่าน
    ถ้าระดับนี้แล้วก็คงแทบต้องมองว่าเป็น การออกแบบโดยเจตนา

• น่าเสียดายที่โปรเจ็กต์ FAIR package manager ไม่ประสบความสำเร็จ
  fair.pm เป็นโครงสร้างแบบกระจายศูนย์ที่ได้แรงบันดาลใจจาก atproto ซึ่งใครก็รันได้โดยไม่ต้องมีคลังกลาง
  แพ็กเกจถูกระบุด้วย DID และองค์กรอย่าง Socket สามารถแนบผลการวิเคราะห์ในฐานะ “labeler” ได้
  ผู้ใช้สามารถบล็อกแพ็กเกจที่มี label บางอย่าง หรือแม้แต่รัน labeler วิเคราะห์ความปลอดภัยด้วย AI เองก็ได้
  มันอาจไม่สมบูรณ์แบบ แต่เป็นแนวทางที่ดีกว่า package manager แบบรวมศูนย์มาก

  • ไม่ได้ล้มเลิก แต่ เปลี่ยนไปเน้นเทคโนโลยี
    ตอนนี้กำลังร่วมมือกับ ชุมชน Typo3 และขยายไปยัง ecosystem อื่นด้วย (ผู้เขียนเป็น co-chair ของ FAIR)
  • มันอาจเป็นแพลตฟอร์มทางเลือกที่น่าสนใจแทน npm
    โครงสร้าง แรงจูงใจ ดีกว่า WordPress แต่ก็อาจยังไม่เพียงพออยู่ดี
  • ถ้ามีโอกาสสูงที่คลังจำนวนมากจะเต็มไปด้วย โค้ดอันตรายเพื่อทำ SEO การหาคลังที่ปลอดภัยด้วย search engine อย่างเดียวก็คงเป็นไปไม่ได้
    การกระจายศูนย์ให้เสรีภาพก็จริง แต่จาก มุมมองของผู้ใช้แล้วใช้งานลำบาก มาก
  • สงสัยว่า FAIR เจาะจงสำหรับ WordPress อย่างเดียวหรือเปล่า

• จุดที่น่าสนใจของเหตุการณ์นี้คือปลั๊กอินถูกซื้อผ่าน Flippa
  Flippa ไม่ใช่ marketplace เฉพาะ WP แต่เป็นตลาดซื้อขายซอฟต์แวร์ทั่วไป
  เลยน่ากังวลว่า แอปหรือส่วนขยายอินดี้ ที่ถูกซื้อไปด้วยเจตนาดี อาจภายหลังถูกเปลี่ยนให้กลายเป็นอาวุธได้
  เพราะสำหรับผู้โจมตี แอปพวกนี้ มีมูลค่ามากกว่าสำหรับผู้ไม่หวังดี เสียอีก

• สิ่งที่น่ากลัวที่สุดไม่ใช่ตัว backdoor เอง แต่คือการซื้อกิจการนั้น ดูปกติมากเกินไป
  การซื้อปลั๊กอินที่น่าเชื่อถือแล้ว push อัปเดตออกไป แทบแยกไม่ออกจากการบำรุงรักษาอย่างถูกต้องตามกฎหมาย
  ผู้ใช้ ไม่มีสัญญาณให้สงสัยเลยแม้แต่นิดเดียว

• การควบรวมและซื้อกิจการ (M&A) ที่จำกัดการแข่งขันในตลาดยังต้องได้รับการอนุมัติจากรัฐ
  ถ้าอย่างนั้นการซื้อกิจการที่มีผลกระทบต่อความปลอดภัยอย่างมีนัยสำคัญ ก็น่าจะต้องมี ขั้นตอนอนุมัติจาก marketplace หรือภาครัฐ เช่นกันหรือไม่
  ดู บทความวิกิเรื่อง Mergers and acquisitions

• WordPress เคยยอดเยี่ยมเพราะปลั๊กอิน แต่ตอนนี้กลับกลายเป็น ecosystem ที่อันตราย เพราะโครงสร้างปลั๊กอินนี่เอง
  ผมย้ายไปใช้ Hugo แล้ว และแนะนำให้คนอื่นดู คู่มือการย้าย นี้ด้วย

• ดูเหมือนว่าบริษัทต่างๆ จะยังไม่ตระหนักจริงๆ ว่าพวกเขาสูญเสีย อำนาจควบคุม ไปมากแค่ไหนจากการ “เอาต์ซอร์ส IT”