AI Safety Incidents

Deadbugz: שרת MCP שהופך לעוין בקריאה השלישית לכלי, ונדחף ל-23 מאגרי קוד תוך 74 דקות

מחבר

Magnus Corvin

תאריך פרסום

Oct 29, 2026

מודלים אחרונים · 20צפו בכל המודלים →

בנצ'מרקים: Artificial Analysis · מתעדכן יומית

חזרה לכל הפוסטים

ב-10 באוגוסט 2026 חשבון GitHub אחד, zellkernel, פתח 23 בקשות משיכה ב-74 דקות כנגד מאגרי AI, MCP וכלי פיתוח שאינם קשורים, כאשר כל אחת הוסיפה שרת MCP בשם productivity-suite שהציג שני כלים רגילים, format_text ו-summarize. לפי Pillar Security, שכינתה את הקמפיין Deadbugz ופרסמה את הדוח שלה ב-12 באוגוסט, השרת החזיר תוצאות כנות בשלוש הקריאות הראשונות שלו ואז שיכתב את המטא-נתונים שהעביר לסוכן: תיאורי הכלים ותוכן ההנחיה החלו להפנות את המודל אל מפתחות SSH, אישורי AWS, היסטוריית מעטפת ותצורת Kubernetes, ולהורות לו להסתיר את הפעילות הזו מהמשתמש. תשע-עשרה מ-23 בקשות המשיכה נסגרו, ארבע עדיין היו פתוחות ואף אחת לא מוזגה כאשר Pillar בחנה אותן. לא אושר קיומו של אף קורבן. זהו רשומה אחת, שדווחה בידי אחרים ומובאת כאן בהפניה אליהם. תקריות הסוכן המתועדות האחרות, שלכל אחת מקורות, חומרה, דרגת ודאות וסימון מחלוקת משלה, נמצאות בארכיון תקריות ה-AI — כך שניתן לקרוא קמפיין שרשרת אספקה שמכוון לכלי סוכן לצד שאר מה שאכן קרה.

הארכיון מדרג את הרשומה הזו בחומרה גבוהה ובביטחון A — מתועדת היטב, עם מקורות ראשוניים שמסכימים — ובמקביל מתעד שאין נזק אמיתי מאומת. שני הדברים נכונים בעת ובעונה אחת, והפער ביניהם הוא נושא הרשומה: קמפיין שעיצובו תועד בפירוט יוצא דופן לפני שהפיק קורבן שמישהו יכול לנקוב בשמו. שני התאריכים החשובים מרוחקים זה מזה ביומיים. בקשות המשיכה נשלחו ב-10 באוגוסט; Ariel Fogel מ-Pillar Security פרסם את הניתוח ב-12 באוגוסט, והפוסט נושא הערת קבע שלפיה הוא יעודכן ככל שיגיע מידע מאומת.

שלושה חיוגים, ואז המטא-נתונים משתנים

שרת MCP לא צריך להריץ קוד על מכונה כדי לשנות את מה שסוכן עושה. הגדרות כלים מועברות למודל כהקשר בכל סשן, כלומר השרת שמספק אותן יכול לשכתב את ההוראות שהסוכן קורא מבלי לשנות את שם הכלי, את המאגר שלו ואת המניפסט שלו כלל. Deadbugz בנוי על הא-סימטריה הזו, והשם ש-Pillar נותן לכך הוא הרעלת מטא-נתונים של MCP עם שער בזמן ריצה.

המכניקה קטנה מספיק כדי לנסח אותה במשפט אחד. השרת מחזיק מונה בזיכרון, לכל לקוח, של בקשות tools/call. בשלוש הבקשות הראשונות הוא מתנהג כרגיל. לאחר שהמונה מופעל, בהמשך, עבור tools/list ו-prompts/get, התגובות חוזרות כשהן שונו — תיאורי כלים שונים, תוכן פרומפטים שונה — ומפנות את הסוכן אל מפתחות SSH, פרטי גישה ל-AWS, היסטוריית shell וקונפיגורציית Kubernetes ומורות לו להסתיר את הפעילות מהמשתמש. טקסט הפרומפט המורעל נושא את הסימן deadbugz וכתובת ביטקוין.

