חדשות סייבר יומיות - 7 באוגוסט 2026

מה קרה

פגיעות use-after-free בסטאק הרשת SCTP של קרנל Linux, שקיימת מאז 2008, מאפשרת לתוקף מקומי להסלים להרשאות root ולברוח מקונטיינרים.

הבאג, שמזוהה כ-CVE-2026-64564 וכונה SCTPhantom על ידי חוקרי Tencent Zhuque Lab, נוצר בטיפול ב-dynamic address reconfiguration (ASCONF): הקרנל מאמת בקשת מחיקה מול כתובת המקור של החבילה, אבל פועל על נתיב אחר שנבחר מתוך ההודעה. רצף שנבנה במיוחד משחרר נתיב תעבורה ואז משתמש מחדש בפוינטר התלוי.

לא היה קוד ניצול פומבי בזמן הגילוי, והפגיעות לא מופיעה בקטלוג KEV של CISA. התיקון נכנס לקרנלים יציבים 7.1.6, 6.18.42, 6.12.101 ו-6.6.148 (שוחררו ב-3 באוגוסט).

מי מושפע

מערכות עם קרנלי Linux לא מעודכנים שבהם SCTP מופעל ונגיש, כולל הפצות נפוצות כמו Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 ו-OpenCloudOS.

נדרשת גישה מקומית; החשיפה מוגבלת לסביבות שבהן משתמשים ב-SCTP. חוקרים הדגימו בריחה מקונטיינר תחת פרופיל seccomp בברירת מחדל בלי capabilities מוגברות בחלק מהבדיקות. ספקים עשויים לבצע backport לתיקונים, כך שמספרי גרסה לבדם לא מספיקים.

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

עדכנו מיד לגרסת קרנל מתוקנת (7.1.6, 6.18.42, 6.12.101, 6.6.148 או מאוחרת יותר / מקבילה של ההפצה). בדקו את ה-security tracker של ההפצה שלכם ל-backports במקום להסתמך רק על מספרי גרסה upstream.

איפה ש-SCTP לא נדרש, השביתו אותו. עברו על runtimes של קונטיינרים, פרופילי seccomp ומדיניות user-namespace כדי להגביל חשיפת sockets ו-capabilities. עקבו אחרי פעילות SCTP חריגה.

מה קרה

מערכת HTTP Terminator מבוססת ה-AI של חוקר PortSwigger ג'יימס קטל (James Kettle) ייצרה ואימתה טכניקות HTTP desynchronization חדשות אחרי בדיקה של כ-30,000 וקטורים מועמדים שנגזרו מקטעי RFC.

היא זיהתה טריגרים חדשים כולל תבנית Content-Length עם התאמה כפולה ושיטת dangling-byte שמשפרת את אמינות response queue poisoning (RQP). שרשרת נפרדת בהנחיה אנושית חשפה zero-day של desynchronization ב-Apache Traffic Server שתוקן מאז.

בדיקות מול יעדי bug-bounty וגילוי מורשים מצאו כ-700 אתרים פגיעים, כולל בנקים, תשתיות ממשלתיות, מוצרי אבטחה ונמל תעופה. המערכת גם הציעה את Shared-Parser Confusion, שקטל אימת בהמשך.

מי מושפע

אתרים ותשתיות שמשתמשים ב-HTTP/1.1 בין שרתי front-end ל-back-end, וגם מפעילי Apache Traffic Server. הממצאים כללו יעדים פיננסיים, ממשלתיים ותשתיות קריטיות בסריקות מורשות.

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

למה זה חשוב

HTTP desync ו-response queue poisoning יכולים לגרום ל-front-end למסור תשובה של משתמש אחד (כולל עוגיות או מפתחות API) למשתמש אחר, ולאפשר גניבת פרטי הזדהות המונית או חטיפת סשן. הגילוי באמצעות AI של טכניקות חדשות מעשיות ושל zero-day מדגים גם את העוצמה של מחקר אוטומטי וגם את השבריריות המתמשכת של HTTP/1.1.

מפתחים ומפעילים חייבים להתייחס ל-request smuggling כסיכון ארכיטקטוני מתמשך ולא כמחלקת באגים שכבר נפתרה.

מה קרה

CISA הוסיפה את CVE-2026-63077, פגיעות קריטית לביצוע קוד מרחוק ללא אימות ב-JetBrains TeamCity, לקטלוג Known Exploited Vulnerabilities אחרי שאישרה ניצול פעיל בשטח.

