תוספים פגיעים – זיהוי, עדכון והחלפה

תוסף שמופיע ברשימת ה-CVE של WPVulnerability.net או Patchstack אינו "סיכון תיאורטי" – הוא וקטור התקפה פעיל. תוקפים מנטרים את אותם מאגרים בדיוק שאתה משתמש בהם, ובאותו יום שפרסום הפגיעות יוצא, סורקים אוטומטיים מתחילים לחפש אתרים שמריצים את הגרסה הפגועה. החלון בין פרסום לבין ניצול מסיבי הוא לרוב שעות בודדות.

למה זה משנה

שלא כמו פגיעות "0-day" שדורשת ידע מתקדם, פגיעות שפורסמה ב-CVE מגיעה עם POC (Proof of Concept) – לעיתים קרובות סקריפט מוכן שכל אחד יכול להריץ. דוגמאות מהשנים האחרונות: SQL Injection ב-LiteSpeed Cache שאיפשר השתלטות על אתרים בלי authentication; Privilege Escalation ב-Elementor Pro שאיפשר ל-subscriber להפוך לאדמין; RCE ב-File Manager שאיפשר העלאת web-shell ישירה. אתרים שלא עודכנו תוך 24–48 שעות נפרצו בהמוניהם. ההשפעה לא מסתכמת ב"מישהו ייכנס לאתר" – פריצה מובילה להחזקה למניות SEO ספאם, גניבת מאגרי לקוחות, חסימת האתר בגוגל בגלל מאלוור, ולעיתים תביעה משפטית בשל דליפת פרטי משתמשים.

איך לזהות

RankPlus משווה את הגרסאות המותקנות מול מאגרי הפגיעויות הציבוריים. הדוח כולל את שם התוסף, הגרסה הנוכחית, גרסת ה-fix, חומרה (CVSS), וסוג הפגיעות (XSS, SQLi, RCE, Auth Bypass). ידנית, אפשר לבדוק כל תוסף ב-https://www.wpvulnerability.net/plugin/SLUG/ או ב-Patchstack DB. בנוסף, סטטוס "This plugin has not been tested with the latest 3 major releases of WordPress" בעמוד התוספים הוא דגל אדום – תוסף נטוש לרוב צובר פגיעויות שאיש לא יתקן.

איך לתקן

תרחיש פשוט – יש עדכון: גבה את האתר, גש ל-Plugins, לחץ "Update now". אם זה תוסף קריטי כמו WooCommerce או Elementor, בדוק תחילה ב-staging. אחרי ההתקנה הפעל את auto-updates:

// אכיפת auto-update בכל התוספים דרך mu-plugin
add_filter('auto_update_plugin', '__return_true');

תרחיש מורכב – אין עדכון: בדוק ב-WordPress.org את "Last updated". אם עברה שנה ויותר, התוסף נטוש. חפש חלופה פעילה (לדוגמה, את WP File Manager הנטוש החליף "File Manager Pro" של תוסף תחזוקה אחר). אם זה רכיב קריטי לאתר ואין חלופה מיידית, השבת את התוסף זמנית והוסף הגנה ברמת השרת:

<Files "vulnerable-script.php">
    Require all denied
</Files>

טעויות נפוצות

טעות ראשונה: לעדכן בלי גיבוי. תוסף לאחר עדכון יכול לשבור את האתר (תאימות PHP, ממשק חדש), ובלי גיבוי תקוע. טעות שנייה: לסמוך על תוסף מקור פתוח שלא עודכן 3 שנים – גם אם "עובד תקין", הוא לא נבדק מול גרסאות PHP חדשות וכמעט בוודאות מכיל פגיעויות סמויות. טעות שלישית: לעדכן את כל התוספים בו זמנית. אם משהו נשבר, לא תוכל לדעת איזה עדכון אחראי. עדכן בקבוצות של 3–5 תוספים, בדוק בין לבין.

בדיקה לאחר תיקון

אחרי העדכון הרץ שוב את האודיט – הבדיקה צריכה לעבור. אם בחרת בחלופה, הסר לחלוטין את התוסף הישן (Plugins > Deactivate > Delete) – השארתו בכונן עדיין מאפשרת ניצול ישיר של wp-content/plugins/old-plugin/exploit.php. בדוק בעמודי האתר שכל הפיצ'רים פועלים: טפסים, גלריה, checkout. אם יש WooCommerce, השלם הזמנת בדיקה.

מעבר לעדכונים, מומלץ לאמץ "תוסף diet": פחות תוספים פעילים = פחות שטח תקיפה. עברו פעם ברבעון על רשימת התוספים, וכל תוסף שלא משמש כבר 6 חודשים – הסירו לחלוטין (לא רק deactivate). תוסף לא פעיל אבל שעדיין מותקן עם קבצים על הדיסק נחשב לפגיעות ידועה גם הוא, כי תוקף יכול להגיע לקובץ ה-PHP שלו ישירות דרך URL גם בלי שיהיה פעיל ב-WordPress. זוהי טעות אבטחה קלאסית שאודיט פעמים רבות לא תופס.