השער הוא גם הסיבה לכך שההגנות הרגילות אינן מזהות אותו. ה-payload נמצא במקור מהבקשה הראשונה; שום דבר בקוד או בתצורה אינו משתנה ברגע ההחלפה. סריקה סטטית, רשומת SBOM או קריאה חד-פעמית של מניפסט הכלי בזמן ההתקנה רואים כלי עיצוב, משום שזה מה שהכלי מחזיר עד שהמונה מתקדם. Pillar מתארת את ההחלפה המושהית כטכניקת התחמקות מחקרית, ואומרת שהחוקרים שלה אישרו הן את הסף והן את המטא-דאטה שהשתנתה באמצעות שליחת בקשות טקסט בלבד לשירות המרוחק החי והתאמת התגובות למקור הציבורי.

פרט אחד הופך את המלכודת לרחבה יותר מסשן בודד. השרת מפרסם tools.listChanged, יכולת ה-MCP שאומרת ללקוח שרשימת הכלים שלו עודכנה. לקוח שמכבד את האות הזה יקרא מחדש את ההגדרות באמצע הסשן וימשוך את הגרסה המורעלת בלי שום פעולה מצד המפעיל; לקוח ששומר הגדרות במטמון בעת האישור לא יעשה זאת. איזו התנהגות יש לסוכן נתון היא תכונה של הלקוח, לא של השרת, והכתוב של Pillar אינו מונה לקוחות בשמם.

HTML card titled 'Three calls, then the metadata changes', kicked 'MCP · productivity-suite', with the subtitle 'The payload is present from the first request; the gate is a counter in memory'. Three columns. 'Calls one to three — benign' lists format_text returning formatted text, summarize returning a summary, and tools/list and prompts/get returning honest tool definitions, with a note that nothing on disk differs from what a reviewer approved. 'The gate' lists an in-memory per-client counter of tools/call requests, a threshold of three, altered tool descriptions and prompt content in later tools/list and prompts/get responses, and the advertised tools.listChanged capability that lets compliant clients re-read definitions mid-session. 'What the poisoned metadata asks for' lists SSH keys, AWS credentials, shell history and Kubernetes configuration, an instruction to keep the activity from the user, and the embedded marker deadbugz with a Bitcoin address. A footer reads 'Per Pillar Security's disclosure of 12 August 2026. Pillar says its researchers confirmed the threshold and the altered metadata against the live remote service using text-only requests, matching the public source.'

מסירה: 23 בקשות משיכה ב-74 דקות

ההפצה לא הייתה חבילה ברישום (registry) או תלות מורעלת שקבורה בקובץ lockfile. היא הייתה ספאם של בקשות משיכה (pull requests) נגד פרויקטים שלא היה להם דבר וחצי דבר עם התפקוד לכאורה של השרת, וזו הצורה שבה ניסיון שרשרת אספקה בעלות נמוכה מתגלם כאשר התוקף אינו יכול להשיג חשבון של מתחזק (maintainer): להגיש מספיק שינויי תצורה ולחכות שאחד מהם ימוזג או ייושם באופן מקומי.

הפילוח של Pillar של 23 המקרים הוא תלת-כיווני. שבעה-עשר מוסיפים נקודת קצה MCP מרוחקת, productivity-suite-mcp[.]onrender[.]com/mcp, המתארחת ב-Render; ארבעה מפעילים קובץ Python מקומי מוסתר בנתיב ~/.config/.cache/.sys/.deadbug-mcp.py; שניים הם הגשות לספרייה או לרשימה, שהתיעוד מתייחס אליהן כאל איסוף מודיעין או מילוי מקום ולא כאל מסירה. חלון הזמן מוצג כ-9:52 PM עד 11:07 PM UTC ב-10 באוגוסט 2026 — 74 דקות לפי מסגור החשיפה, אף ששתי חותמות הזמן עצמן משתרעות על פני 75 דקות, ושום דבר ברשומה לא תלוי באותה דקה. רק מאגר יעד אחד נקרא בשמו באופן פרטני: getsentry/sentry-mcp, בקשת משיכה #1239, שהוצגה כדוגמה למסירת הארטיפקט המקומי.

