BrowserSkill של Tencent בדק רק שמזהה תוסף נראה אמיתי — כל תוסף יכול היה להזין לסוכן דפים מזויפים

ב-17 בספטמבר 2026, משתמש GitHub שפרסם בשם carfeii פתח issue #273 נגד הפרויקט בקוד פתוח של Tencent BrowserSkill, בטענה צרה: הדמון המקומי שמחבר את הרחבת הדפדפן לסוכן AI לא בדק איזו הרחבה התחברה, אלא רק שהחיבור נראה כמו הרחבה בכלל. שלושה ימים לאחר מכן, ב-20 בספטמבר, VulnCheck פרסמה את הממצא כ-CVE-2026-94111, ותיארה דמון ש„מקבל כל מקור chrome-extension עם 32 תווים בטווח a-p”, מסווגת אותו כ-CWE-346 (שגיאת אימות מקור), ומייחסת ל-George Chen. הייעוץ מדרג אותו CVSS 4.0 6.9, בינונית, כאשר השפעה על שלמות מדורגת גבוהה והשפעה על סודיות וזמינות נמוכות. שום דבר ברשומה לא מרמז שהפגם נוצל: הארכיון אינו מתעד ניצול ומדרג את הרשומה בדירוג מהימנות A, עם real_harm false. זוהי רשומה אחת ב-ארכיון התקריות של AI, שבו כל רשומה נושאת מקורות, חומרה, דירוג מהימנות ודגל מחלוקת משלה.

בדיקת פורמט שמעולם לא בדקה זהות

הקוד בלב הרשומה קטן. בקובץ crates/bsk-cli/src/daemon/ws.rs, הפונקציה origin_allowed() מקבלת את כותרת ה-Origin של ה-handshake של WebSocket, מסירה את המחרוזת chrome-extension://, ומחזירה true אם מה שנותר הוא באורך בדיוק 32 תווים וכל תו בו נמצא בין a ל-p. זו הבדיקה השלמה. היא מופעלת פעם אחת, בתוך ה-callback של ה-upgrade של HTTP, וכשל מחזיר 403 שהודעתו היא "Origin not in chrome-extension allow-list" — אף שכפי שפורסם לא הייתה רשימה שאליה אפשר להשתייך.

התבנית אינה שרירותית. מזהי ההרחבות של Manifest V3 של Chrome הם 32 תווים שנבחרים בדיוק מאותן שש-עשרה אותיות, כך שהבדיקה מזהה נכון את הצורה של מקור הרחבה אמיתי. הפגם הוא שלכל הרחבה יש את הצורה הזו. הבדיקה שואלת אם הקורא נראה כמו הרחבת דפדפן, ולעולם לא אם הוא הזה של הפרויקט – קרי הרחבת דפדפן – והמזהה שהיה צריך להשוות אליו כבר היה פומבי: ה-README של הפרויקט מקשר לרשומה ב-Chrome Web Store, שה-ID שלה הוא hhcmgoofomhgciiibhipgmgkgnoenaoi, ומזהה ה-Edge Add-ons שלצידו. אף אחת מהמחרוזות הללו אינה מופיעה בשום מקום בשער.

הדמון מאזין בפורט מקומי קבוע, 52800, המוצהר כ-DEFAULT_WS_PORT ב-CLI ומשמש ללא שינוי בנתיב החיבור המקומי. הפורט מתועד, קבוע, ונגיש לכל דבר שכבר פועל בפרופיל הדפדפן של המשתמש. המיקום הוא הסיבה שווקטור הייעוץ מתחיל ב-AV:L — התוקף זקוק לדריסת רגל במכונה, ו-PR:L מתעד שכזו בהרשאה נמוכה מספיקה. תוסף המותקן באותו פרופיל הוא בדיוק סוג כזה של דריסת רגל.

מה שווה המושב, וכמה ממנו מבוסס.

משפט ההשפעה של הייעוץ רחב: תוקף שרשם תוסף זדוני כלקוח דפדפן יכול "ליירט ולשנות תוכן עמודים, DOM וצילומי מסך המוחזרים לסוכן ה-AI". זהו התיאור שמופיע ב-CVE, ברשומת הייעוץ ב-GitHub GHSA-x6f2-qp26-2xrh ובארכיון, והוא מסביר את דירוג השלמות הגבוה ב-CVSS. זה גם סיכום שנכתב על ידי הגורם שהקצה את ה-CVE, ולא דוח של תקיפה שהודגמה.

