מהו למעשה CVE-2025-68613
CVE-2025-68613 משפיע על n8n, פלטפורמת אוטומציה של זרימת עבודה בקוד פתוח. הפגיעות היא הפעלת קוד מרחוק (RCE) בעיה ב-n8n מערכת הערכת ביטויי זרימת עבודה: בתנאים מסוימים, ביטויים המסופקים על ידי משתמשים מאומתים במהלך תצורת זרימת העבודה ניתן להעריך בהקשר של ביצוע שהוא לא מבודד מספיק מהסביבת הריצה הבסיסית. תוקף יכול לנצל התנהגות זו כדי להריץ קוד שרירותי עם הרשאות של תהליך n8n, מה שעלול להוביל לפגיעה מלאה באותו מופע (גישה לנתונים, שינוי זרימת עבודה, פעולות ברמת המערכת). (NVD)
הערך במאגר הפגיעות הלאומי (NVD) מראה כרגע כי העשרת הניקוד של NVD עצמה עדיין לא סופקה, אך היא מציג את ציון CNA מ-GitHub, Inc.: ציון בסיס CVSS v3.1 9.9 (קריטי) עם וקטור CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)
וקטור זה חשוב מבחינה תפעולית: הבעיה ניתנת לטיפול ברשת, מורכבותה נמוכה, היא דורשת הרשאות נמוכות בלבד, אינה מצריכה אינטראקציה מצד המשתמש, והיקפה השתנה — בדיוק הדפוס שנוטה להפוך "באג באפליקציה" ל"פגיעה בסביבה" כאשר השירות מחובר למערכות פנימיות.
מיפוי החולשות הוא CWE-913. MITRE מגדיר CWE-913 כבקרה לא נאותה על משאבי קוד המנוהלים באופן דינמי (משתנים, אובייקטים, מחלקות, תכונות, פונקציות, הוראות/הצהרות ניתנות לביצוע), התואמת את אופי הבעיה של "הערכת ביטוי חורגת מהבידוד המיועד". (cwe.mitre.org)
טבלה אחת שתוכלו להכניס לייעוץ אבטחה
| שדה | ערך (מאומת) | מקור |
|---|---|---|
| מוצר | n8n | (NVD) |
| סוג | RCE מאומת באמצעות כשל בבידוד הערכת ביטוי | (NVD) |
| גרסאות מושפעות | >= 0.211.0 ו- < 1.120.4 (בתוספת פרטי ענף קבועים) | (NVD) |
| גרסאות קבועות | 1.120.4, 1.121.1, 1.122.0 (NVD); GitHub ממליץ על 1.122.0+ | (NVD) |
| תנאים מוקדמים | התוקף חייב להיות מאומת (PR:L) | (NVD) |
| CVSS (CNA) | 9.9 קריטי; CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H | (NVD) |
| CWE | CWE-913 | (NVD) |
| הקלות לספקים | שדרוג; הגבלת יצירת/עריכת זרימות עבודה למשתמשים מהימנים לחלוטין; חיזוק הרשאות מערכת ההפעלה וגישה לרשת | (NVD) |
מדוע "נדרשת אימות" עדיין מצדיק טיפול דחוף
התייחסות לזה כאל "פחות דחוף כי זה מאומת" היא טעות נפוצה. ב-n8n, משתמשים מאומתים הם לרוב לא רק מנהלים; הם יכולים להיות בוני אוטומציה, מפעילי אינטגרציה או חשבונות שירות. ברגע שגבול הערכת הביטוי נשבר, התוקף אינו מוגבל לפעולות היישום — NVD מציין במפורש ביצוע קוד שרירותי עם הרשאות של תהליך n8n והאפשרות לפגיעה מלאה באינסטנס. (NVD)
בפועל, פלטפורמות זרימת עבודה מרוכזות שלוש תכונות שתוקפים אוהבים: קישוריות רחבה, סודות וביצוע לוגי. לכן, עליכם לבסס את תוכנית התגובה שלכם על וקטור CVSS (PR:L + S:C + C/I/A:H) ולא על האינטואיציה שלכם לגבי "נדרשת כניסה". (NVD)