הפגיעות היא deserialization של נתונים לא מהימנים בפרוטוקול agent polling. תוקף לא מאומת עם גישה רשתית לשרת TeamCity יכול לעקוף אימות ולהריץ פקודות OS שרירותיות בהרשאות של תהליך שרת TeamCity.

מושפעות גרסאות on-premise לפני 2026.1.3 ו-2025.11.7 (CVSS 9.8). JetBrains שחררה תיקונים ותוסף אבטחה; דדליין התיקון הפדרלי תחת BOD 26-04 הוא 8 באוגוסט 2026. פרטי קבוצות התקיפה והיקף הניצול עדיין לא ידועים.

מי מושפע

ארגונים שמריצים שרתי JetBrains TeamCity עצמאיים (on-premise) בכל גרסה לפני הגרסאות המתוקנות. התקנות TeamCity Cloud כבר תוקנו על ידי הספק.

שרתי CI/CD שמחזיקים קוד מקור, פרטי הזדהות, ארטיפקטים של בנייה וסודות pipeline הם מטרות בעלות ערך גבוה; פריצה מוצלחת יכולה להתגלגל לשרשראות אספקת תוכנה בהמשך.

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

שדרגו מיד את TeamCity on-premise ל-2025.11.7 או 2026.1.3. אם שדרוג מלא לא אפשרי, התקינו את תוסף האבטחה של JetBrains (זמין מ-2017.1 ואילך).

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

מה קרה

Unit 42 פרטה את ChainDrop, תולעת בעלת הפצה עצמית שהדביקה יותר מ-400 חבילות npm (שביחד הורדו מאות מיליוני פעמים בשבוע), כולל פופולריות כמו keyv ו-cacheable-request.

אחרי התקנה דרך preinstall hook שמשחרר ומריץ payload מוסתר (לעיתים דרך runtime של Bun), היא גונבת פרטי הזדהות לענן, טוקנים של npm/GitHub, מפתחות SSH וסודות מפתחים נוספים. היא סורקת פרטי הזדהות זמניים וטוקני OIDC מזיכרון תהליכי GitHub Actions runner, ואז משתמשת בטוקני npm גנובים כדי להדביק מחדש ולפרסם מחדש חבילות נוספות תוך שמירה על הפונקציונליות המקורית.

תשתית C2 מזוהה דרך חוזים חכמים ב-Ethereum וניתנת לקונפיגורציה מחדש בעסקה אחת. Persistence מושגת דרך משימות VS Code ו-hooks של Claude Code. Unit 42 זיהתה הרצה בסביבות מרובות וקישרה מאגרי GitHub ציבוריים ששימשו להוצאת נתונים (exfiltration).

מי מושפע

מפתחים, pipelines של CI/CD וארגונים שהתקינו אחת מיותר מ-400 גרסאות החבילות המושפעות. גם משתמשים בהמשך של תוכנה שנבנתה עם החבילות האלה בסיכון.

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

למה זה חשוב

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

השימוש ב-blockchain ל-C2 עמיד ומיקוד בכלי קידוד AI יחד עם סודות GitHub Actions מדגים איומים מתוחכמים ומודרניים באקוסיסטם npm שסריקת חבילות מסורתית לבדה עלולה לפספס.

איך אפשר היה למנוע את זה

זהו והסירו מיד גרסאות חבילות שנפגעו. בדקו מכונות מפתחים ו-CI runners לאיתור סימני פריצה, כולל קבצי .vscode או .claude לא צפויים, שימוש ב-Bun ופעילות רשת חריגה.

בטלו ובצעו רוטציה לכל פרטי ההזדהות שעלולים להיחשף ב-npm, GitHub, ענן, SSH ואוטומציה. עברו על פעילות npm publish ועל פעילות מאגרי GitHub מהזמן האחרון. חסמו דומיינים ידועים להוצאת נתונים וערוצים מבוססי GitHub. העדיפו lockfiles, בדיקות שלמות וטוקנים עם הרשאות מינימליות; שקלו כלים שמזהים חבילות זדוניות בזמן ההתקנה.

מה קרה