דיווח זהיר יותר הגיע באותו שבוע, בשרשור הנושא עצמו. ב-20 בספטמבר, מגיב בשם bb6894 דיווח שבדק מחדש את הקוד מול main בקומיט fa953dc6 (18 בספטמבר) ואיתר למה לקוח זר יכול למעשה להגיע לאחר ה-handshake. רוב שיטות הכלים הנכנסות, כך נטען בתגובה, מחזירות UnknownMethod לעמית WebSocket; בקשות ביקורת מוגבלות לרשומות של הלקוח עצמו; ופעולות חוצות-סשן כגון window_closed, user_interrupt ו-update_interaction מוגנות מפני גישה לסשנים שבבעלות דפדפן אחר. מה ששורד את הסינון הזה הוא צר יותר, ולסוכן, אפשר לטעון, גרוע יותר מיירוט: הרחבה זרה יכולה לתפוס משבצת דפדפן תחת instance_id שנבחר בידי התוקף, ואם היא הדפדפן היחיד הרשום — התחלה קרה או אתחול דמון — היא מקבלת את בקשות הכלים של הסוכן ועונה להן בתוכן דף, DOM או צילומי מסך מומצאים. המגיב מכנה זאת "זיוף תוצאות כלפי הסוכן" ו"ערוץ אל תפיסת הסוכן". השפעה שנייה היא מניעת שירות: כאשר גם דפדפן אמיתי מחובר ואין בורר, הפעלת סשן עלולה להיכשל עם MultipleBrowsersOnline.

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

הקוד כבר ידע

המסמך הכי לא נוח בתיעוד הזה אינו ההתראה. זה ההערה ממש מעל הפונקציה, שנשלחה בגרסה המתויגת שאליה ההתראה מצביעה. היא מסמנת את הפער כ-TODO(M10/M12), מפרטת את רשימת ההיתרים שהיא מתכוונת לבנות — קבוצת DaemonConfig::allowed_extension_ids שמאוכלסת מקובץ תצורה או מתהליך צימוד — ואז מציינת את הסיבה לדחייתה: "פער הגנה לעומק מקובל לעת עתה משום שהצימוד מתרחש דרך החלון הקופץ, אבל הרחבה שנטענה מהצד באותו מחשב עדיין עוברת את השער."

בקריאה כפשוטה, המתחזקים ידעו איזה קורא השער העביר, תיעדו שהם ידעו זאת, ושחררו. זה לא הופך את החשיפה לגדולה מזו שהודעת האבטחה מציינת; זה הופך אותה לפחות מפתיעה, וזה מעביר את השאלה מ"איך זה עבר את הסקירה" ל"מה היה הופך את התיקון הנדחה לדחוף". הנחת התכנון הממתנת היא אמיתית וגם מתועדת: החיבור המקומי הוא אופציונלי (opt-in). לפי ה-README, המשתמש מתקין את התוסף, פותח את החלון הקופץ שלו ומפעיל את החיבור המקומי, והדמון חייב לפעול כדי שכל זה יהיה נגיש. פרופיל שבו התוסף מותקן אך המתג כבוי, או שבו לא פועל דמון bsk, אינו יעד האזנה.

חמישה שבועות לאחר מכן, השער לא השתנה

טווח ההשפעה של הרשומה הוא "עד 0.3.0", וזה הטווח שהוקצה על ידי ה-CNA. זה לא סוף הסיפור במאגר. גרסת 0.3.0 של ה-CLI תויגה ב-17 בספטמבר בשעה 02:22 UTC; התקלה דווחה באותו יום בשעה 15:14 UTC, כשלוש עשרה שעות לאחר מכן. שלוש גרסאות CLI נוספות שוחררו מאז — 0.3.1 ב-23 בספטמבר, 0.3.2 ב-30 בספטמבר, וכן 0.3.3 ב-15 באוקטובר — ופונקציית origin_allowed() בכל אחד מהתגים הללו היא אותה בדיקה שתוארה לעיל, כאשר ה-TODO עדיין מופיע מעליה. הענף הראשי נושא אותה גם נכון ל-27 באוקטובר.