אסטרטגיית תיקון שלא מתדרדרת לכאוס
המצב הסופי ה"נכון" הוא פשוט: להפעיל גרסה מתוקנת. NVD מציין את הבעיה כמתוקנת ב 1.120.4, 1.121.1 ו-1.122.0. (NVD)
הטקסט המייעץ של n8n/GitHub מדגיש כי הבעיה תוקנה ב- v1.122.0 וממליץ לשדרג ל 1.122.0 ואילך מכיוון שהוא "מציג אמצעי הגנה נוספים להגבלת הערכת הביטוי". (GitHub)
מבחינה תפעולית, הדבר מצביע על כלל פשוט:
אם אתה יכול להתקדם בבטחה, התכנס ב 1.122.0+; אם אתה קשור לרכבת שחרורים ספציפית, השתמש בגרסאות הקבועות המינימליות המצוין על ידי NVD תוך תכנון מעבר קדימה בהקדם האפשרי. (NVD)
הנה ביקורת בלבד בודק גרסאות שניתן להפעיל ב-CI, במארחים או במשימת צי (ללא לוגיקת ניצול, רק סימון גרסאות/סיכונים):
#!/usr/bin/env bash # CVE-2025-68613 n8n version audit (no exploitation) set -euo pipefail if command -v n8n >/dev/null 2>&1; then
VER="$(n8n --version | tr -d 'v' | head -n1)" else VER="${N8N_VERSION:-unknown}" fi echo "n8n version detected: $VER"
# טווח מושפע לפי הודעת GitHub: >=0.211.0 <1.120.4 # גרסאות מתוקנות לפי NVD: 1.120.4, 1.121.1, 1.122.0
if [[ "$VER" != "unknown" ]] && \\ [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && \\
[[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
[[ "$VER" != "1.120.4" ]]; then echo "דגל: עלול להיות מושפע מ-CVE-2025-68613. שדרג בהתאם להנחיות NVD/GitHub." exit 2 fi echo "אין דגל מבדיקה מהירה זו. אמת מול ההודעה הרשמית + פרטי הפריסה המדויקים שלך."

הקלות לטווח קצר
ה-NVD וההודעה של GitHub מספקים את אותן אמצעי מיתון לטווח הקצר: הגבלת הרשאות ליצירה/עריכה של זרימות עבודה ל- משתמשים מהימנים לחלוטין, ופריסת n8n ב- סביבה קשה עם הרשאות מערכת הפעלה מוגבלות וגישה לרשת כדי להפחית את ההשפעה — תוך ציון מפורש כי אמצעי ההפחתה הללו אינם מבטלים את הסיכון לחלוטין. (NVD)
אם ברצונכם שהדבר יהיה בר-אכיפה, "סביבה מחוסנת" צריכה להתורגם לבקרות בזמן ריצה. להלן סקיצה שמרנית של חיזוק מכולות כדי להפחית את מינוף הניצול לאחר הפריצה (הגנה מעמיקה):
שירותים: n8n: תמונה: n8nio/n8n:1.122.0 read_only: true tmpfs: - /tmp security_opt: - no-new-privileges:true
cap_drop: - ALL user: "1000:1000" environment: - N8N_LOG_LEVEL=info # התאם למדיניות הרשת / חומת האש: # דחה יציאה כברירת מחדל, אפשר רק יעדים נדרשים
איתור וציד איומים: התנהגות על פני חתימות שבירות
מכיוון שמנגנון ההפעלה הוא "ביטויים במהלך תצורת זרימת העבודה המוערכים בהקשר שאינו מבודד מספיק", ניתן לבנות זיהוי שימושי סביב מי עורך את זרימות העבודה, באיזו תדירות, ו מה עושה זמן הריצה לאחר מכן. (NVD)
גישה מעשית המתגברת על הבדלי יישום היא יצירת מתאם:
עריכות זרימת עבודה חריגות על ידי משתמשים בעלי הרשאות נמוכות (או חשבונות שירות) + ביצוע תהליכים חשודים / חיבורים יוצאים מסביבת ההפעלה n8n. הדבר עולה בקנה אחד עם הצהרת NVD לפיה ניצול מוצלח עלול להוביל לביצוע פעולות ברמת המערכת עם הרשאות תהליך n8n. (NVD)
דוגמה לרעיון auditd (התאם לסביבתך):
-a תמיד, יציאה -F arch=b64 -S execve -F comm=node -k n8n_exec -a תמיד, יציאה -F arch=b64 -S connect -F comm=node -k n8n_net
CVE n8n בעלי השפעה רבה הקשורים אליו, שכדאי לבדוק
אם הארגון שלכם מסתמך על n8n, אין להתייחס ל-CVE-2025-68613 כאל מקרה חד-פעמי. שתי דוגמאות סמוכות ממחישות נושא חוזר בפלטפורמות זרימת עבודה: תכונות שמטשטשות את הגבול בין תצורה לביצוע.
CVE-2025-65964 היא בעיה נפרדת ב-n8n הקשורה לצומת Git: NVD מתאר כי בגרסאות 0.123.1 עד 1.119.1 לא היו אמצעי הגנה מספקים למניעת RCE באמצעות הוקים של Git, שבהם פעולות זרימת עבודה יכלו להשפיע על תצורת Git (לדוגמה, core.hooksPath) ולגרום לביצוע הוקים; הבעיה תוקנה ב- 1.119.2. (NVD)
CVE-2025-57749 היא פגיעות במעבר סימולקינק ב-n8n's Read/Write File node לפני 1.106.0, שבו ניתן לעקוף את הגבלות הספרייה באמצעות קישורים סמליים, מה שמאפשר גישה לנתיבים שהיו מוגבלים אחרת. (NVD)
מדובר בבאגים שונים, אך הלקח זהה: מנועי זרימת עבודה נמצאים קרוב מדי ל"יכולות הקוד והמערכת", ולכן בידוד, מעקות בטיחות ברמת הצומת וגבולות הרשאות קפדניים אינם אופציונליים. ההגדרה CWE-913 של MITRE מסבירה מדוע בעיות אלה חוזרות ומופיעות כאשר משאבי קוד דינמיים עלולים להיות מושפעים באופן בלתי צפוי. (cwe.mitre.org)
אם המטרה שלכם היא לולאה סגורה של הנדסה — גילוי נכסים, אימות גרסאות, אימות תיקונים ודיווח ברמת ראיות — אז פלטפורמת זרימת עבודה אבטחה מונעת AI כמו Penligent יכולה להשתלב באופן טבעי בשלב "אימות תיקונים ורגרסיות". אם המטרה היחידה שלכם היא להפחית את סיכון הייצור באופן מיידי, הפעולה בעלת ההשפעה הגדולה ביותר נותרת: שדרגו לגרסאות המתוקנות והחילו את אמצעי ההפחתה לטווח הקצר של הספק עד שתוכלו. (NVD)