החשבון שמאחורי זה היה משמעותי יחסית לגילו. בזמן איסוף הנתונים של Pillar, ל-zellkernel היו 50 מאגרים ציבוריים, 20 מהם פורקים, ו-21 מתוך אותם 50 נוצרו ב-10 באוגוסט, אותו יום שבו התנהל הקמפיין. הפרופיל היה מקושר באופן צולב לחשבון ה-X @llmgod, אשר קישר חזרה לחשבון ה-GitHub, וזהו סוג של קישור הדדי המעיד על זהות שנבנתה למטרה ייעודית ולא על זהות שנחטפה.

סגורים תשעה־עשר, פתוחים ארבעה, אפס מוזגו — זה הנתון החוזר ביותר בתיעוד, וגם זה שנקרא לעתים הקרובות ביותר כאות שהכול תקין, מה שהוא לא בדיוק. כפתור המיזוג של GitHub אינו רשומת ההרצה של המארח: מתחזק יכול למשוך ענף ולהריץ אותו, להחיל תצורה ידנית, או שמשימת CI יכולה למשוך את ראש ה-PR לפני שמישהו מגיב. ארבע בקשות המשיכה שכותבות תצורה שקוראת לנתיב סקריפט מקומי הן אלה שבהן הפער הזה משמעותי ביותר, משום שהסקריפט נמשך ומורץ מחוץ לחשבונאות המיזוג של GitHub לחלוטין. Cloud Security Alliance Labs העלתה את אותה נקודה בהערה שלה מ-2 בספטמבר: ספירות הסגורים והלא־ממוזגים אינן מוכיחות ששום דבר לא הורץ.

HTML card titled 'Twenty-three pull requests in seventy-four minutes', kicked '10 August 2026 · delivery', subtitled 'Times UTC. Counts are Pillar Security's review snapshot.' Three columns. 'The window' lists the first pull request at 21:52, twenty-three pull requests to unrelated AI, MCP and developer-tooling repositories, the last at 23:07, and a note that the 74-minute framing spans 75 minutes on the clock. 'What each pull request added' lists seventeen adding the remote endpoint productivity-suite-mcp.onrender.com/mcp, four invoking the hidden file at ~/.config/.cache/.sys/.deadbug-mcp.py, two directory or listing submissions, and one named example, getsentry/sentry-mcp pull request 1239. 'At review' lists nineteen closed, four open, zero merged through GitHub's review, zero confirmed victims, and the account zellkernel linked to the X handle llmgod, with fifty public repositories and twenty-one created that day. A footer reads 'Per Pillar Security. Cloud Security Alliance Labs repeated the same figures on 30 August and 2 September 2026 without independent verification. As of 29 October 2026 the GitHub account and the productivity-suite-mcp repository both return 404.'

מה מבוסס, ומה לא

הוכח באמצעות הגילוי, במובן זה ש-Pillar מדווח על כך מארטיפקטים שקרא ובמקרה אחד משירות שחקר: השרת ומאגר המקור שלו, שני הכלים שהוכרזו, המונה וסף שלוש הקריאות, ארבעה יעדי אישורים, מספרי ה-PR ומצב המיזוג שלהם בעת הסקירה, והקשר בין חשבון ה-GitHub לשם המשתמש ב-X. הבדיקה של Pillar עצמה כנגד נקודת הקצה החיה היא הפריט החזק ביותר ברשימה, משום שהיא שחזור ולא קריאה של קוד מקור.

