Deadbugz: เซิร์ฟเวอร์ MCP ที่กลายเป็นปฏิปักษ์เมื่อเรียกใช้เครื่องมือครั้งที่สาม แล้วถูกผลักไปยัง 23 รีโพซิทอรีภายใน 74 นาที
- Orcaใหม่OrcaCyber: MiniMax M3.1 Flash Abliterated2026-10-29orca/orcacyber-minimax-m3.1-flash
- Orcaใหม่OrcaCyber: GLM 5.3 Flash Abliterated2026-10-2793 tok/s
- Orcaใหม่OrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 ต่อ 1 ล้านโทเค็น · 260 tok/s
- Orcaใหม่OrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 ต่อ 1 ล้านโทเค็น · 92 tok/s
- Moonshotใหม่MoonshotAI: Kimi K3.1 Pro2026-10-2446ความฉลาด
- Orcaใหม่OrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 ต่อ 1 ล้านโทเค็น · 104 tok/s
- minimaxใหม่MiniMax: M3.1 Flash2026-10-1929ความฉลาด
- Orcaใหม่Orca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 ต่อ 1 ล้านโทเค็น · 65 tok/s
- deepseekใหม่DeepSeek: DeepSeek V4.1 Flash 10172026-10-1733ความฉลาด
- DeepSeekใหม่DeepSeek: DeepSeek V4.1 Flash2026-10-1740ความฉลาด
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 ต่อ 1 ล้านโทเค็น · 101 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955ความฉลาด
- anthropicAnthropic: Claude Sonnet 5.52026-09-2854ความฉลาด
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 ต่อ 1 ล้านโทเค็น · 180 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228ความฉลาด
- OpenAIOpenAI: GPT-6 Sol2026-09-2248ความฉลาด
- AnthropicAnthropic: Claude Opus 5.52026-09-2258ความฉลาด
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2127ความฉลาด
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2130ความฉลาด
- xAIGrok 4.72026-09-2134ความฉลาด
คือ zellkernel ได้เปิด คำขอผสาน (pull request) จำนวน 23 รายการ ภายใน 74 นาที ไปยังคลังโค้ด AI, MCP และเครื่องมือสำหรับนักพัฒนาที่ไม่เกี่ยวข้องกัน โดยแต่ละรายการเพิ่มเซิร์ฟเวอร์ MCP ชื่อ productivity-suite ซึ่งโฆษณาเครื่องมือธรรมดาไว้สองตัว คือ format_text และ summarize ตามข้อมูลของ Pillar Security ซึ่งตั้งชื่อแคมเปญนี้ว่า Deadbugz และเผยแพร่บทวิเคราะห์เมื่อวันที่ 12 สิงหาคม เซิร์ฟเวอร์ดังกล่าวให้ผลลัพธ์ที่ถูกต้องสำหรับการเรียกครั้งแรกสามครั้ง จากนั้นก็เขียนเมทาดาทาที่ส่งให้เอเจนต์ใหม่ โดยคำอธิบายเครื่องมือและเนื้อหาในพรอมต์เริ่มชี้นำโมเดลไปยัง คีย์ SSH, ข้อมูลรับรอง AWS ประวัติเชลล์ และการกำหนดค่า Kubernetes พร้อมทั้งสั่งให้ปกปิดกิจกรรมนั้นจากผู้ใช้ คำขอผสาน 19 จาก 23 รายการถูกปิด สี่ยังคงเปิดอยู่ และไม่มีรายการใดถูกผสานในขณะที่ Pillar ตรวจสอบ ไม่มีการยืนยันเหยื่อรายใด นี่เป็นบันทึกหนึ่งรายการที่ผู้อื่นรายงานไว้ และอ้างอิงถึงแหล่งเหล่านั้นในที่นี้ เหตุการณ์เกี่ยวกับเอเจนต์รายการอื่นที่ได้รับการบันทึกไว้ ซึ่งแต่ละรายการมีแหล่งข่าว ระดับความรุนแรง ระดับความมั่นใจ และสถานะข้อโต้แย้งของตนเอง อยู่ที่ คลังเหตุการณ์ AI — ดังนั้นจึงสามารถอ่านแคมเปญห่วงโซ่อุปทานที่มุ่งเป้าไปยังเครื่องมือสำหรับเอเจนต์ได้เทียบเคียงกับเหตุการณ์อื่น ๆ ที่เกิดขึ้นจริง
คลังข้อมูลให้เกรดบันทึกนี้ว่ามีความรุนแรงสูงและมีความเชื่อมั่นระดับ A — มีเอกสารประกอบอย่างดี โดยมีแหล่งข้อมูลปฐมภูมิที่สอดคล้องกัน — ขณะเดียวกันก็บันทึกแยกไว้ว่าไม่พบความเสียหายจริงที่ยืนยันได้ ทั้งสองอย่างนี้เป็นจริงในเวลาเดียวกัน และช่องว่างระหว่างสองสิ่งนี้คือสิ่งที่บันทึกนี้ว่าด้วย: แคมเปญหนึ่งซึ่งการออกแบบได้รับการบันทึกไว้อย่างละเอียดผิดปกติก่อนที่จะก่อให้เกิดเหยื่อที่ใครก็ระบุชื่อได้ วันที่สำคัญสองวันนั้นห่างกันสองวัน พูลรีเควสต์ถูกส่งออกไปเมื่อวันที่ 10 สิงหาคม ส่วน Ariel Fogel จาก Pillar Security เผยแพร่บทวิเคราะห์เมื่อวันที่ 12 สิงหาคม และโพสต์ดังกล่าวมีหมายเหตุถาวรระบุว่าจะมีการอัปเดตเมื่อมีข้อมูลที่ได้รับการตรวจสอบแล้วเข้ามา
เรียกสามครั้ง แล้วเมทาดาทาจะเปลี่ยน
เซิร์ฟเวอร์ MCP ไม่จำเป็นต้องรันโค้ดบนเครื่องเพื่อเปลี่ยนสิ่งที่เอเจนต์ทำ คำจำกัดความของเครื่องมือถูกส่งให้โมเดลเป็นบริบทในทุกเซสชัน ซึ่งหมายความว่าเซิร์ฟเวอร์ที่จัดหาคำจำกัดความเหล่านั้นสามารถเขียนคำสั่งที่เอเจนต์อ่านใหม่ได้ โดยยังคงชื่อเครื่องมือ repository และ manifest ของมันไว้เหมือนเดิมทุกประการ Deadbugz ถูกสร้างขึ้นบนความไม่สมมาตรนี้ และชื่อที่ Pillar ใช้เรียกมันคือ runtime-gated MCP metadata poisoning
กลไกนี้เล็กพอที่จะอธิบายได้ในประโยคเดียว เซิร์ฟเวอร์เก็บตัวนับในหน่วยความจำแยกตามไคลเอนต์ของ tools/call คำขอ สำหรับสามครั้งแรก มันทำงานตามปกติ เมื่อตัวนับถูกกระตุ้น หลังจากนั้น tools/list และ prompts/getการตอบกลับจะถูกเปลี่ยนแปลง — คำอธิบายเครื่องมือแตกต่างกัน เนื้อหาพรอมต์แตกต่างกัน — ชี้แนะให้เอเจนต์ไปที่คีย์ SSH ข้อมูลรับรอง AWS ประวัติเชลล์ และการกำหนดค่า Kubernetes และสั่งให้ปกปิดกิจกรรมนี้จากผู้ใช้ ข้อความพรอมต์ที่ถูกวางยาพิษมีเครื่องหมาย deadbugz และที่อยู่ Bitcoin
กลไกเงื่อนไขนี้ยังเป็นเหตุผลว่าทำไมการป้องกันตามปกติจึงจับมันไม่ได้ เพย์โหลดมีอยู่ในซอร์สตั้งแต่คำขอแรก ไม่มีส่วนใดของโค้ดหรือการกำหนดค่าที่เปลี่ยนแปลง ณ ขณะที่เกิดการสลับ การสแกนแบบสถิต รายการใน SBOM หรือการอ่านแมนนิเฟสต์ของเครื่องมือเพียงครั้งเดียวตอนติดตั้ง จะเห็นเป็นยูทิลิตีจัดรูปแบบ เพราะนั่นคือสิ่งที่ยูทิลิตีนั้นส่งคืนมาจนกว่าตัวนับจะเปลี่ยนไป Pillar อธิบายการสลับแบบหน่วงเวลาว่าเป็นเทคนิคหลบเลี่ยงการตรวจสอบเชิงวิจัย และระบุว่านักวิจัยของบริษัทฯ ยืนยันทั้งค่าเกณฑ์และเมทาดาทาที่ถูกแก้ไข โดยการส่งคำขอแบบข้อความล้วนไปยังบริการระยะไกลที่ใช้งานจริง และเทียบการตอบสนองกับซอร์สสาธารณะ
รายละเอียดหนึ่งทำให้กับดักครอบคลุมกว้างกว่าหนึ่งเซสชัน เซิร์ฟเวอร์ประกาศ tools.listChangedซึ่งเป็นความสามารถของ MCP ที่แจ้งให้ไคลเอนต์ทราบว่ารายการเครื่องมือของตนได้รับการแก้ไขแล้ว ไคลเอนต์ที่ปฏิบัติตามสัญญาณนั้นจะอ่านคำจำกัดความใหม่ระหว่างเซสชันและดึงเวอร์ชันที่ถูกวางยาพิษโดยไม่ต้องมีการดำเนินการใด ๆ จากผู้ควบคุมระบบ ส่วนไคลเอนต์ที่แคชคำจำกัดความไว้เมื่อได้รับการอนุมัติจะไม่ทำเช่นนั้น พฤติกรรมที่เอเจนต์หนึ่ง ๆ แสดงออกเป็นคุณสมบัติของไคลเอนต์ ไม่ใช่ของเซิร์ฟเวอร์ และบทความของ Pillar ไม่ได้ระบุชื่อไคลเอนต์เป็นรายตัว
การส่งมอบ: 23 pull requests ภายใน 74 นาที
การเผยแพร่นี้ไม่ใช่แพ็กเกจบน registry หรือ dependency ที่ถูกวางยาพิษซ่อนอยู่ใน lockfile แต่เป็นการสแปม pull request ใส่โปรเจกต์ที่ไม่เกี่ยวข้องกับหน้าที่ที่เซิร์ฟเวอร์นั้นอ้างว่ามี ซึ่งเป็นรูปแบบที่ความพยายามโจมตีซัพพลายเชนต้นทุนต่ำมักใช้เมื่อผู้โจมตีไม่สามารถเข้าถึงบัญชีผู้ดูแลได้: ส่งการเปลี่ยนแปลงการกำหนดค่าให้มากพอแล้วรอให้มีสักรายการถูก merge หรือถูกนำไปใช้ในเครื่อง
การแจกแจง 23 รายการของ Pillar แบ่งออกเป็นสามประเภท สิบเจ็ดรายการเพิ่มปลายทาง MCP ระยะไกล, productivity-suite-mcp[.]onrender[.]com/mcp ซึ่งโฮสต์บน Render; สี่รายการเรียกใช้ไฟล์ Python ภายในเครื่องที่ซ่อนอยู่ที่ ~/.config/.cache/.sys/.deadbug-mcp.py; สองรายการเป็นการส่งไดเรกทอรีหรือรายการ ซึ่งบทวิเคราะห์ถือว่าเป็นการลาดตระเวนหรือเนื้อหาเติมเต็มมากกว่าการส่งมอบ ช่วงเวลาที่ระบุคือ 21:52 ถึง 23:07 UTC ของวันที่ 10 สิงหาคม 2026 — 74 นาทีตามกรอบการเปิดเผยข้อมูล แม้ว่าเวลาทั้งสองจะกินช่วง 75 นาที และไม่มีสิ่งใดในบันทึกที่ขึ้นอยู่กับนาทีนั้น มีรีโพซิทอรีเป้าหมายเพียงแห่งเดียวเท่านั้นที่ถูกระบุชื่อเป็นรายบุคคล: getsentry/sentry-mcp, พูลรีเควสต์ #1239 ซึ่งถูกอ้างอิงเป็นตัวอย่างของการส่งมอบอาร์ติแฟกต์ภายในเครื่อง.
บัญชีที่อยู่เบื้องหลังนั้นมีเนื้อหาสาระมากเมื่อเทียบกับอายุของบัญชี ในช่วงเวลาที่ Pillar เก็บรวบรวมข้อมูล zellkernel มีรีโพซิทอรีสาธารณะ 50 แห่ง โดย 20 แห่งเป็น fork และ 21 จาก 50 แห่งนั้นถูกสร้างขึ้นเมื่อวันที่ 10 สิงหาคม ซึ่งเป็นวันเดียวกับแคมเปญ โปรไฟล์นี้ถูกเชื่อมโยงไขว้กับบัญชี X @llmgod ซึ่งเชื่อมโยงกลับไปยังบัญชี GitHub การเชื่อมโยงแบบสองทางเช่นนี้บ่งชี้ว่าเป็นตัวตนที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะ มากกว่าจะเป็นตัวตนที่ถูกยึดมา
สิบเก้าปิด สี่เปิด ศูนย์ที่ถูก merge คือตัวเลขที่ถูกกล่าวซ้ำมากที่สุดในบันทึก และยังเป็นตัวเลขที่มักถูกตีความว่าเป็นสัญญาณปลอดภัยทั้งหมด ซึ่งไม่เชิงอย่างนั้น ปุ่ม merge ของ GitHub ไม่ใช่บันทึกการรันของโฮสต์ ผู้ดูแลสามารถดึงสาขาและรันมันได้ ใช้การกำหนดค่าด้วยมือ หรือ CI job สามารถดึง head ของ PR ก่อนที่ใครจะแสดงความคิดเห็นได้ pull request สี่รายการที่เขียน config ซึ่งเรียกใช้พาธสคริปต์ภายในเครื่องคือรายการที่ช่องว่างนั้นสำคัญที่สุด เพราะสคริปต์ถูกดึงมาและรันนอกการบัญชีการ merge ของ GitHub ทั้งหมด Cloud Security Alliance Labs ชี้ประเด็นเดียวกันในบันทึกวันที่ 2 กันยายน: จำนวนที่ปิดและยังไม่ถูก merge ไม่ได้พิสูจน์ว่าไม่มีอะไรถูกเรียกใช้
สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน
ข้อเท็จจริงนี้ได้รับการยืนยันจากการเปิดเผย ในความหมายที่ Pillar รายงานจากอาร์ติแฟกต์ที่มันอ่าน และในกรณีหนึ่งจากบริการที่มันสอบถาม ได้แก่ เซิร์ฟเวอร์และที่เก็บซอร์สโค้ดของมัน เครื่องมือสองตัวที่ถูกประกาศไว้ ตัวนับและเกณฑ์การเรียกสามครั้ง เป้าหมายข้อมูลรับรองสี่รายการ จำนวน PR และสถานะการ merge ของ PR เหล่านั้น ณ เวลาตรวจทาน และความเชื่อมโยงระหว่างบัญชี GitHub กับแฮนเดิล X การทดสอบของ Pillar เองกับ endpoint ที่ใช้งานจริงเป็นรายการที่หนักแน่นที่สุดในรายการนี้ เพราะเป็นการทำซ้ำมากกว่าการอ่านซอร์สโค้ด
ยังไม่ได้รับการยืนยัน และบันทึกก็ระมัดระวังในประเด็นนี้: เหยื่อ ฟิลด์ real_harm ของคลังเก็บข้อมูลมีค่าเป็น false ซึ่งเป็นข้อความเกี่ยวกับหลักฐาน ไม่ใช่เกี่ยวกับเจตนา — ยังไม่มีใครแสดงโฮสต์ บันทึก หรือข้อมูลรับรองที่ถูกขโมยซึ่งเชื่อมโยงกับแคมเปญนี้ได้ และยังไม่มีการระบุตัวบุคคลหรือกลุ่มที่อยู่เบื้องหลัง zellkernel และ @llmgod; Pillar ระบุว่าปฏิบัติการนี้เป็นของบัญชีเหล่านี้และหยุดอยู่เพียงเท่านั้น แรงจูงใจทางการเงินขึ้นอยู่กับที่อยู่ Bitcoin ที่ฝังอยู่ในเพย์โหลด ซึ่งเป็นการอนุมานจากตัวชี้วัด ไม่ใช่ข้อค้นพบเกี่ยวกับผู้กระทำ และคำถามที่ผู้ป้องกันภัยอยากได้คำตอบมากที่สุด — ว่าแคมเปญนี้ยังดำเนินอยู่หรือไม่ — ไม่มีคำตอบในบันทึก: โพสต์ดังกล่าวถูกทำเครื่องหมายว่าจะมีการอัปเดต และไม่มีการแก้ไขเพิ่มเติมหรือประกาศการนำออกจาก GitHub หรือ Render ให้เห็น
การยืนยันข้อเท็จจริงนั้นบางกว่าที่ระดับความมั่นใจอาจชวนให้คิด และนี่เป็นสิ่งที่ควรพูดตรง ๆ บันทึกการวิจัยสองฉบับ Cloud Security Alliance Labs ลงวันที่ 30 สิงหาคม และ 2 กันยายน 2026 กล่าวซ้ำถึงแคมเปญนี้; ฉบับหลังระบุชัดว่าให้เครดิต Pillar สำหรับการค้นพบ รายละเอียด PR พฤติกรรมของเซิร์ฟเวอร์ และการระบุที่มาของบัญชี และไม่ได้อธิบายถึงการตรวจสอบยืนยันอย่างเป็นอิสระใด ๆ ของตนเอง. Armor โพสต์บล็อก ลงวันที่ 22 กันยายน 2026 ให้คำแนะนำด้านการป้องกันและกล่าวว่า Pillar ได้รื้อเซิร์ฟเวอร์; แต่ไม่ได้นำเสนอหลักฐานทางฟอเรนสิกส์ใด ๆ ของตนเอง ไม่มีการกำหนดหมายเลข CVE และ CSA กล่าวว่านี่ไม่ใช่ช่องโหว่ในสเปกของ MCP ณ วันที่ 29 ตุลาคม 2026 การค้นหาไม่พบประกาศคำเตือนจาก GitHub หรือ Render และไม่พบการรายงานในสื่อด้านความปลอดภัยกระแสหลัก — ไม่มีข่าวจาก BleepingComputer, The Register, SecurityWeek หรือ Hackread — ซึ่งเป็นเรื่องผิดปกติสำหรับแคมเปญห่วงโซ่อุปทานในรูปแบบนี้ และตัวมันเองก็เป็นส่วนหนึ่งของสิ่งที่บันทึกไว้แสดงให้เห็น “แหล่งข้อมูลปฐมภูมิเห็นพ้องกัน” ในที่นี้หมายถึงแหล่งข้อมูลปฐมภูมิต้นทางเพียงแหล่งเดียว และชุดเอกสารทุติยภูมิที่ได้มาจากแหล่งนั้น
มีความกำกวมเล็ก ๆ สองจุดที่ควรชี้ให้เห็นมากกว่าจะกลบเกลื่อน บทสรุปทุติยภูมิต่างกันว่าการเรียกครั้งที่สามหรือครั้งที่สี่คือรายการแรกที่ได้รับเมทาดาทาที่ถูกวางยา ซึ่งเป็นผลสืบเนื่องจากการที่ตัวนับถูกอธิบายว่าสะดุดเมื่อคำขอครั้งที่สาม ทั้งบันทึกและคำเปิดเผยต่างใช้เลขสาม และหน้าต่างการส่งมอบถูกระบุว่า 74 นาทีสำหรับการประทับเวลาที่ครอบช่วง 75
การตรวจสอบหนึ่งรายการที่ไม่สามารถทำซ้ำได้: เมื่อวันที่ 29 ตุลาคม 2026 บัญชี GitHub zellkernel และที่เก็บ zellkernel/productivity-suite-mcp ทั้งคู่ส่งคืน 404 และ pull request ที่ระบุชื่อเป็นรายการเดียว คือ getsentry/sentry-mcp #1239 ก็ไม่สามารถเข้าถึงได้อีกต่อไปเช่นกัน — ตัวรีพอซิทอรีเองตอนนี้เปลี่ยนเส้นทางไปยัง getsentry/toolkit ดังนั้น จำนวน PR สถานะการ merge และเนื้อหาของรีพอซิทอรี จึงไม่สามารถตรวจสอบยืนยันซ้ำจากแหล่งต้นทางโดยตรงได้ในวันนี้; ข้อมูลเหล่านี้จึงคงเป็นสแนปช็อตของ Pillar ที่บันทึกไว้เมื่อกลางเดือนสิงหาคม
สิ่งที่การเปิดเผยนี้กำหนดให้ผู้ป้องกันต้องทำ
แนวทางรับมือที่ Pillar แนะนำนั้นส่วนใหญ่เกี่ยวกับการมองเมทาดาทาเป็นพื้นผิวด้านความปลอดภัย มากกว่าการเป็นเพียงคำอธิบายของพื้นผิวดังกล่าว สำหรับโฮสต์ สิ่งที่ต้องดำเนินการอย่างชัดเจนคือการบล็อกหรือค้นหา productivity-suite-mcp[.]onrender[.]com/mcp และรักษาปลายทาง trycloudflare.com ก่อนหน้าของแคมเปญให้อยู่ในรายการ deny และรายการ hunting แม้ Pillar ระบุว่าขณะนี้ยังไม่มีการใช้งาน และไม่ให้เรียกใช้ deadbug-mcp.py — พาธไฟล์ที่ซ่อนอยู่ ~/.config/.cache/.sys/.deadbug-mcp.py เป็นอาร์ติแฟกต์ที่ต้องค้นหาทั่วไดเรกทอรี home, รีพозиทอรี และการกำหนดค่าของไคลเอนต์ MCP
ลำดับการสอบสวนสำคัญกว่าบล็อกลิสต์ หากโฮสต์อาจเชื่อมต่อแล้ว Pillar แนะนำให้เก็บรักษาล็อกไคลเอนต์ MCP ก่อนทำความสะอาดสิ่งใด จากนั้นตรวจทานการรีเฟรชคำจำกัดความเครื่องมือและสิ่งที่เอเจนต์ทำหลังการเรียกครั้งที่สาม; ควรหมุนเวียนข้อมูลรับรองเฉพาะเมื่อหลักฐานในเครื่องสนับสนุนว่ามีการเปิดเผย ซึ่งตรงกันข้ามกับปฏิกิริยารีเฟล็กซ์ที่จะหมุนเวียนทุกอย่างเมื่อสงสัย การกำหนดค่าของเซิร์ฟเวอร์ยังอนุญาตให้มีเทเลเมทรีแบบไม่บังคับไปยัง WEBHOOK_URL โดยส่งสัญญาณเมื่อเชื่อมต่อ เมื่อเรียกครั้งแรก และเมื่อเกิดเหตุการณ์ทริกเกอร์ — รายละเอียดที่ทำให้การสอบสวนมีจุดที่สามให้ตรวจสอบนอกเหนือจากล็อกไคลเอนต์และทราฟฟิกของปลายทาง
สำหรับผู้ที่พัฒนาไคลเอนต์ MCP คำแนะนำนี้เป็นเชิงโครงสร้าง และเป็นส่วนหนึ่งของบันทึกที่คงอยู่ได้ยาวนานที่สุด:
• สร้างลายนิ้วมือของนิยามเครื่องมือ ณ เวลาที่อนุมัติ และเปรียบเทียบทุกครั้งที่มีการรีเฟรช แทนที่จะเชื่อถือชื่อและรีโพซิทอรีของเซิร์ฟเวอร์
• มองว่าการเปลี่ยนแปลงคำนิยามบนเซิร์ฟเวอร์ที่ได้รับอนุมัติแล้วเป็นเหตุการณ์ด้านความปลอดภัยที่ผู้ปฏิบัติงานมองเห็นและอนุมัติซ้ำ ไม่ใช่การเปลี่ยนแปลงเมทาดาทาตามปกติที่จะถูกกลืนหายไปอย่างเงียบ ๆ
• บังคับใช้การดำเนินการที่ละเอียดอ่อน — การเข้าถึงข้อมูลรับรอง การเรียกใช้โค้ด การส่งอีเมลขาออก การเขียนลงรีโพซิทอรี — ผ่านนโยบายแทนที่จะผ่านคำอธิบายที่เซิร์ฟเวอร์จัดให้
รายการที่สามนี่เองที่ทำให้ Deadbugz เป็นบันทึกหลักฐานมากกว่าจะเป็นเพียงเรื่องแปลกประหลาด การควบคุมทั้งหมดข้างต้นตั้งอยู่บนสมมติฐานว่าเอเจนต์สามารถถูกโน้มน้าวให้ทำสิ่งต่าง ๆ ได้ด้วยข้อความที่เซิร์ฟเวอร์แนบมากับเครื่องมือ และข้อความนั้นสามารถเปลี่ยนแปลงได้หลังจากที่การตัดสินใจเรื่องความไว้วางใจได้เกิดขึ้นแล้ว Pillar จัดวางแคมเปญนี้ไว้ในสายเดียวกับสิ่งที่รวมถึงการโจมตีแบบ sleeper ผ่าน MCP ของ Invariant Labs ในปี 2025 แพ็กเกจ postmark-mcp ปลอม และแพ็กเกจ MCP ที่ Koi บันทึกไว้ซึ่งถูกเปลี่ยนให้กลายเป็นอาวุธผ่านการอัปเดต ทั้งหมดนี้ล้วนเป็นแบบอย่างก่อนหน้าของเทคนิคดังกล่าว ซึ่ง Pillar อ้างอิงในแง่นั้น มิใช่ในฐานะหลักฐานเกี่ยวกับการส่งมอบครั้งนี้
ทำไม 'เกต' จึงสำคัญกว่าจำนวนเหยื่อ
แคมเปญที่มีความพยายามในการส่ง 23 ครั้ง ไม่มีการ merge และไม่มีเหยื่อที่ยืนยันได้นั้นจัดเข้าแฟ้มหมวด "พยายามแล้ว" ได้ง่ายและข้ามไปได้เลย เหตุผลที่มันควรอยู่ในคลังเก็บถาวรที่ระดับความรุนแรงสูง คือการหลบเลี่ยงของมันไม่ได้ขึ้นอยู่กับความสำเร็จของการส่งในวงกว้าง หากแต่ขึ้นอยู่กับคุณสมบัติหนึ่งที่การติดตั้งใช้งาน MCP ส่วนใหญ่มีร่วมกันในปัจจุบัน: การอนุมัติเกิดขึ้นครั้งเดียว ณ เวลาติดตั้ง และมีการสมมติว่าคำนิยามที่ได้รับการอนุมัติแล้วคือคำนิยามที่จะถูกให้บริการ Deadbugz คงสมมติฐานนั้นไว้ครบสามการเรียก แล้วจากนั้นจึงทำลายมัน
การแก้ไขนี้ไม่ใช่แพตช์สำหรับเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่ง และไม่มี CVE ให้ติดตาม สิ่งที่ต้องเปลี่ยนคือ "approved" ต้องกลายเป็นเงื่อนไขที่ต่อเนื่องซึ่งมีการเปรียบเทียบรองรับอยู่เบื้องหลัง — ซึ่งเป็นการเปลี่ยนแปลงพฤติกรรมของไคลเอนต์และผู้ดำเนินการของไคลเอนต์ ไม่ใช่การเปลี่ยนแปลงสิ่งที่สแกนเนอร์มองหา ยังไม่ทราบว่ามีใครได้รันเซิร์ฟเวอร์นั้นจริงในเดือนสิงหาคมหรือไม่ ตามบันทึกที่เป็นอยู่ กลไกนี้คือข้อค้นพบ
