ה־FBI אישר כי כשל בעדכון אבטחה בפלטפורמה שנוהלה בידי ארגון צד שלישי הוביל לדליפה של מידע אישי רגיש על אלפי עובדי הבולשת. שני מקורות שמכירים את הפרטים מסרו לרויטרס כי מדובר במערכת Oracle PeopleSoft וכי הגורם החיצוני היה Accenture. הבולשת עצמה לא זיהתה בפומבי את המערכת או את החברה.
לפי דיווח רויטרס מ־6 באוקטובר 2026, המידע שנחשף כלל פרטי תפקיד, כתובות ואף מידע רפואי ופסיכיאטרי של עובדים. ראש מערך הסייבר של ה־FBI, ברט לתרמן, מסר כי קבלן לא הטמיע תיקון אבטחה שנועד להגן על הפלטפורמה, וכי הקבלן הוסר והבולשת נקטה צעדים לצמצום הסיכון ולהגנת כוח האדם.
מה ידוע — ומה עדיין מבוסס על מקורות
חשוב להפריד בין מה שאושר רשמית לבין פרטים שיוחסו למקורות. ה־FBI אישר את עצם כשל האבטחה אצל צד שלישי ואת הסרת הקבלן, אך לא נקב בשם המוצר או החברה. שני מקורות זיהו בפני רויטרס את PeopleSoft ואת Accenture. רויטרס לא הצליחה לזהות את האדם הספציפי או לקבוע את מצב העסקתו הנוכחי, ו־Accenture לא התייחסה לטענה המפורטת על אי־התקנת התיקון.
קבוצת התקיפה ShinyHunters קיבלה אחריות וטענה שניצלה חולשה ב־PeopleSoft. טענות של קבוצות תקיפה אינן הוכחה עצמאית, אולם הן משתלבות באזהרות קודמות של חוקרי אבטחה ובפרטי החולשה שפורסמו.
הרקע הטכני: CVE-2026-35273 ונתיב PSEMHUB
Google Threat Intelligence Group ו־Mandiant דיווחו כבר ביוני על ניצול פעיל של CVE-2026-35273 ב־Oracle PeopleSoft, חולשה קריטית שאפשרה במקרים מסוימים גישה מרחוק ללא אימות. בספטמבר פרסמה גוגל עדכון על גל ניצול מחודש, כולל שימוש בנתיב מקודד כדי לעקוף כללי WAF פשוטים.
המסקנה אינה ש־WAF חסר ערך, אלא שהוא אינו תחליף לתיקון היצרן. במערכות ERP ותיקות, שבהן כל שינוי דורש בדיקות תאימות, קל לדחות עדכון. אבל כאשר קיימת חולשה מנוצלת בפועל, יש לנהל את הדחייה כהחרגת סיכון מתועדת עם בקרות מפצות, לוח זמנים ובעל אחריות ברור.
מה ארגונים שמפעילים PeopleSoft צריכים לבדוק
- מיפוי גרסאות ותיקונים: לוודא אילו סביבות חשופות, מה רמת ה־PeopleTools שלהן ואילו Critical Patch Updates הותקנו בפועל.
- השבתת רכיבים מיותרים: אם EMHub אינו נדרש, לבדוק את הנחיות Oracle ו־Mandiant להשבתתו או להסרת PSEMHUB.
- חיפוש סימני חדירה: לסרוק יומני שרת ו־WAF אחר בקשות חריגות, נתיבים מקודדים, קבצים חדשים, תהליכים לא מוכרים וחיבורי יציאה בלתי צפויים.
- החלפת סודות: אם קיים חשד לפגיעה, להחליף סיסמאות, מפתחות וסודות שירות לפי תוכנית תגובה מסודרת — לא לפני איסוף ראיות בסיסי.
- בדיקת ספקים: לדרוש SLA לתיקונים קריטיים, תיעוד הטמעה, חלוקת אחריות ברורה וזכות ביקורת. אישור בעל פה ש״העדכון בוצע״ אינו מספק.
- הגנת מידע אנושי: לזהות אילו נתוני עובדים נשמרים במערכת, לצמצם הרשאות ולתרגל תגובה לדליפה הכוללת כתובות ומידע בריאותי.
כפי שמדגיש אריאל מרום, שעוסק בתשתיות IT, ענן וסייבר, כשלי תיקון אינם רק בעיה טכנית: הם נקודת מפגש בין ניהול נכסים, חוזי ספקים, המשכיות עסקית ואחריות הנהלה. בארגונים שמסתייעים בגורם חיצוני, מומלץ שהבעלות על הסיכון תישאר בתוך הארגון ולא תיעלם יחד עם המשימה שהועברה לספק.
לקריאה נוספת ב־ITPortal: ניצול פעיל של חולשת FortiMail ומה צריך לבדוק. שום רשימת בדיקה כללית אינה מבטיחה שהמערכת נקייה; אם נמצאו סימנים חשודים, יש לערב צוות תגובה מקצועי ולשמור ראיות.
תמונה ראשית: נוצרה באמצעות AI עבור מערכת ITPortal.