לא הוכח, והתיעוד נזהר בדבר: קורבן. השדה real_harm בארכיון הוא false, וזהוStatement על ראיות, לא על כוונה — איש לא הציג מארח, יומן או פרטי התחברות גנובים הקשורים לקמפיין הזה. גם האדם או הקבוצה שעומדים מאחורי zellkernel ו-@llmgod לא זוהו; Pillar מייחס את הפעולה לחשבונות ועוצר שם. המניע הכלכלי נשען על כתובת ביטקוין המוטמעת במטען, וזו הסקה מאינדיקטור, לא ממצא על השחקן. והשאלה שהמגן רוצה ביותר לקבל עליה תשובה — האם הקמפיין עדיין פעיל — אין לה מענה בתיעוד: הפוסט סומן ככזה שאמור היה להתעדכן, ולא נראים שום עדכון מאוחר או הודעת הסרה מ-GitHub או Render.

התמיכה הראייתית דקה יותר מכפי שדירוג האמינות עשוי לרמז, וכדאי לומר זאת בפשטות. שתי הערות מחקר של Cloud Security Alliance Labs מתאריכים 30 באוגוסט ו-2 בספטמבר 2026, מציגות מחדש את הקמפיין; המאוחרת מבהירה שהיא מזכה את Pillar בגילוי, בפרטי יחסי הציבור, בהתנהגות השרת ובייחוס החשבון, ואינה מתארת אימות עצמאי משלה.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, ובקשת המשיכה היחידה הנקובה בשמה, getsentry/sentry-mcp #1239, אף היא אינה נפתרת עוד — המאגר עצמו מפנה כעת אל getsentry/toolkit. לפיכך לא ניתן לאמת מחדש היום ממקור ראשון את ספירות ה-PR, את סטטוס המיזוג ואת תוכן המאגר; הם נותרו כתמונת המצב של Pillar, שנלכדה באמצע אוגוסט.

HTML card titled 'What is established, and what is not', kicked '2026-08-10-deadbugz-mcp-supply-chain', subtitled 'One record, one originating source, two secondary notes that restate it'. Three columns. 'Established by the disclosure' lists the server, its source repository and the two advertised tools; the counter and the three-call threshold, confirmed against the live endpoint; the four credential targets; twenty-three pull requests, nineteen closed, four open, none merged; and the delivery account linked to the X handle llmgod. 'Not established' lists any victim or executed payload, with the archive recording real harm as false; the actor behind the account and handle; motive, which rests on a Bitcoin address in the payload; and whether the campaign is still running, the post having promised updates that are not visible. 'Corroboration' lists the Cloud Security Alliance Labs notes of 30 August and 2 September 2026 as restatement without independent checks; the Armor blog of 22 September 2026 as guidance without forensic evidence; no CVE assigned; no GitHub or Render advisory found; and no mainstream trade-press coverage found as of 29 October 2026. A footer reads 'The archive grades the record A, well documented with primary sources that agree. The secondary documents here all derive from Pillar Security's post, so agreement between them is not a second measurement.'

מה הגילוי מבקש מהמגנים לעשות

התגובה ש-Pillar ממליצה עליה עוסקת בעיקר בהתייחסות למטא-נתונים כמשטח אבטחה ולא כתיאור שלהם. עבור מארחים, הדרישות הקונקרטיות הן לחסום או לצוד אחר productivity-suite-mcp[.]onrender[.]com/mcp, לשמור את נקודת הקצה trycloudflare.com הקודמת של הקמפיין ברשימות החסימה והציד למרות ש-Pillar אומרת שהיא אינה פעילה כרגע, ולא להריץ deadbug-mcp.py — נתיב הקובץ המוסתר ~/.config/.cache/.sys/.deadbug-mcp.py הוא הארטיפקט שיש לחפש אחריו בכל תיקיות הבית, המאגרים ותצורות לקוח MCP.

