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

במהלך יולי 2026 פרסם מערך הסייבר הלאומי התראה נוספת לציבור ולמנהלי אתרים בעקבות השחתת עשרות אתרי WordPress. האתרים שנפגעו פעלו על גבי תשתית בעלת מאפיינים משותפים שכללה WordPress, ‏PHP, ‏Nginx ו-MySQL.

ההתראה האחרונה אינה עומדת בפני עצמה. היא מגיעה בהמשך להתראה מקצועית שפרסם מערך הסייבר הלאומי כבר ב-10 ביוני 2026 תחת הכותרת "השחתת אתרים בסביבת WordPress". גם בהתראה זו דווח על פעילות השחתה של כמה עשרות אתרים ועל תשתית משותפת שכללה את אותם רכיבים. מערך הסייבר המליץ לעדכן את הפלטפורמה ואת רכיביה, להפעיל אימות רב־שלבי, לצמצם את החשיפה של ממשקי הניהול, להשתמש ב-WAF ולעקוב אחר פעילות חריגה בלוגים.

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

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

מאתר תדמית לחלק ממשטח התקיפה

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

אלא שמבחינת תוקף, אתר אינטרנט הוא מערכת מידע לכל דבר.

אתר WordPress (כמו כל אתר) עשוי להיות מחובר למסד נתונים, לטפסים, למערכת דיוור, ל־CRM, לשירותי סליקה, לכלי אנליטיקה, לממשקי API, לרכיבי ענן ולשירותים של ספקים חיצוניים. הוא כולל קוד, חשבונות משתמשים, הרשאות, קבצים ולעיתים גם מידע אישי או עסקי.

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

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

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

למה דווקא WordPress נמצאת על הכוונת?

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

הפופולריות מייצרת כדאיות לתוקפים

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

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

כל תוסף מרחיב את שטח התקיפה

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

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

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

האחריות מפוצלת בין מספר גורמים

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

כל אחד מניח שמישהו אחר מטפל באבטחה, אך בפועל:

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

אז למה ארגונים ממשיכים לבחור בפלטפורמת WordPress עבור האתרים שלהם?

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

גמישות ומהירות

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

קוד פתוח ומבחר ספקים

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

מערכת אקולוגית רחבה

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

זמינות של ידע ואנשי מקצוע

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

עלות ותועלת

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

לכן השאלה אינה רק "האם להשתמש ב-WordPress?", אלא האם הארגון מסוגל לנהל אותה באופן אחראי ומתמשך.

חטיבת מצודה והמעבר להגנה סקטוריאלית רחבה

ההתראות בנושא WordPress משתלבות בתפיסת ההגנה הרחבה של מערך הסייבר הלאומי ושל חטיבת מצודה.

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

בכנס INFOSEC | AI & Security, שנערך ב-12 ביולי 2026, השתתף יעקב אוזוחובסקי, ראש אגף הגנה סקטוריאלית ותמ"ק במערך הסייבר הלאומי. במסגרת הרצאת מערך הסייבר הוא התייחס, בין היתר, לחולשות באתרי WordPress, לסיכוני שרשרת האספקה, לתקיפת חברות הנדסה ואדריכלות, לצורך בתרגילי אבטחה ולאתגרי הבינה המלאכותית.

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

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

מתי WordPress מחייבת רמת הגנה גבוהה במיוחד?

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

יש להתייחס לאתר כאל נכס בסיכון גבוה יותר כאשר הוא כולל:

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

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

12 נקודות חולשה נפוצות באתרי WordPress

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

אלו 12 נקודות חולשה מרכזיות של כדאי WordPress להכיר:

1. תוספים וערכות עיצוב שאינם מעודכנים.
2. רכיבים נטושים או כאלה שאינם מתוחזקים עוד.
3. סיסמאות חלשות והיעדר אימות רב־שלבי.
4. הרשאות ניהול רחבות מדי למשתמשים ולספקים.
5. ממשק ניהול החשוף לכל האינטרנט.
6. גרסאות ישנות של WordPress, ‏PHP או רכיבי השרת.
7. קוד מותאם אישית שלא עבר בדיקות אבטחה.
8. ממשקי API שאינם מוגנים או מוגדרים כראוי.
9. טפסים ואפשרויות העלאת קבצים שאינם מאובטחים.
10. היעדר ניטור, לוגים והתראות על פעילות חריגה.
11. קובצי גיבוי, לוגים או קובצי הגדרות החשופים לגישה לא מורשית.
12. חיבורים לא מאובטחים למערכות ארגוניות ולספקי צד שלישי.

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

