חדשות סייבר יומיות - 19 בספטמבר 2026

מה קרה

חוקרים ב-AIR חשפו פגיעות remote code execution ללא קליק, שכונתה Plugin4Shell, שמשפיעה על ארבעה סוכני קידוד AI מרכזיים: Claude Code, Codex, GitHub Copilot ו-Gemini CLI.

הפגם הוא עקיפת SHA-pinning של תוספים. הסוכנים מבצעים checkout ל-commit נעוץ בלי לוודא שהפעולה הצליחה, וכך תוקף יכול להחליף קוד זדוני בזמן שה-pin נראה תקין. Claude Code, Codex ו-GitHub Copilot חולקים וריאנט שקשור לטיפול בשמות git branch; ל-Gemini CLI יש בעיית fetch/checkout נפרדת עם אותה תוצאה. עדכונים אוטומטיים ברקע, שהם ברירת מחדל בחלק מהסוכנים, מריצים מחדש את ה-checkout כש-marketplace מעדכן את ה-SHA הנעוץ, ומספקים את ה-payload בלי שום פעולה מצד המשתמש.

AIR מצאה את הבאג במאי 2026 עם proofs-of-concept עובדים נגד כל הארבעה, חשפה אותו בחודש העוקב, והדגימה שרשראות מקצה לקצה שכללו הפצה מוקדמת של תוסף ליותר מ-26,000 סוכנים והשתלטויות SkillJacking על 925 skills שהגיעו ל-134,000 סוכנים. שני סוכנים נותרו ללא תיקון בזמן הדיווח.

מי מושפע

כל מי שמריץ Claude Code, Codex, GitHub Copilot או Gemini CLI ומתקין תוספים מ-marketplace חשוף, גם משתמשים שנועצים תוספים שנבדקו בדיוק כמתוכנן.

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

למה זה חשוב

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

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

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

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

העדיפו סוכנים או marketplaces שאוכפים אימות commit קפדני ודוחים שמות branch שמתנגשים עם hashes. נטרו התנהגות תוספים חריגה, שללו גישת marketplace מיותרת, והחילו תיקוני ספקים מיד כשהם זמינים. בדקו תוספים מותקנים והסירו כל תוסף ממקורות פחות מהימנים. הגבילו הרשאות runtime של הסוכן ובדדו אותם מפרטי הזדהות של production ומ-repositories רגישים.

מה קרה

CISA הוסיפה שלוש פגיעויות בקרנל של Linux לקטלוג Known Exploited Vulnerabilities שלה ב-18-19 בספטמבר 2026, ואישרה ניצול בפועל בשטח.

CVE-2025-39682 (CVSS 9.8) היא בדיקה לא תקינה של תנאים חריגים בנתיב הקבלה של TLS, שיכולה לאפשר למשתמשים מקומיים מאומתים לגרום לחשיפת זיכרון או למניעת שירות. CVE-2026-53266 (CVSS 8.8) היא כתיבה מחוץ לגבולות בנתיב SNAT ARP rewrite של ebtables, שמאפשרת התנהגות לא מכוונת, DoS או הסלמת הרשאות מקומית. CVE-2025-39964 (CVSS 7.8) היא race condition שמאפשרת כתיבות מקבילות לאותו AF_ALG socket, ומובילה לקריסות, השחתת תוצאות קריפטוגרפיות, DoS או בעיות שלמות.

Red Hat עדכנה advisories שמכירים באקספלויטים ציבוריים ידועים ובעדיפות גבוהה. עדיין אין פרטים ציבוריים על שיטות הניצול המדויקות או האם הן מרכיבות שרשרת אחת. גילויים נפרדים של חוקרים על ארבע פגיעויות הסלמת הרשאות מקומיות נוספות (כולל DirtyAH6 ואחרות) צוינו אך לא נוספו ל-KEV באותו זמן.

מי מושפע

מערכות Linux שמריצות גרסאות קרנל פגיעות הכוללות את נתיבי TLS, netfilter/bridge ebtables ו-AF_ALG crypto המושפעים. משתמשים מקומיים מאומתים או תוקפים שכבר השיגו דריסת רגל יכולים להפעיל אותן.

סוכנויות Federal Civilian Executive Branch עומדות בפני מועד יעד BOD של 21 בספטמבר 2026. ארגונים, ספקי ענן וכל ארגון עם מארחי Linux ללא תיקון חשופים, במיוחד כאלה שמאפשרים גישה מקומית או עומסי multi-tenant.

למה זה חשוב

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

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

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

החילו תיקוני קרנל ועדכוני ספקים מיד, ותעדפו את שלושת ה-CVEs ב-KEV. Red Hat ומפיצים אחרים פרסמו advisories; אתחלו לתוך הקרנל המתוקן.

