WhatsApp API לא רשמי: מה פרשת אוריך מלמדת על פרטיות

מה קרה בפרשת אוריך, ומה ידוע בוודאות?

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

החלק הראשון הוא קוד פתוח בטעות. לפי Haaretz, אוריך בנה בעזרת Claude כלי שסורק עשרות מקורות חדשות כל 90 שניות ושולח סיכומים לקבוצת WhatsApp, והעלה את הקוד ל-GitHub. לפי Calcalist הקוד חשף מידע רגיש, פרטים טכניים, מזהים ייחודיים ואסימוני גישה לקבוצות שקיבלו את ההתראות. אחרי פנייה של Haaretz הגישה שלו ל-GitHub הוגבלה, אבל הקוד כבר הועתק והופץ (Calcalist).

החלק השני הוא החיבור ל-Ultramsg. לפי Calcalist, אוריך השתמש בשירות Ultramsg וחיבר אליו את חשבון ה-WhatsApp האישי שלו ולא חשבון ייעודי, כך אמר חוקר אבטחה עצמאי. שירותים כאלה מתחברים בסריקת QR, כמו הוספת מכשיר נוסף. Calcalist כתב שהמצב "יכול" לאפשר לרשויות באיחוד האמירויות גישה לתקשורת לפי החוק המקומי, ושאין ראיה שזה קרה (Calcalist, Yeshiva World).

החלק השלישי הוא הדליפה עצמה. ב-11 באוקטובר 2026 התפרסמו ברשת צילומי שיחות שמיוחסים לאוריך עם כמה אנשי תקשורת ויועצים. Haaretz מסר שאימת את הדליפה. לפי הודעה שפורסמה בחשבון ה-X של אוריך ומיוחסת לעורכי דינו, החשבון נפרץ ושהחומר שונה, ואיימו בתביעות (Times of Israel). מי פרסם ואיך השיחות הושגו עדיין לא ידוע, וגם לא אם יש קשר ל-Ultramsg.

איך שירות לא רשמי מקבל גישה להודעות שלכם?

WhatsApp מצפין הודעות מקצה לקצה, ולכל מכשיר מקושר יש מפתח זהות משלו (Meta Engineering). המשמעות ההפוכה חשובה לא פחות: מי שמפעיל את המכשיר המקושר, מחזיק מפתחות ויכול לקרוא.

כשסורקים QR, קורים שני דברים. הטלפון מאשר מכשיר חדש, וגם מעביר אליו חבילה מוצפנת של הודעות מהצ'אטים האחרונים, כפי שמתאר הבלוג ההנדסי של Meta על תמיכה בריבוי מכשירים (Meta Engineering). המנגנון מאפשר אפוא להעביר למכשיר המקושר גם היסטוריה, לא רק הודעות עתידיות.

שירותים לא רשמיים מהסוג הזה עובדים על העיקרון הזה. Green API מתעד חיבור בסריקת QR או בקישור לפי מספר טלפון, והחברה רשומה כ-Green-API LLC באסטנה, קזחסטן (תיעוד Green API). WAAPI מופיע במדריכי השוואה כאחת האפשרויות הלא רשמיות (DEV Community). לא מצאנו דיווח ציבורי על דליפה אצל אף אחד משניהם, וגם לא בדיקה עצמאית של אופן הטיפול שלהם בנתונים. הסיכון שמתואר כאן הוא של המודל, לא האשמה נגד ספק מסוים.

מה Cloud API הרשמי שונה בו?

אפשר להניח ש"רשמי" אומר שאף אחד לא קורא. זה לא נכון, וכדאי לדעת בדיוק מה כן משתנה.

לפי התיעוד של Meta, ב-Cloud API ההצפנה היא בין המשתמש לבין ה-Cloud API שפועל בשם העסק. ההודעה מפוענחת שם ומועברת לעסק, ונשמרת עד 30 יום כנדרש לפעולת המערכת (Meta, Data privacy and security). העסק, וכל ספק פתרונות שבדרך, יראו את התוכן. הכלל הפרקטי: מי שמפעיל את החיבור יכול לקרוא.

ההבדל הוא במה שנכנס לחיבור, ובמסגרת החוזית:

