ה־AI עזר לחשוף פרצות קריטיות. מה בעל עסק צריך לבדוק באתר שלו?
פרצות PHP2Shell עלו היום בשיחה עם רואה חשבון שאני מלווה בנושאי AI. מה הבינה המלאכותית שינתה, ואיך מוודאים שחברת האחסון טיפלה בתשתית האתר שלכם?
בשיחה היום עם רואה חשבון שאני מלווה בנושאי בינה מלאכותית, עלה נושא פרצות האבטחה החדשות ב־PHP. השיחה הזאת ממחישה איך התפתחויות ב־AI מגיעות גם לשאלות היומיומיות של בעלי עסקים: מי אחראי על האתר שלי, האם צריך לעדכן משהו, ואיך יודעים שהטיפול הושלם?
במקרה הזה, יש פעולה שאפשר להתחיל בה כבר היום: לקבל מחברת האחסון אישור שהתיקון מותקן ופעיל באתר שלכם. כדי לדעת מה לבקש ממנה, כדאי להבין בקצרה מה קרה.
מה קרה, ולמי זה רלוונטי?
ב־21 באוקטובר 2026 פורסמו עדכוני חירום לשתי פרצות קריטיות ב־PHP, המכונות יחד PHP2Shell. בתנאים המתאימים, הן עלולות לאפשר לתוקף להריץ קוד בשרת בלי להתחבר לחשבון. מזהי הפרצות הם CVE2026109618 ו־CVE2026109619, ושתיהן דורגו בחומרה של 9.2 מתוך 10. הודעת PHP הרשמית, הסבר Automattic
PHP היא שפת תכנות שפועלת בשרת ומפעילה מערכות כמו WordPress, Drupal ו־Joomla. הפרצות נמצאות בתשתית הזאת, ולכן גם אתר שקוד היישום שלו תקין עלול להיפגע. המחקר של Wiz
התקלה קשורה לניהול זיכרון ולטיפול בשגיאות בתוך PHP. לבעל האתר אין צורך להבין את מנגנון הניצול כדי לפעול; צריך לוודא שמי שמתחזק את השרת התקין את התיקון המתאים. פרטי הפרצה
מה הבינה המלאכותית שינתה כאן?
Wiz מדווחת שהשתמשה ב־Gemini 4 Argon וב־GPT5.6 Sol במחקר, בפיתוח הוכחות ניצול ובבדיקת התיקון. OpenAI מדווחת שגם Calif גילתה פרצה בעזרת GPT5.6 Sol במסגרת תוכנית המחקר שלה. אלה דיווחים של הגופים שהשתתפו במחקר, ולא השוואה עצמאית בין המודלים. Wiz, OpenAI
יש כאן פרט שמוסיף עומק לסיפור: קרן PHP מציינת שסימנים לבעיה שמאחורי אחת הפרצות נמצאו כבר ב־2024. באותו שלב לא הוכחה דרך מעשית להרצת קוד מרחוק, והתיקון הסתבך בשאלות של תאימות, ביצועים ומשאבים. דיווחי המחקר שהגיעו באוגוסט 2026 הבהירו את מלוא ההשפעה. ההסבר של קרן PHP
מבחינתי, זה הלקח לבעלי עסקים: AI יכול לעזור לחוקרים לנתח חולשות מורכבות, ובאותה נשימה לקצר גם את הדרך של תוקפים לכלי תקיפה. היכולת של העסק להגיב תלויה בכך שיש מי שמקבל את ההתראה, מבין אם היא רלוונטית ומבצע את העדכון. זו גם הסיבה ש־AWS ממליצה למדוד את זמן התגובה לפרצות קריטיות במערכות חשופות לאינטרנט בשעות. הדיווח וההמלצות של AWS
למה עדכון וורדפרס לא סוגר את הפער?
וורדפרס ו־PHP הן שכבות שונות. עדכון וורדפרס, התבנית או התוספים מטפל בתוכנת האתר; את הפרצות האלה צריך לתקן ב־PHP שמפעילה אותו. Automattic מדגישה זאת במפורש וממליצה לבקש מספק האחסון אישור שהעדכון הוחל. הנחיות Automattic
מה לבדוק עכשיו באתר שלכם
בוורדפרס אפשר לראות את גרסת PHP תחת כלים ← בריאות האתר ← מידע ← שרת. זו בדיקה ראשונית שימושית; היא אינה בדיקה אם האתר נפרץ. הוראות הבדיקה של WooCommerce
אלה גרסאות התיקון הרשמיות שפורסמו ב־21 באוקטובר, לכל אחד מהענפים הנתמכים. יש להתקין את גרסת התיקון בענף הרלוונטי, או גרסה חדשה יותר הכוללת אותו. הודעת העדכון
| ענף PHP | גרסת התיקון | | | | | 8.5 | 8.5.12 | | 8.4 | 8.4.27 | | 8.3 | 8.3.36 | | 8.2 | 8.2.35 |
יש סייג חשוב: ספקי הפצות עשויים לשלב את התיקון גם בגרסאות ותיקות. Ubuntu כבר פרסמה חבילות כאלה, בהתאם למסלול התמיכה. לכן מספר הגרסה לבדו לא תמיד מספיק: בקשו את מספר החבילה המתוקנת או את הודעת האבטחה של הספק, ואישור שהשירותים הרלוונטיים הופעלו מחדש. הנחיות Ubuntu
אם האתר שלכם רץ על PHP 8.1 או גרסה ישנה יותר, בדקו מול הספק מהו מסלול התמיכה ותכננו מעבר לענף נתמך. גם התמיכה של צוות PHP בענף 8.2 מסתיימת ב־31 בדצמבר 2026. מדיניות התמיכה של PHP
הודעה מוכנה לחברת האחסון
שלום, אבקש לבדוק את האתר בכתובת ביחס לפרצות PHP2Shell, שמזהיהן CVE2026109618 ו־CVE2026109619. איזו גרסת PHP וחבילת תוכנה משרתות אותו בפועל? האם הותקן תיקון לשתי הפרצות, באיזה מועד, והאם השירותים הרלוונטיים הופעלו מחדש? אם הוחל תיקון על גרסה ותיקה, אשמח להפניה להודעת האבטחה המתאימה.
לפני מעבר לענף PHP חדש, דאגו לגיבוי של קובצי האתר ומסד הנתונים ולבדיקת תאימות. אחרי המעבר, בדקו את הפעולות שהעסק תלוי בהן: טפסים, התחברות ורכישה, לפי סוג האתר. הנחיות ההכנה של WooCommerce
אם אי אפשר להתקין תיקון מיד, בקשו מהספק להגדיר הגנות זמניות. Cloudflare פרסמה הגנות ייעודיות בחומת האש שלה, ובמקביל קוראת ללקוחות לעדכן את PHP. ההגנות האלה אינן תחליף לתיקון בשרת. הודעת Cloudflare
איך יודעים שהטיפול הושלם?
AWS דיווחה על ניסיון ניצול שנקלט במלכודות התקיפה שלה כבר ב־17 באוקטובר. היא מציינת שלא ברור אם הניסיונות שתיעדה לפני הפרסום היו מצליחים במערכות אמיתיות. זה מצדיק טיפול מהיר, אך אינו מוכיח שאתר מסוים נפרץ. אם יש חשד לפגיעה, בקשו ממי שמנהל את השרת לבדוק אותו. הדיווח של AWS
כדי לסגור את הטיפול בפרצות האלה, בקשו אישור שהתיקון פעיל בסביבה שמשרתת את האתר שלכם ובדקו שהפעולות החשובות בו עובדות. השיחה עם רואה החשבון הזכירה לי עד כמה שאלות על AI מגיעות מהר לאחריות היומיומית על העסק. במקרה הזה, הצעד הבא הוא הודעה אחת מסודרת למי שמנהל את האחסון.
המידע והגרסאות במאמר נבדקו ב־22 באוקטובר 2026. יש לבדוק בהודעות הספק עדכונים מאוחרים יותר.