עבור סוכנויות פדרליות, עמדו במועד היעד של ה-BOD ב-21 בספטמבר 2026. הגבילו גישה מקומית של משתמשים לא מהימנים, הפעילו תכונות הקשחת קרנל, נטרו פעילות TLS/netfilter/crypto חריגה, ושמרו על מערכות מעודכנות עם ניהול תיקונים אוטומטי. שקלו צעדי מיטיגציה זמניים כמו פריקת מודולים שאינם בשימוש אם התיקונים מתעכבים.

מה קרה

צוות של שלושה מ-Hacktron השתמש ב-Claude Opus 4.8 ו-5 של Anthropic כדי לפרוץ לחשבונות עובדי OpenAI בפחות מ-72 שעות, לפי דיווחים.

הם השיגו גישה דרך Discourse (תוכנת הפורומים מצד שלישי שמארחת את פורומי הקהילה של OpenAI) בניצול בעיה בעיבוד תמונות HEIF. המודל Claude סייע להשיג remote code execution ב-Discourse Cloud תוך שעות מהשקת Opus 5, ואז לעבור לסביבה של OpenAI. משם הגיעו לחשבון Codex של עובד ול-GitHub Monorepo הפנימי של OpenAI (שנטען כי הוא מכיל סודות אלגוריתמיים).

החוקרים נמנעו מקריאת קוד פנימי, אך הוכיחו את הגישה בשליחת pull request מחשבון העובד. טכניקת HEIF Heist שלהם הותאמה במהירות ליעדים נוספים, כולל Slack, Meta, GitHub ועוד, בעלות token נמוכה.

מי מושפע

חשבונות עובדי OpenAI ומערכות שניתן להגיע אליהן דרך סביבת Discourse של הקהילה, לצד ה-Monorepo. הגדרות דומות של Discourse או של עיבוד HEIF בארגונים אחרים שהחוקרים בדקו (Slack, Meta, GitHub Enterprise, Rails, Next.js, ImageMagick ואחרים) חולקות את הסיכון הבסיסי.

כל חברה שמשתמשת ב-Discourse Cloud או בספריות עיבוד תמונה פגיעות לקבצי HEIF שהמשתמשים מעלים חשופה פוטנציאלית.

למה זה חשוב

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

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

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

עדכנו מיד את Discourse וכל ספריות עיבוד תמונות HEIF; השביתו את תמיכת HEIF או הכניסו אותה ל-sandbox קפדני אם אינה נדרשת. אכפו הרשאות מינימליות על חשבונות עובדים, דרשו מפתחות חומרה או MFA חזק, ונטרו pull requests חריגים או סשנים שמקורם בפורום.

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

מה קרה

קבוצת Google Threat Intelligence Group חשפה שאנליסט סמוי של Mandiant חדר לקבוצת התקיפה בשרשרת האספקה TeamPCP כמעט מתחילת הקמפיין הבולט שלה, מה שאפשר ניטור בזמן אמת, אזהרות לקורבנות ותמיכה בשיבוש הפעילות.

קבוצת התקיפה TeamPCP זיהמה מאות חבילות קוד פתוח, גנבה פרטי הזדהות של מפתחים במתקפות מדורגות, ושחררה תולעת שמתפשטת מעצמה, תוך פריצה ליותר מאלף חברות. בין הפרויקטים שנפרצו נמנו Trivy, LiteLLM, תשתית Checkmarx, TanStack ואחרים. שני חברים לכאורה מאוסטרליה, בתחילת שנות העשרים לחייהם, נעצרו בחודש שעבר בסיוע ה-FBI.

Google קיבלה גם מודיעין מ-ShinyHunters (שותף לשעבר שהתהפך) ועקבה אחרי טעויות באבטחה התפעולית שסייעו בזיהוי. פרטי החדירה הוצגו ב-LABScon.

מי מושפע

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

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

למה זה חשוב

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

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

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

קבעו תלויות לגרסאות מדויקות ומאומתות או ל-hashes, הפעילו lockfiles, והשתמשו ב-mirrors פרטיים או ב-allow-lists לחבילות קריטיות. נטרו אירועי publish בלתי צפויים, פעילות maintainers חריגה, וסימנים לגניבת פרטי הזדהות במחשבי מפתחים.

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

מה קרה

CrowdSec דיווחה כי ב-22 במאי תוקף השתמש בחשבון GitHub שעדיין היה פעיל של עובד לשעבר כדי להעתיק כ-170 מהמאגרים הפרטיים שלה. המחשב הנייד נפרץ קודם לכן דרך מתקפת שרשרת האספקה ב-npm של TanStack ממאי 2026 (CVE-2026-45321).

גרסאות זדוניות של 42 חבילות TanStack (84 גרסאות בסך הכול) פורסמו ב-11 במאי וגנבו tokens של GitHub, מפתחות SSH ופרטי הזדהות לענן. השימוש ב-OAuth token מחשבון העובד לשעבר איפשר את ההעתקה; CrowdSec השאירה את הגישה פתוחה כדי שהאדם יוכל לסיים עבודה. החשבון הוסר ב-25 במאי. הארכיון הופיע בפורום ב-16 בספטמבר וכלל קוד מקור לצד כתובות דוא"ל של 83 משתמשים ופרטים על 51 משקיעים פוטנציאליים מ-2020.