12 צעדים להגברת האבטחה באתר WordPress

1. הגדירו בעל אחריות

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

2. מפו את כל הרכיבים

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

3. עדכנו את כל שכבות המערכת

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

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

4. הסירו תוספים ורכיבים שאינם נחוצים

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

5. הפעילו MFA

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

6. הגבילו את הגישה לממשק הניהול

כאשר הדבר אפשרי, מומלץ להגביל את הגישה לממשק הניהול באמצעות VPN, ‏ZTNA או רשימות כתובות IP מורשות.

7. יישמו הרשאות מינימליות

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

8. הפעילו WAF והגנה מפני Brute Force

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

9. הקשיחו את השרת ואת מסד הנתונים

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

10. הפעילו לוגים וניטור

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

לוגים צריכים להישמר במקום מוגן ולהיבדק. באתר בעל חשיבות גבוהה ניתן לחבר אותם למערכת SIEM או לשירות SOC מנוהל.

11. גבו ובדקו שחזור

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

12. הכינו נוהל תגובה לאירוע

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

למה סריקת תוספים באתרי WordPress אינה מחליפה בדיקת חדירה אפליקטיביות?

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

אך כלי אוטומטי אינו מבין תמיד את ההקשר העסקי של האתר.

הוא עשוי שלא לזהות:

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

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

בדיקת חדירה לאתר או אפליקציה, מנסה לענות על שאלה רחבה יותר: מה תוקף יכול לעשות בפועל ומה תהיה ההשפעה על הארגון?

בדיקת חדירה משלימה את תהליך מיפוי הסיכונים

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

הבדיקה צריכה לכלול, בהתאם להיקף ולסיכון:

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

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

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

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

האם נכון להמשיך לבחור ב-WordPress?

כן. עבור ארגונים רבים WordPress עדיין יכולה להיות בחירה עסקית וטכנולוגית נכונה.

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

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

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

מה ניתן ללמוד מהתראות יוני ויולי של אגף הסייבר, בנושא אבטחת מידע לאתרי WP?

ההתראה הרשמית מיוני והפרסום החוזר ביולי של אגף הסייבר הלאומי, אינם קריאה להפסיק להשתמש ב-WordPress. הם קריאה לשנות את אופן החשיבה.

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

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

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

כיצד אנחנו באינפוגארד נכנסים לתמונה?

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

השירותים שלנו כוללים:

• בדיקות חדירה לאתרי אינטרנט
• בדיקות חדירה לאפליקציות
• מבחן חדירה תשתיתי.
• בדיקות API.
• סריקות וניהול חולשות.
• סקרי סיכונים וסקרי פערים.
• בדיקות ספקים ושרשרת אספקה.
• ליווי בתהליכי הקשחה ותיקון.
• בדיקות אימות לאחר תיקון.
• ניטור SIEM ו-SOC מנוהל.
• שירותים מקצועיים וייעוץ במיקור חוץ:
  • CISO – מנהל אבטחת מידע
  • GRC – ממשל, ניהול סיכונים, רגולציה ותקינה
  • DPO – ניהול הגנת הפרטיות במיקור חוץ
  • SOC מנוהל
  • יעוץ סייבר ואבטחת מידע אסטרטגי

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

מנהלים אתר WordPress?

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

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

מאמרים קשורים באתר אינפוגארד

• חוק הגנת הסייבר הלאומי: 10 דברים שכל ארגון בישראל חייב לדעת
• חוק הגנת הסייבר הלאומי: השפעת הרפורמה על הנהלות, CISO ו־CIO
• דוח מבקר המדינה 2026: פערי הסייבר ברשויות המקומיות
• מבדקי חדירה שמגלים פרצות לפני התוקפים
• מבדק חדירה אפליקטיבי: אבן יסוד בחוסן הסייבר הארגוני
• סקר סיכוני אבטחת מידע: מיפוי ותעדוף פערי ההגנה
• סקר פערים באבטחת מידע וסייבר

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו בא להחליף ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי. כל ארגון נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים.
המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב אבטחת מידע, סייבר ומנהל השיווק של קבוצת חברות עידור (Messagent, Infoguard, Idornext).