חולשת OAuth ב-MCP Python SDK אפשרה לשרת זדוני לגנוב אישורי התחברות

חולשת אבטחה בדרגת חומרה גבוהה ב-MCP Python SDK אפשרה לשרת MCP זדוני להסיט אליו פרטי OAuth שאמורים להגיע לשרת ההרשאות האמיתי. צוות הפרויקט פרסם את GHSA-qx49-fqc8-xw99 ב-28 בספטמבר והוציא תיקון בשני ענפי התוכנה: גרסה 1.30.0 לענף היציב וגרסה 2.2.0 לענף החדש.

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

למה הכשל מסוכן גם כשמסך הכניסה אמיתי

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

היקף הפגיעה מוגדר יחסית. לפי הודעת האבטחה, גרסאות 1.9.1 עד 1.29.x וגרסאות 2.0.0a1 עד 2.1.x פגיעות כאשר לקוח HTTP משתמש באחד מספקי ה-OAuth המובנים ומתחבר לשרת MCP שאינו מהימן. לקוחות שמתקשרים דרך stdio אינם מושפעים. גם לקוחות שמצרפים בעצמם אסימון או כותרות HTTP אינם עוברים במסלול הפגיע. החולשה אינה מיוחסת לשרתים שנבנו באמצעות ה-SDK.

מה צוותי פיתוח צריכים לעשות עכשיו

הפעולה הראשונה היא לעדכן ל-1.30.0 או ל-2.2.0, בהתאם לענף שבו משתמש הפרויקט. בתצורות machine-to-machine צריך גם להגדיר issuer מפורש. התיקון קושר בין מסמכי הגילוי, נקודת הרישום ונקודת האסימון לאותו מנפיק, ולכן שרת מרוחק אינו יכול להחליף יעד באמצע הזרימה.

השדרוג אינו מוחק מידע שנשמר קודם לכן. צוות הפרויקט ממליץ לנקות רישומי לקוח שמורים שנוצרו מול שרתי MCP שאינם מהימנים. אם יש חשש שחיבור כזה כבר בוצע, צריך להחליף client secrets, לבטל אסימונים שהונפקו ולבדוק יומני OAuth עבור יעדים חריגים. כדאי גם למפות אילו יישומים משתמשים ב-MCP דרך HTTP ואילו מהם מאפשרים למשתמשים להוסיף שרתים חיצוניים.

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