וורדפרס 7.0.4: קובץ PNG אחד שמריץ קוד על השרת והפרצה שישבה בליבה 10 שנים

קוראים לה CVE-2026-65640, היא מקבלת 8.8 מתוך 10, והיא קיימת בליבת וורדפרס מאז 2016. אבל לפני שאתם נכנסים לפאניקה  יש שני תנאים שחייבים להתקיים כדי שהיא תעבוד, ורוב הסיכויים שאתם לא יודעים אם הם מתקיימים אצלכם. הנה איך בודקים ב-30 שניות.

הקדמה

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

ב-12 באוגוסט 2026 שוחררה גרסה 7.0.4. הפעם זו לא רשימה של 12 תיקונים; זה תיקון אחד, בקובץ אחד, והוא מטופל בדחיפות מסיבה טובה: הוא הופך הרשאה תמימה להעלאת תמונה ליכולת להריץ קוד על השרת שמאחסן את האתר שלכם.

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

מה בדיוק קרה

הפגיעות מתועדת כ-CVE-2026-65640 (ובייעוץ הרשמי: GHSA-8vr3-7mxf-gx8w), ודווחה באחריות על ידי צוות המחקר של pwn.ai אותו צוות שדיווח גם על הפרצה בגרסה הקודמת. הייעוץ הרשמי מדרג אותה High, בציון CVSS 8.8.

ההגדרה הרשמית: הרצת קוד מרחוק למשתמש מאומת בהרשאת Author ומעלה, דרך העלאת קובץ זדוני, באתרים שמשתמשים ב-Imagick וב-Ghostscript.

הקובץ היחיד ששונה בעדכון הוא wp-includes/class-wp-image-editor-imagick.php. זה כל העדכון. תיקון כירורגי, לא גרסה חדשה.

איך תמונה הופכת לקוד שרץ

הנה השרשרת, בשפה פשוטה:

1. תוקף עם חשבון Author מעלה קובץ בשם summer-sale.png. הסיומת אומרת "תמונה".
2. בפועל, תוכן הקובץ הוא לא תמונה אלא תוכנית PostScript.
3. וורדפרס בדק את הסיומת, ראה png, והעביר את הקובץ ל-Imagick לעיבוד (יצירת תמונות ממוזערות, סיבוב, חיתוך).
4. ImageMagick, בשונה מוורדפרס, מזהה קבצים לפי התוכן שלהם ולא לפי השם. הוא פותח את הקובץ, מבין שמדובר ב-PostScript, ומעביר אותו הלאה למי שיודע לפרש את זה Ghostscript.
5. Ghostscript, שהיסטוריית האבטחה שלו בתחום הזה ארוכה ומתועדת, מריץ את התוכנית. עם ההרשאות של תהליך ה-PHP שלכם.

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

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

מי חשוף באמת: שני תנאים, וחייבים את שניהם

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

התנאי	מה זה אומר בפועל	איך בודקים
1. השרת מריץ Imagick וגם Ghostscript	לא כל אחסון. הרבה שרתים משתמשים ב-GD ולא ב-Imagick, והרבה שרתים שכן מריצים Imagick לא התקינו לידו Ghostscript.	כלים ← בריאות האתר ← מידע ← טיפול במדיה
2. לתוקף יש חשבון עם הרשאת upload_files	בברירת מחדל: Author, Editor או Administrator. Contributor לא מספיק הוא לא יכול להעלות קבצים בכלל.	משתמשים ← כל המשתמשים, מיינו לפי תפקיד

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

"הרשאה גבוהה" זה לא מה שאתם חושבים

הרשאת Author נשמעת כמו משהו שנותנים בזהירות. במציאות של אתרי תוכן, מגזינים, בלוגים ארגוניים ואתרי לקוחות, זה נראה אחרת:

• כותב תוכן פרילנסר שסיים פרויקט לפני שנה והחשבון עוד פעיל
• סוכנות SEO עם משתמש Editor שנשאר אחרי סוף ההתקשרות
• אותה סיסמה שהמשתמש הזה מחזיק בשלושה שירותים אחרים, ואחד מהם הודלף
• אתרי רבי-מחברים עם עשרות חשבונות שאף אחד לא עבר עליהם מעולם

חשבון Author שנפרץ הוא בדרך כלל אירוע מוגבל: מישהו יפרסם ספאם, נמחק, נמשיך הלאה. עם CVE-2026-65640, אותו חשבון בדיוק הופך לדריסת רגל להרצת קוד על השרת. זה הבדל של סדר גודל בין "מטרד" לבין "אירוע סייבר".

ולמה דווקא אתרי אלמנטור צריכים לשים לב

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

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

איך בודקים אם אתם חשופים 30 שניות

1. באיזו גרסה אתם