ב-Huntress זיהו תוקפים שניצלו SQL injection בפיצ'ר חיפוש autocomplete באפליקציית Java חשופה לאינטרנט (על Apache Tomcat) כדי לקמפל ולאחסן ערכת כלים מלאה לפוסט-אקספלויטציה בשם khunt ישירות בתוך מסד נתונים Oracle כאובייקטי schema ומחלקות Java.

האפליקציה העבירה קלט לא מאומת דרך JDBC עם חשבון שיכול ליצור אובייקטי Java. ה-JVM המשובץ של Oracle קימפל את המקור לאובייקטים מאוחסנים. המודולים סיפקו shell פקודות Windows, חילוץ פרטי הזדהות מטבלת המשתמשים של Oracle, סייר קבצים, unzip, בדיקות reachability ו-wrappers ב-PL/SQL.

מתוך מסד הנתונים התוקפים פתחו shell עם הרשאות SYSTEM, השתמשו ב-PowerShell ובכלים כדי להכין hives של SAM/SECURITY/SYSTEM לחילוץ פרטי הזדהות, ומיפו שירותים. הפעילות יוחסה ל-IP בודד דרך לוגי Apache. הזיהוי הגיע אחרי התראות על גניבת פרטי הזדהות ב-27 ביולי; הניתוח פורסם ב-5 באוגוסט.

מי מושפע

ארגונים שמריצים מסדי נתונים Oracle הנגישים דרך אפליקציות שמאפשרות SQL injection ומשתמשות בחשבונות DB עם הרשאות יתר שיכולים ליצור אובייקטי Java. המקרה שנצפה כלל מארח Windows עם Oracle ואפליקציית Java על Tomcat.

כל סביבה שבה לחשבון מסד הנתונים יש הרשאות CREATE JAVA או דומות, והאפליקציה בלי סינון קלט, חשופה לטכניקת living-off-the-database הזו.

למה זה חשוב

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

כך SQL injection נפוץ הופך לפוסט-אקספלויטציה בעלת השפעה גבוהה תוך עקיפת EDR קונבנציונלי, ומדגיש את הצורך בניטור מודע למסד נתונים ובחשבונות DB עם הרשאות מינימליות.

איך אפשר היה למנוע את זה

חסלו SQL injection באמצעות סינון קלט תקין, שאילתות עם פרמטרים (parameterized) ו-prepared statements על כל קלט בשליטת המשתמש. ודאו שחשבונות מסד הנתונים של האפליקציות אינם עם הרשאות יתר - במיוחד שללו CREATE JAVA או הרשאות מקבילות אלא אם נדרש בהחלט.

נטרו ב-Oracle יצירה לא צפויה של מקור Java או אובייקטי schema ו-wrappers ב-PL/SQL. הפעילו לוגים של פעילות מסד נתונים והתריעו על הרצת פקודות חריגה או גישה ל-hives. יישמו הרשאות מינימליות לחשבון ה-OS שמריץ את שירות Oracle והגבילו את חשיפת הרשת של מסד הנתונים.

מה קרה

קונור ריילי מוקה (Connor Riley Moucka), קנדי בן 26 הידוע גם אונליין כ-Waifu ו-Judische, הודה באשמה בפריצה ליותר מ-165 ארגונים שהשתמשו בפלטפורמת הנתונים בענן Snowflake, בגניבת מיליארדי רשומות ובסחיטת קורבנות.

לפי משרד המשפטים האמריקאי, הוא ושותפיו השיגו יותר מ-2.5 מיליון דולר בתשלומי כופר וכ-500 אלף דולר ממכירת נתונים בפורומים כמו BreachForums. הקורבנות כללו את AT&T (רשומות שיחות והודעות של יותר מ-100 מיליון לקוחות), LendingTree ו-Ticketmaster; סך הנזקים לקורבנות הוערך ב-9.5 מיליון דולר. מוקה נעצר בקנדה בסוף 2024 ויעמוד לגזר דין ב-27 באוקטובר, עם פוטנציאל לעשרות שנים בכלא.

מי מושפע

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

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

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

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

יישמו סיווג נתונים, טוקניזציה ובקרות יציאה (egress) כך שגם חשבונות שנפרצו לא יוכלו לשלוף בקלות כמויות גדולות של רשומות רגישות. בדקו נתיבי גישה של צדדים שלישיים וקבלנים למחסני הנתונים.

מה קרה

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

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

מי מושפע

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

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

למה זה חשוב

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

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