תיקון קיים, אך רק כהצעה. ב28 בספטמבר, תורם המפרסם בשם dangzitou פתח בקשת משיכה #363 מפורק אישי, שכותרתה "fix(daemon): pin WS origin gate to BrowserSkill's own extension ids". היא מחליפה את בדיקת הצורה בהשוואה לשני מזהי החנות, ומוסיפה את BSK_ALLOWED_EXTENSION_IDS כנתיב קבלה מפורש עבור גרסאות sideloaded וגרסאות פיתוח, שה-IDs הלא ארוזים שלהן נגזרים מנתיב ההתקנה. גוף בקשת המשיכה טוען שהיא סוגרת הן את נתיב הזיוף והן את התקפת מניעת השירות MultipleBrowsersOnline. נכון ל-27 באוקטובר היא עדיין פתוחה ולא מוזגה, והגיליון נותר פתוח ללא הצהרה מצד הספק.

ההשלכה המעשית היא שאין גרסה שאפשר לשדרג אליה ושכוללת את התיקון. כל מי שמייעץ "לשדרג מעבר ל-0.3.0" מייעץ לבצע צעד שעדיין אינו קיים: הגרסאות המאוחרות יותר הן מאוחרות יותר, לא מתוקנות. יש לקרוא את הטווח ברשומה כטווח שה-CNA העריך ב-20 בספטמבר, ולא כהצהרה ש-0.3.1 והלאה נקיות.

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

• נקבע: המקור שפורסם בתג cli-v0.3.0 מכיל שער מקור שמקבל כל מקור chrome-extension באורך 32 תווים בטווח a–p. המדווח, ה-CNA והקובץ עצמו מסכימים, והקוד פומבי.

• נקבע: השער פעל פעם אחת, בעת שדרוג ה-WebSocket, ללא בדיקת זהות מאוחרת יותר, על פורט מקומי קבוע של 52800.

• נקבע: הערת המקור של הפרויקט עצמו הודתה שתוסף שנטען מהצד (sideloaded) יעבור, ודחתה את הטיפול ברשימת ההיתרים.

• נקבע:CVSS 4.0 6.9 ו-CVSS 3.1 6.6 הם שניהם ציונים של VulnCheck, שנרשמו על ידי NVD כציונים משניים. הסטטוס של NVD עצמו עבור הרשומה הוא Deferred, כלומר הוא פרסם את הנתונים של ה-CNA מבלי להוסיף ניתוח שנכתב על ידי NVD.

• נקבע: הערכת SSVC של CISA, מיום 21 בספטמבר, מתעדת ניצול כ"אין", ניתנות לאוטומציה כ"לא", והשפעה טכנית כ"חלקית". מודל EPSS של FIRST מעמיד את ההסתברות לניצול בשלושים הימים הבאים על 0.00135, האחוזון ה-2.9, נכון ל-26 באוקטובר.

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

• לא הוכח: איזה תיאור השפעה תקף. ה"יירוט ומניפולציה" של ה-CNA וה"זיוף תוצאות בתוספת מניעת שירות" של השרשור מתארים תקרות שונות, ואף אחד מהם לא הודגם מחוץ לקריאת קוד.

• לא הוכח: שהפגם מסתיים ב-0.3.0. מחרוזת הגרסה היא הערכת ה-CNA; הקוד לא השתנה בשלוש המהדורות שאחריה, ואין הצהרת ספק שמזכה אותן.

• בסתירה, לא פתור: מאגד אחד, DevGuard, מציג אות "זוהו ניסיונות ניצול" עבור CVE זה בלי לציין מקור, IOC או ספק טלמטריה. זה עומד בניגוד להערכה המתועדת של CISA שלפיה אין ניצול, ובניגוד להיעדר כל דוח פומבי; בארכיון גם לא מתועד ניצול. יש להתייחס לסימון של המאגד כלא מבוסס ולא כנקודת נתונים שנייה.

מדוע שכבת התעבורה היא היעד המעניין

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

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

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

CVE-2026-94111 יזדקן באחת משתי דרכים. או שה-pull request ימוזג והרשומה תהפוך לערך קצר על פער ידוע שנדרש זמן לסגור, או שאותה בדיקת מבנה תישאר בעץ בעוד שנה והרשומה תצוטט כדוגמה מוקדמת למחלקה שאליה היא שייכת: לא דף שנושא הוראה עוינת, אלא הצינור שקובע איזה דף הסוכן קורא.