סדר החקירה חשוב יותר מרשימת החסימה. אם ייתכן שמארח התחבר, Pillar מורה לשמר את יומני לקוח ה-MCP לפני ניקוי כלשהו, ואז לבדוק רענונים של הגדרות כלים ומה שהסוכן עשה לאחר הקריאה השלישית; יש להחליף אישורים רק במקום שבו ראיות מקומיות תומכות בחשיפה, וזה ההיפך מהרפלקס להחליף הכול על סמך חשד. תצורת השרת גם אפשרה טלמטרייה אופציונלית אל WEBHOOK_URL, איתות בעת ההתחברות, בקריאה הראשונה ובאירוע הפעלה — פרט שנותן לחקירה מקום שלישי לחפש בו מעבר ליומני הלקוח ולתעבורת נקודות הקצה.

עבור האנשים שבונים לקוחות MCP, ההמלצה היא מבנית, והיא החלק של הרשומה עם חיי המדף הארוכים ביותר:

• הפיקו טביעת אצבע של הגדרות הכלים בזמן האישור והשוו אותן בכל רענון, במקום להסתמך על שם השרת והמאגר שלו.

• התייחסו לשינוי הגדרה בשרת שכבר אושר כאירוע אבטחה שהמפעיל רואה ומאשר מחדש, ולא כשינויי מטא-נתונים שגרתיים שנבלעים בשקט.

• אכוף פעולות רגישות — גישה לפרטי גישה, הרצת קוד, דואר יוצא, כתיבה למאגר — באמצעות מדיניות ולא באמצעות תיאורים שהשרת מספק.

הפריט השלישי הזה הוא מה שהופך את Deadbugz לתקדים ולא לסקרנות. כל בקרה לעיל מניחה שסוכן יכול להשתכנע מטקסט ששרת מצרף לכלי, ושהטקסט יכול להשתנות לאחר קבלת החלטת האמון. Pillar ממקם את הקמפיין בשורה שכוללת את מתקפת ה-MCP sleeper של Invariant Labs מ-2025, את החבילה המזויפת postmark-mcp ואת חבילת ה-MCP שתועדה על ידי Koi והוסבה לנשק באמצעות עדכון — כולם תקדימים לטכניקה, שאותם מצטט Pillar לצורך זה ולא כראיה בנוגע למסירה הזו.

מדוע השער חשוב יותר ממספר הקורבנות

קמפיין עם 23 ניסיונות מסירה, ללא מיזוג וללא קורבן מאומת קל לסווג תחת "ניסיון" ולהתקדם הלאה. הסיבה שהוא שייך לארכיון בחומרה גבוהה היא שההתחמקות שלו אינה תלויה בהצלחת המסירה בהיקף רחב. היא תלויה בתכונה שרוב פריסות ה-MCP חולקות היום: האישור קורה פעם אחת, בזמן ההתקנה, וההנחה היא שההגדרה שאושרה היא ההגדרה שתוגש. Deadbugz משמר את ההנחה הזו בשלוש קריאות ואז שובר אותה.

התיקון אינו טלאי לשרת מסוים, ואין CVE שעליו לעקוב. העניין הוא ש„מאושר” חייב להפוך לתנאי מתמשך שמאחוריו עומדת השוואה — וזהו שינוי באופן שבו הלקוחות והמפעילים שלהם מתנהגים, ולא שינוי במה שסורק מחפש. האם מישהו אכן הפעיל את השרת באוגוסט עדיין אינו ידוע; לפי הרשומה כפי שהיא, המנגנון הוא הממצא.

Deadbugz: שרת MCP שהופך לעוין בקריאה השלישית לכלי, ונדחף ל-23 מאגרי קוד תוך 74 דקות

שלושה חיוגים, ואז המטא-נתונים משתנים

מסירה: 23 בקשות משיכה ב-74 דקות

מה מבוסס, ומה לא

מה הגילוי מבקש מהמגנים לעשות

מדוע השער חשוב יותר ממספר הקורבנות

מוצר

משאבים

לספקים

הצטרפו לקהילה שלנו

מהבלוג

ספקי מודלים