חלק מהשורות מבוסס על מסמכי הפרויקטים עצמם. Baileys היא ספרייה שמממשת מחדש את פרוטוקול WhatsApp Web ומתחברת כמכשיר מקושר, ו-Evolution API בנוי עליה (Evolution API ב-GitHub). ה-README של פורט פייתון של הספרייה מזהיר שהשימוש עלול להפר את תנאי השימוש של WhatsApp ולהוביל לחסימה (WAeys). טייגרצ׳אט מציעה גם Cloud API רשמי וגם חיבור QR לא רשמי, ולכן יש לנו אינטרס בנושא, והסתמכנו כאן על מקורות חיצוניים. הכלל חל גם עלינו: בחיבור ה-QR שלנו אנחנו מפעילים את השרת, המערכת מתחברת כמכשיר מקושר ויכולה לגשת לשיחות של המספר, ונשאר סיכון לחסימה. לכן חברו אליו רק מספר עסקי, לא אישי.

האם שרת עצמאי פותר את הבעיה?

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

מה כן אפשר לעשות הוא לצמצם מה נשמר. בקובץ הדוגמה של Evolution API יש דגלים נפרדים לשמירת הודעות חדשות, עדכוני הודעות, אנשי קשר וצ'אטים (DATABASE_SAVE_DATA_NEW_MESSAGE, DATABASE_SAVE_MESSAGE_UPDATE, DATABASE_SAVE_DATA_CONTACTS, DATABASE_SAVE_DATA_CHATS), וכולם מופיעים כ-true (Evolution API, .env.example). כיבוי שלהם מקטין את מה שנשאר בדיסק אחרי המסירה. ההודעה עדיין עוברת בזיכרון ובכל webhook שמוגדר, ולכן זה צמצום ולא עיוורון.

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

מה לבדוק לפני שמחברים WhatsApp לשירות כלשהו?

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

• חיבור של מספר אישי. חשבון אישי מכיל משפחה, ספקים וכסף. חברו רק מספר ייעודי.
• קבלת תנאי שמירה בלי לקרוא. שאלו כמה זמן הנתונים נשמרים, איפה, ומי רשאי לקבל אותם. ב-Ultramsg, לפי הציטוט, מדובר ב-120 יום ובהרשאה להעביר נתונים לצדדים שלישיים.
• אסימונים במאגר קוד. מפתח API, מזהה קבוצה או webhook בקוד שעולה ל-GitHub מפורסם לכולם. גם מאגר פרטי שהפך לציבורי בטעות נחשב דליפה.
• פרטי קשר של אחרים בקוד. מספרים של לקוחות או בעלי תפקידים לא שייכים לקוד המקור.
• שכחה של מכשירים מקושרים. ב-WhatsApp, תחת "מכשירים מקושרים", אפשר לראות ולנתק כל חיבור. עברו על הרשימה אחרי כל ניסוי.
• קוד שנבנה ב-AI ולא נבדק. תנו לסוכן הקוד שלכם תפקיד תוקף: בקשו ממנו לחפש בפרויקט סודות חשופים, endpoints בלי אימות ומזהים שלא אמורים להופיע בקוד. זו המלצה שלנו, לא ממצא מהפרשה, והיא לא מחליפה בדיקת אבטחה אנושית.

בישראל יש גם הקשר משפטי. תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף ב-14 באוגוסט 2025, במטרה לחזק את זכויות הגנת הנתונים וליישר קו עם ה-GDPR (Pearl Cohen). האם הדבר חל על עסק מסוים, ומה חלות החובות מול ספק מעבד, נבדק מול יועץ משפטי ולא מתוך פוסט.

בשורה התחתונה

• הסיכון בשירות WhatsApp לא רשמי הוא מבני: סריקת QR מוסיפה מכשיר מקושר שיכול לקרוא טקסט גלוי, והמנגנון מאפשר להעביר אליו גם היסטוריה אחרונה.
• פרשת אוריך כוללת שלושה חלקים נפרדים: קוד חשוף ב-GitHub, חשבון אישי שחובר ל-Ultramsg ודליפת שיחות שמקורה לא ידוע. הקשר בין שלושתם לא הוכח.
• Cloud API הרשמי לא מסתיר את התוכן מהעסק והספק, אבל הוא מגביל את החשיפה למספר עסקי ייעודי ומעגן אותה בחוזה.
• שרת עצמאי מצמצם צד שלישי ושמירה בדיסק, ולא מבטל את הגישה של המפעיל.
• חברו רק מספר ייעודי, קראו את תנאי השמירה, הרחיקו אסימונים מהקוד, ובקשו מסוכן הקוד שלכם לנסות לפרוץ את מה שהוא בנה.

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