CrowdSec מציינת שהתשתית ומסדי הנתונים לא נפרצו, הקוד לא שונה, והקוד שדלף הוא בן חודשים. GitHub אישרה בהמשך את הקשר ל-TanStack. אירועים דומים שמקורם ב-TanStack פגעו במכשירי מפתחים של Mistral AI ו-OpenAI.

מי מושפע

CrowdSec (מאגרים פרטיים, חלק מכתובות הדוא"ל של משתמשים, ונתוני משקיעים ישנים) וכל ארגון שמפתחיו התקינו את חבילות ה-npm הזדוניות של TanStack במאי 2026. OpenAI ו-Mistral AI ציינו בפומבי מכשירי עובדים שנפגעו והגבילו גישה למאגרים פנימיים.

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

למה זה חשוב

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

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

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

שללו מיד גישה לעובדים שעוזבים ובצעו רוטציה לכל ה-tokens, המפתחות והרשאות ה-OAuth. אכפו פרטי הזדהות קצרי חיים, MFA מבוסס חומרה, וגישת just-in-time ל-GitHub.

הצמידו חבילות npm לגרסאות מאומתות, השתמשו ב-lockfiles וב-registries פרטיים, סרקו endpoints של מפתחים אחרי כל התראת שרשרת אספקה, ונטרו את GitHub לשימוש חריג ב-clone או ב-token. בדקו וצמצמו סודות שמאוחסנים בתחנות עבודה. יישמו את הלקחים מ-CVE-2026-45321 והתייחסו לאקוסיסטמות של חבילות פופולריות כאל סיכון גבוה.

מה קרה

חוקרים מאוניברסיטת Massachusetts Amherst ניתחו 61,500 אפליקציות Android נלוות ל-IoT שננטשו (ללא עדכונים במשך שנתיים או שהוסרו מ-Play Store עד מרץ 2025) ומצאו שכמעט שלוש מכל ארבע הכילו תלויות הקשורות לפגיעויות מוכרות, רבות מהן בחומרה גבוהה.

האפליקציות, שמשמשות לשליטה בשקעים חכמים, מצלמות, תרמוסטטים ומכשירים דומים, עדיין נצברו להן בין אלפי ליותר מ-100 מיליון הורדות היסטוריות. הן משלבות דומיינים hard-coded; כרבע מהם כבר לא נפתרים, בכל אפליקציה היה לפחות FQDN אחד שאינו נגיש, חלק מהדומיינים החליפו בעלות (השפעה על יותר מ-2,000 אפליקציות), ובערך אחת מכל תשע כתובות תאמה blocklists של מודיעין איומים לפישינג, תרמיות, רוגלות או נוזקה. יותר משני שלישים מהאפליקציות הכילו לפחות דומיין אחד ברשימת חסימה.

האפליקציות מבקשות הרשאות רגישות (אחסון, מיקום מדויק, מצלמה) ושולחות נתונים בעיקר דרך Wi-Fi; 38.4% במדד מפתח הקשור לנטישה הצביעו על חשיפה מתמשכת, כי אפליקציות נטושות אינן יכולות להסתגל כש-endpoints קורסים.

מי מושפע

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

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

למה זה חשוב

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

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

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

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

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

מה קרה

ה-FBI תפסה דומיינים הקשורים ל-NightmareStresser (nightmare-stresser.com ו-nightmarestresser.org), אחד משירותי ה-DDoS-for-hire הוותיקים ביותר, במסגרת המבצע הבינלאומי Operation PowerOFF.

השירות פעיל לפחות מאז 2022 (חוקרים מתחקים אחרי פופולריות מוקדמת יותר, בשיאים של 2016-2019), הפעיל מאות אלפי התקפות ברחבי העולם, צמח לכיוון מיליון משתמשים, ויכול היה להפעיל 3,000-4,000 התקפות בשעה. הוא קיבל מטבעות קריפטו ועל פי דיווחים נמנע מיעדי ממשלה, חינוך ובתי חולים. מבקרים רואים כעת באנר תפיסה.

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

מי מושפע

מפעילי שירות ה-booter/stresser NightmareStresser ולקוחותיו, לצד הארגונים והפרטים הרבים שכבר היו יעד להתקפות ה-DDoS שלו ברחבי העולם.

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

למה זה חשוב

פלטפורמות DDoS-for-hire מורידות את הרף לכל אחד שמעוניין להפעיל התקפות משבשות בכמה קליקים ותשלום בקריפטו, ומזינות סחיטה, שיבוש משחקים והשבתות אופורטוניסטיות.

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