לוח בקרה ← עדכונים. אם אתם על ענף 7.0 צריך להופיע 7.0.4.

2. איזה מנוע תמונות רץ אצלכם

כלים ← בריאות האתר ← מידע ← טיפול במדיה. המסך הזה מציג את עורך התמונות הפעיל ואת גרסאות ImageMagick, GD ו-Ghostscript. אם אתם רואים שם גם Imagick וגם Ghostscript התנאי הראשון מתקיים אצלכם, ואין מה להתלבט.

3. דרך WP-CLI, למי שמנהל יותר מאתר אחד

wp core version
wp core update
wp core verify-checksums
wp user list --role=author --fields=user_login,user_email,user_registered
wp user list --role=editor --fields=user_login,user_email,user_registered

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

לאיזו גרסה לעדכן

אם אתם על	עדכנו ל-
ענף 7.0.x	7.0.4
ענף 6.9.x	6.9.7
ענף 6.8.x	6.8.8
ענף ישן יותר (עד 4.7)	העדכון הזמין העדכני בענף שלכם או, עדיף, שדרוג ל-7.0.4
7.1 RC	RC3 ומעלה

שימו לב: התיקונים עוברים backport לכל הענפים עד 4.7, אבל הם משוחררים בהדרגה, ככל שהם מוכנים. באופן רשמי, רק הגרסה העדכנית ביותר של וורדפרס נתמכת באמת. ואם אתם מתכננים בכל מקרה לעבור ל-7.1 אל תחכו לזה. 7.1 עולה ב-19 באוגוסט, לוח זמנים נפרד לחלוטין. שבוע של חשיפה מיותרת.

ואם באמת אי אפשר לעדכן היום

קיימת מיטיגציה מוכרת ומתועדת שנים בצד ה-ImageMagick: חסימת ה-coders ממשפחת PostScript בקובץ ה-policy.xml של ImageMagick. זו פעולה ברמת השרת, לא ברמת האתר אם אתם בשרת מנוהל, זו שיחה עם ספק האחסון ולא משהו שעושים לבד. וחשוב להיות ברורים: זו רשת ביטחון זמנית, לא תחליף לעדכון.

צ'קליסט: מה עושים עכשיו

1. עדכנו את הליבה. לפי הטבלה למעלה. אתר בודד "עדכן עכשיו" מהדשבורד. עשרות אתריםwp core update.
2. הדליקו בחזרה עדכוני minor אוטומטיים. עדכוני האבטחה של וורדפרס הם מהיציבים שיש. הסיכון שהם ישברו עיצוב באלמנטור נמוך משמעותית מהסיכון להישאר חשופים שבועיים.
3. עשו סדר במשתמשים. כל Author, Editor ומנהל שלא נגע באתר חצי שנה להוריד להרשאת Contributor או למחוק. הפגיעות הזו נשענת על ההרשאה הזו בדיוק.
4. אימות דו-שלבי לכל מי שהוא Author ומעלה. ההגנה הזולה ביותר מול חשבון שנפרץ בסיסמה מודלפת.
5. בדקו את מנוע התמונות דרך בריאות האתר, כדי לדעת אם אתם בכלל בקבוצת הסיכון.
6. עברו על ספריית המדיה והלוגים. חפשו קבצי PHP חדשים תחת wp-content/uploads, העלאות בשעות מוזרות, משתמשי אדמין שלא אתם יצרתם, ומשימות cron לא מזוהות. במיוחד אם האתר היה על גרסה ישנה תקופה ארוכה.
7. וודאו שהרצת PHP חסומה בתיקיית ההעלאות. זו הקשחה בסיסית שמצמצמת דרמטית את הנזק בכל תרחיש של העלאת קובץ זדוני גם בפרצה הבאה, זו שעוד לא פורסמה.

מה עשינו ב-SPD

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

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

שורה תחתונה

CVE-2026-65640 הוא לא "עוד CVE". הוא תזכורת לשני דברים שקל לשכוח כשמנהלים אתר.

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

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

אם האתר שלכם על ענף 7.0 אל תסיימו את היום הזה על גרסה נמוכה מ-7.0.4.

מקורות: הודעת השחרור הרשמית של WordPress 7.0.4 (12.8.2026) והייעוץ הרשמי CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w. המאמר נועד למידע כללי ואינו מהווה תחליף לבדיקת אבטחה פרטנית לאתר שלכם.

לקריאה נוספת בבלוג:
וורדפרס 7.0.3: הפרצה שלא צריכה סיסמה ולמה דווקא אתרי אלמנטור צריכים לעדכן היום
wp2shell: הפרצה שגרמה לוורדפרס לדחוף עדכון בכוח למיליוני אתרים
Live Kernel Patching ולמה זה שינה את כללי המשחק